Considering JS graveyards, I would have sworn that was 100% of frontend devs until now.
Considering JS graveyards, I would have sworn that was 100% of frontend devs until now.
I'm starting to think that there really are a lot of front-end devs who don't know anything but JavaScript.
Describing a situation as worse than it really is.
But again, what are the clear benefits for the customer of choosing Elm compared to the more popular choices in the market, given the (IMO significant) drawbacks of a niche language?
b) Immutability, strong type system and few language constructs make local reasoning very easy. Developers spend less time chasing bugs.
c) Easy to learn. In virtual all jobs that I've had as a frontend developer, there's always been something new to learn. I spent more time learning Ember than I did spend on learning Elm.
d) Less churn. Javascript and related frameworks are, to me at least, exhausting to stay up to date on. Elm changes at a much slower pace.
I think the technical reasoning is okayish, but from a business perspective I don't think the customer made a good choice.
Go on then. ;)
- Better tooling - Easier to work with existing javascript code - Superset of javascript - Larger community and ecosystem - More developers are familiar with it - Easy Server Side Rendering
In what way is the Typescript tooling better? i.e. what can you do with it you can’t do with Elm’s tooling?
Also I’m intrigued by the claim of “easier server side rendering” is it difficult to run Elm code on top of node.js?
Elm compiles faster, has better error messages, is a simpler language (so our apps tend to stay simple, so easier to pick up again after some time) and has less churn.
We have experience with other technologies, we just find Elm better :)
Other advantages: async is baked into the framework and isn't an afterthought like React. Immutability is standard and doesn't require a competing ecosystem of immutable datastructures like React. Also significantly smaller download sizes [1]
I also question that Javascript the language doesn't change: it's gone through several big language changes, and a growing number of devs wanted more changes, so stared writing in Typescript or Flow.
[1] https://elm-lang.org/news/small-assets-without-the-headache
From a business perspective, having 0 JS crashes or errors in production is nice. I say that as someone who works at a startup that switched to Elm in 2017 and have had that very experience.