3

As libraries seem to evolve, making it easier to program, it seems people are using JS for more things that Java would have been used for in its heyday.

That said, there are many performance problems with JS that we are aware of and just one of them is the ability to optimize runtime using threads.

I saw this: Why doesn't JavaScript support multithreading?, but that was answered 3-4 years ago (and a lot changes in a year, let alone 3-4). With HTML5 growing fast, I'm even more curious if this has been given more consideration.

Community
  • 1
  • 1
vol7ron
  • 40,809
  • 21
  • 119
  • 172

3 Answers3

2

You should ask, ECMA TC39, they own ECMAScript.

But the short answer will be no, if you have long-running scripts that you want to "spawn a new thread" for you should check out WebWorkers, they run in their own context and technically on another thread.

Charles
  • 50,943
  • 13
  • 104
  • 142
Aaron Powell
  • 24,927
  • 18
  • 98
  • 150
  • I knew this was probably going to be closed, but its answers like these that I didn't mind risking that chance. – vol7ron Apr 13 '12 at 00:41
1

I think what we'll see over time is an expansion of what WebWorkers can do and how they can communicate with the main javascript thread. Today it's very limited, but there are ways that it could be made more powerful without risking the stability and simplicity of having the main javascript thread being single threaded.

For example, today you can't load images or prepare graphics in a WebWorker, but that would be incredibly useful for graphics intensive applications. You can do calculations, but are limited at that.

For example, you can't manipulate DOM objects for animations in any sort of background process. That also would be very useful - thought more complicated for the browser engine to implement.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
0

The reason JS doesn't - and probably won't - support multithreading is because it's not appropriate to the kind of work JS does, especially in the browser. Concurrent threads are useful if you have lots of CPU-bound work to do and don't mind paying the price in locking and so on. But browser JS doesn't - or shouldn't - do much CPU-bound work at all: it's an event-driven environment, so JS only needs one thread. It yields control to the browser after every block of work, waiting idly for the next event - a timer, a click, an onLoad or whatever. Concurrency would add hugely to the effort of managing all the event handlers and not add much performance - all your threads will be waiting on the same events, and unless you have a vast rate of events firing there won't be enough work to keep your threads busy.

As Slace says above, WebWorkers are intended to allow for the odd case of wanting to do CPU-bound work in browser JS, but they're not true multi-threading.

jimw
  • 2,548
  • 15
  • 12
  • jimw: that's right, except the threading limitations are one reason why JS isn't used in other ways. For instance, games, computational models, etc. Mind you, I acknowledge that JS has other problems that also hinder those applications, but still. My point is that the future of JS may include more "CPU-bound work". Then again, browsers might just be OS instances in themselves. – vol7ron Apr 13 '12 at 01:03