Road to Elm 1.0(elm-lang.org) |
Road to Elm 1.0(elm-lang.org) |
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.
I love Elm, and I love the community, but I feel a little gaslit here.
I have worked at a few elm places, there is always a dict-for-everything dependency or local implementation.
The language is alright.
With all due respect, not everyone is afflicted with the lack of care sufficient to allow them to launch vibe coded apps as low quality as https://podnami.com. Considered technology choices are one such aspect of the practice of caring about what you're building.
Your argument is a mirror of the snark question "why don't LLMs write in assembly?" for those not looking at the output at all.
But I agree with you that the current solutions for Set/Dict all have one problem or another: You can use elm-sorter-experiment [1] but then you are writing a sort function and passing it around and maybe you don't want the overhead of that. You can switch to the Lamdera compiler and use containers [2] but then it's a different compiler and a you need to tweak your options slightly to compile an Elm project as an Elm project in it and it could get out of sync with the Elm compiler (extremely unlikely though). You can use any of the list/dict implementations that are really just lists with O(n) everything under the hood. So maybe this hashable type is going to make things better, idk.
[0] https://github.com/elm/compiler/issues/774#issuecomment-3472...
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.
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.
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.
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.
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:
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.
[0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826
In his talk, Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8, he does reveal a peek at what he's been working on for the past seven years: a query language with functional ideas applied to them.
He points at the boundaries in web apps that typically destroys type information: - language <-> storage - storage <-> wire
What if we could preserve the type information across these boundaries? What would that buy us? One answer he had was easier migrations. They'd just be a type diff, rather than hand-written SQL.
So I think the right question is, can we infer what Acadia is going to be like given the changes he's shipping with Elm? What does incremental compilation give query languages?
Considering Elm's history, why should anyone trust that Arcadia won't work out the same?
No matter how good his ideas are, if Arcadia doesn't have a more future-proof community-focused development model nobody will adopt it. At best it'll end up being "the project that inspired XYZ".
Evan might think it is about the Next Big Thing, and he might even be right, but after Elm will the world care enough to listen?
Localization is done using one big record for each language, that I just pass into each part of the aplication that uses strings. It's very convenient cause I can use simple functions in the record where they make sense for plurals and special cases in different langauges
Accessiblity is achieved with a combination of good html, ports and in some complicated cases (autocomplete-typeahead) - web components
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.
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.
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.
What is your app? Is it intended for personal use, or commercial?
You are definitely welcome to use my app, it is a music generation and education website! Monic Theory can be found here :)
I have little personal opinion on the state of Elm in prod (the little front end I do is as boring as it gets), but I’m glad to hear the language is still active.
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.
Also, if you ever had to refactor anything, there is no language in the world that makes it as easy to change things.
Hope to see more releases in the future.
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.
I can appreciate even more now why Elm is so opinionated. As much as Elm is a unique technical, research language, it is a huge cultural change, and I think that is why so many people left. Allowing libraries to be thin wrapper over ports is one example that goes completely against the Elm philosophy.
I'm happy to see Elm is still around, and I hope one day people will see more value in it.
0.19.2 Faster builds, and the Road to Elm 1.0 Jul 2026
0.19.1 Friendly syntax hints, faster builds Oct 2019
Everything which could've been said has been said a dozen times already. People have moved on, and Elm is mostly remembered as one of the web's greatest front-end could-have-beens.
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.
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.
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
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.
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.
Almost all of it? Meanwhile Elm had extremely painful "Evan knows best" breaking changes that all but killed it and any momentum it once had
Today's Elm toolchain is the Elm toolchain of 6 years ago!
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.
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.
This sounds like evaporative cooling.
https://lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-co...
But you're missing the vibe at the time: You would get downvoted and argued with if you tried to say that it was one person's hobby language. It was supposed to be a big movement and the next big thing in FE development. People would argue that it was production ready.
You can even see a lot of those comments in this thread.
I understand that defaults matter and that can have a large impact on the flow of libraries and code and stuff... my point is more, if you've got production code bases on this language, or at least, did 6 years ago, why so helpless? Nothing makes the point that an open source project can't dictate to its customers like the customers taking the "open source" part seriously.
I don't actually expect that to "work". What I expect to happen is that in the second-order effects that it would resolve this matter one way or the other once and for all. Either the core language realizes they need to accept the change, or the community works around the blocker, or the core language goes closed source and removes all doubt and people can move on, including their production services.
I'm interested in looking at more commercial products made in Rust, they tend to be far more polished than what I can stumble upon in Github (and are thus a nice showcase of what a bit of polish can do for these frameworks).
First, the comparison is perfectly fair. Elm 0.19.1, 6 years ago/0.19.2 today, React 16.1 6 years ago/19.2 today. Literally identical conditions. What is unfair? Which required app developers to do more work? Which saw more security issues among its releases?
Second, not needing updates for 6 years, and having zero security holes in that time, is the definition of stability. This isn’t really a matter of opinion or preference.
I do see the appeal in other frameworks (ecosystem size, easier to find devs), but the appeal of Elm truly is stability. And it really is that much better than nearly everything else that runs in the browser, in that regard.
No framework that allow you to use actual JS (or “transpiles” but gives you the full JS API, like Coffee/TypeScript), will ever offer the level of stability Elm offers (aside from maybe the web standard APIs on which Elm is narrowly built).
Byte encoder/decoder in Elm are opaque, so their implementation is hidden. A smart compiler, such as the one I am writing, can take advantage of that with compiler intrinsics that replace the implementation with something that the compiler itself optimizes.
Mostly the compiler was fine, we could do with some bug fixes in core packages - not many, but there are a small number of long time bugs that should really be sorted.
It's a little tricky though, because the comment you were replying to was talking about the lack of updates. And in that sense, Elm is now very stable - no breaking changes (or any changes at all!) in seven years and counting.
(Although, for all the complaints about the React ecosystem: you can still write class-style React components, even though they were effectively deprecated when hooks were introduced just over seven years ago.)
OTOH, we have this blog post suggesting development on Elm is kicking up again. Which means more breaking changes might be incoming.
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.
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.
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.
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
I encourage you to read the whole thing, but the standout quote for me is near the end:
> One thing I learned from discovering The Elm Architecture is that it is really lovely to be able to show up in any codebase and know what is going on. I think custom operators detract from that enough that they are not worth it for the whole ecosystem, even if they are great for specific individuals.
Having talked to people at work who had to remove custom operators when they upgraded from 0.18 to 0.19, they initially didn't love dropping them, but getting rid of the syntax cliff for new hires at the expense of terseness for the old hands was a decent tradeoff. Personally, I find it can be easy in an ML family language to get a bit wrapped around the axle trying to write the most terse, pointfree implementation of something.
The price for that is verbosity. What in other languages are hidden behind async and complicated libraries in Elm has to be done explicitly resulting in boilerplate. But that is never a problem for LLMs.
Then Elm compiler has one of the best error messages. This helps agents a lot.
Then Time Machine debugger is another big help for agents as they have access to the full execution trace of the program. The trace is much smaller than would be necessary for other languages and typically fits into content window.
But does the neural net ;)
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
I remember when Rich Hickey was asked "what feature of Clojure you regret and would like to remove?", he said: "None. Doing that would break stuff for people".
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.
Obviously not, but for a short while it felt like Elm evangelization was everywhere.
Ironically, the small group pushing it so hard at the company I was with at the time were arguing that it was very stable and production ready, despite being pre-1.0.
That argument switched for the 0.19 release, when it was argued that it was still early and changing a lot.
The argument switched again when they didn't make any progress for 7 years, which was supposed to be a sign that it was highly stable and mature.
> There's room for projects like Elm. Not every PL has to meet the demands of every single non paying user of the community.
Fully agree, but there's also room for opinions of people using the project. When a project encourages adoption and then pulls the rug out from under actual users, it's also okay for those users to be upset.
That's one thing the Elm project disagreed with. They had drama where even contributors were being handed 7-day bans for innocuous things like talking about native modules after the decision had been made to move away from them. Their subreddit was the kind of place ruled with an iron fist where any post that wasn't completely Elm-positive would be disappeared. There wasn't any room for disagreement in the Elm community and it partially collapsed on them when they pushed it too far.
Even if there had just been incremental bug fixes, I suspect between some and most people would have gotten over it, but seven years of silence is a very long time- long enough for an entire generation of new developers to start calling themselves seniors knowing only that Elm has stalled and shouldn't be used, because the controlling developers are unreliable and prone to giving the appearance of abandoning the language.
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.
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 a tradeoff, sure. But this way, Elm didn't become just another "JavaScript with better syntax".
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.
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
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!
People are welcome to their opinions, but I don't see a rug pull, I see a grad student who created a project that people enjoyed and a few companies offered to fund. Evan clearly wanted to maintain control over direction and stepping away from open source is completely acceptable and not uncommon for the very reasons on display here. People have completely unreasonable expectations from maintainers of free software.