CDN for all the other scripts (backbone.js, modernizr, etc.) | Hacker News Reader

CDN for all the other scripts (backbone.js, modernizr, etc.)

cdnjs.com

27 pointsryankirkman27 comments

I checked out this site the moment it got linked on Twitter, but I haven’t been able to connect to it still. I asked on Twitter, and it seems quite a few people are having issues connecting to it:

http://twitter.com/#!/search/%40KuraFire

For a CDN, having a home page not work for so many people is a serious problem. If it just recently had its DNS changed, then it shouldn’t have been announced, period. If not that, this connectivity is even more concerning.

I’m really excited about seeing dedicated JS CDNs for things like Modernizr (which I lead/run), but a CDN that has such a troublesome start will need to prove itself a couple times over before I can consider it seriously. Mainly, this kind of start doesn’t inspire confidence that the people running it know every little thing there is to know about hosting and DNS. The fact that one of the three examples in this thread, linked by who appears to be the creator of the site, doesn’t actually work, makes me even more concerned.

I’m all for seeing Modernizr and other JS scripts on a CDN, but the CDN should work for that, so I hope that this one gets its act together real soon. Whatever the cause, being largely unavailable for a lot of people in a lot of different countries is obviously unacceptable as a CDN resource—even if it may be only temporary.

Thanks for the feedback KuraFire!

We did stuff up the launch of this service. We should have thoroughly vetted DNS propagation before we launched. We plan to learn from this, and will ensure anything we do in the future has much more rigorous testing.

Please accept our humble apologies.

We're working on resolving current issues as we speak.

Well, better to have a troubled start due to insufficient DNS testing than having hosting/DNS issues along the way. You probably should’ve just waited with getting the word out (>72 hours after the DNS change), but eagerness/enthusiasm is understandable—even if not necessarily desired at all times ;)

I'll be keeping an eye out on how it goes, and should we deem it reliable enough later on, we'll link to it from the Modernizr site. Feel free to let me know at some point in the future when you feel you've resolved all issues.

I am also very excited to see a CDN for the smaller libraries.

The service seems to be hosted on Amazon which is great and gives me a vote of confidence in using the service. Also very cheap to pull off something like this and with community donations are very possible solution.

It's disappointing to see the propagation errors but I have personally worked with the Amazon back end and CNAME records and recall the same issues when I sent a site live. Hard to test how your site works around the globe especially when third party tools report that its working.

This is why it’s always better to get some real world testing done, rather than third-party tools. Ask people of whom you know are in various locations around the world to see how fast things are (and if they’re not working at all, that’ll become evident right away). Get data from the grindstone through other people if you can’t get it on your own (e.g. if you’re a small team in only one location).

DNS is a fickle bitch, but it’s also one that is the easiest to take care of before launch: just wait. (though if after 3 days it’s still not working, you messed it up)

If you aren't able to sustain the site at some point in the future, there would be major downtime and broken scripts across sites. That is the reason why people would trust google or other more trustworthy sites for hosting their main js files, or prefer to do it themselves

I hate to say it, but the site isn't loading for me.

If it doesn't work for you right now, you can go to: http://122.201.100.216/~cdnjs/

For some reason, the main site is taking ages to propagate to some DNS servers.

You're probably covered by one of the servers with an (x) here: http://www.whatsmydns.net/#A/cdnjs.com

This doesn't actually affect the CDN side, which hosts the scripts.

EDIT:

For example:

http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m...

http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/undersco...

http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6....

Firefox can't establish a connection to the server at www.cdnjs.com.

Regardless of the reason, doesn't inspire much confidence.

Additionally, one of your links, http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m... returns an XML "Access Denied" response.

Not a great start ;/

EDIT 2: This issue has now been resolved. The reason you couldn't access this file was that read permissions for the user group "Everyone" were removed on this specific file. We'll endeavor to ensure this doesn't happen in the future.

-----------

We might have to put that one down to initial technical difficulties.

Not sure why you are getting access denied for that particular resource. May have to invalidate that object from CloudFront cache locations.

EDIT: We are using Amazon CloudFront to host the scripts.

cdnjs.com doesn't obey the Accept-Encoding header - it just serves everything gzipped. This is a limitation of CloudFront when backed by S3 - as of a few months ago it's possible to vary on the Accept-Encoding header through CloudFront but only if you run your own origin server rather than using S3.

The Google Ajax CDN varies on Accept-Encoding just fine.

That's a limitation we have to live with for now, unfortunately. We are looking into rectifying this.

You can fix it by running an nginx somewhere that serves the files, then setting your CloudFront distribution to point to that.

... of course, then you'll need to make sure the nginx server is properly redundant.

That is definitely one of our options.

We're looking into jumping ship to Rackspace once they complete their move to Akamai for Cloud Files (anticipated to be finished by the end of Q1 this year). It seems like they will support the Accept-Encoding header: http://news.ycombinator.com/item?id=2097491

Sizzle would be a nice addition: http://sizzlejs.com/

Hosted and minified: http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js

Could we get msutache? https://github.com/janl/mustache.js/

Will look into it.

How is it going to be paid for?

Good question. So far, we are only hosting tiny files (almost everything is well under 10kb).

Given the how cheap CloudFront works out to be for files of that size, we can support quite a lot of growth, even if we have to incur the expense personally.

We do plan to monetize it at some stage. Some ideas are premium accounts that mash all of your resources together and host them for you.

The key benefit of hosting common scripts on a single CDN is that everyone who uses a script can point to the same URL, hence dramatically increasing the chance that a page visitor will already have the file in their browser cache and won't have to fetch it at all.

For that to work, you need to be used on a bunch of large sites and hence be serving a lot of traffic - which at CloudFront's rates will quickly become expensive.

Mashing the resources together would surely destroy the speed boost of a CDN?

No, this website doesn't engender trust, and that's vital for a cdn of this nature.

Would you care to elaborate?

Would putting some links to our profiles on things like Twitter and LinkedIn help add credibility?

It's much more than that. When people use a CDN for their applications, they want to be 100% (or 1000% if that were possible) sure that the CDN will not be compromised. They also want to be sure that the people running the CDN do not have nefarious intentions. They also want 100% uptime. They also want the CDN to stick around as long as their web app is around.

That's why CDN's from Microsoft, Google, and the official jQuery CDN's are trusted (and will inevitably be trusted) more than this one.

As awesome as this is, I'd quite honestly rather host my JS myself than use it. Once Google adds more libraries, I may use their CDN.

EDIT: I don't mean to come off too harsh, but a lot of people don't use CDN's altogether because of the potential for downtime. Combine that with a not-globally-recognized brand and it may not work too well.

Great point.

Trust has to be earned. The goal of this website is to decrease the barrier of entry for people wanting to try out some cool new libraries and/or jQuery plugins on their site, so we aren't really targeting the upper end of the market.

Having said that, we have been using this for all of our personal and business endeavors, so it will be around for the foreseeable future.

It would help a bit. At the moment there's no indication at all of who is running this thing.

The only way I'd trust something like this is if someone stood to take a major blow to their reputation if it failed. Google, Amazon, AOL would be fine. A company that made a living doing high profile operations work (like http://omniti.com/ ) would be OK. An anonymous web page doesn't cut it.

Reply on news.ycombinator.com