> > First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case.
> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.
So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time.
I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")
> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.
So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.