A presentation at JSConf US in August 2019 in Carlsbad, CA, USA by Jeremy Wagner
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.
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.
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?
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.
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.
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 a preferred framework.
[SHOW REACT + REACT-DOM]…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.
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 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.
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.
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.
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.
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…
…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?
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?
…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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
