Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cdnjs - the missing cdn

cdnjs.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Cdnjs - the missing cdn

#71

Post by ryankirkman »

jsdalton wrote: post #65
jonny_eh wrote: post #63

Earlier quoted context omitted.

Maybe they'll only support version that were released from the date that library was added to the CDN. In other words, hopefully once a library+version are added to the CDN, it's supported for a long long time.

Yes, I think you are correct. Digging deeper, I see that libraries are added via pull request and that the Nivo Slider library was added 11 days ago. Other libraries that have been there longer (such as jQuery) continue to have old versions.

We'll host any version of any library. It's just that no one typically adds versions of libraries older than we currently host.

Re: Cdnjs - the missing cdn

#72

Post by bdcravens »

mdlthree wrote: post #39

What do providers get for access to these type of files? Can they capitalize on the information gathered from file requests? Adding to their knowledge of traffic patterns etc...

As it's sponsored by CloudFlare, I suspect it makes for a good Case Study for them.

Re: Cdnjs - the missing cdn

#73

Post by ryankirkman »

ceejayoz wrote: post #52
Sidnicious wrote: post #51

Earlier quoted context omitted.

FWIW, the libraries they host still seem to be getting served normally, so that’s a good thing.

Sort of. I'm still not sure I want to use a CDN that can't keep its main site up. How do I know their .js files won't expire out of the CloudFlare cache before the site comes up, for example?

It doesn't work like that.

The CDN portion is completely independent of the website. The website is really just an index of the files on the CDN.

Re: Cdnjs - the missing cdn

#74

Post by ryankirkman »

jonny_eh wrote: post #63
jsdalton wrote: post #61

What's the policy on previous versions of libraries? I noticed, for example, that only the latest version (3.1) of the jQuery plugin Nivo Slider is available. The last versions ( Given that the previous version was released in May 2012 that's an insanely fast deprecation policy for a CDN. I have to guess that either I've stumbled upon a bug or minor oversight in this case, because I can't see how removing old version…

Maybe they'll only support version that were released from the date that library was added to the CDN. In other words, hopefully once a library+version are added to the CDN, it's supported for a long long time.

Once a library is hosted it stays hosted forever.

Re: Cdnjs - the missing cdn

#75

Post by ay »

mikeash wrote: post #44
rachelbythebay wrote: post #33

Earlier quoted context omitted.

We need to extend the baseline notion of what the web is. If some nontrivial number of sites are using (say) jQuery, then it would be a good idea to have a way to declare "SCRIPT SRC jQuery version x.y.z" and let the browser figure out where it lives. Then you fetch it once, parse it once, and run it many times, no matter what site you may be visiting. Or at the very least, we need some way to say "get this script fr…

It seems to me that the best way to handle this would be a content-addressable system with a more traditional fallback. You'd declare that you want file with SHA-256 (or whatever) hash of XYZ. If the browser has it, then you're done. If the browser knows where to find XYZ, then it can go off and grab it however it feels like. For compatibility, you'd also specify one or more traditional URLs where you think that cont…

I think we already have this system - it's the browser's cache. Consider the following sequence of steps:

1) add the "SIG" values to the tags in the HTML page that have SRC attribute. Be it scripts, or images, or iframes, or what not. So far, we've just bloated the page a bit with no good effect for the user.

2) update the code in the browser to calculate for each resource in the browser's cache the values of a few "frequently used" signatures, and allow the signature-based access to the content [compressed trie?], in addition to indexing the cache by the URL. Now, the "bloat markup" from step 1 starts to kick in - and you can reuse web-wide all sorts of resources - scripts, downloadable fonts, artwork, whatever. At this point the user spends the time only on the first download of the file, even if that file comes from a very slow VPS.

This approach could dramatically decrease the load on the CDNs for the frequently-repeated content, and get the latency down to near zero, so it would be much better than even the ISP-hosted CDNs.

Maybe anyone is reading this who is familiar with the FF/Chromium codebase to comment on the feasibility of such an approach ?

Re: Cdnjs - the missing cdn

#76

Post by mikeash »

ay wrote: post #75
mikeash wrote: post #44

Earlier quoted context omitted.

It seems to me that the best way to handle this would be a content-addressable system with a more traditional fallback. You'd declare that you want file with SHA-256 (or whatever) hash of XYZ. If the browser has it, then you're done. If the browser knows where to find XYZ, then it can go off and grab it however it feels like. For compatibility, you'd also specify one or more traditional URLs where you think that cont…

I think we already have this system - it's the browser's cache. Consider the following sequence of steps: 1) add the "SIG" values to the tags in the HTML page that have SRC attribute. Be it scripts, or images, or iframes, or what not. So far, we've just bloated the page a bit with no good effect for the user. 2) update the code in the browser to calculate for each resource in the browser's cache the values of a few "…

I'm a bit confused, how does this qualify as "we already have this system" when your step #2 is "update the code in the browser"?

Aside from that, yes, this sounds pretty much like what I'm thinking of.

Re: Cdnjs - the missing cdn

#77

Post by acconrad »

Front-end guy here, curious about CDN access on mobile - is it faster to serve one CSS and one JS minified file through a private CDN (like CloudFront), or use something like CDNJS to make concurrent CDN calls with many smaller files spread across a connection?

Re: Cdnjs - the missing cdn

#78

Post by ay »

mikeash wrote: post #76
ay wrote: post #75

Earlier quoted context omitted.

I think we already have this system - it's the browser's cache. Consider the following sequence of steps: 1) add the "SIG" values to the tags in the HTML page that have SRC attribute. Be it scripts, or images, or iframes, or what not. So far, we've just bloated the page a bit with no good effect for the user. 2) update the code in the browser to calculate for each resource in the browser's cache the values of a few "…

I'm a bit confused, how does this qualify as "we already have this system" when your step #2 is "update the code in the browser"? Aside from that, yes, this sounds pretty much like what I'm thinking of.

I thought you had in mind a totally new content delivery mechanism to fetch the data by hash from the network, relative to that adding the content addressability to browser cache is near trivial. Apologies if I misunderstood.

Re: Cdnjs - the missing cdn

#79

Post by mikeash »

ay wrote: post #78
mikeash wrote: post #76

Earlier quoted context omitted.

I'm a bit confused, how does this qualify as "we already have this system" when your step #2 is "update the code in the browser"? Aside from that, yes, this sounds pretty much like what I'm thinking of.

I thought you had in mind a totally new content delivery mechanism to fetch the data by hash from the network, relative to that adding the content addressability to browser cache is near trivial. Apologies if I misunderstood.

I was thinking that this could be added as well, but that it would be purely optional, if anyone got around to adding it.

Basically, you need the hash and a fallback regular URL. The browser is free to grab the content using the hash however it likes, whether it's grabbing it from its cache, using the fallback URL, using another known URL for that content, or using some new delivery mechanism.

Post reply on HN