Why I'm Leaving Elm (2020) | Hacker News Reader

Why I'm Leaving Elm (2020)

lukeplant.me.uk

52 pointsbluewalt55 comments

> they need to think of themselves as stewards and not owners.

This is an important idea that a lot don't seem to get.

Of cource, if you're in (US) business, the norm is to be an owner, often with a PR veneer of steward or faux folksiness, and most savvy people understand that.

(Junior engineers are to be forgiven for not yet understanding that the megacorp or aspiring techbro-ionaire is often trying to trick the kids to get into the back of the ice cream truck of vendor lock-in.)

But in many other contexts, people rightly expect steward. Including in many ostensibly community projects, in which there are very different reasonable expectations.

Elm is pretty much dead at this point. The last substantial commits in the Elm repositories are about 2 years old.

I liked Elm before, and was a great fit for internal corporate applications. Something like an admin control panel or a monitoring tool.

Are there any similar projects that are in the "more alive" state?

PureScript[1][2] seems pretty alive these days. From my relatively small, self-contained experiments, it's a lot more flexible and expressive than Elm at the expense of (maybe?) being a bit harder to learn up-front.

[1]: https://www.purescript.org/

[2]:https://github.com/purescript/purescript

How has it been going for Purescript since its creator and maintainer Phil Freeman stepped down?

Didn't really change anything. PureScript is in goood hands of the maintainers and contributors currently.

There were some Rust WASM frameworks that used similar concepts, I particularly liked yew. However yew has recently chosen a path more towards "magical" features instead of the simple Elm-style architecture. Don't know enough about the other ones to comment.

It's worth sharing Scala.js which has https://github.com/PurpleKingdomGames/tyrian, an ELM-insired library for the UI.

Elm is pretty much finished (meaning feature-complete) IMO. Not much needs to be changed. I love Elm. I can always go back to a project and get back on it in 2 minutes. The compiler is superb. The problem is one must roll on their own almost everything.

I dislike the constant churn of React and other libraries, that often add change for change's sake, and break backwards compatibility or depend on too many libraries. At the same time Elm is maybe too much in the other direction.

React is also pretty much finished. I have not experienced breakage except in some exotic functionality. The churn comes from switching to hooks, but that can happen gradually and is not strictly necessary. Oh, and of course library authors like to break stuff, but that is not on React itself.

Before the switch to hooks there was the switch from class components to functions, but some features (error capture) were only available using class component.

The router situation has always been a mess too, and passing props around and lately contexts also overlap and have changed with time.

Some of building blocks seem to have been built organically, without regards for backwards compatibility. It is still very useful (I happily use react and next js) but the concepts are not very elegant and internally consistent IMHO.

Is there l10n and i18n support yet? I don’t know how a UI framework can be considered production ready let alone finished without support for string translations. Last I checked, after Elm 19 killed the third party wrappers around Intl I hadn’t seen any movement here, but maybe I missed it or this has changed since then

React doesn't have i18n

But React doesn’t prohibit calling Intl API in your code.

Elm does have a escape hatch: ports. You could use ports to call any javascript library. I have done it and it works.

Ports are needed because they make any js code go through the same "even router" than any Elm code. It works very well. Without ports js would break the guarantees that Elm provides. It is quite an elegant solution.

The only problem is if you wanted to call something requiring very high performance, like an event loop in a game, then going through a port call on every frame would probably be too slow. Even in that case you could write a bigger chunk outside of elm and call it from elm, and it would be ok. Please note that this problem happens with any?/most? FFI implementations in any language.

P.S. React does not prohibit anything. They just shame you into it not being best practices :)

That is exactly what I meant with you have to roll your own of everything. The building blocks for this one are there.

Elm could have server side rendering too, like nextjs. That is IMO way worse.

I was just reacting to general sentiment. Few days ago was similar posts about Rust. And one about Python.

And got me thinking, in a world where anybody can fork a project, and tweak it, how does a language keep a solid base to work from. And it does seem like it is those with corporate backing.

I'm not against it. I'm a big fan of F#.

But kind of sad that ELM isn't making it, since, in my opinion the ELM architecture is great concept for functional languages to do GUI's.

Well, yeah, but Elm can’t have corporate backing (apart from NoRedInk where Richard Feldman is CTO) for the reasons outlined in the article. It’s suicide to pick Elm for important production applications when you know that the escape hatches have been welded shut. Go explain to your boss how you have to spend two years to implement, say, an internationalization library because Evan says so. The Elm approach is borderline crazy here. As a technical decision maker you have to hedge your risks in order to ensure you can deliver. And using Elm is just a very risky decision.

