> I think that the Promise API was not the actual thing people directly wanted (and on its own had no compelling reason to be added to the base library), but a standardised Promise API was needed in order to add the hugely useful async/await keywords which are unachievable without changes to the language.

In JS, the async syntax is largely syntactic sugar around chaining promises with `.then()`. Promises alone fixes callback hell and brings structure and scoping to multi-stage async operations - at least to the extent possible in such a dynamic environment as JS. There are only a couple minor additions relating to the main entry points, microtasks and interactions with the runtime, to make the main async/await experience we enjoy today. This is actually a good thing, when you can build abstractions on top of other core constructs, without affecting the rest of the language too much.

There may absolutely be analogous syntactic ergonomic constructs on top of signals, reactivity or observables - whichever is sensible - that could be layered on top to compose really powerful user-facing features in the future. So the success of promises and async is a still a supporting story, in my view. A lot more research and scrutiny is needed, but it’s certainly one of the top interesting ideas.