- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 12 Jul 2009 21:49:49 -0700
On Sun, Jul 12, 2009 at 8:58 PM, Ian Hickson<ian at hixie.ch> wrote: > On Mon, 15 Jun 2009, Joseph Pecoraro wrote: >> >> A while back I came across this two paragraph blog post titled "Browsers >> Should Bundle JS Libraries:" >> http://fukamachi.org/wp/2009/03/30/browsers-should-bundle-js-libraries/ >> >> The premise is basically that browsers are repeatedly downloading the same >> javascript frameworks from different domains over and over every day. ?In the >> author's own words: >> "All popular, stable Javascript libraries, all open source. All downloaded >> tens of millions of times a day, identical code each time." >> >> Below is a summary and expansion of my comments/ideas from the discussion on >> the above blog article. >> >> A typical solution to the problem, and one that works right now in browsers, >> is that if you require a javascript library on your website you can point to a >> "publicly available" version of that library. ?If enough sites use this public >> URI then the browser will continually be using that URI and it will be cached >> and reused by the browser. ?This is the idea behind Google's Hosted Libraries: >> http://code.google.com/apis/ajaxlibs/ >> >> There are some arguments against using Google's Hosted Libraries: >> http://www.derekallard.com/blog/post/jquery-hosted-on-google-and-some-implications-for-developers/ >> >> However, I think the author makes a good point. Bundling the JS >> Libraries in the Browser seems like it would require very little space, >> could even be stored in a more efficient representation (compiled >> bytecode for example), and would prevent an extra HTTP Request. ?The >> problem then becomes how does a browser know example.com's jquery.js is >> the same as other.com's jquery.js. The developer should opt-in to >> telling the browser it wants to use a certain JS Library version that >> the browser may already know about. >> >> The way I thought about it was by adding an attribute to the <script> >> tag. > > I would recommend approaching the browser vendors directly and seeing if > they would be interested in implementing this idea, as discussed in this > FAQ entry on introducing new features: > > ? http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F As a browser vendor (or at least someone working for one, specifically on script-loading), I would definitely be interested in something like this. However there are some hard problems to be solved: 1. How do we choose which libraries to pre-package? I'd rather not be in charge of ruling which libraries are popular enough or cool enough to warrant inclusion. It'd be very nice if the "library cache" were populated dynamically as the user used the web. That way even less commonly used libraries could be cached if a user happened to be browsing a lot of sites that used that particular library. 2. How do we deal with identifying libraries. As Aaron Boodman pointed out, SHA hashes means that you can't make upgrades for security problems etc. 3. Compat when the browser doesn't have a library cached. A solution that includes using a different uri for browsers that do support caching than browsers that don't is scary since there is a big risk that the author will forget to update one but not the other. I believe all these problems are solvable, but they do need to be solved before considering inclusion in any spec. I'm also not convinced this needs to be included in the HTML5 spec, but that might depend on what the ultimate solution looks like. / Jonas
Received on Sunday, 12 July 2009 21:49:49 UTC