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!
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.
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.
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.
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
On the other hand, seven hears of absolutely nothing, then a small compiler performance bump, and calling it the "road to 1.0"? No offense, but why bother? She's dead, we've grieved, and we've long since moved on. Until there's something genuinely mindblowing to release, I don't think many people are going to care.
I once wrote a frontend webapp with Elm. And with backend server in Clojure, it made as much sense as Elm five years ago, right? :)
For the past two years I've instead used Yew, a rust crate for building UIs. It can look like react or like Elm, it's up to you for how you yews it ;0)
My latest app uses The Elm Architecture in Yew. It has been fantastic.
I think the biggest benefit Elm has over Yew is its access to the node js ecosystem through Port. You can interface with any npm package if you (or your AI) can write a port for it.
So far my best integration with yew dev has been using inline script tags (eek!) where I have to inject some external JS.
LLMs are surprisingly effective at helping you learn the "vibes" of making music and understanding various concepts.
Yes but no? It really just depends on the amount of elm in the training data and rlhf. I agree that structured frameworks/languages have codebases more similar to one another and that would ease generation. But that alone won't work and usually dev adoption is a total discourse per se
I noticed that coding agents seemed to get pretty good around 2025 Oct/Nov.
If it's improved? My experience with Nickel-lang (probably as not-in-training-data as Elm) is coding agents have improved with this compared to last time I tried.
There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
Elm's current story for interacting with the wider web ecosystem is "reinvent the wheel a dozen times by DIYing your own wrappers around literally everything". Fine for a trivial toy project, not fine for building production software.
I understand why they made those decisions, and each choice on its own is logical, but that doesn't make the combined outcome any better.
It's 2026, and I'm still using Elm for all the same reasons :)
As an added bonus, Claude seems to play very very nicely with Elm:
So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).
javascriptland really warps peoples minds on stability and project-liveness
If Elm's definition of stability is keeping bugs and runtime errors for years, then I'm glad I stopped using Elm long ago.
Not only were the issues unaddressed, but for the past years the PR got no human response. For instance this one¹ fixes infinite loops in the core. [¹]: https://github.com/elm/core/pull/1137
To be fair, Elm hasn't made it to 1.0 (yet). That's where languages should make breaking changes before being stuck with the flaws forever.
The Elm community (or those who remained anyway) has a very cult-like way of spinning the current status quo as being good for you, even if it’s not.
Removing native JavaScript interop in 0.19? They’re just making it more pure! Sorry your project had to become impossible to continue on Elm, but this is the price we pay for a leader with vision.
No appreciable updates or bug fixes for 7 years? That’s just stability! Look how stable and mature it is that it can go 7 years without a release!
If not, the expectations you and many have here seem pretty unreasonable. There's room for projects like Elm. Not every PL has to meet the demands of every single non paying user of the community.
I think the "Elm is stable not dead" seen from the few people that stuck around with Elm is largely cope for being stuck with an unmaintained language. Languages, like all other pieces of software need maintenance or they degrade in the world moving around it (e.g. there is/was no official aarch64 build of Elm in the period of non-maintenance).
I also would say that Elm is still largely unfit for most realistic production scenarios, unless you have the manpower to build everything from scratch, as interoperability with the outside web world (JS/TS) is an afterthough, and by some parts of the community not desired.
In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.
Elm served its purpose for me - an example of a small language with great tooling and error messages. And the strictness was helpful in learning to do things the "proper" way in the Elm model, even if I did reach for escape hatches in later projects. E.g. writing a notion-like application in Elm, I had to walk through my data twice - once to render it and another time to collect cache misses. With hyperapp, I broke purity a little and accumulated the information on the side.
I never used elm except for doing a tutorial, but lately I've built a full stack gleam app (using coding agents for the most part, with a lot of control in the beginning on the structure of the code) and have found that process works quite well
However, I feel people often miss the real value of a good DSL: it's not about the syntax, but about providing hardened semantics that can bolster or guarantee desired qualities. Elm, for instance, provides value insofar as it makes producing runtime exceptions significantly more difficult.
Personally, I hope languages like Lean, which provides exceptional support for creating DSLs within the language, renew interest in semantically sound DSLs, especially if we insist on using LLMs.
It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
I get that some people like stability, but that is quite different from going without updates for 6+ years.
Today's Elm toolchain is the Elm toolchain of 6 years ago!
[0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826