
CDN for all the other scripts (backbone.js, modernizr, etc.) - ryankirkman
http://www.cdnjs.com/
======
KuraFire
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.

~~~
hooligan
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.

~~~
KuraFire
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)

------
maverhick
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

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

~~~
ryankirkman
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/backbone.js/0.3.3/backbone-
min.js)

[http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/undersco...](http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/underscore-
min.js)

[http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6....](http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6.min.js)

~~~
corin_
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...](http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-
min.js) returns an XML "Access Denied" response.

Not a great start ;/

~~~
ryankirkman
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.

------
simonw
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.

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

~~~
simonw
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.

~~~
ryankirkman
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>

------
davej
Sizzle would be a nice addition: <http://sizzlejs.com/>

~~~
ryankirkman
Hosted and minified:
<http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js>

~~~
thomasdavis
Could we get msutache? <https://github.com/janl/mustache.js/>

~~~
ryankirkman
Will look into it.

------
Stuk
How is it going to be paid for?

~~~
ryankirkman
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.

~~~
simonw
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.

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

~~~
ryankirkman
Would you care to elaborate?

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

~~~
shantanubala
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.

~~~
ryankirkman
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.

