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.
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.
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 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.
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.
> 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.
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?
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.
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.
> 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 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.
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.
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.
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'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.
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.
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.
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 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....
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.
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.
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.
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.
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.
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.
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 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.
What feature is that?
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
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.
For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.
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.
If you have a blog or something anywhere, I'm very interested in your journey.
> 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.
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.
> 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.
LLMs are way past that, Claude Code can very competently write Elm code now, for example.
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.
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
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.
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
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).
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.
> 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.
> 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 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.
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'm glad it's back. Elm had such a remarkable elegance I was always rooting for it.
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.
wow careful, this turkey still has some kick left in 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.
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.
> 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!
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
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!
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.
Weird not to mention Elm's massive breaking change that killed the project?
How does that bear on my comment?
Looks like for the first time in 7 years https://iselmdead.info/ is accurate.
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.
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.
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.
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.
Worth noting there are some Elm to native code compiler projects now.
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
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....
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/
Is it me, the code examples look awful to read?
> ... 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?
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
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.
love it see it :)
What is the point of actively choosing a web framework in the age of LLMs?
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.
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.
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.
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
Sorry buddy this is hacker news, you probably meant to enter your prompt here --> claude.ai