Using Elm in 2025
38 points by blaix
38 points by blaix
This strikes me as being not too dissimilar to the situation with Clojure. The whole “open code but not open governance” thing was very frustrating in early years when that dynamic was present implicitly but has become a lot less so ever since the core team has gotten better at explaining that the way they do things is different from most projects.
The way I see it main differences are that Clojure has still had a couple releases in the years since 2019, and that people looking at Clojure are less likely to be coming from the JS mindset of “if it hasn’t had a release in six months it must be dead”. But going off to spend several years thinking deeply about a problem would be totally in character for Rich.
I feel like while Clojure’s very dependent on Rich -who doesn’t text much from The Hammock- the rest of the core team is pretty communicative, and there’s a bit less hostility to ‘different approaches’ than there seemed to be in the Elm world. This is all purely cultural, ofc.
I’m on a new project after being away from the frontend world for a while… And I have to say I really miss elm. The project where I used elm was truly one where I could build something and it was done. No bugs whatsoever. I don’t think I’ve experienced that in any other language.
Would I use elm again though? Hmmm, maybe for a frontend heavy project with few integrations that I never needed to hand over to anyone.
never needed to hand over to anyone.
This is the big one, to me. I worked for a company that let a team build some tooling in Elm (this was years ago), party, I think, to avoid losing those devs. The problem was that those devs left anyway (of course they did, some other company had more Elm projects than we did) and it all had to be rewritten because no one wanted to learn Elm just to main a couple tools.
and it all had to be rewritten because no one wanted to learn Elm
I’ve seen this pattern described several times in comments here and elsewhere. Personally, I find it curious that some programmers are so resistant to learning new things. It doesn’t match my perspective where I enjoy learning new languages and tools, especially when they offer benefits over the status quo.
There’s no accounting for taste. I would gladly work in Elm any day. But in general, it’s not so surprising that it’s more fun to build things in an esoteric language because you wanted to than it is to inherit someone else’s code base in an esoteric language because you had to.
I can’t speak for others, but I enjoy learning new things as well, I just didn’t feel like learning Elm.
and it all had to be rewritten because no one wanted to learn Elm
Yeah, well, maybe that’s exactly the reason why those devs left.
Can you imagine to work in a company where everyone does, say, Cobol, and they don’t ever want to move to something more modern, despite Cobol not being a good fit for their domain?
Yeah, well, maybe that’s exactly the reason why those devs left.
Yep, that’s what I speculated as well. I’m not sure how you jumped from “nobody else wanted to learn Elm” to “they were stuck on Cobol”, but hey, whatever lets you feel superior to other people, I guess.
There was a point at which I really liked Elm; it was the first typed functional language I’ve ever used seriously, and I probably have to thank it for getting me into frontend development as well. Then I started getting frustrated with its limitations and probably wanted something more… exciting? I think I was annoyed at the lack of “native” support for some JS APIs, which meant that to interact with e.g. localStorage I would have to go through ports, and by how Evan’s response to that was (and still is) to block the community from thinking about it and wait until he personally got some inspiration for how to map that API to Elm in a clean manner. I also did not like that infix operator support was just removed from one release to the next.
I’m still a bit annoyed by those things, but thinking back maybe I just got whiplash from how quickly Elm turned from something new and exciting to “boring technology” that’s meant to be stable. Maybe if I tried it today I would appreciate the constraints a bit more.
I personally love the “boring” stability of Elm, but it sounds like you might like what we’re doing over at https://gren-lang.org/ - Similar goals as elm from a core language perspective but actively evolving with support for more native web apis like local storage and web crypto, running on nodejs, and a desire for community input and involvement.
Personally I wouldn’t touch Elm with a stick. However I do find their approach very solid, that is fully embracing a compiled DSL that is not held back by web shenanigans. By contrast frameworks like say Svelte insist on pretending they’re building on web fundamentals when in reality they’re paradigms of their own. I believe a more modest approach today, now that frontend patterns are ripe and have largely converged, would be a subset of TS that supports reactive variables and/or observables as part of the language, which would be just as interesting to test for UI and server purposes.
The reuse of names makes it hard to tell at a glance what is being discussed. Elm, the email client, comes from the ’80s, where Elm, the programming language, apparently came in to existence in 2012. Which am I going to think this is?
The same thing happened with Alpine, the email program, and Alpine, the Linux distro. Then again, when Dexter became popular on TV, I thought everyone was taking a liking to Dexter’s Laboratory, so perhaps part of the issue is that I don’t keep up with popular culture.