JsDelivr – The advanced open source public CDN

https://hacks.mozilla.org/2014/03/jsdelivr-the-advanced-open-source-public-cdn/

by rnyman • 12 years ago

230 100 12 years ago

hacks.mozilla.org

dalek2point3• 12 years ago

I dont understand how this is paid for -- can someone explain?

lazyjones2• 12 years ago

I should also point out that MaxCDN, CloudFlare, Cedexis and the rest of the companies sponsor jsDelivr for free.

Personally, I don't trust such services any more than I trust cloud hosting, which means not at all. I have no way to make sure that they server these files unmodified, that they aren't neglecting their servers to the point where they're hacked and serve malware to my users etc. ...

wreegab• 12 years ago

Add to this privacy concerns. I un-block such 3rd-party CDNs if and only if it breaks specific web sites which I want really want to un-break.

jimaek17• 12 years ago

I would be happy to address these issues. You have no reason to believe me but all custom servers are secured and are regularly updated.

For CloudFlare and MaxCDN I have 2-Step authentication enabled + for MaxCDN 1 allowed whitelisted IP address.

Regarding unmodified files I guess we can build an app to monitor them? If you want drop by https://github.com/jsdelivr/jsdelivr and we can discuss this even further.

I would be happy to do anything possible to ease your concerns regarding security.

jimaek17• 12 years ago

Cedexis, MaxCDN and CloudFlare all offer their services without any limits and for free. Same for all the custom locations we have from Hosting companies.

We are in excellent relations with all of our sponsors so no issues there.

For the rest stuff like Domains, SSL, Hosting, Freelancers, other I pay myself.

shimon_e• 12 years ago

I wonder if you could somehow get Google as a sponsor too?

Maybe someone could convince them to adopt your multi CDN technology for web fonts? The reason why I want this is because in China the GFW periodically hangs connections to Google's IPs after searching certain keywords for 90 seconds. This causes any site that uses Google web fonts to hang until the connection is resumed.

RaphiePS• 12 years ago

This is really cool. Up to the section on Advanced Features, it seemed like a clone of Cloudflare's cdnjs. But the multiple request feature is absolutely terrific, and I can't wait to use it.

EDIT: I wonder if the multiple-request URL's mean that the individual assets won't be cached, which is a big selling point of CDN's.

jimaek17• 12 years ago

Grouped URLs are cached as always but for less time. You can check the headers.

eli• 12 years ago

I think the parent's point is that people will less likely to have a warm cache because it's less likely any other site has requested the exact same group of files.

