At the time, I didn't think much of it -- I was probably busy learning React and JavaScript and yada yada for employment purposes.
Now, having spent some time in industry and having used some gargantuan web frameworks, I find myself missing Elm. MVC in Elm is wonderfully straight-forward and easy to reason about.
Congrats on the road to 1.0! Glad to see Elm still active all these years later.
Then the 0.18 to 0.19 Elm drama happened: The core team restricted the ability for users to do any native JavaScript interop, which broke every Elm app that needed any functionality that wasn’t in the core library.
It split the Elm fans into two groups: Those who were upset that they had invested in a language that now pulled the rug out from under them, and those who were true believers who told us that they trusted the Elm team’s decisions and we all needed to chill out and wait for them to address our needs, which they thought would happen soon. That was 7 years ago. There were some attempts to spin the lack of updates as “Look how mature and stable it is!” but you don’t have to look very deep to see that they just stopped working on it.
Last time I went back to look at it there were several Elm forks, some maintained by former members of the Elm core team that were more active but never caught on. With the way the core team broke important functionality, ignored the user base, and then abandoned the project for years there is no way I would ever allow this near a production website. I know that will earn me some downvotes from the die-hard Elm fans, but I think it’s important context for anyone who finds themself in a situation where Elm is being proposed for an internal project. It was always interesting as an experimental niche framework, but not as something I’d ever want near a product that I had to maintain. Especially not something that had to survive across developer turnover when your company’s main Elm proponent left and the language was abandoned for years.
It sounds like evaporative cooling.
https://lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-co...
But then you see stuff like this https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
The author is very charitable in their description of the Elm Core teams actions in these interactions, but you read it and they come off entirely unaccountable and dismissive. If they want to make a purely functional language locked down, you really should be upfront that they don't have time to make sure basic parts of the web ecosystem are arbitrarily locked off like i18n until they decide users of their langauge are permitted to use it after ruling out any suggestion it doesn't undermine the purity they were going for.
https://discourse.elm-lang.org/t/bindings-for-intl/1264
Gonna be honest, really got the impression the maintainer here couldn't be stuffed looking to it, and wasn't personally impacted and largely didn't give a shit. Proceeds to run off some bullshit to dismiss the issue entirely about it being too risky (he had better things to do, and anyone he can delegate this too does too), the poster offers to do the work write a report, etc, etc. Then he's ghosted and for some reason the thread is shut after 10 days lol??? I guess giving him the dignity of a reply is out of the core teams hands because of how they arbitrarily configured their discourse.
Don't blame that dude for leaving Elm, glad I never made the mistake of wasting my time being dependent on its infantilizating runtime.
Look if you want to avoid being too coupled to the runtime your language exists in, sounds like a cool experiment, but maybe don't drag everyone along with you until you figure out the basic issues.
All that is 6 years ago hopefully they're more self aware.
The biggest thing for me from practical perspective was to "freeze" some pieces of DOM to be guaranteed to not change/re-created, so that it plays well with some external JS libraries expecting some nodes to not change and stay vanilla.
Another is ability to extend Elm's debugger to filter out big noisy data to keep it usable for our project.
Third is when your data is too big -- it just sometimes fails with "recursion limit" that's hard to debug due to the nature of the langauge.
Otherwise – it's a very beautiful little language that still feels quite modern and easy to work with IMO.
Though with the advent of LLMs it became very easy to spin up alternate backends for it, so it's very much alive outside of JS as well.
it taught me a lot of things - such as simplicity. when I ended up switching to react - redux was easy to pick up cz of elm.
sadly the ecosystem never grew. but oh man elm is nice & the apps were performant.
You won't understand why elm is simple until you actually use elm to the point of internal understanding. I think doing this is much harder nowadays given that most people would likely use an LLM to do most of the coding.