There was a period where it was heavily evangelized. Many blog posts were written and talks given, and there was a lot of enthusiasm and adoption.
Then the author just kind of disappeared and the project stalled.
Which of course he had a right to do since it’s his project, but I think he should have set expectations better from the beginning.
The heavy evangelism helped spread the ideas, but also set up developers to feel blindsided and abandoned.
There was more to the story than that. They made some major breaking changes in v0.19 that broke a lot of apps and left no path for them to continue with Elm, then dug their heels in when the community protested.
If you had an app at your company that used the features they decided not to allow any more, you either had to start deciding which fork to follow or start planning to rewrite your app in something else.
That evangelism turned into an uncomfortable gaslighting where half of the community was trying to tell you that this change was what was best for the language and that you didn’t really need that feature anyway.
There were several forks but I don’t know if any got traction. It felt like an already small community was fracturing into even smaller communities right after alienating a lot of people.
https://discourse.elm-lang.org/t/native-code-in-0-19/826
Personally, I was sad to see signals and FRP go in 0.17
You can still indirectly call native JavaScript, in a message-passing kind of way (via Ports or custom elements) but these changes were still really disruptive to many codebases.
This "nobody is allowed to do this until Evan himself has made time to come up with a blessed solution" style of development left a lot of people quite disappointed. Elm was marketed quite heavily as the best thing since sliced bread and the future of front-end web development, but in reality it turned out to be just Evan's toy language which you could look at but weren't allowed to touch. Which is of course allowed, but it does rapidly kill any kind of community around it.
Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop.
But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port.
It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened.
It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
And the problem isn't just that sync interop was removed. That would've been fine. It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong.
Breakage is totally fine, I never expected anything different from Elm. But community-killing permanent core feature removal is a bit much, is it not?
I luckily never invested too deeply into the ecosystem so there wasn't a lot dor me to "learn", but it sure ruined any chances of me - and with me I bet a lot of other people - ever looking at an Elm 1.0 or Elm++, and considering the valuable insights gained from TEA that really is a shame.
I personally made the same decision. It became very clear to me that Elm was not the foundation for me to build a business on.
IIRC you couldn't, and would be banned on any channels for questioning decisions
This gives flashbacks of the last time I discussed this 7 years ago: Even trying to bring it up would bring denial that it was a problem. It was your fault for using it wrong. If you could demonstrate the cases where it continued to be a problem, it was still your fault for using the project.
Even the pre-1.0 projects I use that have breaking changes will announce a transition period and gradually deprecate APIs over several releases. Community feedback is monitored and the deprecated API may be kept longer than originally planned until suitable alternatives can be produced. Elm wouldn't even consider any of these.
The direction of the argument also changes based on the situation. When Elm was dropping breaking changes in 0.19 the story was that it's a fast changing pre-1.0 project and it was our fault for not expecting breaking changes.
Then they went 7 years without a release and the argument became that Elm was so stable that it was our fault for expecting updates to a mature and stable project.
But this change did more than break things. It meant people using Elm in production had to abandon it, nearly immediately, as all future work would first require them to port the whole stack, in one fell swoop, to Elm (and this was before tail recursion modulo cons was implemented, but recursion was forced).
Imagine if, in Rust's infancy, it decided to remove the C FFI with the argument that people should instead, naturally, rewrite that code in Rust. What would have happened? People would have abandoned it in droves, and it would have been essentially relegated to a research language, never again suited for prime time.
And -- oh, look what happened to Elm!
It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
It has enable me to port the small kernel now to C++ for an Elm to native compiler.
Also, if you really wanted to bypass it and have your own kernel, that was always possible and not hard to do. Even in 0.18 custom effects modules could not be shared on the official package site.
That may be true, but what would have been even better is never having the feature, as opposed to adding it, allowing many people to become dependent on it, and then taking it away. (Like everyone else, I'm not claiming Evan should not be able to make such changes -- just that making such changes will breed predictable resentment.)
> It kept the Elm kernel small and portable.
This is a good thing.
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
This is a bad thing, presented as a good thing. Boring as it may be, if wrapping an existing piece of working code does the job with no downsides then it's always better to do that than reimplement it for reimplementation's sake.
Writing everything yourself is not innovation. It's busy work.
Sure it's a good way to learn a language, but when you just want to build an app why would you build yet another searchable select when there are more than enough JS options already available....
It's vibe-coded (hmmm), Elm syntax, server-side, SSE, compiles to Go, Go FFI, TEA, web/cli/TUI/desktop targets, consistent Db, Ui - a lot of things to like if it all comes together.
The second nicest thing with Elm is the philosophy of if it compiles it works. And to be honest you can get that same feeling with most of Rust as well. Sadly not as much of a haskell feeling but at least it has a warm shadow of some of its functional ancestors.
Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.
The basic idea - all application state and view model creation is in Rust (compiled to Wasm). I'm using Rust not really for performance, but for its strong type system. Components are in TS but have a strict contract they can only accept plain input props and output events. Rust processes the events and ships a view model patch to TS.
This is not "Elm in Rust/TS" but it is definitely Elm inspired.
It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building.
But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every Elm user maintains their own compiler :). There are at least 6 of them (two more got announced in the last month, even as the community keeps shrinking).
So I'm glad Evan is now working towards 1.0. Maybe folks can call Elm "finished" and one of the successors can do the hard work of unifying some of the forks and growing the community.
Personally, the next time I'm looking for an Elm-like thing, I'm going to check out Gleam + Lustre. Seems to have a nice mix of maintainers that care about community and design. And it works on frontend + backend!