I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
> 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.
Neither is even remotely as robust — let alone friendly — as Elm's type system.
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")
You're completely correct, though for whatever reason functional languages almost always have strong type systems.
It's remarkably useful so far. I feel like I have an extra level of protection compared to Ruby or Python.
My point was that 'untyped' should not be conflated with 'dynamically typed'. They're worlds apart.
Better than, say, assembly language.