10

Well these days JavaScript is main player in all web development technologies , on client side for making user interface better, client side logic, on some web servers as server side logic also

Add to that the fact of people (at least some of them ) started moving in web game development from flash to javascript and HTML5

Isn't it time for it to support multi threading ! are there browsers that allow JavaScript to be multi threaded or is it there in any standards , HTML5 or future versions ?!

1
  • 1
    People don't do things that aren't required. People who have contributed in design of Javascript, are also the one who are related to webservers and browsers being developed so they knew about it. It's all about utility. Mar 4, 2012 at 7:12

4 Answers 4

9

Multi threading will not be done in EcmaScript but can be exposed in host environments.

The classic examples are WebWorkers which allows you to spin up a background worker to do work in and abusing <iframe>'s as a way to spawn new processes.

It should be noted that multi threading in JavaScript is not needed (there are exceptions, mainly graphics related programs). You don't need multiple threads, you already have an event loop for your GUI and your graphics rendering (canvas) is hardware accelerated (meaning the GPU renders your graphics in parallel for you).

Although projects like webcl are pretty exciting.

7
  • 2
    Can you expand on the fact that it "isn't needed"? I ran into an instance recently where the natural case in desktop programming would be to spawn a thread to handle the task but that obviously wasn't an easy or standard option. I worked around that case but spawning a thread seemed to be the more elegant solution.
    – Rig
    Mar 4, 2012 at 6:15
  • @rig what was the case you were trying to handle?
    – Zachary K
    Mar 4, 2012 at 6:20
  • @Rig give a concrete example. computationally expensive processing is rare in client side JavaScript
    – Raynos
    Mar 4, 2012 at 6:20
  • @Raynos please do explain more on how it is not needed ,i am only thinking not sure that in game development for example if there is heavy computation on graphics and on physics and logic frame rate will be easily affected if no multithreading is there i think
    – Ali
    Mar 4, 2012 at 6:26
  • @Ali I copped out and said there are exceptions. However most of that heavy computation should be given to the GPU through the hardware accelerated graphics API
    – Raynos
    Mar 4, 2012 at 6:29
4

NO

Multi threading is one of the hardest things in software to get right. There are way too many corner cases that are really hard to work out when your code is not deterministic. (I am talking about multi threading with locks etc). In addition all of the various JavaScript libraries are built on the assumption that it is not multi threaded.

That being said there are web workers which do give you an actor based framework for doing multi processing type of operations. You can create workers and pass data back and forth via events.

EDIT: The other reason is that when JavaScript was created it was done so with the assumption it would get used for small tasks, so no concurrency was built in. To Retrofit it now would break a lot of code. By adding web workers it has been possible to have a system were there is concurrency without any shared memory, but by using actors, a model of concurrency that has shown itself to be very robust in a number of other languages like Erlang, Scala, Clojure etc.

(IF you can't tell I really dislike lock based concurrency)

6
  • 1
    Multi threading is one of the hardest things in software to get right. - i just surprised with this! The browser you are using, OS of your desktop, the web server serving this page - practically every application that you use everyday is multithreaded. ARE YOU SURE YOU MEAN IT? Yet to downvote you, but i will if you say multithreading is not done because it is hard Mar 4, 2012 at 6:26
  • 3
    @DipanMehta multi threading is one of the hardest things in software to get right. The reason all those applications use it is because they are written by really talented people
    – Raynos
    Mar 4, 2012 at 6:33
  • @Raynos - my goodness! So you are calling me talented! I use it everyday... i think when you are C programming or any large scale application, its quite common. The point is, irrespective of usage and requirement, the W3C consortium didn't really spared it for Javascript because it was too hard! Mar 4, 2012 at 6:41
  • 2
    Your severely understating how difficult it is to write correct and efficient parallel programs. But multi threading is not in JavaScript because its unnecessary complexity (the thing was written in 3 weeks)
    – Raynos
    Mar 4, 2012 at 7:01
  • 2
    @DipanMehta getting a lock based concurrency done right, and nailing all the corner cases is a hard problem. For example an implementation of something as simple as a queue with locks that can be proven correct in all cases would have been a publishable result up until a few years ago. But more importantly trying to retrofit that onto a language that has not had it is asking for trouble.
    – Zachary K
    Mar 4, 2012 at 7:05
3

opening javascript up for multithreading will create more issues than it solves:

the current architecture is single-threaded event-based (running in the gui thread more often than not) in other words with every block of code you can be assured that nothing in the environment will change from the start to the end except what is changed in the code.

as soon as you allow preemption or parallel execution this feature will be gone, this means that you need to apply locks to data that you want to mutate plus having the whole hard to debug race conditions to avoid

it is possible to have pseudo-parallel execution using timeouts, this means splitting up large or long running functions into atomic chunks and use setTimeout(function(){nextstep(args);},1); so other stuff can run if needed

0

Intel released River Trail some time ago, which enables parallel programming in Javascript. However, it's a Firefox-only plugin and I haven't heard of a roadmap that brings this technology into W3C, much less ECMA.

Not the answer you're looking for? Browse other questions tagged or ask your own question.