4 ms·

"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/goo

"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.html 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-jquery/ 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.

EvanPlaice 12y ago
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 12y ago
  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.
nextw33k 12y ago
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 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.

EvanPlaice 12y ago

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 12y ago
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.

nextw33k 12y ago

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