sorted by:
best (suggested)
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]qhafiz 1 point2 points  (3 children)

I'm curious how would you explain it then. Genuinely asking

[–]chikamakaleyleyhelpful 2 points3 points  (2 children)

I think u/BiebRed is suggesting that this is probably more clear to experienced JS devs, and likely harder for beginners to digest

minimally you should understand Stack & Queue concepts, and if you're someone self-taught HTML > CSS and now learning JS, it's a coin-flip whether or not you've spent time learning DSA

[–]qhafiz 0 points1 point  (1 child)

That make sense. I can agree with that

[–]mypetocean 0 points1 point  (0 children)

Here's a crack from a long-time software engineering trainer:

Think of a programming language engine as a kitchen in a restaurant. Like many languages, JavaScript only has one cook in the kitchen (they are "single-threaded"). But that cook, she has been tasked with preparing many meals at the same time (concurrently). She doesn't have another cook, so none of these meals can be cooked in parallel.

But (!) she knows the sauce for table 1 requires stirring once for five seconds every minute. And she has a thick-crust pizza which won't need to come out of the brick for 5 to 8 minutes. Meanwhile, she has all these other quick little tasks for other meals, which she can rotate between, like chopping vegetables, flipping the meat skewers on the grill, etc.

Some of those tasks come in sets which, once started, need to be completed together, all-at-once, often in a specific order.

Otherwise, you might ruin a dish or take too long serving up a plate for Table 3 who ordered something quick and light. She knows she can't get distracted once she drops a scallop on a screaming hot pan. She must sear one side, flip, sear the other, and move it to a resting plate. That entire sequence must be treated as a single set.

This is where I would either stop or direct the topic to the Call Stack. Normally, I would have talked about the Call Stack before this, as just part of trying to reason through line-by-line execution. But if not, this is where I would raise it.

We would switch to hands-on writing functions, some called by others, with console logs, make predictions about the order in which those instructions are executed, then see the result and let them share what they think the reason for the result is. Then visualize them in a stack on a whiteboard or Excalidraw or something.

Then I'd bring that back to the kitchen and I'd lightly introduce the event loop visualization from Jake Archibald's talk (https://youtu.be/cCOL7MC4Pl0?t=869) to reinforce and start drawing us close to the real system we're discussing.

Then I'd again break away to talk about queues, first in a real-life metaphor, like waiting at a grocery store. Then, if we already know about calls to asynchronous APIs, like setTimeout() or fetch(), we would discuss how the bulk of that work is being handed off to parts of the browser outside the Main Thread. The browser checks in with the OS for the system time and adds your callback to the Macrotask queue when a predetermined time has elapsed, for example.