Please don't use externally hosted JavaScript libraries | Hacker News Reader

Please don't use externally hosted JavaScript libraries

palant.de

14 pointsAndrewDucker6 comments

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.

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

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

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.

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.

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/

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.

I take your point, the study demonstrates the problem.

However I would counter that the problem is that people are doing it wrong. They shouldn't be linking to a specific minor or patch version, just linking to the major version they want:

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Which would mean you'd get nearly a 13% chance of a hit.

Plus the maths didn't really (and couldn't really) factor in the popularity of sites. If I use the same jQuery as Google's homepage (which they don't but just hypothetically imagine they did) then they'd show up as one data point in the analysis. However the vast majority of web users would then have that in their cache.

I still believe JavaScript CDN used correctly, has the potential to offer improvements. It's just unfortunate that people are doing it wrong.

A superior solution to CDN is the Magnet URI which includes a checksum on the content and a fallback location to retrieve the file.

http://en.wikipedia.org/wiki/Magnet_URI_scheme for example: magnet:?as=https%3A%2F%2Fnews.ycombinator.com%2Ffavicon.ico&xt=urn:sha1:RFJGKU7TT4ZMU7RUB7SR7SW3BINM5JKL

Reply on news.ycombinator.com