Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that.

Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.

> As long as the JavaScript VM and the DOM uses non-blocking async models

The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).

While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.

It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).

THAT'S THE BEAUTY OF IT!

Thing about async/await.

  const a = await doThing();
  const b = await doOtherThing();

The order of the written code and the order of the executed codes are two different things. Being able to write code in proximate/logical order is a enormous relief, even if things don't actually happen like that.

Same with hooks.

To be fair I wasn't very clear, but what I meant was like this:

  function SomeComponent({ someProp }) {
    function doStuff() {
      // do stuff
    }

    useEffect(doStuff, [someProp])
  }

This trivial example is easy to read, but as more state and effects get added to a component, it quickly becomes fairly cumbersome to figure out the exact order in which your code runs.

They're side effects, by the very nature of them, if you're putting them in your code you shouldn't care which order they run.