On Thu, Oct 27, 2011 at 00:52, Ryan Grove <ry...@wonko.com>
On Wed, Oct 26, 2011 at 4:34 PM, The Configurator <config...@gmail.com>
As far as I know, the existing syntax doesn't allow falling back to access the scripts locally. If you use yui.yahooapis.com and that is down, or blocked for a specific user, how do you specify to the browser that it should use a local server version instead?
Existing syntax allows for error handling on script nodes, which makes it possible to provide failure fallbacks. But I agree that this is something that could be made easier. I think that could be a separate proposal from the <library> proposal, though.
I stand corrected - apparently it is possible, though inelegant. There should be a way to load scripts that's baked into the language rather than document.write('<script>'), but I digress.
This syntax also provides something else which I should have mentioned in the original email but slipped my mind - it doesn't actually specify the CDN. It just specifies which library you want. So if there are Google's, Microsoft's, Yahoo's CDN etc. installed on a user's machine, it would check them all, or be smarter about it and have a list of current items in each CDN so that it can just request it from the one that is fastest on that user's connection. Since libraries are signed they are guaranteed to be legit, and thus the using site would work with any of them quite happily.
There are a couple of things that worry me about this.
As a library user, I want to have full control over which CDN gets used for my site. If some users get directed to one CDN while others get directed to another depending on which browser they're using, which version of that browser, or potentially their geographical location, I have no way of reliably pinpointing or reproducing issues a user reports that may be related to a malfunctioning CDN, stale CDN cache, etc.
Libraries are meant to have one and only one representation per version, so that it actually wouldn't matter - any library will be served the same by any CDN that has it. Maybe signing is not enough to guarantee that, but I like to think that it is. So the user should actually not care where the library comes from - only that it's there, reliably, and that it's the right contents. A library, once published, has to be immutable.
As a library user, I definitely don't want to know which CDN gets used for my site. That's my main motivation for posting this suggestion.
As a comparison, look at an app store or market, or at apt-get, or at ruby gems. All of these have one thing in common: even though I've used all of them, I have no idea where the data came from. And they all work great. I want the same thing - but for client-side libraries.
As a library developer, I know that not all CDNs are created equal. A library like jQuery, for instance, has different CDN needs than a library like YUI. Loading YUI from a CDN that doesn't support combo-handled requests can result in poor performance because YUI is highly modular, whereas jQuery is delivered as a single file. Would browsers be expected to know that, when loading YUI, they should always prefer yui.yahooapis.com over ajax.googleapis.com?
The way I envisaged it, the CDN would have to support whichever protocols are required by the library to host it. I would also assume requesting multiple files at one time has to be possible for most libraries even though it isn't for jQuery.
I also think browsers should keep track of which CDNs are quicker in general so they can make intelligent choices. And when CDNs publish lists of library they could say "I provide yui but only partial support for required features", so a browser could know to prefer one with full support if it exists.
It seems like <library> would replicate much of the behavior of <script>, but with some extra baked-in sugar to make loading libraries easier. I like the idea of making failure fallbacks easier to implement, but I think that should be decoupled from the idea of baking predefined CDN knowledge into browsers.
True, we need better ways to fallback. I don't think this detracts from the idea of standardising CDNs.
About the benefits of caching: you make a valid point. However, using CDNs more is exactly what we should strive for - and having a special syntax for it is one thing that can make it more mainstream.
I'm not sure I agree that a special syntax would make CDN usage more mainstream, but I definitely agree that CDN usage (and particularly the usage of common shared CDNs rather than site-specific CDNs) should be encouraged. Google's doing a pretty fantastic job of this, as is cdnjs.com
In short, this idea combines the following:
- CDNs which 'just work',
- bundling some script files and some css files as a single library,
- a simple fallback mechanism.
I'm not sure it's a perfect idea, but it still sounds good to me.