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!
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.
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.
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).
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.
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.
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
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?
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
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'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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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
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
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
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.
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?
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.
[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.
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?
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
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.
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.
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?
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.
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.
> ... 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.
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?
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.
I thought elm was dead.
[flagged]
What is the point of actively choosing a web framework in the age of LLMs?