Would JavaScript fare any better had it been multithreaded

Question

This is a follow up question to Is there a point to multithreading?

If JavaScript were multithreaded, would it fare better than the existing system? Would multithreading with one UI thread and other tasks in different threads (background) bring in greater responsiveness and efficient usage of resources?

Why did the designers of the language decide to stick on to the single threaded model despite the advancements in no of CPUs/machine and the need to simultaneously pull different content and data from different mechanisms. Why are they still ok with the way JavaScript timers work when multithreading can offer far greater accuracy?

I am not trying to pin down JavaScript as inefficient, rather learn how multithreading brings in value in comparison to complexity it introduces to programming

Answer 1

If JavaScript were multithreaded, would it fare better than the existing system?

What are you exactly referring to when you say "the existing system"? The exiting Javascript embedded in your browser? Or standalone Javascript implementations?

I am not trying to pin down JavaScript as inefficient

A language by itself isn't efficient or inefficient, it's implementation is. :-)

Would multithreading with one UI thread and other tasks in different threads (background) bring in greater responsiveness and efficient usage of resources?

Rhino, the Javascript on JVM in Java can access and use threads and any other Java library, so yes, you can script up an entire Swing application in Javascript and it would work like any other Swing application in Java out there.

Anyways, the question of how multithreading brings value in comparison to the complexity it introduces is not specific to any language as such. There are some languages out there which provide a pretty good wrapper around the multithreading capabilities offered by the runtime, so don't. Multithreading is difficult but more so important these days given that we have multicore processors powering our everyday use desktop machines. :-)

Answer 2

Multithreading would not have made a difference to JavaScript, even now with WebWorkers, we don't need it much for most JS applications. Only now that JS is moving server side and bigger applications are written that are WebWorkers becomming useful and webworkers is infinatly better and easier then multithreading.

Next to webworkers, JS, server side JS in particular is also leaning towards asynchronous processing, further alleviating the need for linear processing.

In the past and even to this day, a majority of client side applications written in JS simply do not need multithreading as JS engines are also getting better and faster with HTML/CSS rendering being boosted by hardware acceleration as well.

And there's another nice thing, with JS (server to client) we can easily move a lot of processing to the client side, basically attaining a huge network of computers to do all the computing without clients needing to install fancy programs (just the browser).

Answer 3

Brendan Eich (Mozilla's chief technical officer) talked about the complexity this would create in "Threads suck".

His conclusion: "So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"

Using web workers is the alternative.