The "Developer Experience" Bait-and-Switch  ## Metadata - Author: [[Alex Russell]] - Full Title: The "Developer Experience" Bait-and-Switch - Category: #articles - Document Note: --- tags: - #webperformance - #javascript - #developerexperience Author: Alex Russell Source: Article (Infrequently Noted) Reference: https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} --- # Title: The “Developer Experience” Bait-and-Switch ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Alex Russell, The “Developer Experience” Bait-and-Switch, 2018-09-11. https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ - WebPageTest reference in-article (example trace shared via Twitter thread). - Related communities/tools mentioned: Polymer, Preact, Svelte, Ionic, Vue; USDS, GDS. ## 📝 Summary: - Core claim: “We cannot continue to use as much JavaScript as is now normal and expect the web to flourish.” Overuse of JS imposes asymmetric costs on users—especially those on low-end devices and networks—while benefits accrue to developers and organizations. - The “developer experience” (DX) narrative often substitutes developer convenience for user value, absent evidence. Russell urges an evidence-based discussion that budgets JS and prioritizes Time-to-Interactive (TTI) and accessibility for all users. - He calls for JS budgeting/cap-and-trade, transparent performance baselines, and tooling that is “JS-neutral” or “TTI-neutral,” with clear budgets and device/network applicability. - He plans to publicly analyze public-sector sites (US/UK) to show concrete impacts and push for accountability and better practices. Key lines: - “JavaScript is the web’s CO2.” (0%) - “We must budget. We must cap-and-trade JS.” (33%) - “Tools that cost the poorest users to pay wealthy developers are bunk.” (89%) ## 📖 Main Content: - Problem framing: - JS overuse has grown from ~50KB (2011) to 350KB median compressed on mobile (~2MB uncompressed) (33%). This bloats parse/compile/execute cost—particularly harmful on low-end Android and in constrained networks. - DX rhetoric often equates faster dev iteration with better UX, but lacks measurement linking dev choices to user outcomes (0–22%). - Asymmetry and externalities: - Those deploying heavy JS rarely feel the pain; users on low-cost devices do (0–22%). - Teams lack actionable user-centric metrics; launches rarely blocked for latency regressions, even at large orgs (22%). - Evidence gap: - Performance claims made without WPT traces or global baselines; “speed” gets marketed without context (44%). - Public sector analyses will serve as a proxy for private-sector issues; intent is constructive, not shaming (55–66%). - Proposed remedies: - JS budgeting and cap-and-trade mindset (33%). - Tooling judged by TTI-neutral/negative impact; frameworks must publish budgets, remaining headroom, and targeted device/network profiles (77%). - Move to evidence-based debate; if your target market is wealthy enterprise users only, say so and prove the assumptions (89%). ### 🗒️ Notes - Thesis and analogy - “JavaScript is the web’s CO2” underscores systemic externalities (0%). - Overuse threatens web viability on emerging markets and low-end devices. - DX bait-and-switch mechanics (11%): - Appeals to dev speed and simplicity replace user value conversations. - Frames three values—Universality, Fidelity, Cost to produce—then overweights DX to erase the others. - Organizational dynamics (22%): - Teams seldom track real-user latency metrics (e.g., TTI, FID/INP) or block launches for regressions. - Performance constraints surface only when business pain appears. - Data trends and costs (33%): - Median JS payload ballooned; JS is “the most expensive way” to do things in a browser due to CPU and main-thread contention. - Calls for JS budgets/cap-and-trade to curb emissions. - Tooling landscape (33–44%): - Polymer/Preact/Svelte/Ionic/Vue offer starter kits/CLIs that can send less JS, but disasters persist. - Marketing claims of “speed” lack traces and baselines (44%). - Evidence-first approach (44–66%): - Public sector examples will be published to give concrete, citable cases, leveraging WPT. - Praise for USDS/GDS improvements; aim is to educate and set bar for “serving everybody.” - Practical standards (77%): - Demand TTI-neutral/negative tools; require clear budgets and reproducible instructions. - Many popular tools may be relegated to prototyping—and that’s acceptable. - Call to action (89%): - End the DX bait-and-switch; have data-driven debates that state market targets and performance tradeoffs explicitly. ## 📖 References: - The original article at Infrequently Noted: https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ - WebPageTest (for collecting traces): https://www.webpagetest.org/ - Tools mentioned: Polymer, Preact, Svelte, Ionic, Vue. - Public digital service orgs: USDS, UK GDS. ## 🗣️ Paraphrase: - Original idea (0%): “JavaScript is the web’s CO2... Those who emit the most are furthest from suffering the consequences.” - Paraphrase: Treat JS like a pollutant: a little is essential, but excess contaminates the ecosystem. The heaviest emitters are insulated from the damage—until the environment degrades for everyone. - Original idea (77%): “We need tools...that deliver a better developer experience without fundamentally impairing the user experience... explain clearly… how they deliver under-budget experiences… what devices and networks their tools are appropriate in.” - Paraphrase: Tooling must improve developer workflows without undermining users. Vendors should publish reproducible guidance showing how they meet strict performance budgets, quantify remaining headroom, and specify the device and network contexts where their stack is suitable. ## 📰 Newsletter: This week in WordPress and the wider web: remember that performance is a feature, not a footnote. Alex Russell’s “Developer Experience Bait-and-Switch” argues that we’ve let DX become a stand-in for UX, shipping megabytes of JS that punish users on lower-end devices. The fix? Evidence-first engineering: set JS budgets, measure TTI, and choose frameworks that publish honest performance headroom and device/network targets. Learning web dev? Start with fundamentals: semantic HTML, progressive enhancement, and Core Web Vitals. Recent updates worth a look: - WordPress performance teams continue to improve LCP/INP out of the box; keep your eye on caching, image lazy-loading, and script strategy. - New plugin highlights: performance-focused asset managers, modern image pipelines (AVIF/WebP), and block-level code splitting. Community shout-outs to contributors auditing real-user performance and sharing WebPageTest runs. If your site claims “speed,” show the traces. Links: - Alex Russell on the DX bait-and-switch: The “Developer Experience” Bait-and-Switch - WebPageTest for reproducible measurements: WebPageTest Keep it friendly, keep it fast, and keep it fun—because your users’ thumbs and batteries will thank you. ## ✅ Action Items: A strategic prompt tailored to your role (GoDaddy Developer Advocate, OSS/WordPress educator, aspiring OSPO director): - Purpose: For each article you review, produce a brief mapping to: - Open-source advocacy and sustainability - Contributor onboarding/engagement - Education and curriculum design - WordPress ecosystem transparency and inclusivity - OSPO-aligned governance and policy - Prompt to reuse: “Analyze how this article advances a sustainable and inclusive open-source - Summary: 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. Lightweight, effective 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. - URL: https://infrequently.org/2018/09/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. Lightweight, effective 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.* JavaScript is the web's [CO2](https://www.theguardian.com/environment/climate-consensus-97-per-cent/2013/sep/27/global-warming-ipcc-report-humans). We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences -- until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control. Against this grim backdrop, there's something peculiar about conversations regarding the costs of JS-oriented development: a rhetorical substitution of developer value for user value. Here's a straw-man composite from several recent conversations: > These tools let us move faster. Because we can iterate faster we're delivering better experiences. If performance is a problem, we can do progressive enhancement through Server-Side Rendering. > > This argument substitutes good intentions and developer value ("moving faster", "less complexity") for questions about the lived experience of users. It also tends to do so without evidence. We're meant to take it on faith that it will all work out if only the well intentioned people are never questioned about the trajectory of the outcomes. Most unfortunately, this substitution is frequently offered to shield the preferences of those in a position to benefit at the expense of folks who can least afford to deal with the repercussions. Polluters very much prefer conversations that don't focus on the costs of emissions. The backdrop to this argument is a set of nominally shared values to which folks assign different weights: * Universality and accessibility * Fidelity and richness * Competitive (or superior) cost to produce The "developer experience" bait-and-switch works by appealing to the listener's parochial interests as developers or managers, claiming supremacy in one category in order to remove others from the conversation. The swap is executed by *implying* that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. ***This is not true***. Shifting the conversation away from *actual* user experiences to team-level advantages enables a culture in which the folks who receive focus and attention are developers, rather than end-users or the business. It naturally follows that teams can then substitute *tools* for *goals*. This has predictable consequences, particularly when developers, through their privileged positions as expensive-knowers-of-things-about-computers, are allowed to [externalize costs](https://en.wikipedia.org/wiki/Externality#Negative). And they do. Few teams I've encountered have actionable metrics associated with the real experiences of their users. I can count on one hand the number of teams I've worked with who have goals that allow them to block launches for latency regressions, including Google products. Nearly all developers in modern frontend shops *do not experience performance constraints until it's too late*. The brakes aren't applied until performance is so poor that it actively hurts the business. If one views the web as a way to address a fixed market of existing, wealthy web users, then it's reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web's future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn't tied to demonstrable gains for marginalized users is at best misguided. Competition between these forces is as old as debates about imagemaps vs. tables for layout. What's new is JavaScript; or rather, [the amount we're applying](https://httparchive.org/reports/state-of-javascript#bytesJs) to solve our problems: [](https://httparchive.org/reports/state-of-javascript#bytesJs) Median mobile sites have gone from ~50KB of JS in 2011 to more than 350KB today. That unzips to roughly 2MB of script. I've [previously outlined why JavaScript is the most expensive way to accomplish anything](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/) in a browser. This has been coupled with an [attempt to lean on evolving facts about computing (it's all going to mobile, mostly to Android, and not high-end devices)](https://www.youtube.com/watch?v=4bZvq3nodf4). My hope is that anyone who connects these ideas will come to understand that we can't afford to continue on as we have. We must budget. We must cap-and-trade JS. There is no other way to fix what we have now broken with script -- we simply need to use less of it. There have been positive signs that this message has taken root in certain quarters, but it has not generally changed the dynamic. Despite the heroic efforts of [Polymer](https://github.com/Polymer/pwa-starter-kit), [Preact](https://github.com/developit/preact-cli), [Svelte](https://sapper.svelte.technology/), [Ionic](https://ionicframework.com/pwa/toolkit), and [Vue](https://cli.vuejs.org/) to create companion "starter kits" or "CLI" tools that provide the structure necessary to send less JS be default, as many (or more) JS-heavy performance disasters cross my desk in an average month as in previous years. And still framework marketing continues unmodified. The landing pages of popular tools talk about "speed" without context. Relatively few folks bring [WPT traces](https://www.webpagetest.org/easy) to arguments. Appeals to "Developer Experience" are made without context. Which set of users do we intend to serve? All? Or the wealthy few? [It is apparently possible to present performance arguments to the JavaScript community in 2018](https://engineering.linkedin.com/blog/2018/03/how-we-built-the-same-app-twice-with-preact-and-glimmerjs) -- a time when it has never been easier to collect and publish traces -- without traces against [the global baseline](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/) or an explanation of why that baseline is inappropriate. *The bait-and-switch still works*, and that's a hell of a problem. Perhaps my arguments have not been effective because I hold to a policy of not posting analyses without site owner's consent. This leaves me as open to critique by [Hitchen's Razor](https://en.wikipedia.org/wiki/Hitchens%27s_razor) as my dataless interlocutors. The evidence [has never been easier to gather](https://www.webpagetest.org/easy) and the aggregates paint a chilling picture. But aggregates aren't specific, citable incidents. Video of a single slow-loading page lands in a visceral way; abstract graphs don't. And the examples are there, many of them causing material, negative business impact. A decent hedge-fund strategy would be to run a private WPT instance and track JS bloat and TTI for commercial-intent sites -- and then short firms that regress because they just rewrote everything in The One True Framework. Seeing the evidence instills terror, yet I've been hamstrung to do more than roughly sketch the unfolding disaster while working behind the scenes with teams. There is, however, one exception to my rule: the public sector. Specifically public sector sites in countries where I pay taxes. Today, that's the US and the UK, although I suspect I could be talked into a more blanket exception. So I'm going to start posting and dissecting a lot more traces of public sector work, but the goal isn't to mock or shame the fine folks doing hard work for too little pay. Rather, it's to demonstrate what "modern frontend" is doing to the accessibility of the web -- not in the traditional "a11y" sense, but in the "is going to this site reasonable for its intended users?" sense. That is, I will be talking about this as a proxy for the data I *can't* share. Luckily, the brilliant folks at the [USDS](https://www.usds.gov/) and the [UK's Government Digital Service](https://gds.blog.gov.uk/) have been cleaning up many of the worst examples of government-procurement-gone-wild. My goal isn't to detract anything from this extraordinary achievement: > Just wanted to send my 💌 and 🙏 to the lovely souls a[t @gdste](https://twitter.com/ @gdste)am. > > I spend a lot of time despairing at what Silicon Valley thinks is acceptable and y'all are beacon on a hill, showing what's possible and what inclusion \*really\* means[www.webpagetest.org/result/180827\_FR\_7ca373cd8e9e200d531c63fa03a14809/](https://www.webpagetest.org/result/180827_FR_7ca373cd8e9e200d531c63fa03a14809/)ee > > My hope, instead, is that by showing specific outcomes and the overwhelming volume of these examples it will become possible to talk more specifically about what's wrong, using and pervasively citing data. I hope that by talking about what it means to build well when trying to serve everybody, we can show businesses how short they're falling of the mark -- and why those common root-causes in JS-centric development are so toxic. And if the analysis manages to help clean up some public sector services, so much the better; we're all paying for it anyway. [An old version of Code.gov loading on a fast connection on an iPhone 8 vs. an Android Go device](https://www.webpagetest.org/video/compare.php?tests=180831_25_3a7e0326e5deb329b760f6241b3a87f5-r%3A1-c%3A0%2C180831_Q2_36cc2c3f96e11252eb47d7ce521891bf-r%3A1-c%3A0&thumbSize=200&ival=500&end=full) This isn't Plan A, but neither was the [CDS talk in '16 that got everyone so upset](https://www.youtube.com/watch?v=4bZvq3nodf4). I don't like that this is where we are as a community and as a platform. I hate that this continues to estrange me from the JS community. We need tools. We need frameworks. But we need to judge them by whether or not the deliver a better developer experience *without* fundamentally impairing the *user experience*. We must get to JS-neutral (or, my preferred, Time-to-Interactive-neutral or negative) tooling. Frameworks and tooling need to explain clearly, in small words, with reproducible instructions how they deliver [under-budget experiences](https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/), how much room is left after their budgetary cost, and what devices and networks their tools are appropriate in. This will mean that many popular tools are relegated to prototyping. *That's OK*. This is very much Plan D...or E. But the crisis is real and it isn't inevitable. It is not exogenous. We made it, and we can fix it. To get this fixed, we need to confront the "developer experience" bait-and-switch. Tools that cost the poorest users to pay wealthy developers are bunk. To do better, we need to move the conversation to an evidence-based footing. I wish the arguments folks made against my positions were data-driven. There's so much opening! Perhaps a firm *is* doing market analysis and only cares about ever reaching users who make more than $100K USD/yr or who are in enterprise settings. Perhaps research will demonstrate that interactivity isn't as valuable as getting bits on screen (the usual SSR argument). Or, more likely, that acknowledgement (bits on screen) buys a larger-than-anticipated amount of perceptual padding (perhaps due to [scanning](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/)). Perhaps the global network landscape is shifting so dramatically that the budget for client-side JS runtime has increased. Perhaps the median CPU improvement that doesn't look set to materialize until 2021 at the earliest will happen much earlier; i.e., maybe the current baseline is wrong! But we aren't having that conversation. And we aren't going to have it until we identify, call-out, and end the "developer experience" bait-and-switch. *Thanks and apologies to [Ade Oshineye](https://twitter.com/ade_oshineye), [Ojan Vafai](https://twitter.com/ojanvafai), [Frances Berriman](https://fberriman.com/), [Dion Almaer](https://twitter.com/dalmaer), [Addy Osmani](https://twitter.com/addyosmani), [Gray Norton](https://twitter.com/graynorton) and [Philip Walton](https://twitter.com/philwalton) for their feedback on drafts of this post.*, The "Developer Experience" Bait-and-Switch, Alex Russell, 01h1379sk20bbymxz4rnkmy90d.