What are the subtleties/implications of Javascript being single threaded?

Question

I am not very experienced in Javascript/JQuery. So I recently found out that Javascript is single threaded.
So I am trying to understand what are the implications of this:

1. When writing code
2. What is considered as bad practice to be done in Javascript as a result of this single threaded model

To give an example of what I am asking, in my mind when I found out about this, I immediately though of Java's Swing. In Java's case, the implication is that the code that is time consuming should be outside of the code that updates the UI.
Also concerning 2, I assume that an example of bad practice as a result of the single threaded nature is the recommendation to use server side push technologies instead of Ajax for real time updates. I assume this is the reason that it is preferred.

So can anyone explain the subtleties on this topic?

Answer 1

Swing (when not creating manual threads off the EDT) and browser JavaScript DOM/UI are very similar paradigms - the single-threaded/callback execution model transfers fairly well conceptually.

The same "implication" of one exists in the other - do not block the "UI thread" in any manner such that it impedes user interaction. (In my experience this is generally related to looping over or processing too large a data-set in a given event.)

SwingWorkers can be roughly thought of as Web Workers in that both provide an asynchronous abstraction over a concurrent execution context, where neither supports direct access to the UI. However, JavaScript has no way of "accidentally" touching shared data from different threads.

The use of AJAX/XHR or WebSockets in a "pull" vs a "push" approach is not directly related to the JavaScript concurrency model. They are merely separate means to the same end, and both are (nearly ubiquitously) handled asynchronously.

---

Usually, when needing to split up a long-running UI operation such as adding thousands of complex DOM elements (uhg!), I will use setTimeout in conjunction with an array acting as a queue. A trivialized non-generic example might look like the following:

function processItemsInUI (items) {
    var endTime = (+new Date) + 40 * 1000; // stop ~40ms in future
    var item;
    while ((items = items.shift()) && (+new Date) < endTime) {
       // have item, and limit not exceeded
       // processItem(item);
    }
    if (items.length) {
        // wait ~30s ms before doing more work
        setTimeout(function () { processItemsInUI(items) }, 30 * 1000);
    } else {
        // done!
    }
}

processItemsInUI(getManyManyItems());

Alternatives to the above include

1. Reducing the amount of items fetched/displayed through filters, which simply avoids issues related to an excessive amount of UI work, and;

2. Virtualizing item rendering, such as done in Slick Grid (or say a Tumblr archive view), to avoid creating DOM elements until they are actually "in view".