Why I'm Leaving Elm (2020)(lukeplant.me.uk) |
Why I'm Leaving Elm (2020)(lukeplant.me.uk) |
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.
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?
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.
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.
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?
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 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.
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?
Given this was written in 2020, how has the migration to Bucklescript / Rescript / ReasonML been going?
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...
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.
<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.
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.
Take a look at F# and Fable (F# to JS compiler)
I was surprised this is only the first reposting—I thought for sure I had seen it more often than that.
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
I felt deja vu, because this was posted here before
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.
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.
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.
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.
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.
https://noredink.com/about/team
> where Richard Feldman is CTO
Elm could have server side rendering too, like nextjs. That is IMO way worse.
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 :)