I rant about this because I actually really enjoyed programming in Elm when I tried it out. But this shortsightedness has basically killed it. Had they been more lax with native modules and more community oriented, the language would be much bigger now.

Alas, it is what it is.

Yeah. I'm bit sad about it too. I thought the ELM architecture was great concept. I'm not really for or against corp control. Just on technical merits, I wish ELM had succeeded more because I like that style. And in todays world it seems to take a lot more than technical reasons to succeed.

Elmish in F# is really nice

> apart from NoRedInk

https://noredink.com/about/team

> where Richard Feldman is CTO

https://noredink.com/about/team

Do all projects need to continue having work done on them to be considered 'alive'? Is there no possibility for a project to be 'finished' and still good to use without needing any more work?

For libraries wouldn't you expect at least work to keep supporting newer versions of the language? Or use the improvements brought by said new versions?

For a language itself I don't know. I don't know I've never designed one. Maybe keep working on it to take advantage of improvements made to lower level libraries that you use?

Electric Clojure - https://github.com/hyperfiddle/electric

Extensive discussion (434 comments) when this was first published.

https://news.ycombinator.com/item?id=22821447

Thanks! Macroexpanded:

Evan Czaplicki's response to “Why I'm leaving Elm” - https://news.ycombinator.com/item?id=22837686 - April 2020 (1 comment)

Why I’m Leaving Elm - https://news.ycombinator.com/item?id=22821447 - April 2020 (432 comments)

I'm moving away from working with Elm also, but for different reasons.

I don't care that Elm isn't some jolly club where everyone gets to join in. If it were, we would 100% see escape hatches, and, ultimately, runtime errors.

I also don't care that it doesn't have typeclasses or other more powerful language features. The fact that the language is small is a feature. It's much more thoughtfully designed than JavaScript (which is now worse than it was 10 years ago as it has continued to accrete features it envied from other languages).

I think Elm is the best technology in its space. If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.

I'm moving away from working with Elm because I just don't need to write single page applications, and I believe developers are all too eager to write single page applications unnecessarily.

> If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.

I find this interesting, because SPAs in Elm are more like exercise for the reader. If you look how NoRedInk uses Elm you will see that’s more like one “app” per REST controller [1]. Do you have some experience with specific solutions that you could share?

[1] https://juliu.is/elm-at-noredink/#rails-conventions

Not the OP but one small thing I do along these lines is compile multiple Elm top-level modules into a single binary with "elm make" and then initialize only the ones I need for a particular page. So instead of one big app, I have lots of little apps that only know a small part of the overall picture.

This also eliminates some of the boilerplate nesting/dispatching you would otherwise need between different Elm models for the price of a very slight increase in the risk of seeing runtime decoding errors.

We were doing something like this where I work also, but it's still more firepower than we need. We didn't have one SPA to represent the entire client — we have a few smaller Elm applications, and those are only in the places where we felt we needed a more complex and stateful UI.

In our case — building enterprise insurtech stuff — we can and should be smarter about how we design our UIs so that something as sophisticated as Elm isn't necessary.

We did invest a fair bit in that direction also. We have some clever Template Haskell code which generates Elm code (types, encoders, and decoders) so that the shape of the models stay synchronised across the boundaries. This does work nicely, but it's yet more stuff for us to compile, and it's yet more code for us to own.

I would rather we design our product better and remove the need for some of this code, rather than just try to code around every problem.

