joepeck02 at gmail.com
Mon Jun 15 12:27:25 PDT 2009
>> - 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
> 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.
I noticed this came up on the WebKit mailing list recently and they
said the same thing as you, that compile time was insignificant.
Thanks for expanding on this:
Although this response sounded slightly more promising:
>> - 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
I believe you're correct. HTTP E-Tags and Expires headers can
influence browsers to cache resources for very long times.
Unfortunately I don't think that a lot of developers take advantage of
these tags (this is a bad argument but worth mentioning). Although
Yahoo's Y-Slow and Google's Page-Speed extensions have opened many
developers eyes to ways they can improve their site's performance.
The real gain however, would be if you visited 100 different websites
that all needed the same script and you wouldn't have to make a single
request, or cache a single resource, due to using the script in the
repository. I think this sounds better.
>> - 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
>> 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
You are correct. I'm not too familiar with the process behind the
specifications (although I would like to learn). Maybe including this
as a "Pro" was premature, but having a hash value like a SHA1 be the
identifier has a number of advantages. Maybe there are better
solutions out there that have the same advantages that a SHA1 would
>> - 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.
Significant spec complexity? I'm too inexperienced to know. =(
As for the developer scenario this is similar to modifying any single
attribute on a tag and not appropriately modifying the others. Change
the "src" on an <img> and not changing the "alt". Change the "href" on
a <link> and not changing the "media". I think this could be easily
avoided with validation. If the unique identifier were a SHA1 hash
and the referenced script "src" does not hash to the provided value,
then the page would invalidate with an error/warning.
However, you raise a good point, and I can't come up with any truly
equivalent analogy to any other existing developer specific problem.
Thanks for the points Oliver. Looks like a few of the Pros may have
been eliminated. Do you think this could produce any noticeable
More information about the whatwg