[whatwg] Browser Bundled Javascript Repository

[Oliver Hunt]

> Pros:
> - Pre-Compiled: By bundling known JS Libraries with the browser, the  
> browser could store a more efficient representation of the file.   
> For instance pre-compiled into Bytecode or something else browser  
> specific.
I think something needs to be clarified wrt to compile times and the  
like.  In the WebKit project we do a large amount of performance  
analysis and except in the most trivial of cases compile time just  
doesn't show up as being remotely significant in any profiles.   
Additionally the way JS works, certain forms of static analysis result  
in behaviour that cannot reasonably be cached.  Finally the optimised  
object lookup and function call behaviour employed by JavaScriptCore,  
V8 and (i *think*) TraceMonkey is not amenable to caching, even within  
a single browser session, so for modern engines i do not believe  
caching bytecode or native is really reasonable -- i suspect the logic  
required to make this safe would not be significantly cheaper than  
just compiling anyway.

> - Less HTTP Requests / Cache Checks: If a library is in the  
> repository no request is needed. Cache checks don't need to be  
> performed.  Also, for the 100 sites you visit that all send you the  
> equivalent jquery.js you now would send 0 requests.  I think this  
> would be enticing to mobile browsers which would benefit from this  
> Space vs. Time tradeoff.
I believe http can specify how long you should wait before validating  
the cached copy of a resource so i'm not know if this is a real win,  
but i'm not a networking person so am not entirely sure of this :D

> - Standardizing Identifier For Libraries: Providing a common  
> identifier for libraries would be open for discussion.  The best  
> idea I've had would be to provide the SHA1 Hash of the Desired  
> Release of a Javascript Library.  This would ensure a common  
> identifier for the same source file across browsers that support the  
> feature. This would be useful for developers as well.  A debug tool  
> can indicate to a developer that the script they are using is  
> available in the Browser Repository with a certain identifier.
This isn't a pro -- it's additional work for the standards body

> Cons:
>
> - May Not Grow Fast Enough: If JS Libraries change too quickly the  
> repository won't get used enough.
> - May Not Scale: Are there too many JS Libraries, versions, etc  
> making this unrealistic?  Would storage become too large?
- Adds significant spec complexity
- Adds developer complexity, imagine a developer modifies their  
servers copy of a given script but forgets to update the references to  
the script, now they get inconsistent behaviour between browsers that  
support this feature and browsers that don't.

--Oliver