Why doesn't JavaScript support multithreading?-Collection of common programming errors

Javascript does not support multithreading because the javascript interpreter in the browser is a single thread (AFAIK). Even Google Chrome will not let a single web page’s Javacript run concurrently because this would cause massive concurrency issues in existing web pages. All Chrome does is separate multiple components (different tabs, plugins, etcetera) into separate processes, but I can’t imagine a single page having more than one Javacript thread.

You can however use, as was suggested, use setTimeout to allow some sort of scheduling and ‘fake’ concurrency. This causes the browser to regain control of the rendering thread, and start the Javascript code supplied to setTimeout after the given number of milliseconds. This is very useful if you want to allow the viewport (what you see) to refresh while performing operations on it. Just looping through e.g. coordinates and updating an element accordingly will just let you see the start and end positions, and nothing in between.

We use an abstraction library in Javascript that allows us to create processes and threads which are all managed by the same Javascript interpreter. This allows us to run actions in the following manner:

• Process A, Thread 1
• Process A, Thread 2
• Process B, Thread 1
• Process A, Thread 3
• Process A, Thread 4
• Process B, Thread 2
• Pause Process A
• Process B, Thread 3
• Process B, Thread 4
• Process B, Thread 5
• Start Process A
• Process A, Thread 5

This allows some form of scheduling and fakes parallelism, starting and stopping of threads, etcetera, but it will not be true multithreading. I don’t think it will ever be implemented in the language itself, since true multithreading is only useful if the browser can run a single page multithreaded (or even more than one core), and the difficulties there are way larger than the extra possibilities.

For the future of Javascript, check this out: http://developer.mozilla.org/presentations/xtech2006/javascript/

Traditionally, JS was intended for short, quick-running pieces of code. If you had major calculations going on, you did it on a server – the idea of a JS+HTML app that ran in your browser for long periods of time doing non-trivial things was absurd.

Of course, now we have that. But, it’ll take a bit for browsers to catch up – most of them have been designed around a single-threaded model, and changing that is not easy. Google Gears side-steps a lot of potential problems by requiring that background execution is isolated – no changing the DOM (since that’s not thread-safe), no accessing objects created by the main thread (ditto). While restrictive, this will likely be the most practical design for the near future, both because it simplifies the design of the browser, and because it reduces the risk involved in allowing inexperienced JS coders mess around with threads…

@marcio:

Why is that a reason not to implement multi-threading in Javascript? Programmers can do whatever they want with the tools they have.

So then, let’s not give them tools that are so easy to misuse that every other website i open ends up crashing my browser. A naive implementation of this would bring you straight into the territory that caused MS so many headaches during IE7 development: add-on authors played fast and loose with the threading model, resulting in hidden bugs that became evident when object lifecycles changed on the primary thread. BAD. If you’re writing multi-threaded ActiveX add-ons for IE, i guess it comes with the territory; doesn’t mean it needs to go any further than that.

I don’t know the rationale for this decision, but I know that you can simulate some of the benefits of multi-threaded programming using setTimeout. You can give the illusion of multiple processes doing things at the same time, though in reality, everything happens in one thread.

Just have your function do a little bit of work, and then call something like:

setTimeout(function () {
    ... do the rest of the work...
}, 0);

And any other things that need doing (like UI updates, animated images, etc) will happen when they get a chance.

Do you mean why doesn’t the language support multithreading or why don’t JavaScript engines in browsers support multithreading?

The answer to the first question is that JavaScript in the browser is meant to be run in a sandbox and in a machine/OS-independent way, to add multithreading support would complicate the language and tie the language too closely to the OS.

Just as matt b said, the question is not very clear. Assuming that you are asking about multithreading support in the language: because it isn’t needed for 99.999% of the applications running in the browser currently. If you really need it, there are workarounds (like using window.setTimeout).

In general multithreading is very, very, very, very, very, very hard (did I say that it is hard?) to get right, unless you put in extra restrictions (like using only immutable data).

Intel has been doing some open-source research on multithreading in Javascript, it was showcased recently on GDC 2012. Here is the link for the video. The research group used OpenCL which primarily focuses on Intel Chip sets and Windows OS. The project is code-named RiverTrail and the code is available on GitHub

Some more useful links:

Building a Computing Highway for Web Applications

As far as I have heared Google Chrome will have multithreaded javascript, so it is a “current implementations” problem.

According to this article it is already possible to implement JavaScript threading.

It’s the implementations that doesn’t support multi-threading. Currently Google Gears is providing a way to use some form of concurrency by executing external processes but that’s about it.

The new browser Google is supposed to release today (Google Chrome) executes some code in parallel by separating it in process.

The core language, of course can have the same support as, say Java, but support for something like Erlang’s concurrency is nowhere near the horizon.

Without proper language support for thread syncronization, it doesn’t even make sense for new implementations to try. Existing complex JS apps (e.g. anything using ExtJS) would most likely crash unexpectedly, but without a synchronized keyword or something similar, it would also be very hard or even impossible to write new programs that behave correctly.