Robustness and least power

There’s a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel’s Law, AKA the robustness principle:

Be conservative in what you send, be liberal in what you accept.

Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:

Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.

In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:

It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.

In other words, be liberal in what you accept from users.

I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:

Choose the least powerful language suitable for a given purpose.

On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?

Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

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.

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.

There are some associated principles, like YAGNI: You Ain’t Gonna Need It. That helps you avoid picking a technology that’s too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don’t yet have:

So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

After all, if they’re good enough for Tim Berners-Lee…

Have you published a response to this? :

Responses

CSS-Tricks

> 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.adactio.com/journal/14327

# Posted by CSS-Tricks on Monday, September 17th, 2018 at 1:13pm

Craig Buckler

Before jumping on the next hot JavaScript framework, remember… 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.adactio.com/journal/14327

Lucas Dasso

“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.”adactio.com/journal/14327

# Posted by Lucas Dasso on Thursday, September 20th, 2018 at 12:28pm

Ollie Boermans

On the least power principal discussed by @adactio here adactio.com/journal/14327 The tool of least power demands work from us – effort to make good from constraint. The easiest tools to use often trade this simplity for our ease. To avoid this trap focus on Why.

Jan Boddez

‘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.’ adactio.com/journal/14327

# Posted by Jan Boddez on Saturday, December 29th, 2018 at 1:19pm

Lucas Dasso

“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.”adactio.com/journal/14327

# Posted by Lucas Dasso on Wednesday, March 27th, 2019 at 12:51pm

Lucas Dasso

“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.”adactio.com/journal/14327

# Posted by Lucas Dasso on Saturday, March 30th, 2019 at 11:04am

leivajd.com

Jeremy Keith:

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

# Tuesday, June 23rd, 2020 at 12:00am

amberwilson.co.uk

In this post I’ll compare my experience building my personal blogging site (the one you’re on now) with two static site generators (SSGs) - Gatsby and Eleventy.

The first version of my site was rolled out with Bootstrap CSS and no framework, the second and third used SCSS and again no framework. The fourth version was built with a popular static site generator (SSG) called Gatsby. This SSG uses React and GraphQL. My learning curve from using no framework to using Gatsby was not huge though, as I use React and GraphQL at work.

The fifth, and at the time of publishing this post, current, version of this site uses a static site generator called Eleventy. I was a bit daunted about using this SSG, because the tools I was used to working with all day weren’t baked in. This meant no default React, or GraphQL. This SSG would be a new paradigm for me to learn from scratch. I’d have to pick a templating language I had never used before, and learn how Eleventy manages data. Even so, there were a number of reasons I wanted to move from Gatsby to Eleventy.

Firstly, I’ll summarise the reasons that I decided to use Gatsby in the first place. It lets people write React, takes care of a lot of performance concerns for you, and has a lot of good starter templates. So, it’s excellent for getting started quickly, getting a reasonably good site created, and offers a good developer experience. This was a big pull for me, in addition to all the hype it was creating a few years ago, and the fact I could already use its baked-in tools. Also, the fact I could have my very own, nice and shiny single page app (SPA) was a plus for me, at the time.

Gatsby sounds really good, so why did I move to Eleventy? This is a question I’ve put a lot of thought in to. First, I want to explain that I didn’t add any new features to the site between the Gatsby and Eleventy versions. The only thing that changed is that now, all the learn posts have their own page, instead of existing on one page.

