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) 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 ( ){

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.