[webkit-dev] GlobalScript in WebKit

[Maciej Stachowiak]

On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote:

> Reading this, I am reminded of a great commentary by Alex Russell,
> written nearly 3 years ago:
>
> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
>
> Despite of what I may think about SharedScript, I am certain that
> waiting -- whether for standards community or Web developers to
> embrace or reject our ideas -- is not the right answer. If we really
> want to move the Web platform forward, we can't afford a feedback
> cycle this long. Especially, when we have an opportunity for close
> collaboration with Web developers of some of the most JS-intensive Web
> properties.
>
> Experimenting is great. We should experiment.

WebKit (or at least the mainline) is not necessarily a great place for  
experiments. As our Project Goals say: "WebKit is an engineering  
project, not a science project." <http://webkit.org/projects/ 
goals.html>. Of course, that's a pretty fuzzy line, because sometimes  
a use case is really well proven and we're not willing to wait for  
standards groups to get their butt in gear. But there are some  
potential bad scenarios with building features that don't have a clear  
path to standardization:

1) It will be rejected by other browser vendors and end up a WebKit- 
only (or nearly WebKit-only) feature, but enough WebKit-specific  
content depends on it that we can't drop it, even if we would like to.  
Then we are stuck maintaining a dead-end technology indefinitely. It  
seems like the SQL database may be on this path.

2) It will get adopted into standards, but with significant changes  
when other implementors and standards experts jump on the bandwagon.  
These changes can cause a very painful transition, since we need to  
remain compatible with legacy WebKit-specific content, yet at the same  
time we don't want to be in violation of the consensus spec. This  
actually happened with <canvas> - it changed incompatibly in ways that  
broke a bunch of WebKit-specific content (in particular Dashboard  
widgets), but we had to implement the standard to support content  
coded to Firefox. This really sucked and we have Dashboard-specific  
hacks still lying around in our code base as a result.

So please realize, experimenting is not free. The cost can be much  
greater than the implementation cost, and may indeed last far beyond  
the experimental era. These kinds of bad scenarios are the reason that  
nowadays we try to get standards buy-in on new Web platform features  
*before* they get shipped in a mass-market product. And experience  
with these kinds of scenarios is what makes some of us very wary of  
going hog-wild with experiments in the WebKit code base. We take  
backwards compatibility for Web content very seriously, and so we  
hesitate to put anything in that we don't feel we can commit to.

As I said in my other message, I actually think a global script with  
proper DOM access is a good idea in principle, and in my opinion would  
have been a better design than SharedWorkers (and indeed, given global  
script, you can implement shared workers yourself). But we have not  
done a great job of selling it. Can we make a good case for this  
feature that will get some buy-in from the broader Web standards  
community?

Regards,
Maciej