Make it Boring
A presentation at JSConf US in in Carlsbad, CA, USA by Jeremy Wagner
make it boring jsconf us 2019 :: @malchata :: jeremy.codes
Hi, my name is Jeremy Wagner. I’m a web performance consultant, and a sort of general web tinkerer. I’d love to thank the organizers for such a great opportunity, and you, for your willingness to listen to this talk. I hope you like it.
This talk is the live version of an opinion piece I wrote earlier this year by the same name. So if you’ve read that post, you probably already know what you’re getting into. And be forewarned, there’s not much actual code in this talk. Like the post it’s based on, this talk is kind of a mélange of thoughts, philosophies, and opinions. In any case, I hope you like it.
the pursuit of excitement
Okay, so… …I originally wanted to open this talk with a boring story or anecdote, but that would be, well, boring. So instead, I’ll kick things off and talk about an exciting thing, and how that exciting thing ended up being so risky and destructive that it wiped out trillions of dollars of wealth.
Most of you probably remember the subprime mortgage crisis, which played out between 2007 and 2008. [PAUSE]
Before I continue, I’d like to assure you that this is a talk about web development, not finance. The subprime mortgage crisis was an entirely avoidable economic catastrophe that began with the creation of the mortgage-backed security.
The mortgage-backed security is a financial product backed by home mortgages. It was created long before the crisis ever occurred. A big chunk of home loans get bundled up into this product, which investment banks then offer to investors. It was generally considered a very safe investment. Most people don’t default on their loans. This limited the risk, so while returns were relatively modest, they were dependable. Seems pretty boring so far. Right?
Here’s where it gets exciting. [TRIGGER ANIMATION]
When Congress de-regulated investment banking in the 90s, investment banks got all excited. The lack of proper regulations allowed banks to offer high-risk subprime mortgage loans and sometimes even interest-only loans. Then on the investment side came credit default swaps, where investors could bet against the US housing market, effectively rooting for—and ultimately profiting from —the downfall of the US economy. And that’s exactly what happened. As the fed raised interest rates in an attempt to cool things down, adjustable rate subprime loans adjusted accordingly, which spurred defaults on a massive scale.
And then markets tanked, taking the economy with them. All because investing wasn’t risky or exciting enough already. [PAUSE]
This is a perfect example of when boring would have been preferable to exciting. If markets and banks had been properly regulated and yielded boringly predictable returns, things would be different today. People who were set to retire would have been able to, instead of having to rebuild their retirement portfolios. Some people would have been able to keep their homes. And just as an aside, this is why ethics and regulations are critical. Just because you can fleece someone for everything they’ve got, doesn’t mean you should.
Source: HTTP Archive
If it sounds like I’m drawing a parallel to the state of modern web development, it’s because I am. But! I acknowledge that we are not hurtling toward a comparable crisis with even remotely similar consequences. [REVEAL GRAPH]
But we are heading toward something, and the trend doesn’t look promising. Part of the reason why this trend persists—at least I believe—is because we’re not operating with sensible defaults. More and more, web development has become more like software engineering. In some respects, this is a logical progression, but I sometimes wonder if we’re ready for all the responsibility that entails.
npm install react npm install react-dom
6.5 KB 103.7 KB
npm install react-router
21.6 KB
npm install react-redux
14.4 KB
Because rather than evaluating each individual project’s requirements and adapting our choice of tools to them, we tend to dive right into what makes development exciting for us. So to that end, what do we do when we start a new project? We npm install a preferred framework.
[SHOW REACT + REACT-DOM]
Then, we might install a client-side router for that framework… [SHOW REACT-ROUTER]
…and maybe even a state management library—for the framework of course… [SHOW REACT-REDUX]
…and before you know it, a project has started with an amount of overhead that’s baked in until you decide to migrate away from it somehow.
Your preference for what makes development more exciting—or perhaps I should say more convenient or comfortable—has forced you to make tradeoffs that could make your app slower, less accessible, and less usable.
When it comes to software development, there’s a word that I think is important, and that word is constraints. [REVEAL IMAGE]
Think of your favorite video games from your childhood. Most Super Nintendo games could fit on a one megabyte cartridge—sometimes even in a quarter of that size. This point has been done to death, but it endures because it demonstrates how much can be done with so very little. Yet, I don’t think it fully acknowledges that the constraints game developers faced at the time were far more fixed than ours are now. When developers made console games, they knew every consumer had the same hardware. Those were the constraints, and they were predictable.
Our constraints, however, make our job uniquely difficult. People access the web on a variety of devices with wide-ranging capabilities—such as this affordable, but slow, Moto G4 Android phone—and this is to say nothing of the varying quality of the networks these devices access the web through. This is a reality which requires us to make architectural choices that are best for people. Because while our tools are convenient, they confer an external cost on users that we must acknowledge and redress in some capacity.
This is relevant, because for example here in the U.S., while many people live in large cities which are typically well-served by fast broadband and mobile internet connections, there are gaps, even chasms, in this coverage that we must be mindful of. This 2016 article by the MIT Technology Review revealed that 58 percent of households in the Cleveland metro area with yearly incomes under $20,000 had no broadband internet access. These are people who rely on mobile internet connections, often with data caps, to access the web. Internet access is not a luxury, it is a right.
More striking is this passage, in which Pew Research found that one third of Americans don’t have an internet connection in their homes faster than dial-up. I doubt this has improved significantly since the article was written. The economic and infrastructure challenges haven’t been sufficiently addressed to broaden broadband access. To me, this is a compelling reason to make things boring again.
i wanted to do it all
I can empathize with wanting to make web development exciting. It’s a big reason why I started doing this stuff in the first place… …and when I started, I want to do everything.
My first experience with making web pages was in a WYSIWYG editor in middle school. Once I hit that limits of what it could do, I had a thought, which was: “Hey… the hell happens when I open this here index.htm in notepad?” That thought clearly changed my life for the better. I think it’s fair to say I wouldn’t be standing here on this stage if I hadn’t done that. Everyone in our industry has an origin story. For many of us, that story begins with the making of the “fan page” for whatever thing we were obsessed with at the time.
For me, that obsession was fixed on the popular first-person shooter games of the day. The obsession itself was irrelevant, but it gave me an excuse to propel myself down a path of relentless—and sometimes reckless—experimentation. I wanted to do everything. I mean, everything. I wanted to put every last bit of new knowledge I acquired about making web pages to work right away, and in the most glaringly obnoxious way possible. [REVEAL IMAGE]
And in my fervor, I was inspired to make countless garish sites with horrid color schemes, crappy animated GIFs, guestbooks (that no one ever signed), web rings (that no one ever joined)… …and then there was Flash.
Oh, Flash. Three iterations of my personal website were crappy 2advanced knockoffs where cosmetics and flashy animations won out over literally any kind of sensibility. Like anyone, my inspiration was a conduit through which I developed my skillset, but what I didn’t develop for the longest time was discipline. I didn’t understand basic design principles, accessibility, performance, user experience, or anything that would help me to make websites anyone would want to use.
This is not to say that my excitement for the medium was ill-motivated. I was just inexperienced. But the work that we’re paid to do requires us to build boringly usable things. Sometimes that work is the equivalent of building digital pushbrooms: They’re ordinary as hell, yes, but they’re also tools that help people accomplish tasks. Online banking. Job applications. Buying essentials. You name it. When our excitement for building for the web is coupled with our thirst for pushing it to do more all the time, we can inadvertently build heavy, unusable things that hinder, rather than enable, people to complete the tasks our work enables them achieve.
the web: your new job
And so to that end, many new developers these days aren’t entering the industry with a decade of learning and experimentation under their belts, or even a four year degree. They’re people who are both new to, and really excited about, building stuff on the web and making a living from that work. And we these people among us. They’re going to be the next generation of developers that brings renewed fervor to this industry. This isn’t an experience I can speak to, as my path was different. I didn’t join a web developer boot camp and make a living off of my skills within a year. I had ten years of unfettered experimentation before I started making things anyone would consider usable. It takes time and continuing education to develop those sensibilities.
And because employers favor skillsets that prioritize the fastest ways of building applications, that means they’re going to hire people who know today’s frameworks… …and the fastest way to start getting paid after you graduate is to apply for jobs that match the framework-based skills you were taught in boot camp. [REVEAL IMAGE]
Thus, hiring in the industry has become an ouroboros where employers want applicants with framework-centered skillsets. Consequently, developers learn those frameworks to get gigs, because hiring managers want to tick off the boxes and get devs to ship code fast and often.
In this seemingly infinite loop, frameworks become the scaffolding upon which we build our careers. This isn’t the worst thing that can happen. Framework and library-specific knowledge can propel you to learn their underpinnings. I never would have went as deeply into JavaScript as I have if not for the awesomeness that was jQuery in the 2000s. But I believe that a sole reliance on these abstractions can eventually become a limiting factor in your long-term growth. Unless your curriculum sufficiently covered the fundamentals—or you learned them on your own—you’ll always be reliant on abstractions to do the work.
photo credit: quinn dombrowski
Front-end development has been this way for at least a decade. Read the resume of any veteran front-end developer, and you’ll quickly see that it resembles a geologic column of skills. This industry has always chased what’s “so hot right now”, and we’re set up from day one of our careers to feed into that. Arguably the worst part of this is that our continuing education in HTML, CSS, and platform APIs gets relegated to “some day”—or worse, after hours, where you have to sacrifice some amount of work/life balance just to keep up. And not every person has the time to devote in their off-hours to do that work. In my opinion, we shouldn’t compel them to, but rather enable them to explore and learn on the job.
All of this is ostensibly done in the name of productivity, sometimes at our own peril. This constant churn, as Rachel Andrew suggests in this brilliant post, has us bound to a cycle of never-ending site rebuilds and framework migrations that can seem counter-productive in hindsight.
Without careful consideration for which abstractions are truly beneficial for the purpose you’re trying to serve, being lashed to this wheel becomes a brutal affair where progress becomes difficult to sustain over the long term. Whether it was jQuery then or React now, these tools are designed to make us more productive—and they do! But…
photo credit: doug belshaw
…if we were pressed to admit it, this constant churn is—at least in part—due to our desire to make our work more fun and exciting. It’s something I call Laptop Sticker Culture—something I’m cleary guilty of—where everything we do outwardly appears badass or glamorous. And if I didn’t know any better, I’d swear some of us are on tour.
It’s also why, even in The Year our Lord 2019, you still see job postings every so often with goofy superlatives like “rockstar”, “guru”, or “ninja”. But hey, why shouldn’t our work be more exciting? Right?
the boring essence of things [PAUSE]
We’re all propelled by our interests. For you, that interest may be JavaScript ‘n Friends. Could be HTML. Could be CSS. Or it could be the various abstractions of those technologies. But if you could for second, put aside your interests and ask yourself what purpose you’re trying to serve. When you build something for the web, what are you helping people to accomplish?
The varying answers we give to that question should form a curve around which we adjust our philosophy for how we build for the web… [REVEAL IMAGE]
…because if you’re in charge of any remotely critical resource on the web, your desire for a rich developer experience simply must take a back seat. People depend on the web for more than just buying shit. The web is a portal for many critical resources. Stuff like job applications, public assistance, crisis intervention, and other services we tend not to think about until we need them.
Ours is a job done by people for people. Plumbers might get excited about PEX piping, but they also understand that their job is to ensure the water gets from the main to the faucet the same as always. PEX pipe confers a material improvement for both installers and end users, without hampering functionality. Can we consistently say the same thing about the conveniences we rely on?
photo credit: ruud koot
Data flows through pipes of sorts, but the environmental constraints imposed on us by the network and the devices people use demand our most careful consideration. Factors like network bandwidth and latency are evident, but others such as server protocol and device capabilities are subtle. Then there’s the person holding a phone or a tablet, or behind a laptop: each of which is an individual case study of capabilities and limitations that demand our attention.
Knowing this, it’s important we avoid one assumption like the plague: that our conveniences always confer equal benefits for users. Your enthusiasm for virtual DOM frameworks probably doesn’t benefit someone who’s been thrown out of their home by an abusive partner when they turn to the web to find shelter. Someone trying to find public assistance information or apply for a job on spotty wi-fi isn’t helped by your client side router. Our conveniences have a time and a place, and that time is not always “every time”, nor is that place always “everywhere”. I am not shaming anyone for their choice of tools, but to stress that simply using them won’t do the difficult work of design and user experience for you.
photo credit: jim sheely
And as developers, our ethical duty isn’t limited to identifying and removing excesses in code. We also need to challenge excesses which may look nice in design comps, but only serve to frustrate people in practice. Excesses in design and development are intertwined. Every interaction you simplify, every boondoggle you can remove, represents a benefit to the end user. So let’s make it boring.
boring is unobtrusive
The web is frustrating when it creates obstacles for people. Obtrusiveness in websites are the result of every project manager, designer, and developer unwilling or unable to question ill-conceived business requirements, design decisions, or architectural choices.
Josh Clark wrote an article about design systems a while back, and what struck me was his emphasis on the role of “boring” in UX. He discussed how when he helped his clients to create design systems, he stressed the importance of simplicity: “The more common the problem, the better. Design systems should prioritize the mundane.” In a world where it feels like everyone wants to disrupt everything without considering the consequences, this is sage advice. Avoiding obtrusiveness in design is the very soul of designs that work best for people. Without acknowledging that, we can only create fast, accessible, and usable websites entirely by accident.
source: mappa mundi
A perfect example of obtrusive design was a little-known visualization project developed by Apple’s research division called HotSauce, which was an attempt at visualizing sitemaps for websites. Instead of presenting this data in a straightforward way, it was presented as a 3D spatial field. To its credit, HotSauce was a novel presentation of this data. It was a fun experiment, but people considered it disorienting. No one wanted to browse a spatial rendering of a website’s hierarchy as if they were on the holodeck. They wanted a boringly predictable way to access that information.
photo credit: megan dyton
Examples of obtrusive design as they exist on the web are quite different. I don’t know about you, but I don’t even like one hamburger menu, let alone three of them. It’s not excitement that produces patterns like this, but a sort of unwillingness or inability to address the unsustainable growth of an application over time.
Eminently usable designs and architectures result when simplicity is the default. It’s one of the iron laws. It’s why unstyled HTML works. It so beautifully solves the problem of presenting documents to the user that we don’t consider all the careful thought that went into its jaw-achingly boring presentation. Now, I’m not holding a torch aloft and demand we transport ourselves back to 1994. That would be absurd, and antithetical to the spirit of progress. But I do think this ideal is something we can carry into our daily work. Especially when more websites are consumed as web apps. We can make apps more resilient by adhering to semantics, platform solutions, and progressive enhancement.
As it stands, we’re accustomed to serving heaps of <div> burgers on silver platters of JavaScript that not everyone can access in all the places they may need to. Accessibility advocates aren’t lecturing you to use semantic HTML because it’s fun, but because it’s well understood how people benefit from it. The built-in functionality you get from those semantics allows you to travel lighter, as you won’t need build or install accessible alternatives. Does this mean your choice of tools are in direct opposition to the goal of creating good user experiences? Depends on how you use them. It at least requires us to understand the tradeoffs we might be making if we use them.
photo credit: i_yudai
So we need to bifurcate our focus on what we learn. We should learn frameworks and abstractions, yes, but we also need to learn the platform APIs that serve as their foundation so we can adapt as the wind shifts. The long-term health of the web can not be sustained if we ignore what the web platform brings to the table solely for our own convenience.
boring is expected
Underscoring the importance of those fundamentals is the fact that we’re wired to want things to be boringly predictable. We not only want it. We expect and subconsciously demand it.
When things are predictable, they embody the expected qualities of the essential. We don’t want any surprises with the plane’s landing gear as we come in for a landing. This is an example of a critical fixture, and some of what we preside over as developers are also critical fixtures of a sort. Those fixtures especially need to remain fast and accessible. Part of getting there necessarily involves using HTML, CSS, and platform APIs to reduce overhead.
If your reaction to what I’m saying is to assert that this is boring work that users will find boring, then I must retort with the emergence of “reader mode” features that exist in several browsers. At its core, “reader mode” is just a “boring mode” toggle that strips away scripts and styles to distill a page down to its core content. People are so tired of grappling with stuttering, JavaScript-laden pages that they’ll glad strip away everything “exciting” to get to that crucial nugget of content more easily. Still, reader mode won’t work everywhere. Nor should we expect it to. Its intended application is for written content like articles, not rich applications. Solving human problems does require a human touch, after all.
To that end, we are wired as human beings to want external consistency, which is when an object’s function and recognizable appearance is reinforced by other similar implementations. Imagine a house with no external consistency, where turning the knob on the stove changes the television channel. As Eric Bailey notes in an article on A List Apart, browsers themselves are flush with examples of external consistency, and we would do well to ensure we don’t break those externally consistent behaviors.
Now, I am fully aware of the danger of saying this on stage at a JavaScript conference, but one of the most common subversions of external consistency in browsers is the single page application—or SPA. My personal inclination is to avoid building sites as SPAs. This isn’t because I hate them, but… It’s just that the behavior they replace is one that browsers already do very well. When we decide to take on the task of implementing that ourselves, we’re taking on a lot of unnecessary responsibility in most cases. How browsers navigate from page to page is part of a specification, arrived to after a deliberative process of debate and consensus. In my opinion, it takes a whole lot of courage with a dash of hubris to assume we can do this better than browsers have done in 25 years.
1ms 2.07s 5.24s client-side rendering
And, when a client-side router is used, accessibility can become a casualty in that effort. There’s a whole host of things we end up reinventing or miss altogether. - History must be managed… - …tabindex and scrolling position must be accounted for… - Navigation cancelling can fail… - …and so on. Even if we get client-side routing perfect, there’s another problem we have to grapple with. [SHOW SLIDE CONTENT]
Which is, when we neglect to send server-generated markup in favor of rendering everything on the client, an app’s contents are not only inaccessible if—and when— JavaScript fails, but loading performance suffers as well.
1ms 2.07s 5.24s server-side rendering (with client-side hydration)
When we serve content from the server, sure, we lose some of the snappiness after the initial load, but we retain the external consistency people expect. That’s not to say we can never use client-side routers. If you provide server-side versions of all your client-side routes, people will have a way to access any part of your site from any context. [SHOW CLIENT-SIDE HYDRATION NOTE]
And then, if components are attached to server side markup through client-side hydration, people get a progressively enhanced experience. That gives us freedom to try different things. Perhaps only the authenticated part of an app is an SPA. Or, perhaps client-side routing could be opted into as an app setting, ensuring it only happens if people want it to.
the web is in our care
Which brings me to my final point, and the end of my talk. [PAUSE]
No tool or any amount automation will ever be a perfect substitute for a human’s judgement, which is finely-honed over years of experience solving human problems… …and solving human problems requires that you accept that humans have limitations, either inherent or imposed. It also requires you to accept that the tools you use can fail you, and your judgement is necessary in those situations.
Now let me tell you another story. This is Stanislav Petrov. He was a Lieutenant-Colonel in the Soviet Air Forces during a dangerously tense period of the Cold War. While he was on duty in 1983, a brand new Soviet missile detection system reported that five nuclear missiles were launched by the United States, and on the way to Russia. Through reason and no small amount of intuition, he was convinced that the system was wrong. In the moment, he concluded that five missiles was illogical, because a U.S. strike would have been all-out. So, he did not inform his superiors, and therefore, a retaliatory strike was never authorized. He turned out to be right. The system was wrong. Turned out to be sunlight reflecting on some clouds above North Dakota, and that triggered the false positive. While we’ll never know all of the factors at play at the various levels of command in that situation, it’s not unreasonable to speculate that his decision to disbelieve the tools at his disposal may have averted a global nuclear war. [FADE OUT IMAGE]
Obviously, no JavaScript engineer in this room will ever be charged with such a perilous decision. I hope not! But I think it’s a great lesson about how the tools we depend on can still get things wrong sometimes. If that wasn’t the case, every Github Issues page would be a ghost town. So it’s on us to realize and own up to our responsibility to people, as well as how our preferences as developers and the needs of real people can intersect in a way that’s mutually beneficial.
Knowing where that intersection lies involves realizing that while an accessibility inspector can tell you what semantic elements you should use, knowing why those elements are preferable to a <div> soup is just as vital.
It’s also realizing that while you could install a layout framework, such problems are best solved by relatively new and widely-supported CSS layout modes such as flexbox and grid.
In fact, if you want to create layouts that catch the eye and push the boundaries beyond the ordinary, you need to rely on these new layout modes. You can’t keep kicking that Bootstrap can down the road, people. Because not only is the overhead of Bootstrap onerous, it’s just not where the web is destined to go, nor will it allow you access to the full power of these new layout modes.
source: a list apart
For all of my whinging about the evils of JavaScript and all the sinful excitement it and its framework brethren bring, I firmly believe it has its place… JavaScript is great. It’s given a lot of us a living. …but we do need to rebalance our use of it against other parts of the web platform. [REVEAL IMAGE]
JavaScript is most resilient when we use it with progressive enhancement in mind. That’s to say, when we build a baseline everyone benefits from, and then add that candy coating to enhance usability further for those who can benefit from it, we’re not just building better user experiences, but more inclusive ones. And that to me is the really good work that’s worth doing. Because inclusivity is not just something we should make room for at conferences. It needs to be part of our daily work.
If you care about the web—as I know you all do, because if you’re here, you definitely care—you’ll come to find out that this approach to our work isn’t boring at all, but really quite rewarding. We have two objectives as developers: - One: work to make things better this week than they were last week… - … and two: continue our education to ensure the success of the first objective. I genuinely, truly believe our work can never be boring, so long as it helps us deliver on these objectives in the spirit of making the web faster, more accessible, and therefore more usable for everyone, everywhere.
thank you
Thank you.
A good case can be made for why boring is preferable to exciting in many aspects of our lives. Yet, we’re reluctant to apply this sentiment to the web. Rather, we’re in a relentless pursuit of the exciting in this increasingly JavaScript-centric world of web development. A pursuit that, despite our best efforts, litters the landscape of the web with excruciatingly slow and inaccessible pages. As division brews over the roles of HTML, CSS, and indeed JavaScript itself, we need to ask if it’s worth making the web boring again.
But why make the web more boring? Because boring is fast, resilient, fault tolerant, and accessible. Boring is the essence of unobtrusive designs that facilitate interactions rather than hinder them. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things—things that can hinder or even fail people in unexpected ways despite our best intentions. In this session, you’ll learn why building for the web with a greater emphasis on core technologies is far from boring, but truly rewarding and exciting work that makes the web more inclusive.
for free. You
can too.
Video
Resources
The following resources were mentioned during the presentation or are useful additional information.
-
Make it Boring
In which I make the case that the web we build should be more boring to better benefit those who use what we make.
-
JavaScript Bytes - HTTP Archive
The sum of transfer size kilobytes of all external scripts requested by the page. An external script is identified as a resource with the
jsorjsonfile extensions or a MIME type containingscriptorjson. -
The Unacceptable Persistence of the Digital Divide
Millions of Americans lack broadband access and computer skills. Can President Trump bring them into the digital economy?
-
HTML, CSS and our vanishing industry entry points
Some thoughts on entry points to web development today, and my fears about the loss of something that has enabled so many people without a traditional computer science background to be here.
-
The “Developer Experience” Bait-and-Switch
TL;DR: we cannot continue to use as much JavaScript as is now “normal” and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS…until it’s too late. “JS neutral” (or negative) tools are here, but we’re stuck in a rhetorical rut. We need to reset our conversation about “developer experience” to factor in the asymmetric cost of JS.
-
The Most Exciting Design Systems Are Boring
Design systems should solve problems that designers confront over and over again, so that they can turn to more interesting challenges.
-
HotSauce Interface - Mappi Mundi Magazine
A screenshot of the Apple HotSauce interface.
-
Paint the Picture, Not the Frame: How Browsers Provide Everything Users Need
Designers want to create fully branded experiences, which often results in customized highlighting colors or pixel-perfect typography. While these design touches can enhance the experience for some, they can render the experience inaccessible for others. Designer Eric Bailey makes a case for leaving key accessibility features to the browser to ensure the most accessible experience possible.
-
Understanding Progressive Enhancement
Since 1994, the web development community has beaten graceful degradation’s drum. A carry-over from the engineering world, the concept was, at its core, about giving the latest and greatest browsers the full-course meal experience while tossing a few scraps to the sad folk unfortunate enough to be using Netscape 4. It worked, sure, but it didn’t really match Tim Berners-Lee’s original vision for a universally accessible web.
Buzz and feedback
Here’s what was said about this presentation on social media.
