I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:

JavaScript should only do what only JavaScript can do.

I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:

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.

Surprisingly, I got some pushback on this. Šime Vidas wrote:

Based on my experience, this is not necessarily the case.

Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).

(Emphasis mine.) He goes on to say:

My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.

There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.

To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.

So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.

I wrote about this recently:

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.

That’s why I responded to Šime, saying:

Your main concern should be user needs—not your own.

When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.

Before considering your ease of use, and maintainability, consider users first.

In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:

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.

I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.

There’s a whole group of tools where this point isn’t even relevant—build tools, task runners, version control …anything that never directly touches the end user; use whatever works for you. But if you’re making decisions around HTML, ARIA, CSS, or JavaScript, then appropriateness for the end user should take precedence.

If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.

Have you published a response to this? :


Nitish Chopra

“You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.” from adactio


# Shared by Gunnar Bittersmann on Thursday, August 8th, 2019 at 5:48pm

# Shared by Šime Vidas on Thursday, August 8th, 2019 at 10:51pm

# Shared by Chris Taylor on Saturday, August 10th, 2019 at 2:05am


# Thursday, January 1st, 1970 at 12:00am

# Liked by Charlie Owen on Thursday, August 8th, 2019 at 8:08pm

# Liked by Dominik Schwind on Tuesday, August 27th, 2019 at 8:46am

Previously on this day

3 years ago I wrote Exploring web technologies

From the very basics to the cutting edge.

6 years ago I wrote The dConstruct 2012 website

A little retrospective.

6 years ago I wrote August in America, day five

Philadelphia, Pennsylvania.

10 years ago I wrote dCapsule

Add a memento to the dConstruct time capsule.

11 years ago I wrote Finding five numbers

Off-site Pownce metadata for my future self.

12 years ago I wrote Wordage

Go forth and coin.

13 years ago I wrote BarCamp London

A slumber party for geeks.

14 years ago I wrote Rocking out

If you’re in Brighton and you’re wondering what to do with yourself on a Tuesday night, why night come along to the Hanbury Ballroom to watch my band Salter Cane raise the very ornate roof.

14 years ago I wrote Web design and cultural identity

Andy "Malarky" Clarke penned an editorial a while back entitled Look out Johnny Foreigner in which he talked about web design and national identity.

15 years ago I wrote PDFs with PHP

Not all of the functionality I’ve been adding to this site recently involves JavaScript and the DOM. I’ve also added a new PHP script.

17 years ago I wrote Private And Public

I like this a lot.