I'm reading an (otherwise fascinating) article now on Ionic and came across this snippet of code:
<script type="text/javascript" src="//code.angularjs.org/1.4.3/angular.js"></script>
<script type="text/javascript" src="//code.angularjs.org/1.4.3/angular-resource.js"></script>
<script type="text/javascript" src="js/services.js"></script>
<script type="text/javascript" src="js/index.js"></script>What's wrong with the above code? (And yes, the title mostly gives it away.)
By using a CDN for libraries in your hybrid mobile app, you've essentially ensured the application will be completely broken when offline. This is obvious, but like most of us doing client-side work, we've become accustomed to using CDNs for libraries.
Now - you may ask - what if the core functionality of the application requires you to be online? In that scenario, you still want to ensure you gracefully handle the user being offline. If your CDN libraries fail to load, most likely your application is going to crap the bed. If those libraries were stored locally within the application, you can at least still load up, detect the offline state, and then tell the user they can't do anything while offline.
Even better, you can add a simple event listener for when they get back online and then start the application up again. (And of course, you'll have an event listener for when they go back offline. Because that happens. A lot.)
For an example of this in action, see my earlier blog posts: PhoneGap Online/Offline Tip and PhoneGap Online/Offline Tip (2).
Archived Comments
These external libraries should only be used for initial testing, not in production. For the reason you state but also because the CDNs (or external resource) can disappear or be unavailable; but also because of the overhead of going to multiple sources to pull in JS libraries (and other stuff).
I use the excellent uMatrix blocker to track requests made by web pages and selectively enable the ones I trust. It is not unusual on heavy media sites to see 20-40 separate libraries being pulled in. Even worse is the use of dynamic library loading where there are continued new libraries added to the mix as the page is being built.
The best sites seem to have almost all resources coming from their own domains (and I trust them more.)
I'm not sure I agree with you that CDNs shouldn't be used in production. I think the benefit of them possibly being cached on the user's machine already is helpful, and a good CDN can return a resource that is closer to the user geographically. Yes, a CDN can go down, but I think the benefits outweigh that.
There's going to be trade offs no matter what you do. :\
Using a CDN without http on the url will fail on cordova apps, it will try to load file://cdnurl.
Using a CDN even with http will fail if you don't configure the whitelist/CSP/ATS properly.
And even with all this configured properly, the load will be slower as you have to dowload the code, at least the first time.
So, don't use CDNs on hybrid apps.
Good points. I ran into #1 about a week or so ago and had meant to blog it but never got around to it.
Wait: can't you put //code.angularjs.org/1.4.3/an... inside your cache.manifest file?
Are you joking or serious? (I don't mean that offensively - just curious.)