[mejutoco]

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.

[adamwk]

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

[mejutoco]

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.

[paulddraper]

React doesn't have i18n

[dhucerbin]

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

[mejutoco]

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

[FrustratedMonky]

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.

[jgilias]

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.

[1-more]

> apart from NoRedInk

https://noredink.com/about/team

> where Richard Feldman is CTO

https://noredink.com/about/team

[FrustratedMonky]

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.

[xupybd]

Elmish in F# is really nice

[incrudible]

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.

[mejutoco]

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.