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 ...
- Safari works only with external files while inline data uri are supported only via file protocol
- WebKit nightly does not support inline data uri even through File protocol
- Chrome does not support inline data uri neither via file protocol nor online
- Safari Mobile does not support inline data uri, at least online
- 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:
In some browsers you can use window.URL and window.BlobBuilder instead of Data URI.
https://gist.github.com/1608901
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 :-)
"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.
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();
Post a Comment