Elm composes just fine and you can get close to the semantics of components. I wrote this over 3 years ago, have been using it in many projects with no concerns. https://package.elm-lang.org/packages/z5h/component-result/l...

There are other ways to achieve similar. You don't end up with "big mess of hard-to-follow spaghetti code", you might end up with a "large amount of unfamiliar-looking code". Getting better at reading a larger-than-anticipated amount of unfamiliar code takes a bit of practice, then it isn't a problem. And then you have all the benefits of Elm with zero problems.

The actual hard thing about code is managing complexity, and working with "it just works" magic when it doesn't "just work".

I agree Elm has some flaws, and there is an initial up-front time investment which is unsavoury to many.

Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.

If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.

This is my anecdote though. And I've been away from Elm long enough now (around 1.5 years) that I've forgotten all the specifics.

Thanks for qualifying wrong with "arguably". I did explain in the docs that it was a design choice, but I see your valid point. My motive was to simplify calling code and require dealing with the external message. It's had the intended effect so far. I'll read over the halogen stuff.