So what is the one thing that people can do is to make their website better? To answer that, let’s take a step back in time …
The year is 1998, and the web is on the rise. In an attempt to give a high-level overview of the architecture of the WWW, Tim Berners-Lee — yes, that Tim Berners-Lee — publishes a paper called “Web Architecture from 50,000 feet”. The report covers lots of things: content negotiation, the semantic web, HTML, CSS, and cool URIs (which don’t change), among others.
In the article, Berners-Lee also notes a few design principles very early on. One of those principles is the “Rule of Least Power.”
The Rule of Least Power goes like this:
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. […] The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.
We have three main languages available on the web for the front end:
Semantically describes the content
Controls the presentation and layout
Adds interactivity and behavior
As Derek Featherstone nicely put it:
In the web front-end stack — HTML, CSS, JS, and ARIA — 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.
💡 Hold up: This doesn’t mean you should set font sizes and colors via markup — a thing we used to do in the “olden” days of the web. Case in point: one of the rules covered in Berners-Lee’s piece is the separation of form and content.
The broken web
It has been almost 25 years since Berners-Lee published that article. Yet, somehow, the message he sent didn’t get through, and many developers — but not all — are unaware of it. Take this situation Drew Devault encountered not so long ago:
While a form might be a familiar example, there are more situations where applying the Rule of Least Power gives better results:
In all these examples, we can move some functionality from an upper into a lower layer. Berners-Lee would be proud of us.
By choosing a technology lower in the web stack, closer to the core of the web platform, we also gain the benefit of built-in resilience against failures.
undefined” sounds familiar to you, you know what I’m talking about.
CSS, on the other hand, is very good at failing. Even if you have a syntax error in one of your style sheets, the rest of your CSS will still work. Same with HTML. These are forgiving languages.
If you doubt why you should use the Rule of Least Power, Jeremy Keith brings us the answer in his article “Evaluating Technology”:
We tend to ask “How well does it work?”, but what you should really be asking is “How well does it fail?”
We can do better
- Why not immediately include
- Why not use a
<select>(to choose your size) and a submit
The same goes for certain CSS features that may or may not be available. Provide basic styling, and when a feature is available — detectable using
@supports — enhance the result you already had.
This approach is known as progressive enhancement: You add functionality as more features become available, making the result better as far as the experience goes, but not so much that the feature cannot work without those extra flourishes.
And for browsers that don’t yet support a particular new feature, you can try and find a polyfill that provides that functionality to the browsers.
The web catches up
Things that were impossible years ago and that could only be done by relying on external technologies, like Flash, are now built into the browser itself.
A classic example is the features jQuery introduced. Over ten years ago, jQuery was the very first thing to drop into a project. Today, that’s no longer the case, as the web platform has caught up and now has
Element.classList, etc. built-in — all features inspired upon features jQuery gave us. You could say that jQuery was a polyfill before polyfills even were called polyfills.
While jQuery might be a familiar example, there are many other situations where the web has caught up:
The central theme here is that these features no longer rely on a polyfill or an external library but have shifted closer to the core of the web stack. The web catches up.
While some of these new APIs can be pretty abstract, there are libraries out there that you can plug into your code. An example is Redaxios, which uses
fetch under the hood while also exposing a developer-friendly, Axios-compatible API. It wouldn’t surprise me if these convenience methods eventually trickle down into the web platform.
What Berners-Lee wrote almost 25 years ago stands the test of time. It’s up to us, developers, to honor that message. By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.
Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.