It seems like both a strength and a weakness of the Angular ecosystem. Maybe the testing story needs to improve? I can’t recall how exhaustive marbles are, and maybe fuzzing might help catch gotchas?

Honestly I thought RxJS would benefit a ton from a visual builder. They have this decision tree tool for helping figure out which operators you need to use, but you could go further and actually build out entire observables in a similar way, plotting out the system and behaviours visually along the way.

When you have such excellent boundaries and well defined behaviours, but observables can become complex so easily, it seems like a great opportunity to visualize and constrain things with tools which generate the code you need.

I know some might find that gets in the way of programming, but I have a feeling it would help those who struggle with RxJS produce far more stable observables.

This is actually why I began using XState for a lot of things. Although I can write out all of the logic myself easily enough, their tooling seems like it’s on a very promising path to making complex state management far more approachable to people with less experience. Having well defined state, transitions, and a great testing story is huge in avoiding the kind of buggy mess I’ve seen and you seem to be describing around Angular.

Point of fact, I just started a new job and am already being thrown into fixing their state machine code (not javascript / ts though). I can't say that what they're doing requires fewer lines, tests or has fewer bugs than if they'd just written it out without the whole state machine concept. I can say that it would certainly be a lot simpler and more flexible, though.

I've been hesitant to use state machines for anything complex... I find they work great for small-ish things like an image uploading component in the front end, where the states are very well defined, there is a sort of flow, predictable actions need to be taken, etc.

I've wondered a lot about composing machines. It seems like it could be extremely useful and powerful. The actor model is the approach the XState team is taking and it seems promising, but some things holds me back. The API is certainly one reason, but it's the mounding complexity that scares me more. Like you say, it seems like it could get really messy.

I have a feeling with a good enough API this problem could be reduced, but that's not a trivial thing to figure out at all. I'd love to see it happen, though.