Ask HN: Why or why not should I use Elm instead of vanilla JS?
I am a programming noob. Recently after learning about paradigms, I found the functional approach easier to grasp than OOP. I have been using Haskell and JS for learning primarily. So is there any reason to learn Elm? I know Elm is a domain specific language, but does it have any disadvantage that I should know of before starting with it?
2 comments
My experience, which is of course my experience, has been that programming languages built on JavaScript such as Elm and ClojureScript wound up being harder to learn than Vanilla JavaScript. The reason I think is that JavaScript programming is really two different things. There is the language, JavaScript and its syntax and semantics...this is where the differences between imperative and functional and object oriented techniques show up. Dynamic versus static typing and namespacing/modules also show up as differences between the languages.
The other JavaScript is the Browser/DOM API. This is not syntax and semantics. It is approximately function calls to a standard library. Elm and ClojureScript and TypeScript and what have you, may wrap this in a library or a different API. But, at least for me, this does not solve my problem of being unfamiliar with the underlying abstractions. Even worse, once I scratched the surface to learn an abstraction, for example Service Worker, I was on Mozilla Developer Network looking at JavaScript. Without understanding JavaScript, I gave up "official professional" documentation for ClojureScript or Elm "amateur" documentation of the underlying JavaScript abstraction.
Finally, my specific conclusion about Elm was that it is not worth my effort to keep up with breaking changes. Blog post code samples and tutorials seem to go out of date every few months. Not just a little, but irreparably out of date. If Elm ever stabilizes around a spec or something like a spec, I may take another look. But for me, it feels like a case of perfection as the enemy of excellence.
Good luck.
The other JavaScript is the Browser/DOM API. This is not syntax and semantics. It is approximately function calls to a standard library. Elm and ClojureScript and TypeScript and what have you, may wrap this in a library or a different API. But, at least for me, this does not solve my problem of being unfamiliar with the underlying abstractions. Even worse, once I scratched the surface to learn an abstraction, for example Service Worker, I was on Mozilla Developer Network looking at JavaScript. Without understanding JavaScript, I gave up "official professional" documentation for ClojureScript or Elm "amateur" documentation of the underlying JavaScript abstraction.
Finally, my specific conclusion about Elm was that it is not worth my effort to keep up with breaking changes. Blog post code samples and tutorials seem to go out of date every few months. Not just a little, but irreparably out of date. If Elm ever stabilizes around a spec or something like a spec, I may take another look. But for me, it feels like a case of perfection as the enemy of excellence.
Good luck.
I would say that you should consider using Elm instead of JS if you are building a web application and you care about reliability and maintainability.
With Elm you will have a ridiculously stronger guarantee that what you write won't break at runtime. The type system and compiler also allows you to refactor with confidence.
Vanilla JS, unless you write exhaustive unit tests, gives you neither of these benefits.
With Elm you will have a ridiculously stronger guarantee that what you write won't break at runtime. The type system and compiler also allows you to refactor with confidence.
Vanilla JS, unless you write exhaustive unit tests, gives you neither of these benefits.