Fellow Web Devs: Let’s Get Reacquainted with the “Rule of Least Power”

What’s the best way to build a website? Now there’s a question bound to start a thousand flamewars and tweetstorms. To be clear, though, I’m not asking about the best software to use, the best CMS, the best libraries, etc. No, my question speaks to something far more basic and fundamental.

As part of CSS Tricks’ ongoing series about building better websites, Bramus Van Damme highlights a foundational principle espoused by Tim Berners-Lee (creator of the World Wide Web) called the “Rule of Least Power.” The rule states (emphasis mine):

When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.

In other words, keep things as simple as possible and don’t overpower or overcomplicate.

This might seem counterintuitive, especially if you’re fortunate enough to live in a place with easy access to powerful computing devices and high speed internet. After all, why wouldn’t we choose to use the most powerful tools at our disposal?

There are three languages to consider in front-end web development. They are, in order of most fundamental to least fundamental:

• HTML, which uses tags like <h1> and <p> to create structure and impart semantic meaning to a webpage’s content.
• CSS, which handles the presentation and layout of the webpage’s content by assigning styles (e.g., typography, colors, positioning) to HTML elements.
• JavaScript, which enhances the webpage with interactivity (e.g., responding to user input, dynamically manipulating the webpage’s content, generating modals and popups).

Applying the “Rule of Least Power” to front-end web development, writes Van Damme, means that we should “[do] as much as possible using HTML before resorting to CSS. Once CSS is no longer sufficient, grab for JavaScript — but only if you really have to.” He also quotes Derek Featherstone, a web accessibility expert: “In the web front-end stack… if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.”

Or, as the W3C puts it:

If, for example, some weather data is published as a Web resource using RDF, a user can retrieve it as a table, perhaps average it, plot it, or deduce things from it in combination with other information. At the other end of the scale is the weather information conveyed by an ingeniously written Java applet. While the applet might provide a very cool user interface or other sophisticated features, the results of the program will not usually be predictable in advance. A search engine finding the resource will have no idea of what the weather data is or even, in the absence of other information, that it is a weather-related resource. The only way to find out what a Java applet means is generally to set it running, and see what it does. Thus, HTML, CSS and the Semantic Web are examples of Web technologies designed with “least power” in mind. Web resources that use these technologies are more likely to be reused in flexible ways than those expressed in more powerful languages.

The rest of Van Damme’s article highlights the many ways in which web development has been broken by developers ignoring or deviating from the “Rule.” And specifically, by an inordinate and unnecessary reliance on JavaScript.

JavaScript powers much of the modern web, particularly sites like Gmail, Facebook, and Instagram; it adds all of the dynamic and instantaneous interactivity that makes a webpage feel like a desktop app. Unfortunately, many developers go too far, perhaps out of ignorance, or a desire to experiment with the latest new craze, or just the programmer’s natural tendency to overcomplicate things.

Whatever the reason, they start relying on JavaScript for stuff that HTML and CSS can do perfectly well, thank you very much, such as submitting forms, lazy loading images, and controlling animations. And the extent to which they do rely on JavaScript for such things, the more brittle, less reliable, and less accessible their webpages can become.

Van Damme points to a much better approach: progressive enhancement, i.e., making sure that your webpage functions as completely as possible as plain old HTML first, and then enhancing it with CSS and JS — but only as needed. That way, if something happens (a user has JavaScript disabled, for instance), then your webpage isn’t compromised, but instead, remains accessible and usable.

As you might have guessed by now, I wholeheartedly agree with Van Damme’s article. HTML may seem less-than-robust, and certainly not as sexy as a full JavaScript-powered experience. But there’s something beautiful about its simplicity and straightforwardness. It’s incredibly flexible and surprisingly nuanced. And best of all, it’s solid and reliable.

Years ago, I read an article by a well-known designer — I think it was Dan Cederholm, though I can’t find the original article any more — about his favorite website. It wasn’t some flashy or glamorous portfolio site. Rather, it was a simple, no frills site for his favorite restaurant that served a single purpose: listing their daily specials. Because it was so simple, it loaded quickly every single time, giving him exactly what he needed when he needed it (e.g., when he was trying to decide what to eat for lunch). And I suspect that site, if it still exists, would load just as quickly and reliably now as it did way back then.

Now obviously, most sites don’t have such a simple, singular purpose. Most sites do require more advanced functionality, design, etc. But that story’s stuck with me over the years, lodged in the back of my mind as a sort of Platonic ideal. And perhaps because of it, I continually ask myself, “What’s the simplest, least powerful, and most unobtrusive way to develop a website that still meets its purpose, satisfies its stakeholders, and serves its users well?”

Such an approach may not always be feasible in the end. Perhaps that project you’re working on really does require a lot of JavaScript for some reason. (Are you really sure about that, though?) But in my experience, holding to the “Rule of Least Power” as much as possible is the best way to start things.