Practice Defensive Javascript: Assume Blocking of Third Party Resources
I, being basically sensible and lacking any patience for the indignities that other people consistently try to force upon me in the name of their outdated business models, use a small array of browser add-ons that efficiently block near all trackers and ads. I have little patience for the idea that I should be donning a hair shirt and suffering because various entities can't figure out how to apply basic ransom and donation business models to their provision of content to the world. This is entirely as an aside to the thrust of this post, but here is news for you: if you are in the business of arranging bits into a specific order and then propagating that arrangement for profit, then whether you like it or not you are in fact running some combination of a ransom and donation business model. Everyone who wants your content for free will have it, and with increasingly little effort required as time goes on. The only people paying you are those generous enough to acknowledge your effort or who are willing to pay up front in order to obtain the content at all. You can either acknowledge that and go with the flow, and thereby prosper, or you can fight the tide and suffer considerably as a result.
I am far from alone in blocking ads and trackers. Yet I consistently run into sites where the technical implementation fails to take the blocking demographic into account. Now sure, if you are running an ad-supported site then from a business perspective you might not care about people with ad-blockers, and in fact if they can't see your content more to the good. I'd argue that this perhaps misses many second-order effects in distribution of easily copied content - which is to say all content in this day and age - but that is a choice that content owners can make. As for the rejection of the donation and ransom model, they can live and die by that sword. However there are all too many sites out there using analytics trackers, sharing widgets, and similar tools that are not ad-supported and for which pages won't load, or load excruciatingly slowly, or are missing important sections when these trackers are blocked. There is no good reason for that: it is plain old technical error to create a site that fails gracelessly if a third party resource associated with non-critical functionality cannot be loaded.
Let's pick on the AddThis sharing tools for a concrete example. They are everywhere on the web and also justly and rightfully blocked by the tools I use. Here is a quick way to cause fatal issues on a feature-rich page for everyone who blocks AddThis third party Javascript:
<script type="text/javascript" src="http://s7.addthis.com/js/300/addthis_widget.js#domready=1" ></script> <script type="text/javascript"> addThis.toolbox( "#addthis-toolbox-1", { ui_click: false }, { url: http://www.example.com/page title: "A page" } ); // // Any further Javascript here will not run because the addthis.com // script is blocked and thus the variable addThis isn't set. Thus // attempting to invoke addThis.toolbox will throw an error. // </script>
This and all the other possible ways to derail Javascript execution due to missing pieces are easy to solve provided you keep them in mind at the outset of development: you can create placeholders early and load third party dependent DOM elements late so that designs remain intact; you can check for the existence of important variables set by third party Javascript; you can logically isolate third party page components and functionality in your code; you can defer selected execution for a little while until something does exist, or fail gracefully after a set amount of time. The hard part is retrofitting this sort of robustness into Javascript code that was written without giving any consideration for the possibility that third party resources may not load. There really is no excuse for the core function of a page, such as login or display of data, to fail outright just because a tracker is missing.