Benefits gained
  • As my Eleventy site outputs a non-SPA, I didn’t need to check or ensure that it is server-rendered, is able to be crawled by search engines to allow good search engine optimisation (SEO), or works without JavaScript. Non-SPAs do all of this by default.
  • A number of Gatsby plugins stopped some of the functionality on my site working. For example, Gatsby’s progressive web app plugin caused my server-side rendering to stop working.
  • My site is a personal blog site that does not have thousands of users or masses of data. So, I don’t need to make sure I’m saving on bandwidth or server resources. If I did need that, I would consider creating a SPA, as they tend to request fewer server resources across page views, compared to non-SPAs.
  • I don’t need to force users to download large chunks of React library in their browsers. Gatsby by default forces this, and requires a plugin to ensure that React is only used on the server.
  • I didn’t need to bother code-splitting any React components to ensure users aren’t downloading my whole site on initial page load.
  • I was able to gain more control over performance optimisations such as image rendering. When I first released my Gatsby site, I used their image plugin but ended up disliking several things about it, such as styling inflexibility, and inability to use the <picture> element.
  • I know enough about web development that I can write performant code on my own. Therefore, I can do without plugins that enhance performance, but don’t make it clear how they do so. Also, I prefer using my own skills to create things wherever possible, as it teaches me how things really work.
  • I could pick and choose what JavaScript is necessary in the client (browser), thereby limiting the size of the JavaScript a user needs to download. The only JavaScript my site needs on the client-side is for the dark mode toggle, the blog search input, a tiny (and privacy-first) analytics tool, and some linked data (JSON-LD) for SEO.
  • By writing lower-level template code (Nunjucks vs JSX), I felt like I had more control over the generated code, which allowed me to output better and more consistent HTML.
  • Gatsby has GraphQL baked in. For a lot of use cases, especially a personal blog site, GraphQL is overpowered and can be a large learning curve for some.
Challenges faced
  • Eleventy is newer and maintained by less people than Gatsby. Therefore, I felt that Eleventy is a bit less feature-rich and has less documentation. Although honestly, this isn’t a huge deal. Firstly, I found Eleventy simpler to use (less abstract), and found the documentation covers all the most important aspects of the SSG. Secondly, almost any time I needed extra help or information, I found it in the form of excellent blog posts or example repositories created by other web developers.
  • One of the very few issues I couldn’t find help with was the sharing of one type of data (blog post excerpts) across my Eleventy-powered site. Gatsby, along with React, makes it easy to see what data is being shared and how. Eleventy has a fantastic data-sharing API (in my case the data sharing was orchestrated between Nunjucks and the Eleventy config file). However, I found it to be quite abstracted and struggled a lot trying to get my blog post excerpt data to be easily shared across pages. In the end, I created a workaround for this, but this workaround is quite hacky. I plan to write about it in a separate post.
  • I had to learn how to use the Nunjucks templating language. This is only a small nitpick, as the learning curve was in no way steep.
Concluding thoughts

Using Gatsby has taught me a lot about single page apps, and that’s important! Sometimes using it was frustrating, and a few things broke without me realising why or even when, but these experiences can be good lessons. Also, I am employed to work on a large SPA, and probably will continue to work on SPAs professionally for years to come, so any experience working with them is good!

I believe it is a good idea to use the least-powerful technology possible for any given task. Building with Eleventy made this possible for me. I find React and GraphQL nice to use, and I was daunted at the thought of not being able to use JSX. But, using simpler and lower-level tools such as Nunjucks made me feel more confident about my site’s output (robust HTML and the least JavaScript possible), and I enjoyed the experience much more than I thought I would.

Please don’t take what I’ve written here as a reason not to choose Gatsby over Eleventy. I chose to re-write my site in Eleventy for several reasons. I have the knowledge to build in performance and accessibility myself, I realised I didn’t need an SPA for my use case, and I wanted to use simpler, less powerful developer tools. I think developers should use the tools that suit them best. There is only one thing I want to encourage you to do: no matter what tools you use, please pay attention to your site or app’s final output! It’s never a good idea to make users pay for your technology choices.

# Friday, November 20th, 2020 at 12:00am

1 Bookmark

# Bookmarked by Jan Boddez on Sunday, May 24th, 2020 at 11:53am

Previously on this day

5 years ago I wrote Brighton in September

The digital festival is in full swing.

8 years ago I wrote The mind-blowing awesomeness of dConstruct 2012

Preceded by the mind-blowing awesomeness of Brighton SF.

10 years ago I wrote JavaScript jamboree

Whacky and wonderful JavaScript experiments.

14 years ago I wrote Backnetworking

This is my honour roll: it was an honour to meet these people.

14 years ago I wrote Fables of the dConstruction

A whirlwind weekend of geeky goodness in Brighton.

16 years ago I wrote Farewell to Florida

It’s time for me to head back to Blighty. My stay in Saint Augustine wound up being longer than originally intended but there are worse places to be stranded for a few extra days.

17 years ago I wrote It's alive!

I have my iBook back!