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. 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 feels like a recreation of onClick.
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.
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 scale. My browser was completely fine with my 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.
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 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 in the mobile/hybrid space, something like inline click events is a small price to pay for what could be a large number of happier users on aging, lightweight devices.