Jeremy Wagner

Canned Web Development

14 September, 2020

A new Lighthouse feature was recently rolled out which calls out opportunities to use smaller alternatives to popular JavaScript libraries. I was initially excited for this feature because I've long evangelized for reducing how much JavaScript we use. We have a serious problem on our hands in modern web development, and that problem is our collective overreliance on JavaScript.

There was a predictable backlash on Twitter after this feature was rolled out, but it didn't play out the way I expected. The issue of how this feature could impact open source software maintainers was raised in a way that led me to consider how this feature could end up being a bad idea over the long haul. It's not often I disagree with any guidance to reduce JavaScript usage. I even don't disagree with the spirit of what Google tried to accomplish here, just the way in which they did it. Lighthouse shouldn't be the venue for this kind of guidance, and no company should bring its influence to bear on the community in such a way that could be harmful, no matter how inadvertently so.

As my attention drifted to other things over the next couple of days, the idle part of my mind whittled away to the core of what bothered me so much about the current state of the web and open source software. It eventually occurred to me that this industry is failing in its work in two critical ways:

  1. We are exploiting the labor of open source software maintainers and expecting community members to remedy that exploitation via donation capitalism.
  2. Our mental model for how we build for the web is too reliant on canned solutions to unique problems.

The first of these failures is both abjectly depressing and utterly predictable in a hypercapitalist society. Large corporations are benefitting from the labor of open source software maintainers with no meaningful regulation compelling them to be compensated. When something is free, a different sort of price is paid. When an open source offering becomes popular, the maintainers are inevitably buried in feature requests and issues they have to address—typically during their unpaid free time. When an open source offering becomes simultaneously popular and an indispensable part of toolchains, a small group of people are asked to do important work for free. Crowdfunding or other flavors of donation capitalism are not the solution, but rather a blood-soaked bandage that relies on the goodwill of a community that appears to be increasingly entitled to free labor.

The second of these failures is almost equally depressing. As the web has matured, we've adopted a mindset that prioritizes velocity over thoughtfulness. The default behavior of the web is something I like to call "the document web", where each navigation is synchronously driven by the server. Everything we've been trying to do since Web 2.0 has been one long effort in escaping this inextricable part of how the web behaves. The result is a parade of escape hatches from the web's default behavior. We're told that these escape hatches—pushed and marketed as critical software by hugely influential tech companies—are necessary in order to deliver good user experiences.

As much as we'd like to think our respective situations require mountains of JavaScript to provide a "rich" user experience, that's almost certainly not the case. So much of what we use the web for is a perfect fit for the document web model, and needs only a modest amount of JavaScript to do the job. E-commerce websites are a perfect example of how egregious our abuse of JavaScript today is. Those sites didn't need megabytes of JavaScripts in the late 90s and early 2000s to be financially successful, and they don't need that much JavaScript to be financially successful today. Any success these companies enjoy isn't because of how we build for the web today, but in spite of it. We seem to aggressively A/B test every feature except for the ones that have universal importance to actual people: speed and accessibility.

Our industry's collective mindset is a prominent obstacle to creating fast and accessible websites. Compounding this problem is that too few boot camps are preparing new web developers to think critically about what problems are best solved by JavaScript and which aren't—and that those problems that are best solved by JavaScript can be solved without engaging in frivolous framework whataboutism. The question developers should ask more often when grappling with framework shortcomings shouldn't be "what about that other framework?", but rather "what's best for the user experience?". That's a hard question to answer, since your situation will compel you to answer it in your own way, but the outcomes are more rewarding for people. To get there, you have to critically weigh the tradeoffs you're making when you choose a framework, and make peace with idea of building a bespoke solution when the tradeoffs you've made are too damaging to the user experience.

I don't want to fritter away my remaining years in this industry by engaging in an endless string of framework migrations, deciding that the sole dependence on some golden dependency is a "best practice" only to find out later on that an almost religious adherence to that "best practice" has failed in some intractable way. Nor do I want to abide by so much wasted effort brought on by those migrations which have the unfortunate side-effect of leaving open source software maintainers open to exploitation by well-to-do corporations and abuse by ill-tempered and demanding community members.

Lighthouse is a valuable tool, one I'm sincerely grateful for. But wielding it in such a way that tells people which libraries and frameworks to use doesn't get us away from the problem of canned web development and the exploitation of free labor in open source software; it only further entrenches us in it.

Feel like reading more? Head on back to the article list!