[mjaniczek]

I can confirm the sentiments from Humio's blogpost. I am leading a frontend team at GWI creating the platform: https://www.globalwebindex.com/platform

Complex UIs are a breeze in Elm. We have 140k lines of code of Elm so far on that one product (there are also internal admin interfaces that I don't count here) and I can't imagine writing and maintaining something like that in React+TypeScript or some other JS UI library. (Mentioning React because I have experience with it. Dunno about Vue/Svelte/others.)

Wrt. hiring, we are experiencing the Python paradox: the last time I posted a job in the #jobs channel in the Elm Slack, I had about 8 solid applicants reply in the matter of hours/days. From my perspective, people are absolutely eager to work with Elm full-time and we don't have the problem of having to sift through totally junior/beginner candidates.

Re the Elm development model: I tolerate the fact that PRs don't get picked up immediately and that work gets done in batches. It is sometimes a bit frustrating and contrary to default expectations from other open-source projects, but it's not the end of the world. In the ~3 years of working on our app I haven't found a situation where we'd be blocked without some kind of escape hatch (typically ports and WebComponents).

Re community: I can again only sing praise about it. Yeah it might be protective of the best practices and idioms, but the folks are incredibly helpful. If you are willing to listen, there will be enough advice to save you from digging yourself into a hole (native JS modules etc.) and writing a heated "Elm sucks" article later.

Overall, Elm is both what I write small experiments and spikes in, and large production-ready applications. Not to mention side-projects. 10/10 would start an Elm project again :)

[capableweb]

Could you share some screenshots of the complex UIs you're building over at GWI? It always helps me to understand other perspectives as difficulty/complexity seems to be relative in discussions around UIs most of the time.

[mjaniczek]

Sure thing! Here is an Imgur album with screenshots of some of the apps: https://imgur.com/a/GCxSrr1

[capableweb]

Thanks a lot for sharing those! Very interesting to see. The "crosstab" page looks like it was a lot of fun to implement! :)

[anko]

wow thank you! this was great to see

[tootie]

My org has a load of code written in Ember and are suffering mightily for it. Not to directly compare Ember and Elm on their quality, but just from the POV that Ember had a group of diehard supporters who believed it was a better approach to development at one point, but ultimately lost the debate to React/Vue/Angular. Deserved or not, it no longer has strong community support and it's really hard to find anyone willing to work on it. Unfortunately, making these kind of technical decisions can't always be done on intrinsic merits.

[wolfadex]

Having spent the past year plus in very large (over 1M loc) and old (10+ years) Ember code bases and having used it about 6-7 years ago I can confidently say that Ember has a very different mantra. Ember's selling point for many years has been "If you know Ember at company A then you know Ember at every company" (paraphrasing here). I've found this to not only not hold true, but to be very unhelpful for onboarding new developers. Conversely I've onboarded devs onto Elm projects with lots of ease.

Those Ember diehards definitely still exist too, I work with a lot of them. They, like a lot of the Elm die hards, are also really kind people and great devs. The main difference I've seen is that Elm devs get to spend most of their time building features while the Ember devs end up spending much of their time trying to keep up with Ember and a lot of time dealing with project build bugs and infra.

I've also been writing React on and off for around 6 years and can confidently say that React doesn't suffer from maintenance issues in the same way that Ember does. Where it does fall short of Elm, even when including TypeScript, is both speed (both build and runtime performance) and ease of refactoring.

I've also spent the past 2 months working on a small-ish Svelte + TypeScript app. That's probably the closest I've come to the experience of using Elm. It's runtime performance is on par with Elm, sometimes faster and sometimes slower. It's build time is still a bit slow, mostly due to TypeScript, and it's onboarding is quite quick for someone who already knows HTML + CSS + JS. It still falls short when it comes to refactoring though as it just can't match the error messages that Elm is able to provide.

Just my 2 cents having used many of the frameworks for many years.