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?
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).