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

[9oliYQjP]

This looks promising. I'm sorry I'm late to the game with the postMessage API (first time I've seen it). But I have a question about that. How does it compare to, say, Cocoa's NSNotificationCenter style of messaging, in which there is a default message center that handles receiving and dispatching? From my really brief look at it, it seems similar with one caveat: you can have multiple NSNotificationCenters. So observers don't have to observe all messages. But here it looks like every observer will be observing all messages sent. Is that correct?

As you point out here (http://ejohn.org/blog/postmessage-api-changes/) this will lead to a potential security issue in which you might be responding to messages posted by an external source. Maybe another property could be added, which I'll refer to as messagingDomains. This could be set to a string like 'http://example.com or an array of strings. Each string corresponds to a domain. If this property is set the onmessage would only be called if the origin was from the domain(s) specified in messagingDomains. It's a subtle addition to the API, yes. But it would more clearly establish the existence of a security risk here, because it would probably be propagated better in documentation than a warning to conditionally check event.origin.

For reference, here is how onmessage works right now:

observer.onmessage = function(e) {

  if (e.origin == 'http://example.com') {

    // I trust this domain, do something

  }

}

Here is what I think would make sense to clearly establish that security matters here, and as a benefit it would not break backward compatibility:

observer.messagingDomains = ['http://one.example.com, 'http://two.example.com];

observer.onmessage = function(e) {

  // By default execute accordingly.

  // However, if messagingDomains is set, only execute if the domain is mentioned explicitly

}