

Computing with JavaScript Web Workers - emontero1
http://ejohn.org/blog/web-workers/

======
peregrine
Javascript just keeps getting cooler and cooler. The more I learn about it the
more I find myself loving it.

~~~
Bjoern
I can only second that, also since JS is runnable Serverside you can do alot
of funny things.

<http://en.wikipedia.org/wiki/Server-side_JavaScript>

~~~
n8agrin
I have a feeling that server-side js will eventually become a major player in
the web world, especially if solid, reliable implementations are created. The
idea of having a uniform language to communicate between the server and client
with a decent data transportation format (JSON) has been something I've long
for, enough so that one of my New Year's resolutions was to start contributing
to a SS-JS implementation this year.

~~~
tlrobinson
In that case, can I enlist your services :)

I started Narwhal (a JavaScript standard library: <http://narwhaljs.org>) and
Jack (a WSGI/Rack-like web server interface: <http://jackjs.org>) earlier this
year with the intention of bringing JavaScript up to par with Ruby, Python,
etc.

There are other nice SSJS products, but they're all very monolithic and self-
contained (in a bad way). I'm hoping Narwhal will be more modular and open,
like we have with most other languages.

~~~
peregrine
I am really looking to use V8 more then anything. Rhino is nice but the
momentum is with V8. The issue with those is that a feature is Java library
support and I personally would prefer native libs then some hack to make Java
libs work.

~~~
tlrobinson
So one of the cool things about Narwhal is it was created with the goal of
supporting multiple interpreters. Where possible, code is written in
JavaScript to facilitate sharing between interpreters. For example, the
"binary" module is currently about 700 lines of JavaScript, plus about 100
lines of C/C++ or JavaScript per platform.

While Rhino is currently the most complete Narwhal platform (mostly due to the
ease of prototyping in it) We've also started working on V8
(github.com/tlrobinson/narwhal-v8/) and JavaScriptCore
(github.com/tlrobinson/narwhal-jsc) support. They're still very incomplete but
it's a start.

------
axod
Web Workers look ugly to me :( Sad that they thought of this as a good idea.
It's just a horrible hack that'll lead to horrible code.

Threads are usually misused. When you add threads and it speeds up your code,
you're usually doing something terribly wrong (When #threads>#cores).

~~~
jeresig
I don't really understand what you're upset about - you don't like how they
look and you're worried that they're a hack? Are you familiar with the current
situation of processing in JavaScript? It involves running chunks of code,
split up using delayed timers, that constantly block the user interface from
being usable. If you want to talk about something that doesn't look good and
is hacky - that's what you should be railing against.

~~~
axod
That current situation is basically extremely powerful. It's effectively doing
your own time slicing. In terms of code, to me, it's pretty.

IMHO it'd be far nicer just to speed js up and perhaps create some helper
functionality to aid in splitting chunks of work up into bite size pieces, and
make it more optimal.

It'd be much nicer to just have some yield statement which allows you to say
"Hey, it's ok if you process any pending UI events, timers etc etc here". That
way you could just have a single main loop with some yields in the right
places. It'd create simpler, more maintainable code, and there's no reason
it'd be slower or less responsive UI wise than the web worker version.

I can see the examples where web workers can be useful, where you're doing
really CPU heavy backgroud work such as image processing etc. But I think
people will end up using web workers for far more than that, which will make
for some ugly code (IMHO).

------
robryan
So now any website could setup a web worker in the background of pages to
massively improve there processing power.

Very cool feature though, makes the entry level to distributed processing very
low.

------
huhtenberg
How long until some high-traffic page owner decides to resell his visitors CPU
time ?

------
gruseom
I'm rather amazed that this is available in Firefox and Safari today.

~~~
ams6110
Running the demo caused my Safari to crash

------
ohgrayt
tragedy of the commons. wow, i just can't wait for every amateur web designer
to take up the mantle of threaded coding.

get used to "kill -9", you're going to be using it to preempt all this
amateur-hour worker code people slap together and foist on you

~~~
DrJokepu
I can't say I agree with that. Actually I think that an easily-accessible code
interpreter sitting inside a browser, with a language and runtime capable of
delivering spectacular stuff in just a few lines can nurture a future
generation of programmers, not unlike the generation raised on easily
accessible basic interpreters on various 8-bit computers in the 70s and 80s. I
don't think denying access for beginners to powerful but harmless tools (it
sits inside a browser) is a good idea, how could they become experienced
professionals such as you then?

------
TweedHeads
Why web workers can't take a function or an object?

    
    
      myobject={
        start:      function(){ /* do stuff */ }
        stop:       function(){ /* end worker */ }
        postMessage:function(){ /* communicate */ }
        onmessage:  function(){ /* receiving data*/ }
        onerror:    function(){ /* handle stuff */ }  
      }
      
      myworker = new Worker(myobject);
      myworker.start();
      myworker.postMessage("dostuff");
      myworker.stop();
    

Or something like that...

~~~
jeresig
That can't work because the individual methods may contain a closure to a non-
threadable object (like the DOM). The reason why all of the logic is forced
into in an external script is to prevent contention from occurring - your
proposed solution definitely would not allow for that.

On the other hand, allowing for an easy way to call global functions of the
child worker would be really nice.

    
    
       var worker = new Worker("worker.js");
       worker.start();
    

Child Worker:

    
    
       start = function(){
         // Gets called by the parent
       };
    

That would be sexy and surely simplify a lot of logic surrounding message
passing.

~~~
TweedHeads
Point taken, then let me rephrase that.

Threads we can fire and forget. Threads we can start "inside" our script and
let them work while we do other stuff.

    
    
      myfunnyfunc = function(){/* do long funny stuff */}
      mycallback  = function(){/* do something when done */}
      
      mythread = new Thread(myfunnyfunc,mycallback);
    

Asynchronous like xmlhttprequest, just a way to replace the "settimeout" hack.

