HN Explorer

Why don't modern browsers include precompiled js libraries?

9 points by seanica ↗ HN
For example, Google recommend using their CDN for a range of js libraries Why doesn't Chrome include these libs as precompiled scripts? On detecting a request for a script hosted on Google CDN, Chrome could check it's precompiled cache first and use it if available. For specific js libraries, this would eliminate some aspects of Sam Saffron's "The jQuery Tax".

The release cycles of stable versions of jQuery, jQueryUI, et al, seem to be longer than release cycles of Chrome & Firefox patches, so it kinda seems practical.

The only issue I can think of right now is potential js library bugs & vulnerabilities being 'baked into the browser'. However I'm pretty sure things like this can be solved. The first thing that comes to mind is it would be treated like any regular browser bug/vulnerability.

Are there any enlightened browser hackers that can explain why this is a bad idea?

6 comments

[ 2.9 ms ] story [ 21.8 ms ] thread
chrisacky
Chrome is light weight, unbloated, it's just one of the reasons why I'd say that it has excelled so quickly.

When it starts supporting a tonne of libraries it has to really start beefing up on it's dependencies.

So, at what point should Google allow/prevent access to their CDN. Additionally, the CDN is notoriously slow for updating to the latest versions. How would these changes them be rolled out to the browser? Through updates, or just realllly long caching?

Plus, this would then turn into a kind of DMOZ, where libraries compete to get included and struggle...

Plus the CDN supports multiple versions, does this mean that Chrome would have to support all 22 versions of jQuery?

jQuery is not a defacto library. I don't start a project and immediately think, lets include jQuery. However if it was precompiled, in Chrome, then the barrier for making this choice would be lowered, and I might find myself just including it for the sake.

I think this is totally unfair to other librariesm and it could quite possibly prevent or at least stifle innovation to some extent, since if the footprint of including jQuery in your application is zero, why not just include it, rather than try some other cool DOM project that's not included in the CDN.

bryanlarsen
"Chrome is light weight, unbloated"

Chrome might be fast, chrome might be clean, but with its one process per tab model it will never be light weight.

chrisacky
Only just saw this response bryanlarsen.

In response, I would actually say that this is an incredible feature. It makes detecting memory issues during development soooo much easier.

no_more_death
1. Browser computes hash for all JS files loaded, and tallies number of uses.

2. JS files that get a certain number of uses get marked for compilation.

3. On browser startup, the marked files are recompiled into the binary.

4. The modules are pulled in when the browser detects an HTTP requested file matches an existing file.

MD5 hashing couldn't be used, due to collision vulnerabilities!

I guess the question is whether the browser's JITter is already as fast as compiling javascript into the binary.

jensnockert
Because compiling jquery etc. is not expensive compared to the cost of downloading the script. Each version on Google CDN is already only downloaded once if the cache in the browser works correctly, so the cost is minimal.
maratd
JS libraries on the client-side are currently stagnating and will soon be dead, largely, because they won. bind, each, map, filter, etc are now part of the language, with more coming in Harmony. They are becoming less and less necessary. Even animation, the very thing that got them started, can now be done in CSS3. There's no need to include them.