Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You shouldn't have to depend on CDNs as there's no guarantee they'll be up all of the time. I usualayy have a local fallback that can be triggered in this way:

    <script type="text/JavaScript" src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
    <script>!window.jQuery && document.write(unescape('%3Cscript src="/js/jquery-1.4.2.min.js"%3E%3C/script%3E'))</script>
The second script looks for the jQuery global object that should exist after the CDN fetch. If it doesn't exist, it knows to get your own copy.

(If you're wondering "hey, where's the 'http:' part in that src attribute?", it's because it's a safer way to ask for a resource when you don't know if the you are under http or https.)

Also, you should try to place your <script> tags near the bottom of the <body>, rather than the <head> so that they don't block the rest of the page from loading/rendering.



Have you tested that to make sure that it blocks on the first script tag in every browser?

Over the internet (as opposed to on your dev box), I'd expect that to always evaluate to false and therefore include your local script.

You might want to look into putting that call into window.onload so that it does what you think it does.


The point made (below) by @dspillet is correct, and important for one very good reason:

You will almost definitely have scripts that you have included after these two that depend on the jQuery object existing (otherwise what's the point in having jQuery at all). So imagine this trick wasn't used, and you just served up a local (or CDN hosted) copy of jQuery, then started using it in later scripts. It's reasonable at that point to assume that jQuery exists - which is because each script blocks, or if it doesn't, the browser itself will still make sure they execute in order. So it's perfectly safe to use this script without worrying about the order of things.

This is exactly why I (and many others) suggest that you put all of your <script> tags at the bottom of the <body> element. They block page rendering, so if they're in the <head>, or dotted around the <body>, they're going to delay the presentation of the page to the visitor.


I believe all browsers block execution of the script (and rendering of other proceeding content) so his code should work generally.

Even the latest browsers that do not block further object (scripts requests during the download and execution of the script will execute scripts sequentially, so his check for "is jQuery present" will not fire until the external script has either returned and executed (so the check passes, and nothing else happens) or errored (so jQuery is not present and the document.write executes, making it load from the local resource).


That looks like a neat trick. Thank you.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: