Live data from Hacker News

Microsoft's Ajax CDN tumbles worldwide

zdnet.com

1–10 of 46 posts

Re: Microsoft's Ajax CDN tumbles worldwide

#3
More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc.

But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Everything else might be up and working great, but how well will the UI function if the user can't pull in jQuery? I just don't see any value in taking a dependency on these third parties for hosting JS libs and the like.

Re: Microsoft's Ajax CDN tumbles worldwide

#4
post #3

More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc. But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Ever…

CDN, with local fallback:

    
    
    window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))
    

Re: Microsoft's Ajax CDN tumbles worldwide

#5
post #3

More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc. But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Ever…

CDN, with local fallback: window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))

Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request.

Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.

Re: Microsoft's Ajax CDN tumbles worldwide

#6
post #5

Earlier quoted context omitted.

CDN, with local fallback: window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))

Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.

> bundle them with your other scripts and save a request

There's huge merit in that IMO for single-page type applications that have many lib dependencies.

For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.

Re: Microsoft's Ajax CDN tumbles worldwide

#7
post #3

More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc. But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Ever…

CDN, with local fallback: window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))

This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.

Re: Microsoft's Ajax CDN tumbles worldwide

#9
post #5

Earlier quoted context omitted.

Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.

> bundle them with your other scripts and save a request There's huge merit in that IMO for single-page type applications that have many lib dependencies. For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.

I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.

Re: Microsoft's Ajax CDN tumbles worldwide

#10
post #7

Earlier quoted context omitted.

CDN, with local fallback: window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))

This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.

Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers.

However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before ), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.

Post reply on HN