Go to vox.com. Go to uber.com. Diy.org. Jetsetter.com. (Just to name a few.) In order to imitate a real-life scenario — as-in: you’re someone whose time is valuable; you’re someone who is not reading this blog and not blindly following my instructions — scroll around quickly as soon as you have anything to scroll. Look to find some information you believe will be there, like a company blog, or a particular section or post. Click through. Scroll around and back to the top.
You probably experience what I do, and it is something you won’t see running the same tests at nytimes.com, daringfireball.net and much more. As you scroll, new loading happens even if the site appears ‘done’ previously. Sometimes, when you’re looking at something, it ‘disappears’, pushed down by some content that finished loading after it and above it. The site’s width changes. An image appears unexpectedly. An image that was there, is now re-loading.
If you’re on your fancy computer, try the test again on your iPhone 5. Or your iPad 3. Or your brother-in-law’s 2-generations ago Nexus. Or your 3-year-old Windows 7 laptop. The problem only gets worse on the newer sites. Why? I’ll hazard a guess:
These (cutting-edge) websites are making our computers do tons of math. Client-side, on-time rendering, much-vaunted techniques enabled by the best and brightest web-development frameworks available, are ruining many newer sites. These are probably great developers with good management and intentions. But the user experience here is one of incoherence. This is chaos-side rendering, because it takes away the ability of the programmer and the user to know what the app does in practice.
Client-side rendering should give web developers pause. Developers have to know their users have far more than enough bandwidth, processing power and memory to load the content the way they see it in development. And while top of the line computers get faster, the entry level computing devices do not. (Then, they should have to load their site in the 12th tab in a $100 no-name Chinese ASOP device while
in Antarctica on hotel WiFi to be sure they know what they think they know.) Client-side rendering might have gotten a site off the ground under budget. But now it might be bewildering that site’s users.
Other websites use this technique to great effect, I know. Some sites are perfect for it: Only loading a splash screen. Load data based on user input into a static design. Render a minimalist text-heavy blog. These can and have all been done correctly client-side.
This turn is even more frustrating, given that the Web won the battles of 2008: These sites tend to get their layout, navigation and error messaging right. But user experience is more than that; design is more than how it looks.
(It’s no wonder Mr. Arment has stuck with PHP. I’m similarly addicted to Ruby, so I realize I have a confirmation bias here. Please, explain to me why I’m wrong.)
Implementation is always the hard part. Choosing frameworks and languages with theoretical benefits is like picking any such idea: un-proven. But loading content in a browser is not cost free. And someone has to pay up. First prove that won’t be left to your users.
(For the record, these observations were made in mid-2014 on a late-2013 rMBP and iPhone 5S over Britain’s decent fibre via WiFi.)