Having basically written this same article but in 2016, I just don’t think Elm scales like people think it might. I’ve also had two different companies I worked for already where we ran into the limitations and needed hacks so dirty that rewrites were seen as more practical. Need synchronous native code? SoL. Do you have i18n and l10n considerations? There’s no good solution for you. Need a browser API not supported yet by the Elm team, good luck becoming anointed to the boy’s club gets access to solving your real world problems.
I feel Elm is best used as a tool to learn FP and has a lot of things to teach about design/architecture (we see TEA now used as an acronym all over because of the idea’s success), but it’s not the horse you should bet on when you can do TEA-style programming without all of the limitations; there are dozens of options now in many different languages, especially the purely functional languages.
Both of the following can be true at the same time:
Elm has flaws
Elm scales better than TypeScript
I’d say Elm’s downsides compared to TypeScript are more domain specific (e.g. no native i18n support) whereas TypeScript’s are more structural (e.g. npm vs Elm’s package manager). So how relevant those downsides are to you depends on your use cases.
At NoRedInk we’ve been extremely happy with Elm since 2015, but to be fair, we don’t do any i18n. Maybe if we did we’d be less happy with it.
Vendr is another company with 400K+ LoC Elm in production that powers their whole frontend with Elm, and has for years (they hosted the NYC Elm meetup pre-pandemic), and they use TypeScript on the backend, so they’re very aware of how the two stack up!
Maybe “might not scale for you” would be a more accurate phrasing depending on your product requirements. There is a subset of applications, even common ones like SPAs, where Elm be the easiest work with because of runtime being something you don’t need to think about. I still however stand by that that are quite a few sore spots that can be showstoppers for other applications.
I don’t think TypeScript vs. Elm is the only fair comparison though. There are good functional (and even TEA-like) frameworks that compile to JavaScript in PureScript, ReScript, derw, ClojureScript, Scala, F#, Haskell+GHCjs that are also worth considering and could cover those limitations. The package manager was mentioned, and it too has issues: working offline, private repositories, the freedom to host a packages not on Microsoft GitHub, dealing with versioning providing patches packages released for older version versions of the Elm compiler.
If I were put in a position to choose TypeScript or Elm though, even if I had to make some painful workarounds, I would absolutely choose Elm because TypeScript isn’t built for functional ergonomics and it’s by-design type system adherence to the goofiness of JavaScript make it awful and verbose to work with. I also wouldn’t be where I am without having chosen to invest time learning Elm.
A team in my company invested heavily in Go + Elm and created a cool open-source continuous integration server product called Vela. We need more people for that team.
There are some extensions such as Typescript which addresses some of these issues at the cost of flexibility. But then again, we still have null exceptions. We have the option of ignoring error handling.
I’ve read that TypeScript was originally null-unsafe, but the current language does a pretty good job of keeping NPEs at bay, unless you start abusing the “!” operator or turning off compiler safety flags.
Even without the safeties turned off you can run into problems, TypeScript’s types aren’t enforced. You can say that an API returns an object with a certain type, but that doesn’t mean it’s what you got. In Elm you can only use a value from outside the runtime after you’ve parsed it.
It’s certainly a tradeoff. On the one hand, you have TypeScript’s types as a contract. On the other, you have Elm’s moat, inside of which everything is 100% type safe but outside of which everything has to be either decoded (e.g. when fetching JSON over HTTP) or implemented as a web component (i.e. when you just want to build a little DOM/styling-heavy component).
I personally prefer Elm overall, but I’ve found TypeScript to be adequately safe for my day job (3D graphics + ecommerce), particularly when using tools to import GraphQL or OpenAPI schemas as TypeScript types. If I were working on a web app for a bank or some other project with an extraordinarily low tolerance for runtime exceptions, I would push harder for Elm.
Having basically written this same article but in 2016, I just don’t think Elm scales like people think it might. I’ve also had two different companies I worked for already where we ran into the limitations and needed hacks so dirty that rewrites were seen as more practical. Need synchronous native code? SoL. Do you have i18n and l10n considerations? There’s no good solution for you. Need a browser API not supported yet by the Elm team, good luck becoming anointed to the boy’s club gets access to solving your real world problems.
I feel Elm is best used as a tool to learn FP and has a lot of things to teach about design/architecture (we see TEA now used as an acronym all over because of the idea’s success), but it’s not the horse you should bet on when you can do TEA-style programming without all of the limitations; there are dozens of options now in many different languages, especially the purely functional languages.
Both of the following can be true at the same time:
I’d say Elm’s downsides compared to TypeScript are more domain specific (e.g. no native i18n support) whereas TypeScript’s are more structural (e.g. npm vs Elm’s package manager). So how relevant those downsides are to you depends on your use cases.
At NoRedInk we’ve been extremely happy with Elm since 2015, but to be fair, we don’t do any i18n. Maybe if we did we’d be less happy with it.
Vendr is another company with 400K+ LoC Elm in production that powers their whole frontend with Elm, and has for years (they hosted the NYC Elm meetup pre-pandemic), and they use TypeScript on the backend, so they’re very aware of how the two stack up!
Maybe “might not scale for you” would be a more accurate phrasing depending on your product requirements. There is a subset of applications, even common ones like SPAs, where Elm be the easiest work with because of runtime being something you don’t need to think about. I still however stand by that that are quite a few sore spots that can be showstoppers for other applications.
I don’t think TypeScript vs. Elm is the only fair comparison though. There are good functional (and even TEA-like) frameworks that compile to JavaScript in PureScript, ReScript, derw, ClojureScript, Scala, F#, Haskell+GHCjs that are also worth considering and could cover those limitations. The package manager was mentioned, and it too has issues: working offline, private repositories, the freedom to host a packages not on Microsoft GitHub, dealing with versioning providing patches packages released for older version versions of the Elm compiler.
If I were put in a position to choose TypeScript or Elm though, even if I had to make some painful workarounds, I would absolutely choose Elm because TypeScript isn’t built for functional ergonomics and it’s by-design type system adherence to the goofiness of JavaScript make it awful and verbose to work with. I also wouldn’t be where I am without having chosen to invest time learning Elm.
TEA ?
The Elm Architecture
A team in my company invested heavily in Go + Elm and created a cool open-source continuous integration server product called Vela. We need more people for that team.
I’ve read that TypeScript was originally null-unsafe, but the current language does a pretty good job of keeping NPEs at bay, unless you start abusing the “!” operator or turning off compiler safety flags.
Even without the safeties turned off you can run into problems, TypeScript’s types aren’t enforced. You can say that an API returns an object with a certain type, but that doesn’t mean it’s what you got. In Elm you can only use a value from outside the runtime after you’ve parsed it.
It’s certainly a tradeoff. On the one hand, you have TypeScript’s types as a contract. On the other, you have Elm’s moat, inside of which everything is 100% type safe but outside of which everything has to be either decoded (e.g. when fetching JSON over HTTP) or implemented as a web component (i.e. when you just want to build a little DOM/styling-heavy component).
I personally prefer Elm overall, but I’ve found TypeScript to be adequately safe for my day job (3D graphics + ecommerce), particularly when using tools to import GraphQL or OpenAPI schemas as TypeScript types. If I were working on a web app for a bank or some other project with an extraordinarily low tolerance for runtime exceptions, I would push harder for Elm.
A moat you can cross with a bridge and secure it with some guards, if only. Elm is a whole island, you need to build a port to get there.