Discussion summary
Discussion centered on the relevance of web frameworks like Elm in the age of LLMs, with some seeing benefits in static typing and compiler feedback, while others question its necessity.
What the discussion says
- LLMs make choosing frameworks easier but don't change core tradeoffs.
- Elm's strictness might be beneficial for LLM compatibility.
- Many see no need to change existing development practices.
- Some believe Elm is outdated or less relevant now.
“Elm might be a good fit for LLMs because it forbids taking shortcuts.”
“Statically typed languages with compiler hints are ideal for LLMs.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by song_synth - 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?
by 1024bits - 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.
by Aurornis - It's amazing that business would tolerate paying staff to build products on one person's prototype hobby language.by gowld
- > 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...
by networked - 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.by whichdan
- Stability. It works. Frequent breaking changes to core functionality of your tech stack is not a feature, it’s a bug.by auslegung
- 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.by adamwk
- 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.
by crote - 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.by kubb
- 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
by shamsartem - 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?
by iamwil - > 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?
by crote - 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.by willdr
- what?by jacobjuul
- Nope.by Munksgaard
- 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.by chuckadams
- 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 anotherby auslegung
- Fair point. I hadn't thought about it that way, but I would still hesitate if the ecosystem isn't moving forward.
- 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.by rapind
- > 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
by hollowturtle - 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.
- 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?
by lambdas - 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 beyondby miniBill
- I wrote a thing in 2023 about why I'm still using Elm:
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:
by surprisetalk - the list numbering in that first link is a bit surprisingby tensegrist
- 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.by metaketa
- 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.by OhSoHumble
- wow careful, this turkey still has some kick left in it!by shiqi_Rao
- I know right. I’m glad DSLs have fallen out of fashion. Just use the platform.by ale