[whatwg] Browser Bundled Javascript Repository

[Tab Atkins Jr.]

On Mon, Jul 13, 2009 at 2:01 PM, Aryeh Gregor<Simetrical+w3c at gmail.com> wrote:
> I'm not sure how useful this would actually be, though.  Are there
> really *so* many sites using the *exact* same version of jQuery or any
> other single library?

Yes there are.  jQuery doesn't put out very many updates, and I don't
think most people alter their jQuery file.

Remember that this would also help with, frex, plugins for jQuery.
Some of them (especially the jQuery UI plugins) are really fat, and
being able to cache them across many sites could be useful.

> It seems like a better idea would be to get all
> the valuable user-created APIs standardized and implemented in some
> form cross-browser, as a few (e.g., getElementsByClassName) have been.
>  Then the common uses of jQuery or whatever would just be
> compatibility layers for legacy browsers.  Kind of like how a bunch of
> Boost is getting added to standard C++.  Of course, this requires more
> effort, but it's more likely to actually work, in the long term.

That'd only address the things that the various vendors can agree are
'standard' enough to push into a common API.  It would also mean that
legacy browsers break completely, as you're depending on the browser's
built-in libraries that don't exist in older versions.  It's much
better to lean on existing files so that older browsers download them
like normal, and newer browsers download them once and then cache them
across the web.

>> 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.
>
> The most obvious place to solve this seems to be HTTP, not HTML.  HTTP
> is closer to the resource itself.  If you do something with HTML, like
> an extra <link> attribute, then you're going to get authors updating
> the HTML but not the thing it points to or vice versa.  An ETag-like
> solution would be implemented either in the web server or whatever
> script is serving the content, and those should always know whether
> the file has changed.  (Modulo pathological behavior like something
> changing the file and then forging the mtime/ctime.)
>
> So yeah, doesn't seem like something for HTML 5.

Agreed, and your approach seems workable to me.

~TJ