David N Brooks Designer, Developer, Musician, Artist, and Writer

Hello! I’m David, an interactive designer, musician, artist, and writer living in Georgia.

Web Standards and JavaScript for Aging Devices

17 July 2014

JavaScript code in an Commodore64-themed editor

The first thing I learned about web development was that there was this thing called “Web Standards”, and it was awesome. We as an industry are better for it because it’s inclusive and altruistic. People with screen readers, for example, benefit from it because we knew better than to just use Flash on everything. You’re probably not writing your HTML into tables these days, so thank the web standards movement for that too.

But web standards also ventures into things like removing onClick=“Insert your JavaScript Here” from your HTML, and instead advocates for placing that JavaScript in your actual JavaScript file. And that’s smart, because when you’re working on a web app, or a site with a lot of pages, you don’t want to go through and pull out references to things you use over and over again.

In fact, that has been one of my primary frustrations with AngularJS. It’s so much of ng-click=”“ that it’s basically a collection of “bad practices”.

The Problem With that

We’ve been working hard on an iOS app over at Artletic. We opted to use the Ionic Framework, but not all of the Angular JS stuff because, well, at the time it didn’t seem to be necessary when all we wanted was some HTML and some JS. I set the thing up on day one and it just flew. Seriously, it was quick.

Fast forward to last week and the app was just dragging on my actual iPhone 4. Now, that’s on a 4. It was semi-usable on a 5, but not everyone has a 5. In fact, I could hardly test the latest features because it was so slow on my phone.

So I remembered something that happened to me a few years ago when I worked at (what was then) Fellowship Technologies. I created this nice and orderly list wherein people could interact with their data. However, we never tested it with thousands of entries. Shortly after, Nathan Smith and I (mostly Nathan) refactored my code to work for larger sets of data because it had a serious performance drain under those conditions.

The Wisdom in Being “Wrong”

The way he did it, was to rework and then reference the JavaScript function with an onClick. Why did it work? By registering click events for every last one of those thousand items, there was just so much extra memory weight that it dragged down the app. Putting things in the HTML itself meant that the browser didn’t have to roll through every entry and create those events, then watch each and every one of them. It meant that the browser didn’t have to care until you interacted with that data. Then, it would see the onClick event and take action… But only when you clicked it.

In my Ionic project it was the same thing, but on a much smaller and finicky scale. My browser was completely fine with the JavaScript, the simulator was fine with the JavaScript, but the actual device was not. The iPhone is a much lighter device than my Macbook (obviously), there should be no expectation of comparability.

I had been using the module pattern, and each click event was already referencing functions.

Before, it looked like this:

$('body').on('click', '#something', function ( ){
	interaction.load_something();
});

But for performance’s sake, I changed it to be this:

<a href="#whatever" id="something" onClick="interaction.load_something();">Whatever</a>

When there are large sets of data, that markup is neatly placed in a Handlebars template that gets added and subtracted from the DOM as necessary. It’s just as performant if there are one or a hundred things in the list, and because it’s included in a partial, I’m not having to maintain that code in 100 pages across an app. And I think that’s why AngularJS uses hg-click as well.

The speed increase was immediately apparent. I removed the click function in my JS file for one of the biggest offenders, and the app was suddenly very usable. It wasn’t as usable as I wanted it to be, however, but when we removed a good number of the click events it sped up quite a bit.

So while it wasn’t exactly a tactic that I’ll be applauded for in the web standards community, it saved our app and, thanks to Handlebars, still kept me from having to weed through too much JavaScript in my HTML.

In Reality

This really isn’t an anti-web standards post. Honestly, the old wisdom is so good that most of my sites will still use the same module pattern and click events routine. But when I’m building something mobile/hybrid, inline click events are a small price to pay for what could be a large number of happier users on aging, lightweight devices.

Care to Leave a Comment?

Note: Off-topic or offensive comments will be removed.

About Me

I'm David Brooks, an interactive designer, generative artist, and electronic musician from Michigan. During the day I build things for Artletic, a great UX studio in Colorado. At night I create art and write music as Light The Deep and craft applications like Thousand Wires, JavaScript libraries like ArtisanJS, and build interesting things for the amazing clients of Northward Compass.

Read My Full Bio

You Also Might Like...

Technically Speaking

This site runs on the Textpattern content management system. CSS is precompiled by SASS, of course. Only a handfull of JavaScript libraries are in use, most notably Grunt. The visuals are done (by me) in Processing and Modo. The fonts are delivered with love by Typekit.

Whew!

365 Days of Paleo/Progress

On July 1, 2014 I started into a year of Paleo and better health.
Here's my progress at a glance.

-18.2 lb. Weight

72 oz. Water Per Day

1787 Ave. Calories

See the progress

© Copyright 2005 - 2017 David Brooks. All rights reserved.