5 ms·

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

27 points by ryankirkman 16y ago

Charuru 16y ago
No, this website doesn't engender trust, and that's vital for a cdn of this nature.
- ryankirkman 16y ago
  Would you care to elaborate? Would putting some links to our profiles on things like Twitter and LinkedIn help add credibility?
  - shantanubala 16y ago
    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 16y ago
      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.
  - simonw 16y ago
    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/ http://omniti.com/ ) would be OK. An anonymous web page doesn't cut it.
ladon86 16y ago
I hate to say it, but the site isn't loading for me.
- ryankirkman 16y ago
  If it doesn't work for you right now, you can go to: http://122.201.100.216/~cdnjs/ 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 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-min.js http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m... http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/underscore-min.js http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/undersco... http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6.min.js http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6....
  - corin_ 16y ago
    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-min.js http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m... returns an XML "Access Denied" response. Not a great start ;/
    - ryankirkman 16y ago
      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.
  - deleted 16y ago
    [deleted]
Stuk 16y ago
How is it going to be paid for?
- ryankirkman 16y ago
  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 16y ago
    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.
  - reubenyeah 16y ago
    Mashing the resources together would surely destroy the speed boost of a CDN?
davej 16y ago
Sizzle would be a nice addition: http://sizzlejs.com/ http://sizzlejs.com/
- ryankirkman 16y ago
  Hosted and minified: http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js
  - thomasdavis 16y ago
    Could we get msutache? https://github.com/janl/mustache.js/ https://github.com/janl/mustache.js/
    - ryankirkman 16y ago
      Will look into it.
KuraFire 16y ago
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 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.
- ryankirkman 16y ago
  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.
  - KuraFire 16y ago
    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.
maverhick 16y ago
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
simonw 16y ago
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 16y ago
  That's a limitation we have to live with for now, unfortunately. We are looking into rectifying this.
  - simonw 16y ago
    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 16y ago
      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 http://news.ycombinator.com/item?id=2097491

27 points by ryankirkman 16y ago

Charuru 16y ago

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

ryankirkman 16y ago
Would you care to elaborate? Would putting some links to our profiles on things like Twitter and LinkedIn help add credibility?
- shantanubala 16y ago
  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 16y ago
    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.
- simonw 16y ago
  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/ http://omniti.com/ ) would be OK. An anonymous web page doesn't cut it.

ladon86 16y ago

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

ryankirkman 16y ago
If it doesn't work for you right now, you can go to: http://122.201.100.216/~cdnjs/ 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 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-min.js http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m... http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/underscore-min.js http://ajax.cdnjs.com/ajax/libs/underscore.js/1.1.4/undersco... http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6.min.js http://ajax.cdnjs.com/ajax/libs/modernizr/1.6/modernizr-1.6....
- corin_ 16y ago
  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-min.js http://ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-m... returns an XML "Access Denied" response. Not a great start ;/
  - ryankirkman 16y ago
    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.
- deleted 16y ago
  [deleted]

Stuk 16y ago

How is it going to be paid for?

ryankirkman 16y ago
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 16y ago
  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.
- reubenyeah 16y ago
  Mashing the resources together would surely destroy the speed boost of a CDN?

davej 16y ago

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

ryankirkman 16y ago
Hosted and minified: http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js http://ajax.cdnjs.com/ajax/libs/sizzle/1.4.4/sizzle.min.js
- thomasdavis 16y ago
  Could we get msutache? https://github.com/janl/mustache.js/ https://github.com/janl/mustache.js/
  - ryankirkman 16y ago
    Will look into it.

KuraFire 16y ago

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

ryankirkman 16y ago
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.
- KuraFire 16y ago
  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.

maverhick 16y ago

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

simonw 16y ago

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 16y ago
That's a limitation we have to live with for now, unfortunately. We are looking into rectifying this.
- simonw 16y ago
  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 16y ago
    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 http://news.ycombinator.com/item?id=2097491