If you haven't already, do also have a look at Scott Wlaschin's talk "Domain Modeling Made Functional with the F# Type System" (it seems he has a whole book out on it now too) <a href="https://fsharpforfunandprofit.com/ddd/" rel="nofollow">https://fsharpforfunandprofit.com/ddd/</a> (F# and Elm are similar enough that the concepts map directly.)<p>I've been challenging folks for a while now: What's the <i>economic</i> argument for using JS in a world where Elm exists?<p>In other words, if you want a front-end app, and you do not care about the technology used to make it (you're not using a particular stack just because you like it) then you should pretty much just use Elm, eh?<p>If I'm some business owner who wants a web app that works reliably and is cheap to maintain, I don't know or care about the underlying tech stack, it seems like Elm is sooooooo much better than all the JS frameworks and "ecosystem" in terms of the metrics I care about.<p>Typical objections:<p>1) JS devs are easier to find.<p>I would never hire a programmer who can learn and use JS but refuses to learn and use Elm. That's a <i>technician</i> not a programmer.<p>It's easy to train non-programmers to use Elm. (If you can solve Sudoku you can learn to program.)<p>2) Elm doesn't integrate with some library or service.<p>That's an argument for wrapping that lib/service in an Elm module, not against using Elm entirely. (E.g. in Rust you sometimes must use <i>unsafe</i> code but we do not give up the borrow checker entirely.)<p>3) Evan is mean.<p>I do not care.<p>4) I can't control the Elm compiler development.<p>Elm is simple, write your own compiler.<p>- - - -<p>I've heard that there's work on an Elm-to-native app compiler... Neat.