I like good design principles. I collect design principles—of varying quality—at Ben Brignell also has a (much larger) collection at

You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?

  • Good design principles are memorable.
  • Good design principles help you say no.
  • Good design principles aren’t truisms.
  • Good design principles are applicable.

I like those. They’re like design principles for design principles.

One set of design principles that I’ve included in my collection is from government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:

Government should only do what only government can do.

This wasn’t a theoretical issue. The multiple departmental websites that preceded were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.

I think that the design principle from GDS could be abstracted into a general technology principle:

Any particular technology should only do what only that particular technology can do.

Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:

JavaScript should only do what only JavaScript can do.

Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.

I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:

Choose the least powerful language suitable for a given purpose.

Or, as Derek 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.

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

Have you published a response to this? :


Andrew Travers

Nice to see Co-op’s design principles feature in @adactio’s list linked here. Pretty proud of that collective effort. You have to be inside an org to appreciate the context but they were, for us, part intent, part provocation. Said with feeling.

Patrick Haney

@adactio should only do what only @adactio can do”, which is to say that Jeremy once again has thoughtfully explained why the “appropriate” technology stack is more important than the “latest” one

Stuart Robson

> “It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering.” Principle from @adactio

Šime Vidas

Even a blog site requires a tool that builds, generates, renders the site. Why couldn’t that tool be a JS framework? Depending on how you use it, it doesn’t have to be over-engineering.

Andy Bell

Eleventy is JavaScript and pre-builds a static HTML website. This is fine. What the quote references are projects like Gatsby that do similar but then push a ton of JavaScript down the pipe which makes the blog behave like an SPA, which is completely unnecessary.

# Posted by Andy Bell on Saturday, July 27th, 2019 at 5:47am


# Shared by Jacky Alciné on Friday, July 26th, 2019 at 7:29pm

# Shared by Aleksi Peebles on Saturday, July 27th, 2019 at 4:54pm


# Liked by Chris M. on Thursday, July 25th, 2019 at 7:24pm

# Liked by Aleksi Peebles on Sunday, July 28th, 2019 at 12:21am

Previously on this day

1 years ago I wrote The history of design systems at Clearleft

From pattern portfolios to Fractal.

3 years ago I wrote Animating

A few examples of animation on the web.

3 years ago I wrote Class teacher

When abstraction becomes obfuscation.

7 years ago I wrote How do I convince…?

All of this has happened before. All of this will happen again.

14 years ago I wrote Geekend in the country

I spent the weekend in Oxfordshire in the company of my fellow geeks and Brit packers. A photo pool has been set up on Flickr so you can see exactly who was there and what merry japes we got up to.

16 years ago I wrote Beach Guardian

Here’s the Guardian article about writing Guardian articles from the beach in Brighton.

17 years ago I wrote Band photos

There’s a local "what’s on?" type magazine here in Brighton called The Source. The next issue of The Source is going to run a feature with a passing mention of my band. Fame at last!