larlet-fr-david-cache/cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/index.md

title: Make it boring - jlwagner.net
url: https://jlwagner.net/blog/make-it-boring/
hash_url: 9ad9f5ea367dbd74e4aeeb8471747247

<p>
A good case can be made for why <em>boring</em> can be preferable to <em>exciting</em>. Read about <a href="https://en.wikipedia.org/wiki/Subprime_mortgage_crisis" rel="noopener">the subprime mortgage</a> crisis sometime, and you'll see that things got hairy because someone, somewhere, thought that investing in mortgage-backed securities should be less boring and more <em>exciting</em>. If those financial instruments as well as the subprime lending market that exploded beneath them had been reasonably regulated and yielded boringly predictable returns, the world might be a better place today.
</p>
<p>
I feel similarly about the state of web development, and I worry when I think about where it's all headed. We're hurtling toward <a href="https://httparchive.org/reports/state-of-javascript#bytesJs" rel="noopener">a bubble of our own</a>. A bubble which exists partly because we're not operating with sensible defaults. Web developers are accustomed to starting projects with the massive overhead of JavaScript frameworks like React — not to mention all that gets installed with it — as well as ancillary packages, module bundlers, and all this... <em>stuff</em>. Stuff that clutters the already densely occupied space of our minds, which inevitably seems to burden the people who use what we make.
</p>
<h3 id="i-was-young-and-wanted-to-do-it-all">I was young and wanted to do it all</h3>
<p>
Remember the first time you made a web page? I do. From the instant I opened a WYSIWYG editor-generated HTML file with notepad.exe in 1995 and saw how much was possible with so little, I was all in on the web. I made websites so frivolously excessive by shoehorning in every new little thing I learned. Garish color schemes, <code>&lt;font&gt;</code> tags, animated GIF backgrounds, guestbooks, oh and who could forget Flash? Three of my personal websites were crappy 2Advanced knockoff Flash sites. I was eager to show off everything I knew, so I churned out Frankenstein monsters that stitched together every new thing I learned.
</p>
<p>
It was only by the time I started my professional career in 2005 that I started to rein in my excesses. I have to remember that it took me <em>ten years</em> of undisciplined experimentation before I began to consider what it meant to build things people would <em>want</em> to use. I need to continually remind myself of this as I consider the new devs out there joining the ranks of the employed.
</p>
<h3 id="the-web-your-exciting-new-job">The web: your exciting new job</h3>
<p>
Most new developers aren't entering the workforce today with a decade of learning and experimentation already under their belts. They're people who are simultaneously new to — and really excited about — building for the web <em>and</em> making a living from it.
</p>
<p>
This isn't a perspective I can speak to. My path was radically different. I didn't join a web developer bootcamp and start making a living off of those skills within a year. I had the benefit of time from middle school to the end of college to experiment and do all the wrong things. I made slow, unusable, inaccessible websites. As my knowledge and skills increased, I made slightly faster, more usable, and more accessible websites.
</p>
<p>
Most new developers haven't had this luxury. Particularly in the U.S., where their flaming baptism into the industry occurs in an increasingly hostile economic environment. New developers will learn the skills that are deemed the most valuable. When you're fresh off an expensive training program and you need to make money <em>now</em>, you're going to chase what makes that money — and a tech company will only pick you up if their HR department can check the boxes. That means you're going to be learning the framework du jour, and for a time, probably little else as you inevitably take time to get up to speed.
</p>
<p>
Front-end development has been this way to an extent for at least the past decade. Read the resume of any veteran front-end web developer, and you'll find it resembles a geological column of skills. It might start with MooTools, YUI, and Dojo underneath jQuery, which itself is underneath Backbone and Knockout, which brings us roughly to where we are today with React and friends. The industry has always chased what's <em>so hot right now</em>. The industry has set us up from day one to chase the new and shiny to pay the bills, while our duty to educate ourselves on core web technologies has been relegated to "some day".
</p>
<p>
We do all of this in the name of productivity — <a href="https://rachelandrew.co.uk/archives/2019/01/30/html-css-and-our-vanishing-industry-entry-points/" rel="noopener">even at our own peril</a>. Whether it was jQuery in the late aughts or React now, these tools were designed to make us more productive — and they do! But, if developers were pressed to admit it, they're also a product of our desire to make our work less <em>boring</em> and more <em>exciting</em>. It fuels what I like to call <em>laptop sticker culture</em> — something I'm certainly guilty of — where everything we do feels badass and glamorous. Shouldn't our work be more fun and <em>exciting?</em>
</p>
<h3 id="the-jaw-achingly-boring-essence-of-things">The jaw-achingly boring essence of things</h3>
<p>
People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be <em>JavaScript 'n Friends</em>, or HTML and CSS. Maybe it's all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to <em>do?</em> If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and <em>fast</em>. Ours is a job done by people for people, not a glamorous rockstar gig. Plumbers might get excited about <a href="https://en.wikipedia.org/wiki/Cross-linked_polyethylene" rel="noopener">PEX piping</a>, but they also understand that their job is to ensure the water gets from the main to the faucet as expeditiously as before.
</p>
<p>
Water and data flow through pipes of their own, but whether data flows easily from server to client depends. The environmental constraints imposed on developers by the network, devices, and the browsers people use are legion. Factors such as network bandwidth and latency are obvious, whereas others such as server protocol, device capabilities, and a multitude of others are subtle. Then there is your biggest factor: the people using the thing you make, each one of them a unique case study of capabilities and limitations that we must account for as best we can.
</p>
<p>
If you use a JavaScript framework and a toolchain to manage your code and its output — and my intent isn't to shame you if you do — simply <em>using</em> those tools won't do the difficult work of design for you. Even as developers, our job is not solely to identify and remove excesses in code. We also need to question and seek to trim excesses in design which may look good in a design comp, but only serve to frustrate and impede people in practice. These excesses in development and design aren't simply related, they <em>depend</em> on one another to exist. The more complex a design is, the more it will cost to develop it.
<em>
Every interaction you simplify, every boondoggle you can remove,
represents a benefit to the person who uses what you make.
</em>
</p>
<p>
So make it <em>boring.</em>
</p>
<h3 id="boring-is-unobtrusive">Boring is unobtrusive</h3>
<p>
A website is at its worst when it creates obstacles for people. Obtrusive design is the result of every project manager, business analyst, designer, and developer unwilling or unable to question ill-considered business requirements or design decisions. <a href="https://bigmedium.com/ideas/boring-design-systems.html" rel="noopener">In a piece striking a similar tone</a> on making design systems boring, Josh Clark had the following to say:
</p>
<blockquote cite="https://bigmedium.com/ideas/boring-design-systems.html">
"The more common the problem, the better. Design systems should prioritize the mundane."
</blockquote>
<p>
Prioritizing the mundane <em>necessarily involves avoiding obtrusiveness.</em> Without acknowledging that simple truth, we can only create fast, accessible, and usable experiences entirely by accident.
</p>
<p>
To wit: a perfect example of obtrusive design was <a href="https://en.wikipedia.org/wiki/HotSauce" rel="noopener">Apple's HotSauce</a>, which provided a 3D visualization of sitemaps. Instead of aiming for a mundane, utilitarian way to present this information, the visualization chosen instead was seen as cumbersome and pointless. When folks browse a list of URLs from a website, they don't care what that experience would be like if they were on the deck of the <em>Enterprise</em>. They crave a <em>boringly predictable</em> way to access that information <em>quickly</em>.
</p>
<p>
Eminently usable designs and architectures result when simplicity is the default. It's why unadorned HTML works. It beautifully solves the problem of presenting documents to the screen that we don't even consider all the careful thought that went into the user agent stylesheets that provide its utterly boring presentation. We can take a lesson from this, especially during a time when more web <em>sites</em> are consumed as web <em>apps</em>, and make them more resilient by adhering to semantics and native web technologies. As it stands, we're serving heaps of <code>&lt;div&gt;</code> burgers on silver platters of JavaScript with a generous helping of layout framework sauce not everyone can choke down.
</p>
<p>
To that end, accessibility advocates aren't yelling at you to use <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#HTML" rel="noopener">semantic HTML</a> because it's exciting, but because it's well understood how users benefit from it. This doesn't mean your choice of tools makes building great websites impossible, but it <em>does</em> require you to understand how their overhead is a liability right from the very start. That is, <em>unless</em> you're cognizant of the pitfalls and know how to avoid them. That kind of knowledge takes years of trial, error, and continuing education to get right — knowledge you can't gain by starting your career using JavaScript frameworks and toolchains exclusively while ignoring what HTML and CSS brings to the table.
</p>
<h3 id="boring-is-expected">Boring is expected</h3>
<p>
Boring and predictable are <em>expected qualities of the essential</em>. Traffic lights functioning as expected? Awesome. The plane's landing gear doesn't fall off on approach? Even better. While we as developers and designers aren't in charge of those critically essential things, we <em>are</em> responsible for the services people expect to be available. Some of these services, such as resources for federal aid and assistance, are <em>critical</em> fixtures in an economically hostile landscape. We must go the extra mile to make sure that they're highly available, accessible, and fast.
</p>
<p>
Central to that endeavor is recognizing that the browser gives you a <em>ton</em> of stuff for free. Relying on those freebies requires a willingness to not <code>npm install</code> a solution for every problem — <em>especially</em> those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is <em>accessible</em>. When we rely wholesale on JavaScript to build for the web, we're inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation" rel="noopener">client-side form validation</a>  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.
</p>
<p>
If your initial reaction to reading this is to assert that people hate boring websites, you must reconcile that assertion with the emergence of " <a href="https://css-tricks.com/reader-mode-the-button-to-beat/" rel="noopener">reader mode</a> " features in most desktop, phone, and tablet browsers. These features are, in essence, "boring mode" toggles that reduce a page's functionality to its core. People are so tired of coping with stuttering, JavaScript-laden pages that they'll gladly strip away everything "interesting" to make those pages <em>usable</em>. Still, reading mode doesn't work on all pages, particularly those dependent on JavaScript for even the base level of functionality. Nor should we expect it to. Reader mode was never designed to address those use cases. Solving human problems requires a human touch, after all.
</p>
<h3 id="the-web-is-in-your-care">The web is in your care</h3>
<p>
No tool or amount or automation is a substitute for expertise built years of experience in solving human problems. It's <em>realizing</em> that while an accessibility inspector can <em>tell</em> you that you should use <code>&lt;label&gt;</code> elements for form fields, you need to know the human reasons for <em>why</em> such a pattern is preferable over meaningless <code>&lt;span&gt;</code>s. It's <em>understanding</em> that while icons might look good in your design comp, relying on language to communicate those actions is more sensible. It's <em>knowing</em> that while a layout problem can be solved by <code>npm install</code>ing a module, such problems are best solved by CSS.
</p>
<p>
For all of my whinging about the evils of JavaScript and the sinful <em>excitement</em> it brings, I still believe it has value. We <em>do</em> need to rebalance our use of it against CSS and HTML, however, because the status quo of how we build for the web can't continue without consequences. JavaScript works best when we use it with progressive enhancement in mind. When we can build a baseline <em>everyone</em> benefits from, and <em>then</em> <a href="https://alistapart.com/article/understandingprogressiveenhancement#section4" rel="noopener">add that candy coating</a> to enhance usability further for that subset of people who can benefit from it, we're not just building better experiences, but more <em>inclusive</em> ones. That's the good work we should all strive to do.
</p>
<p>
If you care about the web — as I <em>know</em> you do — you'll come to find out that this work isn't boring at all, but really rather delightful and rewarding. What’s more, your choice of framework isn’t mutually incompatible with making stuff for the web that people love to use. It <em>does</em> make that goal harder to achieve, but continuing education and forethought will go a long way in helping you to get the balance right.
</p>
<p>
As developers, we have two objectives: Work to make things better this week than they were last week, and continue our education to ensure the success of the first objective. With a stronger embrace of HTML and CSS, I genuinely believe our work can never be boring, so long as it helps us deliver on these objectives in the spirit of making the web better for all people.
</p>
<p>
<em>Special thanks to <a href="https://www.zeldman.com/" rel="noopener">Jeffrey Zeldman</a>, whose industry expertise, advice, and insight helped me to shape these thoughts into a more coherent narrative.</em>
</p>