5 ms·

This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, th

This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc). useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.

littlecranky67 3y ago
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.
- SahAssar 3y ago
  > 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).
  - littlecranky67 3y ago
    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.
    - SahAssar 3y ago
      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).
paulddraper 3y ago
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.
- danielvaughn 3y ago
  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.
  - c-hendricks 3y ago
    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.

littlecranky67 3y ago

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.

SahAssar 3y ago
> 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).
- littlecranky67 3y ago
  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.
  - SahAssar 3y ago
    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).

paulddraper 3y ago

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.

danielvaughn 3y ago
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.
- c-hendricks 3y ago
  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.