As I mentioned in Part I, the Web Worker API is available for use in Firefox 3.5+, Safari 4+ and Chrome 4+, however the implementations are inconsistant. This has been completely overlooked by every single tutorial I’ve found.
The issue revolves around the accepted argument to postMessage() (from both the main window and the worker).
The Gecko (FireFox) implementation has excellently allowed us to pass almost anything: JSON, Objects, Strings, Numbers, Booleans, Arrays, etc. through postMessage() and have them arrive on the other end as expected. In reality, postMessage() natively serializes (read: stringify) the argument before sending it to the worker and vice versa. Security risks are minimal, because all that goes through the pipes are strings, as long as the developer isn’t irresponsibly using eval() inside the worker. (Any use of eval() should be considered irresponsible).
On the other hand, the WebKit (Safari & Chrome) implementation is limited to strings. Just strings. Got it? Strings. That’s it.
In order to level the playing field, the following code would have to be used consistently throughout your application if you wanted to use something other then strings to pass messages. Take this example:
Then in the worker…
Get these files from GitHub
…and run them in either FireFox, Safari or Chrome,they will all produce the same results, despite passing an object as an argument. (Requires a javascript console to see the results)
Continued in Part III
*Edit*
In the time since this was originally published, Chrome, Safari & Opera now support complex JSON messages.
5 Comments
I wouldn’t make standards-compliant browsers have to do extra serialization and deserialization. You should just check if the data property is a string, and always send an object, as shown in my JSandbox library for example.
Another reason to not force always encoding to JSON: ImageData objects can be passed through postMessage(), but can’t be serialized into JSON.
Thanks for your feedback.
The spec doesn’t actually state what the ‘message’ should be, so there is no standard to be compliant to.
The problem with your suggestion is that it’s backwards to the inconsistency… You can’t always send an object, but you can always stringify an object and always send a string.
Rick: You can always send an object with a toString method. Methods arn’t sent via postMessage() so it gets discarded by Gecko and for WebKit, it is called before sending the message, and JSON.stringify also discards methods.
The toString object method idea is a good possible solution as well, however is not the one used in Hive/Pollen
2 Trackbacks
[...] Continued in Part II [...]
[...] http://weblog.bocoup.com/javascript-web-workers-from-basics-to-jquery-hive-part-ii-browser-implement... [...]