JavaScript Concurrency Model and Event Loop

One thing this doesn&#x27;t touch on is the different handling of microtasks and macrotasks:<p><a href="https:&#x2F;&#x2F;jakearchibald.com&#x2F;2015&#x2F;tasks-microtasks-queues-and-schedules&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jakearchibald.com&#x2F;2015&#x2F;tasks-microtasks-queues-and-s...</a><p><a href="http:&#x2F;&#x2F;www.c-sharpcorner.com&#x2F;article&#x2F;overview-of-micro-tasks-in-knockoutjs&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.c-sharpcorner.com&#x2F;article&#x2F;overview-of-micro-tasks...</a>

&gt; A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks.<p>That seems like a dangerous, misleading statement.

Side topic :<p>The event loop architecture is also heavily used in iOS &#x2F; Cocoa, although it is often not well understood by developper. Each thread has an event loop, including the main UI thread, and many weird behaviors can be understood better once you know a bit about them.<p>Which made me wonder if a simple implementation of agent based concurrency in swift server couldn&#x27;t simply be one agent - one event loop, plus a way to prevent direct calls across agent boundaries. Server is not iOS, but i suppose some language facilities should already be there and make it easier to implement.<p>&#x2F;side topic

This doesn&#x27;t mention server-side JavaScript at all. There are lots of blocking routines in Node.js, the standard library is full of them.<p>But it is interesting that it doesn&#x27;t mention the oft repeated meme &quot;JavaScript is single-threaded&quot;. Would be nice with an example showing parallel number-crunching without WebWorkers. Is that possible?

In my time I have encountered quite a few descriptions of how the event loop works in JavaScript.<p>What I would like to find is _why_ do they work like this. What is so important that this is the way it must be done. We live with browsers that lock up for a while until they figure out that some code has inadvertantly done a while(true). Promises and similar callback amelioration techniques took ages to turn up, when without the event model they might never have been required at all. Is there a reason for this? Is it a good reason?

This reminded me of Phil Roberts&#x27; excellent talk a couple of years ago at ScotlandJS: &quot;Help, I&#x27;m stuck in an event loop&quot;. Well worth the 20 minute watch. <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;96425312" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;96425312</a>

practically speaking, I think for the most part, when folks talk about blocking execution, they are referring to the browser locking up while the long running process is running.<p>To gracefully establish expectation in the user - A processing indicator will buy the application some time before the user gets impatient. The setTimeout 0 pattern is useful to delay the long running process enough for the browser to redraw the UI to throw up the processing indicator.<p>One can further achieve another state in the processing indicator by leveraging time delayed CSS animation which runs in a thread that&#x27;s parallel to JS. So you could use CSS to augment the content of the processing dialog while the blocking JS is running.

Misleading title. There was actually nothing about concurrency in the article.