101–110 of 192 posts
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.
Earlier quoted context omitted.
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.
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.
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 decis…
Elm served its purpose for me - an example of a small language with great tooling and error messages. And the strictness was helpful in learning to do things the "proper" way in the Elm model, even if I did reach for escape hatches in later projects. E.g. writing a notion-like application in Elm, I had to walk through my data twice - once to render it and another time to collect cache misses. With hyperapp, I broke purity a little and accumulated the information on the side.
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).
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
Elm's current story for interacting with the wider web ecosystem is "reinvent the wheel a dozen times by DIYing your own wrappers around literally everything". Fine for a trivial toy project, not fine for building production software.
I understand why they made those decisions, and each choice on its own is logical, but that doesn't make the combined outcome any better.
Earlier quoted context omitted.
What feature is that?
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossib…
Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop.
But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port.
It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened.
It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.
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 t…
This sounds like evaporative cooling.
https://lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-co...
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.
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 someth…
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