Czaplicki frames the compiler rewrite as the first concrete milestone on the road to Elm 1.0, presenting working code, benchmark numbers showing roughly 10x faster incremental builds, and a design sketch of what remains. He deliberately avoids apologizing for the six-year gap and instead lets the technical substance — a redesigned dependency tracker and rewritten type-checker pass — speak for the project's continued viability.
The editorial notes that in the six years since 0.19.1 shipped in October 2019, React went through hooks/Suspense/Server Components, Svelte reinvented itself twice, and Solid emerged — while Elm shipped nothing user-visible. The community fragmented to PureScript, ReScript, and TypeScript, and no compiler speedup addresses whether 'back' is even a meaningful concept for a language that made a virtue of not moving.
The editorial acknowledges Elm's founding pitch that a small opinionated core with TEA architecture and a compiler that produced human-readable errors was a persuasive trade-off, especially during 2016-2018 when it won significant mindshare. This framing suggests the compiler rewrite matters less as a speed number and more as evidence the original design philosophy is still being maintained.
The 255-point score and 109-comment thread indicate the community's interest is driven less by the raw benchmark number and more by the fact that this is the first substantive public movement from Elm's core team since 0.19.1. The subtext caught immediately in the thread is whether this ends the running r/elm joke about whether Elm is 'finished' or 'abandoned.'
Evan Czaplicki, Elm's creator and BDFL, posted 'Road to Elm 1.0' on elm-lang.org, laying out a compiler rewrite that dramatically cuts incremental build times. The headline number in the post and the HN thread (255 points at time of writing) is roughly 10x faster incremental builds on realistic project sizes, driven by a redesigned dependency tracker and a rewritten type-checker pass. The post frames this as the first concrete milestone on the path to a 1.0 release — a version number Elm has deliberately avoided for its entire fifteen-year existence.
The subtext, which the HN thread caught immediately, is that this is the first substantive public movement from Elm's core team since 0.19.1 shipped in October 2019. That's a six-year gap in a JavaScript ecosystem where six years is roughly three complete framework generations. In that window React shipped hooks, then Suspense, then Server Components; Svelte reinvented itself twice; Solid appeared from nothing and ate a chunk of the reactive-primitives conversation. Elm, meanwhile, shipped nothing user-visible. The community fragmented — some to PureScript, some to ReScript, most quietly back to TypeScript — and the running joke on r/elm became whether the language was 'finished' or 'abandoned.'
Czaplicki's post doesn't apologize for the gap and doesn't commit to a 1.0 date. What it does is show working code, benchmark numbers, and a design sketch of what remains between here and 1.0 — which is more concrete substance than the community has had since 2019.
The interesting question isn't 'is Elm back' — it's what 'back' even means for a language that made a virtue of not moving. Elm's original pitch was that a small, curated core with no runtime exceptions, a single opinionated architecture (TEA), and a compiler that gave you human-readable errors was worth more than a fast release cadence. For a stretch around 2016-2018 that pitch was extremely persuasive; Elm was the language TypeScript hadn't figured out how to be yet. Then 0.19 broke a lot of published packages, native modules were removed, and the community discovered that 'small curated core' and 'BDFL who doesn't explain roadmap decisions in public' are the same sentence viewed from two different angles.
The 10x compile speedup matters less as a benchmark and more as evidence that the core team is still capable of shipping compiler work — which was the specific capability the community had started to doubt. Incremental compile time is also the single loudest complaint in every 'why we moved off Elm' post-mortem from the past three years; Vendr, NoRedInk-adjacent shops, and a stream of smaller studios all cited it. Fixing it doesn't undo the migrations, but it removes the most common technical justification for the next one.
The comparison worth drawing is to Clojure, another language that moves at geological speed and ships breaking changes rarely. Clojure survives its cadence because Rich Hickey earned enormous credit through public design essays and the community learned to read silence as 'still thinking.' Elm never built that same layer of public reasoning, which is why silence read as abandonment instead. The 'Road to 1.0' framing looks like an attempt to fix the communication problem alongside the compiler one — publish a target, publish the milestones, let people plan.
For a working developer the practical read is this: languages that ship a compiler rewrite with real benchmark numbers are not dying languages, regardless of what Reddit says about them. The Elm job market is still tiny and probably always will be, but the technical foundation is being actively rebuilt rather than left to bit-rot. That's a meaningfully different risk profile than it was in June.
If you're already running Elm in production — NoRedInk, Vendr, Rakuten, the various fintech and health-tech shops that quietly still ship it — this is the update you've been waiting for since roughly 2020. Test the new compiler against your largest module graph before it lands in stable; if the 10x number holds on your codebase, the case for staying put just got significantly stronger, and the internal conversation about a TypeScript migration can probably be shelved for another year.
If you're greenfielding a frontend today, this doesn't change the calculation much. Elm remains a bet on a small language with a small ecosystem and a small hiring pool — the compiler getting faster doesn't fix any of those things, and none of them were technical problems in the first place. The teams who should pick Elm in 2026 are the same teams who should have picked it in 2019: small, senior, willing to write their own bindings, and value zero runtime exceptions more than they value ecosystem breadth.
If you left Elm between 2020 and 2024, this is worth a serious re-evaluation only if the specific reason you left was tooling speed. If you left because of the package situation, the native-module removal, or the general sense that the project had stopped listening — none of that is addressed here yet. The 'Road to 1.0' post is a down payment on communication, not a full apology tour, and the community will fairly ask what the next milestone actually looks like before extending credit.
The real test isn't the 10x number — it's whether the next public update lands in months rather than years. Compiler speed was the easy fix; the harder ones are the package ecosystem, the native-module story, and whether 1.0 comes with a stability promise that lets library authors ship without fearing another 0.19-style break. If Czaplicki publishes a second milestone post before the end of 2026 with the same level of concrete substance, Elm has a genuine second act. If this post is followed by another two years of silence, the compiler will be faster and the community will still be somewhere else.
I wrote a thing in 2023 about why I'm still using Elm:https://taylor.town/elm-2023It'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
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 L
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?
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.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
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