Road to Elm 1.0

Post by metaketa » Thu, Jul 09, 2026, 7:21 AM UTC

surprisetalk wrote: post #10

I wrote a thing in 2023 about why I'm still using Elm: https://taylor.town/elm-2023 It's 2026, and I'm still using Elm for all the same reasons :) As an added bonus, Claude seems to play very very nicely with Elm: https://taylor.town/diggit-000

This. Generating a frontend with guarantees can almost not be done with any other language. If you use the graphql module with code generation it's an absolute game changer. Every time I have Claude generate a moderately complex frontend in react I regret it sooner or later due to state issues and inconsistent behaviour. Not with elm. Everything that makes it difficult makes it perfect for ai.

Post by pseudocomposer » Fri, Jul 10, 2026, 12:44 PM UTC

dminik wrote: post #46

pseudocomposer wrote: post #36

Earlier quoted context omitted.

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 co…

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.

I don’t like being disagreeable, but just no. On both of these.

First, the comparison is perfectly fair. Elm 0.19.1, 6 years ago/0.19.2 today, React 16.1 6 years ago/19.2 today. Literally identical conditions. What is unfair? Which required app developers to do more work? Which saw more security issues among its releases?

Second, not needing updates for 6 years, and having zero security holes in that time, is the definition of stability. This isn’t really a matter of opinion or preference.

I do see the appeal in other frameworks (ecosystem size, easier to find devs), but the appeal of Elm truly is stability. And it really is that much better than nearly everything else that runs in the browser, in that regard.

No framework that allow you to use actual JS (or “transpiles” but gives you the full JS API, like Coffee/TypeScript), will ever offer the level of stability Elm offers (aside from maybe the web standard APIs on which Elm is narrowly built).

Re: Road to Elm 1.0

Re: Road to Elm 1.0