> and migrate to some other language (most likely Bucklescript

Given this was written in 2020, how has the migration to Bucklescript / Rescript / ReasonML been going?

ELM is great. So where do people go if they like ELM and want that type of thing, but sustained?

If everyone is leaving all languages, based on the flurry of these types of posts, what is left? What language/platform do we use, if everyone is leaving everything because of some X?

Sounds like open source is fragmenting. And what will we be left with? The big corp backed platforms, that have marketing departments, and product managers, and support departments. .Net, Java, etc...

Calm down, none of what you're saying has any basis in reality.

You can still use elm all you want, you just won't get paid for it by a corporation. You seem to not want corporate backing, so you should be okay with that.

Alternatively there are other languages/platforms out there other than ".Net, Java" you can use.

Ah, another “why I’m leaving X” post, I’ve never seen these kinds of posts as particularly fruitful regardless of the language they go on about. Engineers can assess the pros and cons of a technology for themselves based on their needs, and usually these kinds of posts don’t have the relevance their authors wish they would. I think they serve more as emotional catharsis (or worse) than actually meaningful content (most of the time).

This sort of feedback is just difficult for people to consume in a mature way. Many get defensive or weaponize it. Language design is hard to critique since it becomes so abstract making most comments superficial. But people in this situation often have some actual knowledge. The other situation is when the language devs actually listen to some of the feedback.

Language design is really goddamned hard and if you’re really good at it, you’re rewarded with a fan base that won’t give you permission to do it again for another ten or fifteen years.

Wow. That’s a really insightful and funny quip. I’ll most probably remember it for a long while. :D

Reasons you might want to use Elm:

<list>

Reasons you might want to not use Elm:

<list>

Great. These are only technical reasons, though. What’s the community like? What’s the process like if you want to contribute to the core project?

Oh, discussing that topic is verboten. It would be too cathartic.

why do these elm hit pieces keep getting dug up and reposted? It's almost always in response to some other elm post (there was one yesterday). People use elm in production at quite a few companies without worrying too much about the concerns laid out in the article, but it feels like people seem almost fervent in their need to justify their reason for leaving elm and why other people shouldn't use elm.

HN can’t resist crapping on Elm and Tailwind. I wonder what the other popular hate topics are?

Tailwind? I must've missed that; I thought HN liked Tailwind for the most part.

Speaking as someone who despises Tailwind, my impression is certainly that HN generally likes it. It is amusing that somebody else gets quite a different impression. Shows how biased human memory can be.

React?

This is called The Baader–Meinhof phenomenon, a belief that something happens far more often than it actually does.

A year ago I started using Elm for a side project where I wanted to let my users go beyond typical Markdown and templates and apply their own processing rules on html/css generated by an Elm view. Unfortunately I discovered Elm's libraries aren't really intended for that - a view can trivially create html nodes but you can't transform those same html nodes in the obvious way because their attributes aren't readable. If you want something you can transform in multiple passes you have to use your own IR or html wrapper.

Maintaining a redundant IR just to be able to transform attributes wasn't a price I was willing to pay for a fun side project so since Elm really didn't want me to work with the generated html the way I wanted to I looked around and decided to give Yew a try. Unlike Elm, Yew gives you a way to include arbitrary html in the rendered output. Accessing third party javascript with wasm-bindgen is also much simpler than using ports or custom elements in Elm.

Well after playing around with Yew a bit I found myself missing the effortless refactoring experience I had working in Elm so I decided to come back to Elm and go with a hybrid approach. Now I have static html/css with small Elm modules for forms and simple views and a completely separate app does the transformation. This wasn't the architecture I originally had in mind but overall I like it better.

Having said all that I can sympathize with the author's frustration. It's really really irritating when you encounter something that you think should have a trivial solution but turns out to be hard in Elm because of the choices the Elm developers made. In my case I felt like I was on a luxury cruise that was fun 99% of the way until finding out their policy was that I had to swim the last 1% on my own.

(2020)

For people looking for a replacement:

Take a look at F# and Fable (F# to JS compiler)

previously: https://news.ycombinator.com/item?id=22821447 (April 9, 2020 — 732 points, 431 comments)

I was surprised this is only the first reposting—I thought for sure I had seen it more often than that.

You have seen it more than that, because it is linked in the comments of almost every Elm-related post on HN.

There is a small group dedicated to ensuring nobody uses a language that, according to them, nobody uses.

*Edit: https://news.ycombinator.com/item?id=34750499

https://news.ycombinator.com/item?id=35499892

https://news.ycombinator.com/item?id=34748430

https://news.ycombinator.com/item?id=34747958

https://news.ycombinator.com/item?id=34747376

https://news.ycombinator.com/item?id=31666100

https://news.ycombinator.com/item?id=30035052

https://news.ycombinator.com/item?id=29308496

https://news.ycombinator.com/item?id=28499112

https://news.ycombinator.com/item?id=27823758

https://news.ycombinator.com/item?id=27819792

https://news.ycombinator.com/item?id=26862280

https://news.ycombinator.com/item?id=24334514

https://news.ycombinator.com/item?id=22831410

https://news.ycombinator.com/item?id=22827205

It looks like the haters found my comment, and really, really want to make it clear that they hate Elm. To each their own.

(2020)

I felt deja vu, because this was posted here before

Everything could be solved by using metaprogramming. Take it easy.

Good for elm, now even more intrigued to use it, seeing it triggers the right people. What is described in the article is infinitely better than what usually goes around as acceptable in front end.

Basing a decision on which technology to use based on who it triggers is, uh, stupid.

Elm seems like a really awesome piece of technology, but it's pretty obvious that its BDFL shit the bed pretty hard by neglecting the project, and the momentum behind the project has been drying up for a long time.

I would hope it comes back, but even if it doesn't, a lot of people have adapted elements of the Elm architecture into other projects, and the community still prospers as a result.

Cool. Please do share when you write up about your experience with the language and ecosystem. Positive or negative, it'd make for a good read.

Reply on news.ycombinator.com