My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Monday, February 13, 2012

Web Workers - Current Status

A quick one about workers after few tests.

Mobile

Workers are apparently nowhere in Android devices stock browsers. The only one able to bring workers seems to be Chrome in ICS.
As alternative, both Opera Mobile and Firefox Beta work without many problems.
About iOS, version 4 does not support workers while version 5 does and quite well.

Desktop and Data URI

Workers are almost fine everywhere except IE9 ( surpriiiiiiiiiise ) but there is one thing not a single browser does except again Firefox and Opera, accepting "data:application/javascript;" with or without base64 encoded code.
On mobile side this is supported again by Opera Mobile and Firefox Beta without problems but on desktop, and not only ...
  1. Safari works only with external files while inline data uri are supported only via file protocol
  2. WebKit nightly does not support inline data uri even through File protocol
  3. Chrome does not support inline data uri neither via file protocol nor online
  4. Safari Mobile does not support inline data uri, at least online
  5. Chrome Mobile does not support them at all


Why Bother With Data URI

Quite simple, Workers are a mechanism to detach some logic from the main thread and execute it in the background. The possibility to create inline Workers means we could create a sort of Threads manager, delegating runtime ad-hoc functions to perform certain tasks handling all requests from and to the main page.

Workers Until Now Are Not Good

Not only the serialization and deserialization problem does not scale with large amount of data, probably the only reason you would think to use a worker for some job, but the DOM security exception thrown with data URI and for no reason on earth is yet another limit for this technique.
Current status, except for data URI, is that you may need webkitPostMessage rather than simply postMessage in order to at least optimize data transfer between global objects, but on the other hand, the dream we all have about "HTML5" keeps fading out every time I understand I need to prefix something, either if I use CSS3 or JavaScript (i.e. requestAnimationFrame).

Disappointed, nothing else to add.

4 comments:

Anonymous said...

In some browsers you can use window.URL and window.BlobBuilder instead of Data URI.
https://gist.github.com/1608901

Andrea Giammarchi said...

awesome, but I believe the security error would be thrown in any case, otherwise I really don't get that error at all and I will file bugs all over :-)

timb said...

"Not only the serialization and deserialization problem does not scale with large amount of data"

i'm looking forward to transferables which should fix this issue:

http://html5-demos.appspot.com/static/workers/transferables/index.html

it works in chrome 17, and i hope to see it in the other browsers soon.

Ben said...

Agree with first anonymous commenter.

//e.g. in chrome, may need other prefixes elsewhere
//open up your developer tools and you can enter this on the console at any page
//or you could put it into a page itself
var bb = new WebKitBlobBuilder();
bb.append('self.onmessage=function(event) { self.postMessage("I live!") };');

var url = webkitURL.createObjectURL(bb.getBlob());
var w = new Worker(url);
w.onmessage = function(event) { console.log(event); }
w.postMessage();