With any craft, high quality output takes time. Unfortunately, many businesses don’t make the time for their website to be treated this way (I say “website,” but as the lines between “websites” and “web apps” continues to blur, I use them interchangeably.) Output, either in volume (number of features or changes) or appearance, is often valued over specific techniques, or how things are built “under-the-hood”. As developers, we often hear that, “users don’t care” what framework or tools are used to build your site. And this is largely true - until it isn’t.
To deliver quickly (often at the demands of some management team), teams take shortcuts, or piece together bulky, off-the-shelf solutions, all in service of shipping quickly. Eventually, the choices made in building a website inevitably spill into the user experience. Fast-made, flashy output comes at a cost, and that cost is often exclusion.
And yet, the internet is supposed to be for everyone. The core principles of the web prioritize access over all else. One of the earliest goals for the Internet was the democratization of information, after all. HTML – the foundational programming language upon which all web sites are built – includes Universal Access as one of its design principles. And yet, modern development practices often forego accessibility in the name of “developer experience” (or “DX”) with the argument that better DX leads to better user experience. This may sometimes be true, but it’s not the maxim the industry wants you to believe. Our devices get faster every year, and yet the modern internet still feels slow thanks to ever increasingly bloated websites. Developers’ choice of tools play no small part in this.
The presumed starting point today typically consists of an app framework (React, Vue, etc.), state management (Redux, Vuex, whatever hot new one was invented this month), CSS framework (Tailwind, Bootstrap, etc.), and a long list of dependencies for whatever build tools your selections require. Tutorials abound with starting points like this, without much consideration for whether or not the project requires such powerful tools. These tools are fickle, change often, and introduce complexity, often before they’re actually necessary. The result is frequently a slow, error-prone, over-engineered end product that only gets harder to manage over time.
But the web’s foundation – its simplest set of tools – is largely unbroken, and surprisingly powerful. Another of HTML’s guiding principles is to support existing content, meaning: don’t break what’s already been built. While nothing special by modern standards, the fact that you can visit the first website ever (released August 6th, 1991) in a modern browser and it still works is a remarkable feat. Plenty of “modern” websites simply don’t have that same resiliency. In a landscape that changes as fast as the web, the resiliency of your website should be a top priority. By utilizing simpler, more foundational tools and approaches, we can build faster, more accessible, more resilient websites. A return to basics is both good for the web, and for business.
But basic doesn’t mean incapable. It means thoughtfully and intentionally selecting the right tool for the job. It means striving to find the most basic means of achieving the desired outcome and building from there. If this approach is ringing any bells, it’s because we generally call this Progressive Enhancement. Most of the time, this means (semantic) HTML-first solutions that we selectively “upgrade” with javascript when we can.
This is generally the opposite of “default” tools the industry gravitates to in the name of “DX”. If all your markup depends on React (or other framework of choice) executing before it can render anything, it’s not only slower, but a single error can result in a blank page. The “default” tools shift evermore javascript into the browser despite the high cost of shipping javascript. Mitigating those costs adds an increasing level of complexity to even the most basic use cases, and failing to mitigate them results in slow user experiences.
And the experiences aren’t just slow, they’re exclusionary. The heavier your site is, the more powerful a device your users need in order to use it. You’re excluding lower-income users this way. Along with the speed penalties of lots of javascript, the ever-increasing weight of the average web page means it can cost a lot (in actual dollars) for someone to even visit your website, as What Does My Website Cost can show you. According to Statista, 52.3% of U.S. internet users in 2021 were mobile-only. Presumably they’re on wi-fi sometimes, but the likelihood they’re on a metered connection is pretty high. Data-heavy websites further select your audience by wealth.
We further exclude audiences by taking shortcuts. Modern development practices undervalue semantic HTML, and other accessibility best practices. Accessibility advocates are constantly fighting a culture that sees the steps required for ensuring a site is accessible as “extra work.” Instead, we should see this for what it is: cutting corners. Rather than spend time doing the right thing, a profit-seeking industry of “accessibility overlays” has emerged, promising companies 1-step fixes for “full accessibility compliance”, despite mountains of evidence to the contrary – accessibility overlays don’t work.
Our modern tools promise time savings, outputting complex capabilities in short amounts of time. But the way those capabilities are output matters. As the presumed defaults, these tools often feel like using a power drill to repair eye glasses. Sure, a drill turns screws, but it’s way more than you need to fix a delicate pair of glasses. Lately it’s the same with websites. That’s not to say our more powerful tools don’t have a place – they absolutely do! – but as the assumed default, they’re probably too much. I believe a simpler way is not only possible, but yields better longterm results through dependability.
Ultimately, I believe this is rooted in a lack of belief that our work as web developers is indeed a craft. An art as much as it is science. Like any craft, experience is the best teacher. Yet the industry pitches powerful frameworks and related tools as shortcuts to complex, professional outputs. But no one becomes an expert at their craft by jumping straight to advanced tools. And yet this is largely what our industry pitches to developers.
Look – there’s nothing wrong with getting a crash course in pro-level tools to jumpstart a career. But as a craftsperson for the web, there’s a duty to also understand the foundations those tools ultimately rely on on behalf of your would-be users. Building for the web comes with a responsibility of ensuring access, knowing where your tools and techniques fall short, and doing what you can about it.
When you view building websites as a craft, your most basic techniques are your most useful. You learn over time when to bust out the power tools, and when to keep things a little simpler. The prioritization of output over methods is directly opposed to this craftsmanship view of web development. Craftsmanship takes time. Most companies aren’t willing to give their teams the time, and their users ultimately pay the price in buggy, slow, inaccessible products. If you’re lucky, your users will tell you something is broken; most of them will leave. Site speed matters.
You see this kind of bloat in more than engineering practices. Too much content (or the wrong kind). Too many ads. Too many user behavior trackers for the marketing team. All contributing to poor user experiences that prioritize business goals over user needs. The list goes on; in extreme cases to the point where a website’s (or at the very least, a given page’s) purpose is entirely unclear to the visitor. The demands of a modern website are indeed high.
I don’t have answers for all of these issues, but on the engineering front I propose a radical return to basics. Treat web development as a proper craft, to make simple, well-crafted websites.
A simple, well-crafted website is enduring. It requires little maintenance, and works reliably.
A simple, well-crafted website is accessible. It can be used by anyone, regardless of their abilities.
A simple, well-crafted website is fast. It loads only what is needed, as it’s needed, in the most efficient manner possible.
A simple, well-crafted website achieves its purpose. Its reason for existing is clear, and readily executed.
By looking to simpler, more basic engineering approaches, we can spend less time managing and mitigating the impacts of our power tools, and more time delivering the best for our users.