7 ms·

Computing with JavaScript Web Workers

63 points by emontero1 17y ago

peregrine 17y ago
Javascript just keeps getting cooler and cooler. The more I learn about it the more I find myself loving it.
- Bjoern 17y ago
  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 http://en.wikipedia.org/wiki/Server-side_JavaScript
  - n8agrin 17y ago
    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 17y ago
      In that case, can I enlist your services :) I started Narwhal (a JavaScript standard library: http://narwhaljs.org http://narwhaljs.org) and Jack (a WSGI/Rack-like web server interface: http://jackjs.org 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 17y ago
        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 17y ago
        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.
      - n8agrin 17y ago
        I'm tracking your two projects on github and have also been watching ry's node project. I'm really interested in how SS-JS will develop. For one it necessarily removes the DOM model people are familiar with and it also has evolved in an environment that has fostered the growth of many interpreters without one being totally dominant. V8 and Rhino are both very manageable, it will be interesting to see how compatible they all remain and if one assumes the position as the de-facto standard.
    - bhrgunatha 17y ago
      I asked a similar question some time ago - whether Javascript will become the long sought after unifying language of web development. I was surprised that the other option seemed more appealing to people - writing interpreters/compiler in Javascript for other languages which can then run in the browser. For example see Flapjax (http://www.flapjax-lang.org http://www.flapjax-lang.org)
    - TweedHeads 17y ago
      I am waiting for that day, and I'm willing to collaborate on any project that bring JS closer to unify web development.
- ohgrayt 17y ago
  i'll be happier when john et al push through the next major lang revision this clinginess to js strikes me of stockhold syndrome. people are working themselves into a lather as to how awesome and powerful it is, but most of this power is rooted in crappy hacks. namespaces for example. or crockfords currying stuff. very hacky. js will do. it gets the job done. would i choose to code on the server side with it over python, perl, or haskell? nope
gruseom 17y ago
I'm rather amazed that this is available in Firefox and Safari today.
- ams6110 17y ago
  Running the demo caused my Safari to crash
ohgrayt 17y ago
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 17y ago
  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?
robryan 17y ago
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.
axod 17y ago
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).
- FooBarWidget 17y ago
  So what better solution are you proposing?
  - cbetz 17y ago
    Gripes: * All communication is done via strings. This is really a hack which takes advantage of the immutability of strings in JS. Maybe some kind of queueing/message passing system would be better but that is another can of worms. * Loading workers via a separate file is nice for the web, and I get the point that it makes sense for keeping workers out of the global namespace. However, I would have liked to see something function (or even object) based. All that being said. I think it is a good start and is coming at the concurrency problem from the right angle (i.e. no threads/locking).
- jeresig 17y ago
  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 17y ago
    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).
TweedHeads 17y ago
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...
- TweedHeads 17y ago
  Taking a lok at it, sending messages back and forth is retarded. Just call the damn functions by their names with their arguments since the worker itself is already threaded and sandboxed.
- jeresig 17y ago
  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 17y ago
    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.
huhtenberg 17y ago
How long until some high-traffic page owner decides to resell his visitors CPU time ?

63 points by emontero1 17y ago

peregrine 17y ago

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

Bjoern 17y ago
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 http://en.wikipedia.org/wiki/Server-side_JavaScript
- n8agrin 17y ago
  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 17y ago
    In that case, can I enlist your services :) I started Narwhal (a JavaScript standard library: http://narwhaljs.org http://narwhaljs.org) and Jack (a WSGI/Rack-like web server interface: http://jackjs.org 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 17y ago
      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 17y ago
        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.
    - n8agrin 17y ago
      I'm tracking your two projects on github and have also been watching ry's node project. I'm really interested in how SS-JS will develop. For one it necessarily removes the DOM model people are familiar with and it also has evolved in an environment that has fostered the growth of many interpreters without one being totally dominant. V8 and Rhino are both very manageable, it will be interesting to see how compatible they all remain and if one assumes the position as the de-facto standard.
  - bhrgunatha 17y ago
    I asked a similar question some time ago - whether Javascript will become the long sought after unifying language of web development. I was surprised that the other option seemed more appealing to people - writing interpreters/compiler in Javascript for other languages which can then run in the browser. For example see Flapjax (http://www.flapjax-lang.org http://www.flapjax-lang.org)
  - TweedHeads 17y ago
    I am waiting for that day, and I'm willing to collaborate on any project that bring JS closer to unify web development.
ohgrayt 17y ago
i'll be happier when john et al push through the next major lang revision this clinginess to js strikes me of stockhold syndrome. people are working themselves into a lather as to how awesome and powerful it is, but most of this power is rooted in crappy hacks. namespaces for example. or crockfords currying stuff. very hacky. js will do. it gets the job done. would i choose to code on the server side with it over python, perl, or haskell? nope

gruseom 17y ago

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

ams6110 17y ago
Running the demo caused my Safari to crash

ohgrayt 17y ago

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 17y ago
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?

robryan 17y ago

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.

axod 17y ago

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).

FooBarWidget 17y ago
So what better solution are you proposing?
- cbetz 17y ago
  Gripes: * All communication is done via strings. This is really a hack which takes advantage of the immutability of strings in JS. Maybe some kind of queueing/message passing system would be better but that is another can of worms. * Loading workers via a separate file is nice for the web, and I get the point that it makes sense for keeping workers out of the global namespace. However, I would have liked to see something function (or even object) based. All that being said. I think it is a good start and is coming at the concurrency problem from the right angle (i.e. no threads/locking).
jeresig 17y ago
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 17y ago
  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).

TweedHeads 17y ago

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...

TweedHeads 17y ago
Taking a lok at it, sending messages back and forth is retarded. Just call the damn functions by their names with their arguments since the worker itself is already threaded and sandboxed.
jeresig 17y ago
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 17y ago
  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.

huhtenberg 17y ago

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