Comment by fbonetti
8 years ago
Elm is extremely opinionated and bottlenecked by one person. It’s great for the specific usecases it was designed for, but it gets tedious once you start interacting with external code and the outside world. The development cycle is slow and communication from the dev team is sparse. Some would argue that the slow deliberate, development pace is a good thing, but I was personally turned off by the fact that compiler bugs (and even documentation spelling mistakes) would stay open for months or years.
I know somebody is going to jump in and tell me I’m wrong, that they’re using Elm in production and it’s the best, etc. This is my personal experience from using Elm on several side projects and also in production at my last job.
If your opinion lines up with whatever opinionated tool you use, you won't experience friction and will perceive the tool as aiding your work. It's not rocket surgery.
It was the same thing when Ruby on Rails hit it big; some people swore by it and others detested it. It's like having a car that will only turn left, as long as you need to go left the car is perfect for you.
I appreciate you sharing your experience. I think point you raised are valid.
Elm works for me and makes me happy. I couldn't ask for more. Any perceived slowness in initial development is gained later by very solid foundation on which I work. Again, all you said is true.
Elm actually means Elm + JS.
Given
1) The language development pace (localStorage does not have an Elm equivalent, let alone service workers, etc)
and
2) The Elm ecosystem is very closed and only one person can actually release powerful libraries in the blessed package manager.
Make it so that Elm will still not be able to do everything we need it to to write an SPA in 5 years without javascript on the side.