[webkit-dev] GlobalScript in WebKit
levin at google.com
Mon Nov 30 16:29:44 PST 2009
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 30 Nov 2009, Dmitry Titov wrote:
> > That also pretty much means if we won't do SharedScript, we'll need to
> > explore other opportunities toward efficient sharing of code and data
> > which does not make people to write a multithreaded UI as SharedWorker
> > solution would do. We have practically zero positive response to
> > SharedWorkers being used this way. Granted, this is "just one company"
> > but the limited unscientific poll kind of shows the direction...
> The pushback on SharedWorkers at Google is because Google teams don't want
> to rewrite their apps to work with workers -- SharedScript lets them
> handle some of the cases SharedWorkers would get them, without having to
> rewrite as much code.
Presenting this as a SharedWorker vs SharedScript thing is a false
dichotomy. SharedWorkers and SharedScript serve different purposes for the
people who want to use each.
The majority of applications are not written to do *all* of their logic in a
background thread, so it is odd to me that it is espoused as the right
paradigm on web developers. There is a certain amount of logic that makes
sense to happen on the main thread and be shared across windows.
> However, we should not be basing the platform's progress on transition
> cost avoidance of one company. Google can afford to rewrite GMail if it
> comes down to that. It is not in the Web's long term interests for us to
> design features that are optimised for the transition phase at the cost of
> the long-term health of the Web.
On the other hand, just because there is a hammer, it doesn't mean that
everything is a nail no matter how much we want it to be.
> What we should be looking at is what API do teams prefer to work with when
> starting from scratch,
And it makes a lot of sense for new apps to do some logic that is quick on
the main thread (and not proxy it off to another thread).
> because on the long term that will be the far more
> common case than transitioning from a legacy codebase. I don't think that
> our (Google's) response is representative here.
Based on my 10+ years of experience as an app developer, I think the
response is very representative of what I'd want.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev