Over the last few months there has been a surge of prominent web people – designers, developers, thinkers – questioning the current obsession with complex “web app” style frameworks. Perhaps this was prompted by Jeffrey Zeldman’s ‘The Cult of the Complex’ article from June 2018, or perhaps this is a natural reaction from people who deeply understand the web.
The ‘backendification of front-end development’ is causing a lot of different questions to be asked. From Bridget questioning the usage of a JavaScript framework to Michelle building a dependency-free site. There are designers learning about semantic HTML and calls to consider limiting JavaScript usage. And reminders to developers that you probably don’t need a single-page application.
The theme perhaps culminates in this instant-classic article by Jeremy Wagner on A List Apart: Responsible JavaScript. This pared-down approach is closely aligned with accessibility – it’s about using the most suitable technology for the job.
Which brings me on to horses. But first, web apps.
What is a ‘web app’? Wikipedia helpfully has a definition – of sorts. But there’s a certain amount of bet-hedging:
The general distinction between a dynamic web page of any kind and a “web application” is unclear.
https://en.wikipedia.org/wiki/Web_application
Which chimes with my experience when I ask peers for a definition. They all but cry “You just need to feel the difference, man!”
After all, it’s not like we’ve not had interactivity in web pages before the advent of the current crop of JavaScript frameworks. Gmail, considered by many the poster-boy for a modern web app, was launched this very day in 2004. Fifteen years ago!
So, horses. Back when the early automobile engineers were putting together the first cars, there was a clear distinction between the mode of transport widely used before – the horse – and what they were building. There was no confusion, no perplexed on-lookers asking “is that a horse, or an automobile?” There was a world of difference between the ‘old’ and the ‘new’.
A world of difference, but still much the same. The problem that horses and automobiles were solving was, essentially, the same: getting people from point A to point B. But the mechanism – the technology – used to achieve that goal was entirely different.
Not so with ‘web apps’. The technology is pretty much the same as before: HTML, CSS and JavaScript. The application of that technology has a few extra bells and whistles, and there are newer browser APIs we can take advantage of – Service Workers being a prime example. But, essentially, what we build for the web hasn’t changed all that much.
Except it has, or so the framework-fanboys would have you believe. I’ve heard developers talk about the more traditional ways of building websites to be akin to riding a horse, while using a Single Page Application framework is like driving a sports car.
I have bad news. A sports car works great in the circumstances for which it was designed. But take it out of its natural environment – take it off the track and onto a mountain pass, for example, and you’re in trouble. For harsh terrain you’ll need a horse, not a sports car.
You see, a horse might not be as quick on a flat race track. It might not have a heads-up 3D display to show you the turns ahead. It probably isn’t equipped with intelligent side impact protection systems. But you know what it does have? The ability to do the job in less-than-ideal conditions.
Because that is how the web is experienced by most people, most of the time. Poor bandwidth, slow latency, underpowered devices – these are the bumps, potholes and rocks in the road which will stop your JavaScript sports car in its tracks.
So, like the luminaries of the web I mentioned above, I add my voice to the growing cry: consider your JavaScript use carefully. You may not need as much of it as you think.