Been suggesting we use it for a complicated bit of interface for a company I was working at two years ago, we were pleasantly surprised at how well it held both in requiring low (almost no) maintenance once written and how easy it was to improve on the codebase.
We migrated pretty easily from 0.18 to 0.19, we only had to import a bit of code here and there from libs that would not migrate or update where changes had been made, strong typing and the compiler made it a rather pleasant experience.
The only thing we did not do was migrate to an SPA ; the scope of the app was wide and the cost to achieve this was too high I guess.
Few pain points, amongst which:
- Sometimes you have to do something you would expect to find off-the-shelf (like a souped-up drop-down or a tag editing system) but it's ususally a matter of designing your ui well and can be fun (plus you get to really design the user experience).
- Sometimes you have to do a bit of JS for stuff that aren't designed in Elm (anymore, ie websockets) and use ports to communicate.
- If you're building incrementally, and make mistakes (over-design, useless code to conform to an unrequired philosophy, etc.) it's a good thing to sometimes challenge the bad old choices and get them smoothed down ; thankfully the compiler is your friend here too.
- The learning curve, especially if your team isn't fond of functional programming, can be daunting if you don't have an Elm advocate. That was me in my team, and we grew fond of it, but made quite a few beginners mistakes on the way. All very fixable though.
Well, that's about it ; if you want help getting people started and boosted on the functional programming paradigm, please have a look at my blog: it's Elm-centric, focusing on the most important functional programming concepts that'll get you up and running on what's happening there :)
https://medium.com/wat-the-elm-ist
And it might even explain what monads are ;)