Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Leaving Elm (2020)

lukeplant.me.uk

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Why I'm Leaving Elm (2020)

#51

Post by mejutoco »

incrudible wrote: post #38
mejutoco wrote: post #32

Earlier quoted context omitted.

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

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.

Re: Why I'm Leaving Elm (2020)

#52

Post by FrustratedMonky »

jgilias wrote: post #47
FrustratedMonky wrote: post #44

Earlier quoted context omitted.

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 architectur…

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 border…

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.

Re: Why I'm Leaving Elm (2020)

#53

Post by dhucerbin »

paulddraper wrote: post #48
adamwk wrote: post #40

Earlier quoted context omitted.

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.

Re: Why I'm Leaving Elm (2020)

#54

Post by dhucerbin »

yakshaving_jgt wrote: post #29

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 JavaScrip…

> 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

Re: Why I'm Leaving Elm (2020)

#55

Post by xupybd »

FrustratedMonky wrote: post #52
jgilias wrote: post #47

Earlier quoted context omitted.

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 border…

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

Re: Why I'm Leaving Elm (2020)

#56

Post by srhtftw »

dhucerbin wrote: post #54
yakshaving_jgt wrote: post #29

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 JavaScrip…

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

Re: Why I'm Leaving Elm (2020)

#57

Post by yakshaving_jgt »

dhucerbin wrote: post #54
yakshaving_jgt wrote: post #29

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 JavaScrip…

> 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

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.

Re: Why I'm Leaving Elm (2020)

#58

Post by avgcorrection »

hinkley wrote: post #30
NeuroCoder wrote: post #10

Earlier quoted context omitted.

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

Re: Why I'm Leaving Elm (2020)

#59

Post by mejutoco »

dhucerbin wrote: post #53
paulddraper wrote: post #48

Earlier quoted context omitted.

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

Re: Why I'm Leaving Elm (2020)

#60

Post by bPspGiJT8Y »

azangru wrote: post #21
tikhonj wrote: post #13

Earlier quoted context omitted.

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.
Post reply on HN