
Please don't use externally hosted JavaScript libraries - AndrewDucker
https://palant.de/2014/06/30/please-don-t-use-externally-hosted-javascript-libraries
======
nextw33k
The article misses the main point of content delivery network JavaScript: The
hot cache.

If you use jquery-1.11.1.min.js from Google or Microsofts CDN then there is a
good chance that its already on the users computer. Saving them having to
download it again and making your site look more responsive.

Saying that you shouldn't trust a CDN for reliability is just crazy, CDNs are
designed to be multi-access points for speed and resilience. For 99% of people
the CDN is going to have better up time than a single server.

Yes for the security paranoid don't use CDN's, but for everybody else that has
better things to do with their time, carry on.

~~~
Isofarro
" _The article misses the main point of content delivery network JavaScript:
The hot cache._ "

The stats don't really bear that out: [http://statichtml.com/2011/google-ajax-
libraries-caching.htm...](http://statichtml.com/2011/google-ajax-libraries-
caching.html)

and a followup two years later:
[http://www.stevesouders.com/blog/2013/03/18/http-archive-
jqu...](http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/)

these third party CDNs are littered with different versions of jQuery and
whatever, so the fragmentation of top sites using different versions seems to
dent the chances of having one of these libraries hot cached.

~~~
EvanPlaice
I wonder if cdnjs rates are any better.

It's too bad more sites don't use CDNs. Nothing loads faster than a warm cache
and they remove the unnecessary added complexity of managing third-party
scripts in source control.

It would help if the Open Source dev community could revise their versioning
practices to include long-term releases and post those to a CDN.

Unfortunately, the current standard is to backward-compatibility-breaking API
changes in major versions. API changes that will likely introduce new bugs.

It would be cool if we started using a convention where the last update prior
to a new major version release is marked as final; thereby deprecating all
previous minor versions in that series. OSS developer library projects usually
don't have the time/resources to waste maintaining old code anyway.

For example use something like a bang to mark the final version. So, when
major version 2.0 is released the final major version 1.x gets released as 1!
for long-term support and everything previous gets deprecated.

It's a win/win. Bang versions get marked as for long term support (ideal for
production environments) and everybody who depends on that API version get
consolidated into using a single stable branch.

~~~
nextw33k
We already have a versioning plan with the three dot version numbers. As a
developer using a library I should be able to use any minor or patch version
without breakage. They should just add functions and fix bugs and regressions.
Major version numbers mean something will break. The problem is that many
library developers need to accept that as their core philosophy or downstream
will end up fixing to a specific version.

[http://semver.org/](http://semver.org/)

What the jQuery CDN doesn't do is offer a jquery-1.8.min.js or a
jquery-1.min.js for me to always ensure I have an up-to-date and compatible
library.

