Yes. I honestly find it much easier to think about, easier to design, and eventually easier to modify and maintain.

It feels like a lot of code needs to be written, but in my experience that's because it necessitates thinking about the edge cases in a way that you can try to ignore with more imperative UI or data flow.

I've used the Elm paradigm in Elm and in Swift on iOS. Would definitely use it again for any data-driven complex UIs like apps or big web frontends.

It's nice in elm

It's horrible in JS because of the boilerplate

It's ok in rust, at least you have types

Yeah, it's nice. I don't know what it would be like in a language with a weak/no type system (e.g. JS) though, probably annoying.

> Does anyone actually enjoy using the Elm paradigm?

Reading "Elm architecture" (https://guide.elm-lang.org/architecture/) it looks like classic MVC - they just call it Model / View / Update instead of Model / View / Controller.

If not, the rest of my comment is invalid.

> I personally can't stand the amount of boilerplate and "indirect thinking" that it requires.

Of course, just because you use a classic paradigm it doesn't mean the implementation thereof is elegant. And that might be because according to the Elm docs programmers "stumbled" upon it (reinvent) instead of designing for it: "Rather than someone inventing it, early Elm programmers kept discovering the same basic patterns in their code."

Could you elaborate on boilerplate and indirect thinking? Those are the exact opposite things I think of when I thinking of model-view-update, so I'm not sure I understand your comment.