(Though there's debate as to how much that matters.)

moystard6• 12 years ago

There is cdnjs.com that proposes the exact same features and has been available for quite some time.

I regularly submit new libraries and update the current ones through their Github repository.

The multiple files per request is nice however, but contributing to cdnjs might have been a better way of proposing it.

xpose2000• 12 years ago

But according to the benchmarks, cdnjs.com is worse than google and jsdelivr. http://www.cdnperf.com/#jsdelivr,google,cdnjs/http/90

jimaek17• 12 years ago

Exactly, we use multiple CDNs. We are the only project to do that. This is why our performance and uptime will be always better.

moystard6• 12 years ago

Thanks for the link, we will be experimenting with cdnperf in the coming weeks, and make the move if we are happy with it.

thomasfromcdnjs• 12 years ago

Just be careful with those benchmarks, cdnperf is run by jsdelivr. An uptime and speed monitor based in one location is a pretty flawed way of analysing the performance of a cdn. As for Jimaeks comment above "multiple cdns" do not enforce better performance either.

alecsmart12• 12 years ago

I must say that the process for adding files is too complicated and time consuming.

jimaek17• 12 years ago

I know. I hope the auto-update app will fix this.

We are also thinking new ways to add files https://github.com/jsdelivr/jsdelivr/issues/347

alecsmart12• 12 years ago

Why not implement origin pull?

gales• 12 years ago

I currently use cdnjs, but very interested in the single HTTP request & simpler versioning that JsDelivr is offering, so will start using this for my current project.

Most of the libraries I use are already on there, and I like the fact that brief glance information is shown for each library. Also noticed there's a duplicate misspelt typeahead library listed.

nawitus• 12 years ago

I'd like something like this integrated with a module system. For example, I could just say "var jquery = require("jquery")", and the script would be automatically downloaded from the CDN.

bebraw• 12 years ago

I suppose someone could write something like this on top of the API, https://github.com/jsdelivr/api .

riffraff• 12 years ago

isn't that what google does? https://developers.google.com/loader/

kjell• 12 years ago

[browserify-cdn](http://wzrd.in/) and http://requirebin.com/ are heading this direction.

aw3c23• 12 years ago

How about not leaking to third-parties? I value my privacy and I wish Mozilla would too.

rnyman2• 12 years ago

Robert here, Editor of Mozilla Hacks. We cover all kinds of resources for developers, especially with a strong focus on open source and technologies. If you are interested in knowing more about privacy, please get in touch with the people behind jsDelivr, write a comment to the blog post or similar. Thanks.

aw3c23• 12 years ago

Hi Robert, sorry I did not realise that this was not a Mozilla project. The post sounds like it is and the site suggests it is a "hack" by Mozilla.

_puk• 12 years ago

Sorry, I don't get the comment.

Leaking what? Your publicly available JS libraries? or is this a more general Mozilla bashing comment?

The service itself looks great, and the versioning is exactly what I'm after.

pgeorgi• 12 years ago

Users requesting files from CDN leak metadata.

I guess, browsers could provide a separate cache for CDN domains that's _really_ long lived (there's a certain guarantee that files won't change there) and also send requests there with no referer at all times.

aw3c23• 12 years ago

Sorry, I thought it was obvious.

Requesting assets from third-party websites leaks that I have been visiting your site to the third-party. Now imagine having a big CDN that many websites use and you can spy on a lot of unsuspecting users.

gtirloni• 12 years ago

There are no popularity restrictions and all kinds of files are allowed, including JavaScript libraries, jQuery plugins, CSS frameworks, fonts and more

So what is 'Js' about it? Has 'i' prefix become old-fashioned?

jimaek17• 12 years ago

jsDelivr is javascript centered. But it allows all kinds of projects too. For example the combination feature will only work with js projects. And we have all kinds of plugins for js developers.

But we still want to help open source projects to take advantage of our network. This is why we allow even windows binaries and other stuff too.

userbinator• 12 years ago

The 'i' prefix would risk unwanted attention from Apple.

it_learnses• 12 years ago

Can I work for mozilla? I feel like they're only one of the few organizations that are doing cool things for the common good. Keep it up!

F30• 12 years ago

They may be, but JsDelivr appears to have no deep affiliation with Mozilla:

Who is behind jsDelivr?
Basically just me, Dmitriy A. or @jimaek. But a lot of other people are involved, giving their advice and helping me out. I always refer to jsDelivr in the plural sense because of this.

It is sponsored, amongst others, by CloudFlare and MaxCDN, where @jimaek is also employed. But the only connection to Mozilla seems to be that it's featured on the Mozilla Hacks blog.

ozten• 12 years ago

https://careers.mozilla.org/en-US/listings/

AdrianRossouw8• 12 years ago

So this is something I wrote last week relating how I've come to believe that it's really not appropriate to rely on vendor code on public CDN's for anything more complex than a JSFiddle.

http://daemon.co.za/2014/03/from-trenches-js-cdn-point-of-fa...

Basically, if you need to include something like jquery, you have to have code that makes use of it. Since by definition, you can't serve that code from a public cdn, you are going to need to serve those static assets somehow.

I now believe that you should serve the vendor code from the same 'place' as you serve your application's static assets, because by relying on external resources, you are adding more moving parts that all have to be in perfect working order for your app to actually be able to run.

This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is.

I did read the jsdelivr post, and it actually looks like a really well thought out system. I just don't think I will use something like this for anything where I have the choice not to.

IMO, the possible benefits of using a public CDN, don't outweigh the fragility that gets added. It just feels like it is trying to optimize best case performance while worst case is far more important.

I'm not against CDN's as a concept though, I just think you should serve all the code that is needed for normal operation from the same one.

untog2• 12 years ago

It's very easy to add a fallback, though. If the CDN goes down, load the local version.

This doesn't really have anything to do with how reliable the CDN itself is, but rather with how reliable the client's connection is.

If they have the CDNed version of jQuery cached then it doesn't need their connection to do anything.

AdrianRossouw8• 12 years ago

you could just have loaded the local file the first time and have it work every time, without all those ifs and maybes involved.

it can take several seconds for the request to fail, during which your application won't have been loaded or working.

the fallback adds complexity to your code, which ultimately didn't need to be there.

I just think that it's better to reduce the ways that your application can break, before trying to make it a little bit faster for the cases in which all the conditions are met.

On principle, even in the theoretical best case scenario, I think it's not the right approach to be taking.

I also don't think that the best case scenario can be reliably enough predicted to be something you should try to optimize for. There are many CDN's, many different versions of the many different libraries. Especially on mobile devices, cache size is limited.

IMO, at least.

moystard6• 12 years ago

I think your statement is a bit extreme. While relying exclusively on a cdn to serve your static assets is risky, doing it using require.js with a local fallback works very well. You still benefit from cdn caching, while preventing your assets to become unavailable (even in China).

AdrianRossouw8• 12 years ago

that's just added complexity, where it could all just work.

or fail consistently at the same time if your server isn't accessible. In that case it doesn't matter that the public cdn is still accessible.

i just don't think the possible benefit of public cdn hosted code can justify how many moving parts it adds.

lerouxb4• 12 years ago

Really? Have you ever sat through the experience of waiting for the primary source to time out so that the fallback can kick in?

elwell• 12 years ago

If you spread your resources over multiple domain names, the client can download more files in parallel.

AdrianRossouw8• 12 years ago

you can shard your own domains too.

AdrianRossouw8• 12 years ago

https://developers.google.com/speed/docs/best-practices/rtt#...

stcredzero2• 12 years ago

I'd like to see something like a CDN, but for completely dynamic content. Something like a system that could host instances of a game server, with a framework that ensures clients make connections with very low latency.

devicenull2• 12 years ago

Huh? The game server instances would still need to sync between themselves, so this really wouldn't address latency.

Rather then having the latency between the client and the server, you'd instead have latency between the two servers.

stcredzero2• 12 years ago

Huh? The game server instances would still need to sync between themselves, so this really wouldn't address latency.

No. If you design the game properly, they actually don't have to coordinate very much at all.

Dorian-Marie3• 12 years ago

Neat, but I couldn't get three librairies with minified JS:

    https://cdn.jsdelivr.net/g/jquery@1.10.2,bootstrap@3.0.3,angularjs@1.2.10

And I couldn't get Boostrap CSS even if they say they also host CSS.

Also, it's not clear if you can or not mix CSS and JS in the query, that would be neat to do that and then to insert CSS with Javascript (or maybe that would be a bad idea).

jimaek17• 12 years ago

jQuery was deployed from the official source. And it does load a map file suggesting its minified. Not sure why it looks like this.

You can mix CSS and JS in one query but its up to you to make it work.

To load Bootstrap CSS you need to specify the exact file like so

https://cdn.jsdelivr.net/g/bootstrap@3.1(css/bootstrap.min.c...

Because the main file for this project points to a js

Dorian-Marie3• 12 years ago

The original file was not minified: https://github.com/jsdelivr/jsdelivr/pull/478

Dorian-Marie3• 12 years ago

Thanks, I didn't see the files were in sub-directories for Bootstrap.

Here is my final Javascript query: https://cdn.jsdelivr.net/g/jquery@1.10.2(jquery.min.js),boot...

javajosh2• 12 years ago

When you include 3rd-party hosted content in your program, you give those 3rd-parties:

   1. Access to your users' browser details (via request headers).
   2. Access to your users' habits (via the referrer header). 
   3. The ability to replace executable code. (This code can be used to gather more data from the state of the web page (e.g. keystroke logging), or break out of the browser sandbox and compromise the whole system. Note: this only applies to JavaScript.)
   4. The ability to break your software, either intentionally or unintentionally, by not serving the resource at all.

When you host and serve your own resources, these are non-issues.

I think there is a sense among good-hearted programmers that "But gosh, they wouldn't do [1-3]! These CDNs are just a really nice public service by companies that care about keeping the web community healthy and fast. And besides, if they ever abused their access to user data, there would be hell to pay!"

Unfortunately this blasé attitude about user privacy on the part of programmers is why we have such a rough time with privacy in general these days. I believe that if you're a programmer with any interest at all in protecting your users from bad actors, that you'll do your best to avoid using 3rd party hosts, especially for executable code.

majika2• 12 years ago

Thank you thank you thank you.

What's worse is when you see sites running JavaScript from multiple analytics companies, social media companies, and CDNs - even on pages that should be private (login forms, personal details, etc.). It's even worse when those sites break without those scripts. This is a concern that far too many developers overlook. I made this (harsh) comment [0] on such a site posted to HN a few months ago.

CDNs are way overrated, from what I've seen. I think, for most use cases, you're better off avoiding the multiple HTTP requests and just compressing all your JavaScript into a single file. Serve that from your own server and you'll save the client from another domain name resolution too.

Do yourself a favor and install NoScript. For one thing, it will show you how easily Google can (or, could have) track your internet usage - and, as you pointed out, so much more. In my experience, about 50% of sites serve scripts from some Google domain.

[0] https://news.ycombinator.com/item?id=7187593

javajosh2• 12 years ago

You're welcome! And I agree that the upsides of CDNs are overrated - but in fairness they do have the benefit of being very easy to use, high performance, and ease the bandwidth costs of applications. The geographical proximity thing is a nice feature, and expensive to reproduce. Of course, even these upsides come with their own downside: front-end developers have gotten into the habit of including every lib under the sun. Heck, it's just a script tag! This makes the page heavier, which makes the CDN even more indispensable, and it leads to a downward spiral of browser-hosted bloat-ware that requires a CDN to load in a reasonable amount of time. This is, of course, a win for the CDN sponsoring companies.

What's remarkable to me is how ubiquitous and unquestioned the use of CDNs has become.

BTW NoScript/Ghostery don't address the CDN issue. They don't actually block CDNs, they just block explicit trackers (mainly in the forms of iframes and scripts linked to known-bad hosts).

dangayle• 12 years ago

HOw is this different from cdn.js? I already use that, and it too is on Cloudfare.

SimHacker3• 12 years ago

2004 calld. Thy want their missing "e" back.

jimaek17• 12 years ago

You can use this domain if you prefer http://www.jsdeliver.com/ :)

SimHacker3• 12 years ago

Ys, I prefr.

SimHacker3• 12 years ago

I am worrid about wb sits with misspelld nams.

Mistakn usrs somtims correctd missd lettrs, so thy downloadd pags from unrelatd servrs.

Howevr, the spc thy postd mentiond othr use cass, and presentd exampls of anothr systm with enterprisy qualitis to delivr usrs to correctd wb sits with misspelld nams:

A clevr browsr evn maks guesss, which enabls fils with unrequestd but correctd nams to be downloadd in paralll ovr integratd distributd per to per technologis, oftn receivd replis cachd, and latr presentd.

Ys, yt again, browsrs designd by committs enabld Opn Sourcs and Fre Softwars to answr anothr complicatd Internt problm!

lerouxb4• 12 years ago

The problem I have with this is the same I have with all public js CDNs: Your project doesn't just use public js files. You are almost guaranteed to also have custom javascript (which could itself be opensource or not. irrelevant), css, possibly fonts, images, etc.

You can't put your static files on that public cdn. So either you have to serve it up yourself or you have to put it on your own CDN (either one you run yourself or a managed one).

So you have an additional point of failure (because your static files are coming from at least two places rather than one) which multiplies the chances of something going wrong for little benefit in my opinion.

Deployments are likely to be much more complex too, etc.

And before someone mentions the limit of how many concurrent requests a browser will make to a host: That's also irrelevant. I'm not arguing that you should have loads of little files. You should still be combining things with build tools. In fact if you host those "vendor" files on your own webserver or cdn you actually have more flexibility around how to combine them. And you can still have multiple subdomains and ip addresses or whatever pointing to the same CDN to try and optimise around that if you want.

JsDelivr – The advanced open source public CDN

Related Stories