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) https://fsharpforfunandprofit.com/ddd/ (F# and Elm are similar enough that the concepts map directly.)

I've been challenging folks for a while now: What's the economic argument for using JS in a world where Elm exists?

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?

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.

Typical objections:

1) JS devs are easier to find.

I would never hire a programmer who can learn and use JS but refuses to learn and use Elm. That's a technician not a programmer.

It's easy to train non-programmers to use Elm. (If you can solve Sudoku you can learn to program.)

2) Elm doesn't integrate with some library or service.

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 unsafe code but we do not give up the borrow checker entirely.)

3) Evan is mean.

I do not care.

4) I can't control the Elm compiler development.

Elm is simple, write your own compiler.

- - - -

I've heard that there's work on an Elm-to-native app compiler... Neat.