Including local vs. remote javascript libraries

Question

I'm using jsSHA 1.3.1 which I downloaded here and used in learning project on my localhost. It gives a slightly different result than the copy I got by referring to the remote as follows:

<script src="https://raw.github.com/Caligatio/jsSHA/master/src/sha1.js"></script>

The remote copy works well for me, now, thanks to this excellent answer by @Andreas here.

But it leaves me with a new question: what's the rationale for including a copy vs. referring to a remote js library? Is it like 'vendoring' the library, insulating my app from subsequent changes in the code?

Answer 1

If your application is available on the WWW, you should consider using a well-known external URL.

---

<script type="text/javascript"
   src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js">
</script> 

This example below gets the minified version of jquery 1.8.0 from google's servers.

---

• The benefit obtained by this method comes from caching:

• You do not want the first visit a potential user makes to your website to be slow and disappointing. If your first-time visitor has visited my site which uses this URL for jQuery, her browser will probably have cached it so it will not need to load it.

• Using immutable versioned resources (jquery/1.8.0 instead of something like jquery/current) both helps developers not have to track down breaking changes in their production code and ensures that these resources can be cached.

• If the resource has to be downloaded and the URL is hosted on a CDN you are likely to get lower latency as the resource will probably be loaded from a server closer to the user's network. The URL in the example is hosted on Google Hosted Libraries which is a CDN. See https://developers.google.com/speed/libraries/devguide for more information.

• Another argument often seen in such discussions is that when the resource has to be downloaded, you will be able to get better client-side resource loading parallelism if the resource is not on your own servers together with 10 more resources your page includes because browsers limit themselves to loading up to a small number (6 or so in modern browsers) of resources form the same server.

• If your internet-wide web application is security-critical, you must keep control of as much of it as you can securely manage (and static immutable or nearly immutable resources are relatively easy to manage securely).

• If my bank's e-banking application which runs over HTTPS were to rely on google's HTTP servers for serving, it would both be granting Google authority over the client-side part of its e-banking application and eliminating practically all benefits of the HTTPS connection to its servers. There are very few things that a rogue client script cannot do...
  
  

• If your application is accessed locally, you should probably include it in your application for both performance (access to your servers should be faster than accessing some remote server both in terms of latency and in terms of bandwidth) and reliability reasons (you are not relying on the external internet connection and on the remote servers being up and running).

Answer 2

It comes down to whether or not the developer is happy with you 'hotlinking' to the JS library.

Regarding the specific URL that you have posted,

https://raw.github.com/Caligatio/jsSHA/master/src/sha1.js

I would be wary of referencing that. It is the master branch of their source code, they may include breaking changes at any time. They may even decide to move and restructure their codebase, in which case your application will break as the URL above will lead to a 404.

The better solution is indeed referencing a specific version of the library. This ensures that your application behaves, and will continue to behave, in an expected and known manner as far as the jsSHA library is concerned.

There are a few ways to do this. You can reference a specific, fixed URL that explicitly specifies a version

http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/hmac-sha1.js

Because its tagged (3.0.2), you are a bit safer, but you are still referencing source control. This should really be done via a CDN if one exists. I do not believe that the googlecode.com URL is a CDN URL (I could be wrong). It is of course a common practice to use a proper CDN or external link to reference a JS library and you can see an example of this on the JQuery page, but this is often done as part of page performance enhancements. A CDN is optimized for a user's geographic location so a reference to any content on a CDN (as opposed to the main server) will be served faster. It has user experience benefits. It's useful if page load times are important for your userbase.

The alternative, and the safest way, is to keep a copy of the JS library in your own source control and reference it using your own infrastructure. It's with you, it is a fixed version and there are no surprises if something changes, such as restructuring, sites going down, and so on.