What I learned from writing payment interfaces (Part II)

[Note: Each post in this series will have a sidebar with questions intended to encourage you to think.]

In Part I the focus was on the foundational elements of a web app, and how those foundational elements aren't generally within the domain of the UI engineer, even though they are of significant importance. In this entry, I'd like to consider the aspects of code speed that are generally within the domain of the UI engineer.

Code speed

• Which is faster - Value equivalence (==) or Type/Value equivalence (===)?
• Which is faster – a native JS for loop to iterate through a NodeList or the jQuery "each"?
• Which is faster – an if..else statement or a switch statement?

One of the practices I’ve seen in my years as a UI Engineer is a constant, steady, relentless increase in the amount of code associated with an app. We, as a group, know the importance of keeping page weight low; however, somehow we end up with 86MB pages that win design awards^[1].

Even though such monster pages are rare, common code that I've seen typically includes a little bit of everything from poorly-written HTML that either uses tables for layout or is rampant with div-itis^[2] to bloated and/or low-performance CSS and low-performance JavaScript. All of these have an impact beyond page weight alone.

I have no desire to jump on the JavaScript is bad bandwagon. I firmly believe that HTML and CSS should be subject to many of the same rules as we have for JavaScript and be as simple as possible; however, there is often little we can do to HTML and CSS to increase the speed with which the most basic page renders. We ought to hold fast to the principles of both progressive enhancement and semantic markup, but we ought not stop there. We are no longer - at least in my experience - being paid by the KLOC^[3], so take up the practice of delivering the least amount of code possible. I can promise that this practice will benefit you in a number of ways in the future^[4].

Further, as UIEs, we must take the same ruthless approach with JavaScript. The first question we must ask is "is it necessary" because, based on my observation, we seldom consider the effect seemingly simple things, like DOM manipulation, have on speed. It’s all too easy to look at a block of code and think “it runs in less than 10ms, so it’s fine” without considering how that block of code is actually used - a practice we must abandon. We have to ask ourselves how the code is being used. For example, does the code trigger a repaint? Is the block of code wrapped in a setTimeout or setInterval that may cause a race condition that impacts the interface? Does the block of code do something that impacts user interaction, like disabling a field or repopulating a drop-down list?

Beyond the overarching questions, however, we must get into a practice where every line, every block of code is ruthless written to perform. For example, it is fairly commonly to see a value equivalence check used even though a faster type/value check would return the same result, and I see many more if/else statements than faster switch statements. We must implement design patterns that give speed advantages whenever possible. This simple practice will become increasingly important as we develop more apps that run on mobile devices and we begin to focus on framerate and how our code affects animation.

We must change our thinking. As I said before, speed cannot be considered in isolation but it also must not be an afterthought. We must get out of the mindset that development is about function – the app does the job – or form – the app is habitable, not only for users but for engineers as well – and into the mindset that development must be a balance of function, form, and fitness – the software performs – and that we must develop from the outset for fitness.

Notes:

1. This time it's Oakley's page for the Airbrake MX, which I have every reason to believe is a wonderful product. Details about the Site of the Day award from awwwards, and some discussion about it can be found on the awwwards award page. Documentation about the site can be seen at Oakley's monster page of baubles.
2. Div-itis is the tendency to wrap portions of code inside a div tag, and preferably add an ID attribute in case there will be some DOM manipulation in the future.
3. LOC is "line(s) of code", so KLOC is 1000 lines of code, which was an early measure of productivity for programmers
4. Many of us have heard it said, and can attest to the truth of the matter, that complex systems fail in complex ways. Simple code not only carries a lower risk of failure, but a greater chance of resolution and repair when failure occurs.