Five JavaScript Errors That Attack Without Warning

"The Web is the most hostile software engineering environment imaginable."

— Douglas Crockford

We run web applications in a hostile environment. With each page-view, our JavaScript is deployed over an unpredictable network into a browser that we do not control. It's scary, but we've broken down five JavaScript errors that impact JavaScript apps today, usually without the developers even knowing about the problem.

1. Asset Loading Failures

Most web applications load a few JavaScript assets: a framework from a CDN, some third-party plugins, and one or more custom script files. What would happen if some or all of them failed to load?

This isn't a hypothetical question. Statistics from TrackJS show that on average 1 in 500 page-views is impacted by a load failure. This can happen for many reasons: poor network connections, server blips, provider changes, and DDoS attacks.

In a way, complete failure is an easier case to deal with. If none of the JavaScript loads, your Single-Page Application will simply show an empty or "No JavaScript" UI. But it can be far more dangerous if only one script fails to load.

For example, failure to load a payment processor library could expose transactional details and personal information. Failure to load a social, advertising, or content network could prevent part of the UI from rendering.

2. Async Race Conditions

Lots of JavaScript involves setting up and responding to asynchronous events, such as user actions or network transmissions. When multiple async actions need to come together to produce a result, you have the makings for a race condition. Consider this simple example:

var obj = {};

$.post("/api/thing1", {}, function (resp) {
	obj.thing1 = resp;
});

$.post("/api/thing2", {}, function (resp) {
	obj.thing2 = resp;
	obj.result = obj.thing1 + obj.thing2;
});

There are two AJAX requests started. When the second completes, the two responses are combined for a result. This works fine when "/api/thing1" finishes before "/api/thing2", which may be true on your local environment. But introduce a real network and the orders can reverse.

3. Vendor Library Changes

Many sites take advantage of third-party libraries: payment processors, analytics, advertisers, or social networks. Each of these provide valuable services that make it easier for all of us to build something awesome.

But we must recognize that we're introduce a dependency and a risk with these libraries. Vendors can change their API or their performance without warning.

4. Browser Runtime Changes

The browsers themselves are changing on us. Every day, they fix bugs and push new capabilities. But sometimes we expect those bugs, or sometimes new bugs are introduced.

Last October, Apple shipped a version of WebKit into iOS that made subtle changes to the DOM and caused bugs in Ember, Angular, and Polymer core.

In a few weeks, Microsoft Edge will launch. It will inevitably include changes to the JavaScript runtime, the DOM, and CSS interpretation. We'll have to retest our apps to make sure they all work great in it.

5. Invasive Browser Plugins

Many browsers have an ecosystem of plugins that users can install to extend and enhance the pages they visit. Unfortunately, these plugins can stick their fingers into the DOM and sometimes mess with the flow of your app. It only takes one important user to make this a big problem:

"…the boss found a bug, but it only happens on his wife's computer. This has to be fixed before launch!"

—Anonymous Client Interaction

Search toolbar plugins are really common malware, and they frequently mess with form inputs. They can also change performance characteristics, override APIs, and mask events.

Monitoring and Prevention

Running web applications is hard. Because the platform is constantly shifting, we are never "done". We must constantly monitor and re-test our applications to work with current users, the networks they access through, and the browsers and plugins that run our app.

Once you've launched, you should monitor your web applications with TrackJS. TrackJS monitors real users on your site and tells you when they have a problem. TrackJS records all your production JavaScript errors, and includes deep context about what the user, the network, and your application were doing leading up to the failure. TrackJS doesn't just count your errors, it gives you the context to fix them.

TrackJS is an incredible tool for monitoring your site's JavaScript reliability. Every day I receive an email listing the error rate and the top errors for my site. After logging into my TrackJS account, I can see detail about each error, including browser and browser versions, pages the error occurred on, and more. There isn't a better tool out there!

— David Walsh

Grab a free 30 day trial today from TrackJS and let's start finding and fixing bugs for your users.

About Todd Gardner

Todd Gardner is a software entrepreneur and developer who has built multiple profitable products. He pushes for simple tools, maintainable software, and balancing complexity with risk. He is the cofounder of TrackJS and Request Metrics, where he helps thousands of developers build faster and more reliable websites. He also produces the PubConf software comedy show.

www.toddhgardner.comtoddhgardnerPosts