[whatwg] Browser Bundled Javascript Repository

Joseph Pecoraro joepeck02 at gmail.com
Mon Jun 15 14:28:01 PDT 2009


> Chris Holland: But you're right, this is all a lot of end-user  
> intervention: it would
> be a slightly, err, very painful process of installing a browser
> plugin, which is currently very-much of a user opt-in process, and not
> something very practical.
>
> [...]. I'm just trying to find ways to leverage a lot of what's  
> already there.

Yes, I don't like the idea of requiring users to act.  But I see what  
you were tying to do with reuse.


> Interesting thing is the same scheme could be leveraged for local CSS
> extensions:

I thought about this as well, but CSS is far less likely to be  
duplicated across multiple sites.  There are plenty of CSS Frameworks  
but I feel that none have picked up enough dominance for this kind of  
optimization to be useful.

You do mention what looks like urn schemes and extending this idea to  
CSS.  I was specifically thinking of javascript because of its  
widespread use of libraries/frameworks.  Using URN Schemes could let  
this repository idea extend to more then just javascript, however I  
don't think any other type of resource (CSS, Images, Etc.) have this  
unique pattern of "the exact same content being served on thousands of  
different domains."


> <link rel="local:extension"  type="text/css" href="ext:ibdom. 
> 0.2.js" />
>
> To handle users who don't have the "ibdom" javascript extension
> installed, developers could add something like this to their document:
> (assuming a decent library which declares a top-level
> object/namespace):
>
> <script type="text/javascript">
> if (!window.IBDOM) {
> var newScript = document.createElement("script");
> scr.setAttribute("type","text/javascript");
> scr.setAttribute("src","/path/to/ibdom.0.2.js");
> document.appendChild(newScript);
> }
> </script>

Although the idea is the same (have a fall back plan if a repository  
lookup is ignored or fails), I think this is needlessly complex  
compared to just adding a new attribute on the <script> tag.  By  
extending the script tag you already have fall back behavior to just  
download the script from the "src" attribute.

If you take the <link> approach then you're practically requiring that  
you need to write fault tolerant code like you showed above, and that  
is no fun for web developers.


------

The more I think about it, the more I think this might not necessarily  
be a web standards idea.  More of a browser optimization, however it  
would never take off unless it was standardized.  I don't know what to  
do about this... CDN Caching, like Google's Hosted Libraries, is more  
generic but less optimized.  Maybe this is just a special case?

- Joe



More information about the whatwg mailing list