I think of Elm more as an incredibly influential research language these days.
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!
> Then the author just kind of disappeared and the project stalled.
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.
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.
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossible! If I recall correctly something similar happened to other core libraries.
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'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.
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.
I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it.
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 think you are taking the wrong lesson. The lesson is not "things make break." Many languages break things. Haskell has made it a feature, not a bug.
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.
Elm was better without custom kernel modules and sync JS-interop.
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.
> Elm was better without custom kernel modules and sync JS-interop.
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.
Custom kernel never was a feature the language had. It was an implementation detail that people discovered they could hack, but it was never meant as a feature.
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
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....
Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else).
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.
The nicest thing of Elm is how much it feels like Haskell. Have built some fun things with Elm years ago.
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.
These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org
I agree and I think the ideas in Elm are applicable in many other contexts. Adopting a new language is just hard, especially with larger teams. I ended up taking some of the ideas of Elm but implementing with Rust and TS - https://dave.tonge.org/articles/make-ts-boring/
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.
If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.
I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types).
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 project was dead. The previous release was 7 years ago, where it stopped because the creator (same as author of this announcement) stopped maintaining it and since the community hasn't progress beyond a BDFL-model that's where it died.
So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).
> your definition of dead is elms definition of stability
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
You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.
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".
> your definition of dead is elms definition of stability, I think :D haha
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!
I've just stated working around that time when the cult was active. And I think that is the correct term for it because other languages that have been praised to the same level (ruby, rust, haskell) actually have things to show for and not just simplistic functional programming
Were people forced to use elm prior to a 1.0 release or something? Is Evan being accused of baiting people with a lovely experience and then bailing? I'm not really familiar, so maybe the ball was dropped in some kind of contract I'm not aware of.
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.
> Were people forced to use elm prior to a 1.0 release or something?
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.
Well surely evangelization doesn't absolve a technical leader for choosing to rely on a BDFL project that's pre 1.0.
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.
Elm was very heavily evangelized for a while, and people were using it. Had there been a migration path through the breaking changes, it would have been a lot less disruptive.
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've head the displeasure of working with more than one Elm zealot in the past, and also allowed a service to make it into production (which was a huge disaster). Due to that, I know a lot more about Elm than I'd like to.
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.
This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable.
(And also arguably, for good or bad reasons, why it will never become mainstream).
I'm not deeply involved in the community, but I know people who were, and my understanding is the removal of custom infix operators lost a lot of community support. Very popular feature removed specifically because the creator of the language didn't like it, and despite large community cries for it to remain.
In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.
Not exactly removed, the feature was still there, but could be used only if your module was in Elm namespace (the compiler checked). It was kind of a "no soup for you" situation, which bothered me.
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’ve been using Elm professionally at a very profitable, lean company the last two years. (Didn’t know it coming in, but had enough React, Redux, and other experience to learn quickly.)
The Elm community would call this a feature. How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain?
It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
Oh yeah, no shade against the language itself. I had fun learning it and using it for some toy development years ago - and the TEA still exists in multiple library implementations. Just wild to see the creator of the language emerge from the fog like that.
Same, I basically assumed the community around it had died out. But i guess the sole maintainer/creator is still around.
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
I can understand why developers might not care for DSLs, especially when they force a choice between entirely different toolsets and toolchains.
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.
I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.
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.
This. Generating a frontend with guarantees can almost not be done with any other language. If you use the graphql module with code generation it's an absolute game changer. Every time I have Claude generate a moderately complex frontend in react I regret it sooner or later due to state issues and inconsistent behaviour. Not with elm. Everything that makes it difficult makes it perfect for ai.
Did the restrictions on JavaScript get resolved? IIRC, they made it so you had to use their “Ports” mechanism to interface with JavaScript, and you couldn’t write your own wrappers.
There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
And combined with its inability to provide mature native APIs and its hostility towards libraries containing ports, this essentially kills the language.
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.
You can also do lunatic things like overload the `Object` prototype and get synchronous FFI by encoding then decoding an object. I do this at work to get locale-aware sorting. I know you know this, but it'll be news to others in the thread.
Slightly important point: it's still safe FFI! Everything that crosses the JS/Elm boundary has to be encoded/decoded from serialized JS Objects. So it's hacky BUT it's not actually unsafe, which is kind of funny. I have an example where I use it to effect locale-aware sort. This repo is a benchmark test of that: https://github.com/perkee/elm-js-sort-ffi-speed-test/tree/ma...
About two years ago I was experimenting with ChatGPT vibecoding a snake game in the browser in elm, because elm is my favorite language. It was rough going and I concluded at the time that LLM‘s might kill elm. Today I use elm in production and LLMs are vastly better at it, and if anything I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now. It’s a simpler language than most, it’s stable, it has an opinionated architecture built into the language which causes most code bases to be very similar to one another
On that note, because of AI I've been more into music, bought a midi keyboard, got real DAW software setup. I've also finally built more and more with Rust, and have been reading more Rust docs. LLMs should never be an excuse not to learn the things you're using it for, those are the bad engineers. An LLM affords me the time to research and learn what it gave me so I can maintain it. It's easier to prompt about the problem if you understand it.
I do though I havent been blogging as much, its a blessing and a curse to have a SSG based blog. I would love to have an SSG engine that I can use remotely from anywhere, currently using Publii.
> I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now
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
That's not why Elm is an ideal language for LLMs: it's because, if it compiles, it's most likely working software. Agentic workflows have gotten significantly better over the last year, so LLMs using languages like Elm, Haskell, or even Rust have an amazing feedback loop where even lower quality models can keep trying until things compile.
can keep failing til you're tired of having the agent running in loops, as I said it doesn't matter, agent tools are more effective with models trained with a lot of elm examples
Yet Elm due to its simplicity does not need a lot of examples. Language itself is small and blessed way to architecture things consist of few patterns. Then things are composable. This is ideal for LLMs.
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.
Maybe it's improved, but I was very disappointed to find agents constantly tripping over significant white space with Elm (Claude Code). Always struck me as strange since they are very proficient with python... and Elm has been one of the most stable modern languages (so stable that people complain about it never changing!). I think the last time I tried was a year ago though, so I assume it has improved.
Good to know. I built https://github.com/pairshaped/hypertea to get some of Elm's safety in typescript while being easy for LLMs to use (this is basically just hyperapp in TS, with added elm-like guardrails). Maybe I'll go back to Elm now that LLMs are handling it better.
I don't think anyone complained about the language changing, it was a lack of trust in the language due to the compiler not getting any updates. You can still improve the compiler without having to change the language.
Yes. But that is about to change, and the compiler is now getting the updates it needs.
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.
> I think the last time I tried was a year ago though, so I assume it has improved.
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.
I started working with Elm in production again about a year ago and have bounced back and forth between codex and Claude code and haven’t noticed whitespace problems, so I would conclude it’s better but of course your mileage may vary
I was already working with elm (have been since Signals) and I was very disappointed in what agents (CC) produced. In contrast, I was pleased with the Rust code they produced.
I'm interested less in getting to Elm 1.0 than getting past Elm 0.19, which is the version that locked out all native modules that weren't officially blessed by Elm's author. Far as I can tell, that pretty well marked the end of Elm.
In Elm 0.19, they removed the ability for third party packages to provide native bindings for JavaScript APIs that the language or its official packages didn't yet support.[0] The only alternative proposed by Evan is to use ports, which are about as ergonomic as calling a function in a web worker.
there is also web components (best way to do a "copy this to clipboard" button in my experience) and secret back door synchronous FFI through overloading the Object prototype. In all cases the communication is gated through decoders/encoders that can fail; you can only pass serialized data across the boundary from JS to Elm.
The compiler has hard coded domains that control who can use certain features. For example, custom operators aren’t allowed, but Evan is able to use them.
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.
I think Evan's pointing at something, and everyone's looking at the finger. I don't think this is really about Elm at all, but the preparation for Acadia.
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?
> I don't think this is really about Elm at all, but the preparation for Arcadia.
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?
I can’t think of a worse announcement for your road to 1.0. Who cares? Without localization or accessibility support, it doesn’t make sense to call your UI framework production ready with a 1.0 version. I think limiting what third-party contributors can bridge from browser APIs killed Elm’s momentum for anything but toy projects. It now seems more like a sandbox for Evan to play around with compiler ideas than something meant for production use.
I don't think what you say is accurate. I maintain an Elm app and it is fully localized and I think it has a pretty good accessibility
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 one hand, it's good to see Evan's doing fine. He has some pretty good ideas about language development, and Elm has inspired quite a bunch of very interesting projects.
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.
There's a lot to love about Elm, and I've written quite a bit of production code with it starting around 0.18.0. But in 2026 I'm not sure why a company would newly choose a language that hasn't otherwise been updated in nearly 7 years.
Longstanding issues that prevent usage? Not for me and the projects I’ve been apart of. No doubt there are plenty of reported issues, and no doubt they truly negatively impact some users, but I would still much rather choose the usability and stability of Elm 0.19.1-2 than anything in the typescript ecosystem today
When I worked on an Elm app in 2020, my users reported compatibility issues with various browser extensions (e.g. Grammarly, 1Password). I personally would prioritize making my apps usable for my users over making the DX usable for myself, so I stopped using Elm for future projects.
Well, you're suggesting a reason to choose Elm is stability - a lack of breaking changes. But Elm is actually notorious for its wildly unpopular, dramatic, community-fracturing breaking changes. Backwards compatibility is not a concern for them.
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.
I agree that the stability is quite nice. But there are plenty of areas where the language could use some improvement - for instance, the ergonomics around writing nested Single Page Apps is pretty cumbersome.
We had some big Elm proponents who were trying hard to convince the company to use Elm, including doing proof of concept buildouts in Elm.
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 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.
We didn't tolerate it for main production projects.
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.
It's going to be hard to explain to future generations that the demand for computer-speakers was once such that sometimes they could even decide the language in which they spoke to the computer, and that really was a big deal back then because computers couldn't just switch back and forth like they can today.
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.
I don't know about Yew but I've been using Iced 0.14 which is also a Rust crate inspired by the Elm architecture. It seems like Yew is specifically geared towards web applications, which I suppose is in some ways closer to the original Elm project.
What is your app? Is it intended for personal use, or commercial?
Nice! I'm quite the beginner when it comes to music production and theory (took me a while to even figure out "Audition" means "Listen"), so I couldn't make full use of this site, but I like ideas presented in your about section. The website is quite functional, which is nice to see from a Rust base.
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).
I had dinner with Evan at Scala Days last year and had no idea who he was until he casually mentioned Elm. He is delightful and had some great insights on the philosophy behind Elm and on programming languages in general to share.
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.
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.
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.
I see all these people complaining about Elm limiting privileges to certain Github projects. A sensible complaint. But why hasn't anyone simply forked Elm, made the small tweak to make the check function return true or whatever, and offer that as a download/patch to the community?
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 remember using Elm in one of my gigs. After I left, the client hated me. Not to forget all the drama that it had before Covid. I really want this language to succeed, but its bdfl is trying hard....
I hope to see progress in the future. I loved Elm and it made me a better programmer. Things changed a lot since then, but beauty of Elm is not matched by any language.
Also, if you ever had to refactor anything, there is no language in the world that makes it as easy to change things.
We're now migrating to React, but have some very large Elm projects still in prod.
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 worked on an Elm project professionally for a few years, and I just finished upgrading an old React app to version 19 on my own, which took a greater part of a year.
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.
For me the problem wasn’t the cultural change, it was depending on language whose leadership doesn’t seem to give a fuck about real-world problems the language users face in production. And then being constantly gaslighted about it on the official channels like the language forum.
Am I right in thinking that Elm has lost a lot of momentum? It is barely discussed on HN anymore and I wonder if the releases/news have a lot to do with it. Look at the time between releases:
0.19.2 Faster builds, and the Road to Elm 1.0 Jul 2026
0.19.1 Friendly syntax hints, faster builds Oct 2019
There's very little left to discuss, unfortunately. The 0.19 release included some extremely controversial changes. The core Elm team responded by killing all discussion of it and (to the outside world) abandoning the project, the Elm community responded by scattering to a dozen forks and reimplementations of The Elm Architecture.
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.
Back in my undergrad, I took a Functional Programming class taught in Elm. It was primarily about functional data structures, but we also got to build a web app using Elm towards the end.
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.
The Elm Architecture[1] makes it easy to reason about code. You render the current state. You create a new state by applying a message to the current state.
You really need to use it to see the light. It's like reading about programming and actually programming. You don't understand programming until you actually program.
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 many casualties in that period of groping around in functional programming concepts for the frontend from, like, 2014 - 2020 or so. But a lot of good things endured from that at least.
Haha we may have worked together. Equatable has been a theoretically huge, actually OK hole in my opinion because it _can_ lead to runtime crashes but never has in any code I've written (\_ -> () == \_ -> () is a runtime crash). So I'm glad to see something more robust than "just don't do that." And "hashable" as the real thing you need to implement Set/Dict is a good idea imo. I'm sympathetic to keeping "comparable" closed and even smaller than it is for the reasons in this discussion [0]. In my perfect world, String would not be comparable as-is because string comparison should be locale dependent. Right now string comparison just ends up using JS's < operator which compares as a list of code units. So I'd like to be able to have a Set of Strings or a Dict with String keys without having the footgun of being able to think that I've alphabetized a list when all I've done is annoy a user by putting Área after Zapato and not between Azul and Barcelona.
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.
Professional diligence, perhaps? A desire to not be blindly led into the kind of narrow, often first-party stack which is so often proposed by Claude Code?
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.
Stronger foundation (as to mean better tested), less accidental complexity of reinventing everything, transferability of knowledge, easier onboarding and review of changes.
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.
Statically typed languages with compiler hints are the absolute best languages for LLM's to work with. Successful compilation is incredible feedback, and it basically just means that there is a higher chance that the feature is in a complete and working state at the end of each agent iteration.
If anything, LLMs make it easier to choose from a broad set of options. The tradeoffs are the same as pre-LLM days, but the learning curve is more favorable.
I think of Elm more as an incredibly influential research language these days.
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!
Yeah Elm has had a very strange arc, but I think calling it a research language is right.
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.
> Then the author just kind of disappeared and the project stalled.
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.
For a non-fork that has appeared recently, Sky: https://news.ycombinator.com/item?id=47662116
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.
What feature is that?
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossible! If I recall correctly something similar happened to other core libraries.
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.
[0]: https://github.com/elm-lang/websocket
This really overstates the problem and situation.
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'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.
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.
I'm not mad, I'm disappointed. Elm was quite promising prior to this, but 0.19 essentially killed it.
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.
Don't fret it. Many of us were in the same boat. Evan can do whatever he wants, but we can also call it out when it's wrong.
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.
> Evan can do whatever he wants, but we can also call it out when it's wrong.
IIRC you couldn't, and would be banned on any channels for questioning decisions
We've been calling him out for YEARS. Half the comments on this article are people calling him out. He can't escape it.
I think you are taking the wrong lesson. The lesson is not "things make break." Many languages break things. Haskell has made it a feature, not a bug.
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!
Elm was better without custom kernel modules and sync JS-interop.
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.
> Elm was better without custom kernel modules and sync JS-interop.
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.
Custom kernel never was a feature the language had. It was an implementation detail that people discovered they could hack, but it was never meant as a feature.
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
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....
[dead]
It doesn't matter how good a language is in theory if people using it for practical purposes end up having to abandon it.
Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else).
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.
One form of JavaScript interop. Instead of being able to write bindings directly to native code, you had to pass messages through "ports" instead.
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
https://elm-lang.org/news/farewell-to-frp
The nicest thing of Elm is how much it feels like Haskell. Have built some fun things with Elm years ago.
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 feels like a simplified Haskell which can handle a single space problem.
These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org
I agree and I think the ideas in Elm are applicable in many other contexts. Adopting a new language is just hard, especially with larger teams. I ended up taking some of the ideas of Elm but implementing with Rust and TS - https://dave.tonge.org/articles/make-ts-boring/
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.
For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.
Never heard of it and I am glad you mentioned it, thanks. Already homepage and examples look familiar and welcoming.
If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.
I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types).
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.
Can you share your git repo link?
I think because it's so nice, that's why people are disappointed in it's stagnation. But the stagnation is partly why it's so nice!
Oh my God, I had no idea this project was still alive. I don't mean to throw any shade but I had assumed that the lid was on this turkey.
The project was dead. The previous release was 7 years ago, where it stopped because the creator (same as author of this announcement) stopped maintaining it and since the community hasn't progress beyond a BDFL-model that's where it died.
So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).
Not dead, Evan was working on Acadia (elm on db) which is about to be released, to make Elm development and funding more sustentable.
your definition of dead is elms definition of stability, I think :D haha
javascriptland really warps peoples minds on stability and project-liveness
> your definition of dead is elms definition of stability
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
You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.
> ClojureScript doesn’t do that.
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".
> I mean Elm has removed features breaking compat
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.
... which is totally fine, but that's also why you can hardly call it "stable".
> your definition of dead is elms definition of stability, I think :D haha
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!
I've just stated working around that time when the cult was active. And I think that is the correct term for it because other languages that have been praised to the same level (ruby, rust, haskell) actually have things to show for and not just simplistic functional programming
Were people forced to use elm prior to a 1.0 release or something? Is Evan being accused of baiting people with a lovely experience and then bailing? I'm not really familiar, so maybe the ball was dropped in some kind of contract I'm not aware of.
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.
> Were people forced to use elm prior to a 1.0 release or something?
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.
Well surely evangelization doesn't absolve a technical leader for choosing to rely on a BDFL project that's pre 1.0.
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.
Elm was very heavily evangelized for a while, and people were using it. Had there been a migration path through the breaking changes, it would have been a lot less disruptive.
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've head the displeasure of working with more than one Elm zealot in the past, and also allowed a service to make it into production (which was a huge disaster). Due to that, I know a lot more about Elm than I'd like to.
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.
This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable. (And also arguably, for good or bad reasons, why it will never become mainstream).
I'm not deeply involved in the community, but I know people who were, and my understanding is the removal of custom infix operators lost a lot of community support. Very popular feature removed specifically because the creator of the language didn't like it, and despite large community cries for it to remain.
In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.
Not exactly removed, the feature was still there, but could be used only if your module was in Elm namespace (the compiler checked). It was kind of a "no soup for you" situation, which bothered me.
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'm glad it's back. Elm had such a remarkable elegance I was always rooting for it.
I’ve been using Elm professionally at a very profitable, lean company the last two years. (Didn’t know it coming in, but had enough React, Redux, and other experience to learn quickly.) The Elm community would call this a feature. How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain?
It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
Any code you wrote on a React version from 6 years ago will still work the same on that React version today. Let's make that a fair comparison.
I get that some people like stability, but that is quite different from going without updates for 6+ years.
> How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain
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
> How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain?
Today's Elm toolchain is the Elm toolchain of 6 years ago!
Oh yeah, no shade against the language itself. I had fun learning it and using it for some toy development years ago - and the TEA still exists in multiple library implementations. Just wild to see the creator of the language emerge from the fog like that.
Same, I basically assumed the community around it had died out. But i guess the sole maintainer/creator is still around.
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
I know right. I’m glad DSLs have fallen out of fashion. Just use the platform.
I can understand why developers might not care for DSLs, especially when they force a choice between entirely different toolsets and toolchains.
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.
I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.
And then there are sealed DSLs...
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.
wow careful, this turkey still has some kick left in it!
I wrote a thing in 2023 about why I'm still using Elm:
https://taylor.town/elm-2023
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:
https://taylor.town/diggit-000
This. Generating a frontend with guarantees can almost not be done with any other language. If you use the graphql module with code generation it's an absolute game changer. Every time I have Claude generate a moderately complex frontend in react I regret it sooner or later due to state issues and inconsistent behaviour. Not with elm. Everything that makes it difficult makes it perfect for ai.
the list numbering in that first link is a bit surprising
Did the restrictions on JavaScript get resolved? IIRC, they made it so you had to use their “Ports” mechanism to interface with JavaScript, and you couldn’t write your own wrappers.
There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
FFI is still mostly done through ports (or web components, for the view part). This is an intentional choice and likely to stay until 1.0 and beyond
And combined with its inability to provide mature native APIs and its hostility towards libraries containing ports, this essentially kills the language.
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.
You can also do lunatic things like overload the `Object` prototype and get synchronous FFI by encoding then decoding an object. I do this at work to get locale-aware sorting. I know you know this, but it'll be news to others in the thread.
Haha, yeah I didn't realize there would be a monkey patch route to FFI in Elm. Can't control the runtime. Is there a good read up on this technique?
Slightly important point: it's still safe FFI! Everything that crosses the JS/Elm boundary has to be encoded/decoded from serialized JS Objects. So it's hacky BUT it's not actually unsafe, which is kind of funny. I have an example where I use it to effect locale-aware sort. This repo is a benchmark test of that: https://github.com/perkee/elm-js-sort-ffi-speed-test/tree/ma...
Great hack, thanks! And yea I was missing some native string api when I abandoned Elm at 0.19.
About two years ago I was experimenting with ChatGPT vibecoding a snake game in the browser in elm, because elm is my favorite language. It was rough going and I concluded at the time that LLM‘s might kill elm. Today I use elm in production and LLMs are vastly better at it, and if anything I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now. It’s a simpler language than most, it’s stable, it has an opinionated architecture built into the language which causes most code bases to be very similar to one another
On that note, because of AI I've been more into music, bought a midi keyboard, got real DAW software setup. I've also finally built more and more with Rust, and have been reading more Rust docs. LLMs should never be an excuse not to learn the things you're using it for, those are the bad engineers. An LLM affords me the time to research and learn what it gave me so I can maintain it. It's easier to prompt about the problem if you understand it.
This is very similar to my recent experience!
LLMs are surprisingly effective at helping you learn the "vibes" of making music and understanding various concepts.
If you have a blog or something anywhere, I'm very interested in your journey.
I do though I havent been blogging as much, its a blessing and a curse to have a SSG based blog. I would love to have an SSG engine that I can use remotely from anywhere, currently using Publii.
https://giancarlostoro.com
> I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now
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
That's not why Elm is an ideal language for LLMs: it's because, if it compiles, it's most likely working software. Agentic workflows have gotten significantly better over the last year, so LLMs using languages like Elm, Haskell, or even Rust have an amazing feedback loop where even lower quality models can keep trying until things compile.
can keep failing til you're tired of having the agent running in loops, as I said it doesn't matter, agent tools are more effective with models trained with a lot of elm examples
Yet Elm due to its simplicity does not need a lot of examples. Language itself is small and blessed way to architecture things consist of few patterns. Then things are composable. This is ideal for LLMs.
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.
> Yet Elm due to its simplicity does not need a lot of examples
But does the neural net ;)
Maybe it's improved, but I was very disappointed to find agents constantly tripping over significant white space with Elm (Claude Code). Always struck me as strange since they are very proficient with python... and Elm has been one of the most stable modern languages (so stable that people complain about it never changing!). I think the last time I tried was a year ago though, so I assume it has improved.
LLMs are way past that, Claude Code can very competently write Elm code now, for example.
Good to know. I built https://github.com/pairshaped/hypertea to get some of Elm's safety in typescript while being easy for LLMs to use (this is basically just hyperapp in TS, with added elm-like guardrails). Maybe I'll go back to Elm now that LLMs are handling it better.
I don't think anyone complained about the language changing, it was a lack of trust in the language due to the compiler not getting any updates. You can still improve the compiler without having to change the language.
Yes. But that is about to change, and the compiler is now getting the updates it needs.
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.
> I think the last time I tried was a year ago though, so I assume it has improved.
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.
I started working with Elm in production again about a year ago and have bounced back and forth between codex and Claude code and haven’t noticed whitespace problems, so I would conclude it’s better but of course your mileage may vary
I was already working with elm (have been since Signals) and I was very disappointed in what agents (CC) produced. In contrast, I was pleased with the Rust code they produced.
Fair point. I hadn't thought about it that way, but I would still hesitate if the ecosystem isn't moving forward.
I'm interested less in getting to Elm 1.0 than getting past Elm 0.19, which is the version that locked out all native modules that weren't officially blessed by Elm's author. Far as I can tell, that pretty well marked the end of Elm.
Did they walk back that thing where certain language features could only be used by the Elm team? That seemed like a language-killer to me.
Nope.
what?
In Elm 0.19, they removed the ability for third party packages to provide native bindings for JavaScript APIs that the language or its official packages didn't yet support.[0] The only alternative proposed by Evan is to use ports, which are about as ergonomic as calling a function in a web worker.
[0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826
there is also web components (best way to do a "copy this to clipboard" button in my experience) and secret back door synchronous FFI through overloading the Object prototype. In all cases the communication is gated through decoders/encoders that can fail; you can only pass serialized data across the boundary from JS to Elm.
The compiler has hard coded domains that control who can use certain features. For example, custom operators aren’t allowed, but Evan is able to use them.
Why.... ?
The reasoning for removing custom infix operators is explained here https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...
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.
Because.
That's partially true. Evan is not able to use it outside core packages.
I think Evan's pointing at something, and everyone's looking at the finger. I don't think this is really about Elm at all, but the preparation for Acadia.
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?
> I don't think this is really about Elm at all, but the preparation for Arcadia.
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?
I can’t think of a worse announcement for your road to 1.0. Who cares? Without localization or accessibility support, it doesn’t make sense to call your UI framework production ready with a 1.0 version. I think limiting what third-party contributors can bridge from browser APIs killed Elm’s momentum for anything but toy projects. It now seems more like a sandbox for Evan to play around with compiler ideas than something meant for production use.
I don't think what you say is accurate. I maintain an Elm app and it is fully localized and I think it has a pretty good accessibility
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
I say let him cook. The real ones will know when it's good and ready, and hype driven folks can't be saved anyway.
On the one hand, it's good to see Evan's doing fine. He has some pretty good ideas about language development, and Elm has inspired quite a bunch of very interesting projects.
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.
There's a lot to love about Elm, and I've written quite a bit of production code with it starting around 0.18.0. But in 2026 I'm not sure why a company would newly choose a language that hasn't otherwise been updated in nearly 7 years.
Stability. It works. Frequent breaking changes to core functionality of your tech stack is not a feature, it’s a bug.
Does it though? They are many longstanding bugs reported in their compiler repository, and this release doesn't seem to address any of them.
Longstanding issues that prevent usage? Not for me and the projects I’ve been apart of. No doubt there are plenty of reported issues, and no doubt they truly negatively impact some users, but I would still much rather choose the usability and stability of Elm 0.19.1-2 than anything in the typescript ecosystem today
When I worked on an Elm app in 2020, my users reported compatibility issues with various browser extensions (e.g. Grammarly, 1Password). I personally would prioritize making my apps usable for my users over making the DX usable for myself, so I stopped using Elm for future projects.
Oh yeah those are a bear: grammarly, 1password, and darkreader were the big ones, but translation was too. Elm assumes it's the only thing modifying the DOM underneath its root element; the extensions assume the DOM is free to be manipulated. NRI did a writeup on how they fixed it. https://blog.noredink.com/post/800011916366020608/adopting-e... The TLDR is to use https://github.com/lydell/elm-safe-virtual-dom/
You don't have to choose between Elm and TypeScript though, there are so many other options now - Haskell, F#, Rust, OCaml, just to name a few.
Weird not to mention Elm's massive breaking change that killed the project?
How does that bear on my comment?
Well, you're suggesting a reason to choose Elm is stability - a lack of breaking changes. But Elm is actually notorious for its wildly unpopular, dramatic, community-fracturing breaking changes. Backwards compatibility is not a concern for them.
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.
Dont worry, if breaking changes start happening, people will magically have always been saying it's good, actually.
I agree that the stability is quite nice. But there are plenty of areas where the language could use some improvement - for instance, the ergonomics around writing nested Single Page Apps is pretty cumbersome.
Bugs not being fixed is not a feature, it's a bug, and it's certainly not stability, it's just cope.
[flagged]
We had some big Elm proponents who were trying hard to convince the company to use Elm, including doing proof of concept buildouts in Elm.
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 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.
This sounds like evaporative cooling.
https://lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-co...
It's amazing that business would tolerate paying staff to build products on one person's prototype hobby language.
We didn't tolerate it for main production projects.
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.
It's going to be hard to explain to future generations that the demand for computer-speakers was once such that sometimes they could even decide the language in which they spoke to the computer, and that really was a big deal back then because computers couldn't just switch back and forth like they can today.
Any insight on comparing Elm to Yew?
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.
I don't know about Yew but I've been using Iced 0.14 which is also a Rust crate inspired by the Elm architecture. It seems like Yew is specifically geared towards web applications, which I suppose is in some ways closer to the original Elm project.
What is your app? Is it intended for personal use, or commercial?
Iced looks nice! It would be super sweet to have a desktop + web cli with a mostly-shared rust codebase.
You are definitely welcome to use my app, it is a music generation and education website! Monic Theory can be found here :)
https://monictheory.com
Nice! I'm quite the beginner when it comes to music production and theory (took me a while to even figure out "Audition" means "Listen"), so I couldn't make full use of this site, but I like ideas presented in your about section. The website is quite functional, which is nice to see from a Rust base.
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).
I almost fell off my chair! Elm is easily my favourite language, and I didn't think it'd ever get another update. Thanks Evan!
I had dinner with Evan at Scala Days last year and had no idea who he was until he casually mentioned Elm. He is delightful and had some great insights on the philosophy behind Elm and on programming languages in general to share.
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.
Wish them all the best, I really respected the efforts made to normify some of ideas with unapologetic mathematic names like monads and such
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 automatic closing of threads is so hostile to the community.
I see all these people complaining about Elm limiting privileges to certain Github projects. A sensible complaint. But why hasn't anyone simply forked Elm, made the small tweak to make the check function return true or whatever, and offer that as a download/patch to the community?
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 remember using Elm in one of my gigs. After I left, the client hated me. Not to forget all the drama that it had before Covid. I really want this language to succeed, but its bdfl is trying hard....
I hope to see progress in the future. I loved Elm and it made me a better programmer. Things changed a lot since then, but beauty of Elm is not matched by any language.
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.
You should try more languages
I didn't downvote you, but what you have in mind? ROC maybe? I really have yet to experience joy as I did while writing Elm.
We're now migrating to React, but have some very large Elm projects still in prod.
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 worked on an Elm project professionally for a few years, and I just finished upgrading an old React app to version 19 on my own, which took a greater part of a year.
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.
For me the problem wasn’t the cultural change, it was depending on language whose leadership doesn’t seem to give a fuck about real-world problems the language users face in production. And then being constantly gaslighted about it on the official channels like the language forum.
Looks like for the first time in 7 years https://iselmdead.info/ is accurate.
I’m trying out foldkit.dev now. It lacks Elms elegance but you have access to ecosystem: it’s just Typescript. Here’s their Elm comparison: https://foldkit.dev/elm/foldkit-vs-elm-side-by-side
Am I right in thinking that Elm has lost a lot of momentum? It is barely discussed on HN anymore and I wonder if the releases/news have a lot to do with it. Look at the time between releases:
0.19.2 Faster builds, and the Road to Elm 1.0 Jul 2026
0.19.1 Friendly syntax hints, faster builds Oct 2019
There's very little left to discuss, unfortunately. The 0.19 release included some extremely controversial changes. The core Elm team responded by killing all discussion of it and (to the outside world) abandoning the project, the Elm community responded by scattering to a dozen forks and reimplementations of The Elm Architecture.
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.
Evan is back! Now I know the love is back I might do some Elming!
Back in my undergrad, I took a Functional Programming class taught in Elm. It was primarily about functional data structures, but we also got to build a web app using Elm towards the end.
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.
used elm between 2016-17.
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.
What's the Elm definition of simplicity? Genuinely asking, because the concept of simplicity is very vague and overloaded in programming.
The Elm Architecture[1] makes it easy to reason about code. You render the current state. You create a new state by applying a message to the current state.
1. https://guide.elm-lang.org/architecture/
You really need to use it to see the light. It's like reading about programming and actually programming. You don't understand programming until you actually program.
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.
said it better than me.
It's been some years since I last heard about Elm, but I still rememeber how it blew me away when I first saw it
On the subject of functional languages with JS as a compilation target, is anyone still using PureScript?
There are a few of us still at it :)
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.
Happy to see elm is still under development, I thought it stopped.
Worth noting there are some Elm to native code compiler projects now.
So many casualties in that period of groping around in functional programming concepts for the frontend from, like, 2014 - 2020 or so. But a lot of good things endured from that at least.
> ... and others are more visible features like equatable and hashable types.
I love Elm, and I love the community, but I feel a little gaslit here.
say more! Is it that it has typeclasses but they're closed?
It is that even without an open typeclass system, these specific typeclasses have been a common request for a long while.
I have worked at a few elm places, there is always a dict-for-everything dependency or local implementation.
Haha we may have worked together. Equatable has been a theoretically huge, actually OK hole in my opinion because it _can_ lead to runtime crashes but never has in any code I've written (\_ -> () == \_ -> () is a runtime crash). So I'm glad to see something more robust than "just don't do that." And "hashable" as the real thing you need to implement Set/Dict is a good idea imo. I'm sympathetic to keeping "comparable" closed and even smaller than it is for the reasons in this discussion [0]. In my perfect world, String would not be comparable as-is because string comparison should be locale dependent. Right now string comparison just ends up using JS's < operator which compares as a list of code units. So I'd like to be able to have a Set of Strings or a Dict with String keys without having the footgun of being able to think that I've alphabetized a list when all I've done is annoy a user by putting Área after Zapato and not between Azul and Barcelona.
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...
[1] https://github.com/rtfeldman/elm-sorter-experiment
[2] https://github.com/lamdera/containers/tree/main
Is anyone using Elm with Tauri to produce a front-end for a Rust library? It seems like it could be a really nice combo.
I would love to see Elm adopt an effects system as an answer to React hooks.
Is it me, the code examples look awful to read?
it's an ML family language. If you're not used to them they can be a trip.
love it see it :)
wait? elm is not dead?
No offense to the coder, but I would have preferred the name elm to have stayed in my memory as an text-based email client.
The language is alright.
Thank you for another check on my bingo card.
I thought elm was dead.
[flagged]
What is the point of actively choosing a web framework in the age of LLMs?
Professional diligence, perhaps? A desire to not be blindly led into the kind of narrow, often first-party stack which is so often proposed by Claude Code?
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.
Stronger foundation (as to mean better tested), less accidental complexity of reinventing everything, transferability of knowledge, easier onboarding and review of changes.
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.
The point is the same as in pre-LLM.
Statically typed languages with compiler hints are the absolute best languages for LLM's to work with. Successful compilation is incredible feedback, and it basically just means that there is a higher chance that the feature is in a complete and working state at the end of each agent iteration.
I haven't tried it, but Elm might be a really good fit for LLMs, because it forbids taking shortcuts.
It works really great with LLMs, it introduces less bugs compared with other languages
I am also confused by this, and not just for web, but any dev technology. I personally couldn't care less what the llm is writing in.
If anything, LLMs make it easier to choose from a broad set of options. The tradeoffs are the same as pre-LLM days, but the learning curve is more favorable.
Sorry buddy this is hacker news, you probably meant to enter your prompt here --> claude.ai