Why I'm Leaving Elm (2020) (opens in new tab)

> 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?

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

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

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.

> 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...

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).

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.

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.

(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.