5 ms·
Always seemed to be to be a bad practice from a security point of view - you are putting the security of your site in the hands of whoever is hosting the .js T
by dedward 16y ago
Always seemed to be to be a bad practice from a security point of view - you are putting the security of your site in the hands of whoever is hosting the .js
This also applies when .js is dynamically included as a type of API call to embed widgets and whatnot - but in those cases there's a necessary reason - it's the only practical way - but for a simple .js, you should be managing your own .js library and publishing on your own (including all the speedup tricks you know you should be doing)
- wzdd 16y ago> Always seemed to be to be a bad practice from a security point of view This is why I can't understand people's recommendation to use Google's or Microsoft's CDN. Even if you assume they're not going to be malicious, you have to trust that they're secure. Not to mention that the CDN owner can derive accurate traffic stats from the number of requests for the JavaScript.
- jdminhbg 16y agoWhy would I be less sure that they're secure than my own personal hosting?
- dfranke 16y agoNo reason you would be. But you can be sure that your personal hosting is more secure than (your personal hosting ∪ Google). In the latter case if either breaks you're screwed.
- rhizome 16y agoYou know the components of, and the capacity to upgrade, your own stack. With hotlinking, you (and consequently your users/customers) have an external dependency to a mysterious system with who-knows-what going on.
- Encosia 16y agoAs long as the CDN is configured to transmit its files with a far-future expires header (which Google and Microsoft's CDNs are), the CDN owner can't accurately track usage at all. In a perfect world, the CDN would only handle one HTTP request per user per expires period (+1 year on Google and Microsoft's jQuery CDN). In reality, the file will be pushed out of or cleared from caches for various reasons, but they still persist long enough to make tracking end-usage of the CDN meaningless.
- dminor 16y agoPerformance. Many of your visitors will already have it in their cache.
- mootothemax 16y agoMy concern has always been the one-day-in-a-thousand when the CDN will be down and so my sites won't work. When my sites go down it doesn't matter as the entire package stops working, but I'd hate myself ten times more if things stopped working due to an admittedly extremely rare CDN failure. That said, I'm open to the idea that I'm being extremely foolish about this ;)
- adamdecaf 16y agoMost users will have the javascript in their cache anyway, so they won't even be hitting the CDN. Also, why not check to see if the object exists before doing anything else? <script id="jquery" src="http://code.google.com/jquery.js"></script> <script> if (jQuery == undefined) { document.querySelector("#jquery").src = 'Backup CDN'; } </script> That should work, in theory, if not then just remove script#jquery, create a new one and append to the document before executing any script(s).
- mootothemax 16y agoIt's at times like this that I feel really stupid ;) Thanks, you can guess what I'll be changing on my sites the minute I sobered up, err, sometime in the next couple of days ;)
- catshirt 16y agoiirc changing the src attribute directly does not resend the request (in at least some browsers). you need to create a new node.
- wizard_2 16y agoStolen from the html5 boilerplate <!-- Grab Google CDN's jQuery. fall back to local if necessary --> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script> <script>!window.jQuery && document.write(unescape('%3Cscript src="js/libs/jquery-1.4.2.js"%3E%3C/script%3E'))</script>
- simonbrown 16y agoPlenty of people use Google Analytics, which, of course, gives Google just as much access.
- lwat 16y agoI trust Google and Microsoft enough for the benefits I get in return (faster loading clients). Sure they can screw me over but not too badly. Worth the risk for some applications.