

CDN for JavaScript libraries - thefox
http://cdnjs.com/

======
thomasfromcdnjs
Hey guys,

Thomas from cdnjs here, we have been on HN before.

[https://news.ycombinator.com/item?id=4412044](https://news.ycombinator.com/item?id=4412044)
\- 671 days ago
[https://news.ycombinator.com/item?id=2828516](https://news.ycombinator.com/item?id=2828516)
\- 1057 days ago

cdnjs has been very successful since inception in early 2011, this is mainly
due to Cloudflare's early and ongoing sponsorship of the project.

According to BuiltWith, we have over 187,000 websites using cdnjs in
production - [http://trends.builtwith.com/cdn/CDN-
JS](http://trends.builtwith.com/cdn/CDN-JS)

According to w3techs, we have just recently overtook Microsoft's cdn, which
puts us in around third place for market size -
[http://w3techs.com/technologies/comparison/cd-cdnjs,cd-
micro...](http://w3techs.com/technologies/comparison/cd-cdnjs,cd-
microsoftajax)

jsbin, codepen and jsfiddle users generally use our tool for code snippets.

We have had no major downtime and only one brief security problem which was
due to a library version which had insecure swf's.

We have 100's of developers contributing to the project, and our repository
has become quite active -
[http://www.ohloh.net/p/cdnjs](http://www.ohloh.net/p/cdnjs)

As always our thanks goes out to the community who help us keep the libraries
up to date and Cloudflare's dedication to speeding up the web. A special
mention goes to Pete Cooper who has been the primary moderator and sole reason
for our growth in the last 12 months -
[https://github.com/petecooper](https://github.com/petecooper)

I will try to answer other questions in the thread today.

Edit: With regards to peoples privacy enquiries, because Cloudflare is our
official mirror it is best to consult their privacy policy. I have been
working with [http://taskforce.is](http://taskforce.is) over the last year on
campaigns against mass surveillance so I do take the issue very seriously.

Edit: Also a lot of users don't use cdnjs in production, it's just very
convenient when developing to be able to quickly include scripts.

Atom Plugin - [https://atom.io/packages/cdnjs](https://atom.io/packages/cdnjs)
Sublime Plugin - [https://github.com/dafrancis/Sublime-Text--
cdnjs](https://github.com/dafrancis/Sublime-Text--cdnjs)

~~~
iancarroll
You did have some rather long downtime when you ran with a revoked SSL
certificate.

------
aw3c2
I see no privacy policy so you have to assume that they will log all they can
about your visitors.

In these global dragnet surveillance ridden times it should be a no-brainer
but please don't expose your visitors to third-party websites, respect their
privacy, host your assets yourself.

~~~
kalleboo
> In these global dragnet surveillance ridden times it should be a no-brainer
> but please don't expose your visitors to third-party websites, respect their
> privacy, host your assets yourself.

I still wish there was a "hash" attribute to script tags (and others) so that
browsers could cache common JS/CSS/etc assets cross-domain.

~~~
woadwarrior01
I've been wanting this for a while now. The common argument against this is
that this enables cache poisoning attacks where an attacker can craft
malicious files with matching hashes. But I think the security it offers
against CDNs turning rogue makes it worthwhile. Here's the draft proposal
[https://github.com/pwnall/script-digest](https://github.com/pwnall/script-
digest)

~~~
dsl
Ugh. This proposal also suggests using "magic comments" in scripts, which
needs to die. They will get stripped by things like pagespeed and various
acceleration proxies, completely outside the developers control.

~~~
voltagex_
shouldn't it be something like <script src="blah" data-hash-sha512="...">?

------
kirab
Well, this also allows powerful actors to inject malicious code into your
page. I think they can easily be forced via an NSL to target certain websites
or client IPs.

~~~
jlebar
This a thousand times.

I'm not accusing these guys of being dishonest, but we know that the three-
letter organizations do this sort of thing, both with and without the
knowledge of web hosts.

It seems like these guys (and anyone else who has a similar service) shouldn't
require people to trust them. Instead, they should allow CORS (it appears
cdnjs does) and provide boilerplate code that verifies the script's sha256
before inserting it into the page.

------
kalleboo
So now the big question is... any reason to switch to this from
googleapis.com? Short term loss in cacheablilty since the Google one is so
widespread, long term less dependence on the Google corporation. Insecurity
since CloudFlare seems like a prime target for an acquisition/acquihire.

~~~
BtM909
It's not a representative test (as I'm only providing one source), but I'm
seeing lots and lots of websites proving that CloudFlare is faster than
Google's CDN.

It might be because their "userbase" is still smaller than Google, but for now
that might be 1 interesting reason to use CloudFlare.

[http://www.baldnerd.com/make-your-site-faster-cloudflares-
cd...](http://www.baldnerd.com/make-your-site-faster-cloudflares-cdnjs-vs-
google-hosted-libraries-shocking-results/)

~~~
magicalist
No clue about their relative speeds, but that test is pretty bad, as it seems
to only measure transfer rate once the transfer starts, not total transfer
time (including latency).

~~~
BtM909
I just picked the first result from Google. This isn't StackOverflow, so I
could imagine that the topicstarter would actually do some research himself.

------
vijayaggarwal
There are so may factors at play in determining the amount of gain from using
such a service, e.g.,

1\. How widespread the usage is. The more widespread it is, the better the
chance of finding the resource in the browser cache itself, instead of having
to make external request.

2\. Geo distribution of resource by the CDN. The closer the nearest CDN server
to the end user, the quicker the delivery.

3\. Popularity of CDN domain used to serve the resource. Since a DNS request
is potentially involved in fetching the resource, the domain name should be
widely used to keep the DNS cachces warmed up.

I am especially skeptical towards adding DNS calls to my page. One for HTML
and one-two for static resources is what I have seen works best in practice,
especially with modern browsers that do not have the _two parallel downloads
per domain_ limit.

~~~
kalleboo
Another thing to consider is parallel downloads. Last I checked, all browsers
limited simultaneous HTTP calls to a single domain. Spreading downloads across
domains will increase multithreaded downloading, which on most connections
will increase speeds.

~~~
acdha
Parallelism is complicated: the per-server connection limit has been increased
in modern browsers and will change dramatically as SPDY deployment rises[1]
and multiple connections per domain becomes a complete de-optimization.

In contrast, the speed of a DNS query is relatively fixed – that initial
lookup can take a long time on a cold cache (possibly seconds, particularly
internationally) and nothing will transfer until it's completed, so you really
need to calculate the time to last byte with that in mind. If you're talking
about small, cached files, domain sharding is often a significant step back if
the entire transfer can complete over an existing connection in the time it
takes to perform DNS + connection for a new hostname. This is particularly
interesting when you remember that modern browsers can do DNS prefetching
really early so e.g. DNS for your primary domain was completed before someone
even clicked on the link and multiple connections were opened as soon as they
clicked.

Steve Souders looked at this last year:

[http://www.stevesouders.com/blog/2013/09/05/domain-
sharding-...](http://www.stevesouders.com/blog/2013/09/05/domain-sharding-
revisited/)

> A middle ground is to alter domain sharding depending on the client: 1
> domain for browsers that support SPDY, 2 domains for non-SPDY modern
> browsers, 3-4 domains for IE 6-7. This makes domain sharding harder to
> deploy. It also lowers the cache hit rate on intermediate proxies.

1\. interestingly, CDNJS has supported SPDY for 2 years:
[https://twitter.com/cdnjs/status/231227466335797249](https://twitter.com/cdnjs/status/231227466335797249)

------
graystevens
You can use [http://www.cdnperf.com/](http://www.cdnperf.com/) to figure out
which may be best for your circumstances (lowest HTTPS latency, downtime etc.)

~~~
brainsmith
Could be a good solution for projects with high volume of Russian visitors:
access to many cloudflare servers is restricted by great fucking russian
firewall.

------
notastartup
one major improvement of cdnjs would be where they allow a faster adding of
libraries from websites such as unheap.com

