views:

27

answers:

5

We are currently developing an ASP.NET MVC application which will be deployed on a corporate intranet, with a slightly-modified customer facing version available on the public internet.

We're making use of a number of external javascript libraries (e.g. jQuery) and a discussion has come up regarding referencing the libraries - should we reference them from an external source (e.g. via the Google load jQuery method) or keep our own version locally and reference from there?

The project manager is a little concerned about having a 'dependency' on Google (or whoever) if we reference from there, and thinks that having our own copy of the library makes us more independent. On the other hand, I have heard there are a number of advantages to letting someone else host the library - for example, they handle versioning for us, Google aren't going anywhere anytime soon...

(for the purpose of the discussion assume the intranet we're hosting on has external access - obviously if it turns out it doesn't the decision is very much made for us!)

So. Does this matter? And if so, what should we do and why?

(I appreciate this is subjective - but it would be very useful to get advice from anyone with experience or thoughts on the matter. Not sure if this is a candidate for community wiki or not, let me know if I should have put it there and I'll know for future!)

Thanks :)

+2  A: 

Is the application critical to your internal users? If the 'internet is down' will your business suffer because internal users cannot access the applications? It's really more about risk than anything else.

Besides if there is change - breaking or otherwise, would you not want to manage the 'upgrade'?

Preet Sangha
It is critical. But we're writing it with degradation in mind - so it should function minimally without javascipt anyway. And I'm more interested in the pros of external hosting as the cons are readily apparent. You're absolutely right that these are possible concerns though, thanks!
randomsequence
A: 

you can do something like

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"&gt;&lt;/script&gt; 

<script type="text/javascript"/>
if( window.$ ) {
    // jquery script goes here
} else {
    var elmScript = document.createElement('script');
    elmScript .src = 'jQuery.js'; // path to jquery
    elmScript .type = 'text/javascript';        
    document.getElementsByTagName('head')[0].appendChild( elmScript );
}
</script>
From.ME.to.YOU
A: 

Notwithstanding the complexity-issues that arise from having your code scattered over multiple sites, some of which you don't control, there is also a slight performance penalty to pay for pulling content from multiple domains (Eg. an extra dns lookup). For a public web site, where a lot of users will be first-timers, there may be some benefit to having the code cached already, but otherwise I don't really see the point.

troelskn
+1  A: 

Usually the reason of using a hosted library is performance. I browser will only download a limited number of files per host. So using a hosted library will load the files from a different host and therefore in parallel to the other files.

The second reason is that those files are usually being compressed and the cache headers are set correctly. And those files are usually stored in a CDN which means that your users will download the file from the hosts which is closest to them.

But all those reasons are not so important in a intranet environment.

Kau-Boy
A: 

The main (only?) reason to do this would be for performance reasons as @Kau-Boy has already mentioned. JQuery is a relatively small library (for what it gives you) and it will be cached locally by your external user's browsers/proxies/ISPs. So it doesn't really give you anything except a small latency gain.

If you find yourself adding many external Javascript files then you should perhaps reconsider your overall design strategy. Choose a good general purpose library (I personally consider jQuery to be unbeatable - this is the subjective part) and learn it inside-out. You shouldn't have to add many more libraries apart from the odd plugin, which should be included on a page-by-page basis anyway.

Some really good answers from the others on here by the way.

Daniel Dyson