# webdev Published articles for webdev. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why Code Removal May Be Preferable to Scheduling for Performance Remediation DevFeed: [Why Code Removal May Be Preferable to Scheduling for Performance Remediation]() Original publisher: [Read original article]() Author: Alex Russell Published: 2026-08-19T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Code](), [ordering]() Tags: [code](), [ordering](), [performance](), [webdev]() ### AI overview An opinion article arguing that removing code can be a more reliable performance-remediation strategy than reordering or deferring work. It says both approaches require understanding page behavior, while scheduling changes can increase validation, coordination, bandwidth, and main-thread performance risks. ### Source excerpt My colleague Marko Ilić has published an insightful piece on how to schedule work on the critical path, and I recommend reading it before proceeding here. Contents Elimination vs. Scheduling: An Organisational Perspective What's Good for the Goose... "Preloading" as Scheduling Scheduling Is For Closers General-Purpose Advice ...and welcome back. As you likely anticipated, Marko's beautifully presented post kicked off healthy discussions around the office. Since we almost always see eye-to-eye, it seemed interesting to surface some of that discussion here. With his permission, what follows are expanded versions of some points I posed in reply. Elimination vs. Scheduling: An Organisational Perspective There's no daylight between our positions on code reduction: sending and running less is always ideal. Where we differ, perhaps, is the priority teams should assign to scheduling vs. code removal in their performance remediation efforts. Contra Marko, I posit that reordering can almost never be assumed to be cheaper or easier. While it may be hard to remove code, my view is that it is generally not harder than re-ordering in most codebases. Why? The primary cost of both code removal and scheduling interventions is the investment to deeply understand page behaviour. This presents a narrative challenge to the proposition that scheduling is an easier fix, as both approaches share the largest cost. At the team level, the consequences of restructuring are harder to reason about than direct removal, reducing potential upside and increasing validation costs. Bytes that are only deferred still contend for bandwidth, potentially delaying above-the-fold resources in ways that only become visible in the tail of the connection quality curve. Worse, late-fetched JS resources generate heavy "thuds" when residual allocations from background compilation arrive on the main thread. These stalls show up in INP data, but can be maddening to track down due to their stochastic relationship wi ## Why "state management" is a misleading term in React DevFeed: [Why "state management" is a misleading term in React]() Original publisher: [Read original article]() Author: Alex Russell Published: 2026-07-23T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [React](), [JavaScript](), [GraphQL]() Tags: [alternatives](), [frameworkism](), [javascript](), [library](), [react](), [redux](), [state-management](), [webdev]() ### AI overview This opinion article argues that "state management" is an imprecise label for React and the surrounding ecosystem. It surveys libraries including Redux, Zustand, Apollo, and others, and contends that they primarily encapsulate state or propagate notifications about state changes rather than manage state themselves. ### Source excerpt It is by no means the gravest linguistic crime of the React epoch,1 but "state management" grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this: me: This UI is far too heavyweight for what it does, have you considered not using React? them: But how will we do state management without React? me: What do you mean? are reactive. them: React manages state in our app. me: It does? Then what are for? them: Oh, those manage state. me: The libraries that trigger this "Who's on First?" routine include: MobX, which promises "simple, scalable state management." Satchel, apparently, "is characterized by exposing an observable state that makes view updates painless and efficient" Recoil, billed as "a state management library for React" Jotai, which pledges "primitive and flexible state management for React" XState, a "state management and orchestration solution for JavaScript and TypeScript apps" Apollo, promising "a comprehensive GraphQL state management library for JavaScript" Redux, tagline: "a predictable state container for JavaScript apps." TanStack Store, "a framework-agnostic state primitive for immutable updates" Zustand, described as the "🐻 bear necessities for state management in React" Contrasts sharp enough to cut softened butter.2 Suffice it to say, the ecosystem has not picked a winner. Indeed, I regularly see several of these libraries on a single page. But even one would seem too many, given that we're adding a second "state management" system to a framework that spills considerable documentation ink chest-beating about its state management facilities. One of the following must be true: React is a state management system and someone has smuggled in a duplicative dependency we can jettison. React is an inadequate state management system and we should stop trusting it with an ill-defined subset of the "state management" problem. React is not a state management system and we should s ## Safari 27's Web Platform Test progress compared with Firefox and Chromium DevFeed: [Safari 27's Web Platform Test progress compared with Firefox and Chromium]() Original publisher: [Read original article]() Author: Alex Russell Published: 2026-07-06T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [browser](), [Web platform](), [Chromium](), [Firefox]() Tags: [browsers](), [chromium](), [competition](), [firefox](), [openweb](), [safari](), [test](), [web-platform](), [webdev]() ### AI overview An opinion article argues that Safari 27's quality and Web Platform Test improvements should be assessed against its slower release cadence and compared with Firefox and Chromium. It says Safari's time-weighted rate of improved tests is lower than those competitors. ### Source excerpt It's perilous to disagree with someone as wise and thoughtful as Jeremy, but for the past fortnight his post in response to Apple's iOS 27 marketing invades my quiet moments like a cricket in the attic. "Why", I ruminate, "should someone who understands the state of play give Apple credit for doing less than the minimum while rubbishing those who have consistently done more?" Contents Redux Features Over Tests Focus Areas Consequences You Do Not Have To Hand It To Them Everywhere You Turn Quality Has A Quality All Its Own Redux Like Apple's previous marketing of Safari 16.4 and Safari 26, the conjoined September release of Safari and iOS 27 documents an achingly slow release cycle. It would be one thing if the features or spec conformance were world-beating, but looking closely at the release notes, Safari 27 is set to deliver fixes for issues that, by and large, competing engines didn't suffer.1 Don't get me wrong: it's great that Apple is focusing on quality; it remains a persistent issue for Safari. But how much relief should long-suffering web developers expect? The best comparative measures come from the communal Web Platform Tests project. Comparing the current experimental builds with stable channel releases can illuminate the scale of change we can expect when the next major version of each browser launches:2 WPT Test Pass Rates (%) 90% is the minimum Apple requires across all WPT tests for competitors' engines in the EU and Japan where it has been forced to allow them (in theory). Safari barely clears the bar. Source: wpt.fyi It would appear that Safari is closing on Firefox, but this is misleading. Apple managed seven releases over the past year, or a roughly eight week cadence. Mozilla and Chromium, meanwhile, have released 12 versions to stable, or one a month. These serve as denominators (7.4 weeks vs. 4.3) when calculating rates of improvement. Safari's larger increase in passing tests between nightly and stable versions (1558 vs. 990 for Firefox) look ## The Web Is An Antitrust Wedge DevFeed: [The Web Is An Antitrust Wedge]() Original publisher: [Read original article]() Author: Alex Russell Published: 2026-04-03T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Web](), [interoperability](), [browsers](), [Mobile](), [App]() Tags: [apple](), [apps](), [browsers](), [competition](), [interoperability](), [regulatory](), [web](), [web-apps](), [webdev]() ### AI overview This opinion argues that browsers and progressive web apps should be central to antitrust efforts targeting mobile ecosystems. It contends that regulators are accepting weak enforcement and that focusing mainly on alternative native app stores may leave the existing mobile duopoly's power intact. ### Source excerpt TL;DR: Armed with new powers to rein in the worst excesses of mobile's duopolists, antitrust bodies around the world are struggling to find their footing, and an incurious tech press is letting it pass with nary a nod. Browsers are app stores, but that perspective is almost entirely absent from the antitrust conversation. Instead of prioritising the one, narrow intervention that can safely unlock maximal competition, regulators are gripped by alt store fever dreams; driving down cul-de-sacs that will leave the duopolists' power intact even if new native app stores materialise. Worse, enforcers of new regulations are choking in the face of blatant non-compliance. Laws designed to kickstart competition and unchain web apps are being flouted, but regulators seem unfazed. The web is an engine of interoperability; this was understood by the drafters of these laws, but enforcers have not internalised the lesson, with the UK's CMA being only the latest to pose capitulation as success. Instead of unlocking growth and dynamism, overcautious regulators are ratifying non-compliance through inaction. Timidity today reduces room for manoeuvre tomorrow while hampering home-grown competitors to Big Tech. As it did twenty-five years ago, the web can unlock maximum change with the lowest risk, but regulators are falling down on the job, and tech reporters are not informing readers of the options or the stakes. It's time we spoke plainly about these overlapping institutional failures. Contents Open Societies Necessitate Interoperability Shared Premises Alt Stores, PWAs, and the App Store Endgame Regulators Are Missing The Ripest Opportunity Cupertino is Running Circles Around Brussels, Tokyo, and London Browsers Are App Stores Our Tech Press is Missing the Story, Too It's a day that ends in "y", which means The Verge is at it again: covering the regulatory tussle over mobile ecosystems without mentioning browsers, the web, or PWAs. This long-established pattern is as frustrating as i ## The Performance Inequality Gap, 2026 DevFeed: [The Performance Inequality Gap, 2026]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-11-24T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Web Development](), [JavaScript](), [Front end](), [Core Web Vitals](), [Mobile](), [Network](), [TLS (Transport Layer Security)]() Tags: [2026](), [core-web-vitals](), [cpu](), [devices](), [doom](), [frontend](), [javascript](), [mobile](), [network](), [performance](), [tls](), [webdev]() ### AI overview This article updates network and device assumptions for 2026 and derives resource budgets for three- and five-second page loads. It argues that growing page sizes and JavaScript payloads worsen performance inequality, while noting that fewer than half of mobile origins pass Core Web Vitals. ### Source excerpt The Budget, 2026 Edition Let's cut to the chase, shall we? Updated network test parameters for 2026 are: 9 Mbps downlink 3 mbps uplink 100 millisecond RTT Regarding devices, my updated recommendations are the Samsung Galaxy A24 4G (or equivalent) and the HP 14. The goal of these recommendations is to emulate a 75th percentile user experience, meaning a full quarter of devices and networks will perform worse than this baseline. Plugging these parameters into the updated budget calculator, we can derive critical-path resource thresholds for three and five second page load targets. Per usual, we consider pages built in two styles: JS-light, where only 15% of critical-path bytes are JavaScript, and JS-heavy, comprised of 50% JavaScript: Time JS-light (MiB) JS-heavy Total JS Other Total JS Other 3 sec 2.0 0.3 1.7 1.2 0.62 0.62 5 sec 3.7 0.57 3.2 2.3 1.15 1.15 Note: Budgets account for two TLS connections. Many sites initiate more early connections, reducing time available to download resources. Using four connections cuts the three-second budget by 350 KiB, to 1.5 MiB / 935 KiB. The five-second budget loses nearly half a megabyte, dropping to 3.2 / 1.9 MiB. It pays to adopt H/2 or H/3 and consolidate connections. These budgets are extremely generous. Even the target of three seconds is lavish; most sites should be able to put up interactive content much sooner for nearly all users. Meanwhile, sites are ballooning. The median mobile page is now 2.6 MiB, blowing past the size of DOOM (2.48 MiB) in April. The 75th percentile site is now larger than two copies of DOOM. P90+ sites are more than 4.5x larger, and sizes at each point have doubled over the past decade. Put another way, the median mobile page is now 70 times larger than the total storage of the computer that landed men on the moon. Median page weights are more than 2.5x larger for mobile sites than a decade ago, and sites at the 75th percentile are now 4x their 2015 weight. An outsized contributor to this bloat co ## How Apple's App Store Model and Browser Restrictions Relate to the EU's DMA DevFeed: [How Apple's App Store Model and Browser Restrictions Relate to the EU's DMA]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-10-11T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [interoperability](), [Data Space](), [web applications](), [Web](), [App](), [browser](), [iOS]() Tags: [app](), [apple](), [appstores](), [browser](), [competition](), [dma](), [eu](), [interoperability](), [opensocieties](), [policy](), [right-to-repair](), [web](), [web-applications](), [webdev]() ### AI overview This opinion article argues that Apple's App Store model depends on control over app distribution and browser access. It links Apple's opposition to interoperability and browser engine choice under the EU's Digital Markets Act to the company's ability to collect revenue from developers and users. ### Source excerpt Eric Prouzet And now we see it clear, like a Cupertino sunrise bathing Mt. Bielawski in amber: Apple will censor its App Store at the behest of the Trump administration without putting up a fight. It will twist words into their antipodes to serve the powerful at the expense of the weak. To better serve autocrats, it will talk out both sides of its mouth in ways it had previously reserved for dissembling arguments against threats to profits, like right-to-repair and browser choice. They are, of course, linked. Contents Who's Afraid of the Big Bad Web? Dots Unconnected "Who should rule?" The Price of High Modernism is Dignity Endnote: Let's Talk About Google Apple bent the knee for months, leaving many commentators to ask why. But the reasons are not mysterious: Apple wants things that only the government can provide, things that will defend and extend its power to extract rents, rather than innovate. Namely, selective exemption from tariffs and an end to the spectre of pro-competition regulation that might bring about real browser choice. Over the past few weeks, Tim Apple got a lot what he paid for,1 with the full weight of the US foreign and industrial policy apparatus threatening the EU over DMA enforcement. This has been part of a full-court press from Cupertino. Apple simultaneously threatened the EU while rolling out fresh astroturf for pliant regulators to recline on. This is loud, coordinated, and calculated. But calculated to achieve what? Why is the DMA such a threat to Apple? Interoperability. The DMA holds the power to unlock true, safe, interoperability via the web. Its core terms require that Apple facilitate real browser engine choice, and Apple is all but refusing, playing games to prevent powerful and safe iOS browsers and the powerful web applications they facilitate. Web applications that can challenge the App Store. Unlike tariffs, which present a threat to short-term profits through higher costs and suppression of upgrades in the near term, inter ## 11ty Hacks for Fun and Performance DevFeed: [11ty Hacks for Fun and Performance]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-10-04T00:00:00Z Content type: tutorial Language: en Sources: [Alex Russell]() Topics: [Script](), [Nunjucks](), [Markdown](), [Web Development](), [Code]() Tags: [11ty](), [async](), [blog](), [blogging](), [build](), [code](), [fun](), [hacks](), [how-to](), [js](), [module](), [performance](), [script](), [web](), [webdev]() ### AI overview A developer shares techniques for improving performance in an 11ty site, including selectively loading shortcode resources through the 11ty Bundle plugin, avoiding duplicate scripts, and handling Nunjucks and Markdown preprocessing. ### Source excerpt This blog really isn't just for beating up on Apple for the way it harms users, the web, standards, and society to maintain power and profits. So here's some fun stuff I've been doing in my 11ty setup to improve page performance. Contents Page-Specific Resources via Shortcodes and the 11ty Bundler Mo Pagination, Mo Problems Build Time Impact Scroll-Position Based Delayed Code Loading Faster CSS Selectors for 11ty Syntax Highlighting Lean Rada's CSS-only Low-Quality Image Previews Bonus Hack: Global Acronyms for Better Abbreviations Does It Work? Page-Specific Resources via Shortcodes and the 11ty Bundler You know how it gets once you've got a mature 11ty setup: shortcodes proliferate, and some generate output that might depend on JS or CSS. If your setup is anything like mine, you might also feel conflicted about including some of those resources globally. It's important to have them available for the posts that need them, but it's not great to bring a charting library, e.g., into every page when only 1 in 20 will need it. This blog has grown many such shortcodes that generate expansions for features like: Web Components for YouTube and Vimeo embeds WebPageTest.org test embeds plot.js based charts Here, for instance, is how a Vimeo embed looks in the markdown of a page, using Nunjucks for Markdown pre-processing: {% vimeo "VIDEOID", "TITLE" %} This expands to: TITLE But this also requires script; e.g.: And the list keeps growing. To avoid having the weight of these components clogging up every page, a system for selectively pulling in their code would be helpful. It'd also be grand if we could make sure scripts appear just once, even if shortcodes are invoked multiple times per page. Included code should preferably also be located towards the top of the document. The 11ty Bundle plugin ## Apple's Dispute With the EU Over DMA Compliance and Browser Competition DevFeed: [Apple's Dispute With the EU Over DMA Compliance and Browser Competition]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-25T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [browser](), [Security](), [iOS](), [PWA](), [push-notification](), [Web]() Tags: [apple](), [browser](), [browsers](), [competition](), [dma](), [eu](), [geofencing](), [ios](), [iphone](), [pdf](), [push-notification](), [pwa](), [sdk](), [security](), [webdev]() ### AI overview The article argues that Apple is misrepresenting the European Union's enforcement of the Digital Markets Act and shifting responsibility for its own compliance decisions onto regulators. It focuses on alleged barriers affecting browser competition on iOS, including geofencing, restricted PWA and Push Notification APIs, SDK bugs, and difficult development entitlements. ### Source excerpt Contents Lies by Any Other Name Great Artists Steal Dear Tech Reporters: Access Is Not A Beat This blog is failing on several levels. First, September 2025 is putting the "frequent" in "infrequently", much to my chagrin. Second, my professional mission is to make a web that's better for everyone, not to tear Apple down. But just when I thought I was out, they pull me back in. Over the past 24 hours, Cupertino has played the hits from its iPhone-era anti-user, anti-business, anti-rule-of-law power trip. To recap: Apple sent a demand that the EU give up on DMA enforcement in a petulant and utterly misleading press release that mostly served to catalogue Apple's own failures to comply. Cupertino's kept astroturf outfit -- ACT | The App Association -- penned unhinged misinformation for consumption by US regulatory types (h/t Damien Geradin). The EC then called Apple's bluff. Make no mistake about what's going on: Apple is claiming that the EU is forcing Apple to adopt interpretations of the DMA that no other party has, which the EC itself has not backed, and which are "forcing" Apple to avoid shipping features in the EU. Or, put another way, Apple wants to launder the consequences of its own anticompetitive, anti-user choices through a credulous tech press. The goal is to frame regulators for Apple's own deeds. Lies by Any Other Name If this smells like bullshit, that's because it is. Apple tried similar ploys last year when it sprung a blatant attempt to kill PWAs on the EU as a price for having the temerity to regulate. The plan, it seemed then, was to adopt an exotic reading of the DMA and frame the EC for killing PWAs. What Apple's attempting now is even more brazen, particularly after 16+ months of serial non-compliance since the DMA came into force (h/t OWA). Remember that: Apple's browser, and by extension every iOS browser, fails on basic security and privacy controls, putting users at risk constantly. Apple serially misrepresents this situation to anyone who will ## Optimizing Third-Party Content Delivery: A Deep Dive into Preconnect's Performance and Call Cost Implications DevFeed: [Optimizing Third-Party Content Delivery: A Deep Dive into Preconnect's Performance and Call Cost Implications]() Original publisher: [Read original article]() Author: Veda Published: 2025-09-23T07:48:40Z Content type: article Language: en Sources: [Bazaarvoice]() Topics: [Web](), [Latency](), [Front end](), [Core Web Vitals](), [Optimization](), [Network](), [Contentful]() Tags: [api](), [apigateway](), [bazaarvoice](), [cdn](), [corewebvitals](), [cwv](), [lcp](), [optimizing](), [performance](), [performanceoptimization](), [preconnect](), [preconnect-cost](), [resourcehints](), [seo](), [technicalseo](), [third-party](), [ux](), [web-performance](), [webdev](), [webperformance]() ### AI overview This article explains how preconnect and other resource hints can improve third-party content delivery by establishing network connections early. It focuses on Bazaarvoice content, frontend performance, LCP, and the claim that preconnect operations are not counted as API calls in internal testing. ### Source excerpt This document details how preconnect improves web performance, especially for Bazaarvoice's third-party content, by accelerating connection setups and reducing LCP. Crucially, internal testing confirmed preconnect operations are not counted as API calls, validating a "no count, low cost" model--a key insight for our developer blog. ## Apple's WebKit Feature Pace and Browser Competition on iOS DevFeed: [Apple's WebKit Feature Pace and Browser Competition on iOS]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-23T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [WebKit](), [browsers](), [iOS](), [Web]() Tags: [apple](), [browsers](), [features](), [standards](), [web](), [webdev]() ### AI overview This opinion article examines Apple's approach to web-platform collaboration and feature development, arguing that WebKit has trailed Blink and Gecko while Apple's iOS policies prevent competing browsers from shipping alternative engines. It introduces data intended to assess claims about Apple's handling of challenging APIs. ### Source excerpt Update: The charts below were inappropriately snapped, compressing the range of values. This has been corrected. Feature availability numbers also changed since drafting and have been updated. In several recent posts, I've attempted to address how the structure of standards bodies and their adjacent incubation venues accelerates or suppresses the potential of the web as a platform. The pace of progress matters because platforms are competitions, and actors that prevent expansions of basic capabilities risk consigning the web to the dustbin. Inside that framework, there is much to argue over regarding the relative merits of specific features and evolutionary directions. This is healthy and natural. We should openly discuss features and their risks, try to prevent bad consequences, and work to mend what breaks. This competitive process has made browsers incredibly safe and powerful for 30 years. Until iOS, that is. Imagine my surprise upon hearing that Apple isn't attempting to freeze the web in amber, preserving advantages for its proprietary platform, and that it instead offers to redesign proposals it disagrees with. Contents Background Is Apple Engaged In Constructive API Redesign? General Trends Hard Cases Overall Impressions What's Happening Here? As I have occasionally documented, this has not been my experience. I have relatively broad exposure to the patterns of Apple's collaboration, having designed, advised on, or led teams that built dozens of features across disparate areas of the platform since the Blink fork.1 But perhaps this was the wrong slice from which to judge? I've been hearing of Apple's openness to collaboration on challenging APIs so often that either my priors are invalid, or something else is at work. To find out, I needed data. Background A specific parry gets deployed whenever WebKit's sluggish feature pace comes up: "controversial" features "lack consensus" or "are not standards" or "have privacy and security problems" (unspecified). The ## Web Standards and the Fall of the House of Iamus DevFeed: [Web Standards and the Fall of the House of Iamus]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-21T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [web-standards](), [browsers](), [interoperability](), [Chromium]() Tags: [apple](), [browsers](), [chromium](), [interoperability](), [standards](), [web](), [web-standards](), [webdev]() ### AI overview This commentary argues that web standards and Working Groups generally document, refine, and spread designs that have already demonstrated value rather than determining what browsers may ship. It concludes that responsible feature development depends on thoughtful launch processes, not prior consensus. ### Source excerpt Photo by Photo by Artan Sadiku Commentary about browsers and the features they support is sometimes pejorative towards pre-standardisation features. Given Apple's constriction of Mozilla's revenue stream and its own strategic under-funding of WebKit, this usually takes the form "Chromium just ships whatever it wants." This is true, of course, but not in the way commenters intend; and not only because Blink's rigorous launch process frequently prevents unvalidated designs from shipping. Except for iOS, where Apple attempts to hide its role in undermining the competitive foundation of web standards, every vendor always ships "whatever it wants." That is the point of voluntary standards, and competition is the wind in those sails. Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. There are no seers; no Delphic oracles that fleetingly glimpse a true logos. Working Groups do not invent the future, nor do they hand down revealed truths like prophets of the House of Iamus. In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread. In the end, this is the role of standards and the Working Groups that develop them: to license patents that read on existing designs, reducing risks to implementers who adopt them. Anyone who tries to convince you otherwise, or invites you to try your hand at invention within a chartered Working Group, does not understand what those groups are designed to do. Sadly, this includes some folks who spend a lot of time in them. Contents Terminology Traps Standardisation != Interoperability Standardisation != Responsibility What Working Groups Really Do Chartered Working Groups Are Not Design Venues The Role of Incubation No Prophecies, Only Engineering Complaints about certain engines leading ## Apple's Influence on Browser Choice and Internet Standards DevFeed: [Apple's Influence on Browser Choice and Internet Standards]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-02T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [interoperability](), [Internet](), [Web](), [browser](), [Software]() Tags: [browser](), [browsers](), [competition](), [internet](), [interoperability](), [standards](), [web](), [webdev]() ### AI overview The article argues that competition and interoperability are foundational to internet standards because they limit vendor power and enable users to switch software. It contends that Apple's control over hardware and software has restricted browser choice, weakened interoperability, and undermined the role of internet standards. ### Source excerpt TL;DR: Market competition underlies the enterprise of standards. It creates the only functional test of designs and lets standards-based ecosystems route around single-vendor damage. Without competition, standards bodies have no purpose, and neither they, nor the ecosystems they support, can retain relevance. Apple has poisoned the well through a monopoly on influence, which it has parleyed into suppression of browser choice. This is an existential threat to the web, but also renders web and internet standards moot. Internet standards bodies should recognise the threat and respond. Contents The Power of Interoperability Voluntary Adoption Is Foundational to Internet Standards Apple's Unique Monopoly How Apple Uses Its Monopoly to Centralise and Enclose Apple's Transgressions Against Voluntary Adoption Unilateral Off-Ramps How Apples Crimes Differ From Prior Episodes Necessary, Proportional Responses Why Now? Do Standards Matter? Internet enthusiasts of the previous century sometimes expressed the power of code by declaring the sovereignty of cyberspace, or that "code is law." As odd as these claims sound today, they hit a deep truth: end-users, and even governments, lack power to re-litigate choices embodied in software. Software vendors, therefore, have power. Backed by deeply embedded control chokepoints, and without a proportional response from other interests, this control is akin to state power. Both fear and fervour about these properties developed against a backdrop of libertarian1 attitudes toward regulation and competition. Attenuating vendor power through interoperability was, among other values, a shared foundation of collaboration for internet pioneers. The most fervent commitment of this strain was faith in markets to sort out information distribution problems through pricing signals,2 and that view became embedded deeply into the internet's governance mechanisms.3 If competition does not function, neither do standards. The internet's most consequential ## How Do Committees Fail To Invent? DevFeed: [How Do Committees Fail To Invent?]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-08-11T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Development](), [Web platform](), [W3C]() Tags: [bias](), [browsers](), [consensus](), [development](), [engineering](), [standards](), [web-platform](), [webdev]() ### AI overview The article applies Conway's Law to standards development organizations, arguing that a "fifth column" problem can arise when delegates conceal their intentions through objections or silence. It examines how open membership, veto-heavy rules, and poor information can obstruct progress in standards working groups and affect developers' perceptions of standards. ### Source excerpt Mel Conway's seminal paper "How Do Committees Invent?" (PDF) is commonly paraphrased as Conway's Law: Organizations which design systems are (broadly) constrained to produce designs which are copies of the communication structures of these organizations. This is deep organisational insight that engineering leaders ignore at their peril, and everyone who delivers code for a living benefits from a (re)read of "The Mythical Man-Month", available at fine retailers everywhere. Conway's Law is generally invoked to describe organisations working to solve well-defined problems, in which everyone is working towards a solution. But what if there are defectors? And what if they can prevent forward progress without paying any price? This problem is rarely analysed for the simple reason that such an organisation would be deranged. But what if that happened regularly? I was reminded of the possibility while chatting with a colleague joining a new (to them) Working Group at the W3C. The most cursed expressions of Conway's Law regularly occur in Standards Development Organisations (SDOs); specifically, when delegates refuse to communicate their true intentions, either through spurious objection or tactical silence. This special case is the fifth column problem. Contents How Does This Happen? Mayfly Half-Lives The Web Platform's Power Structure But Why? Problem Misstatements Closed For Business Survivorship Bias and The Problem of Big, Old Rooms Marketing Gridlock As Thoughtfulness When Is A "Consensus" Not Consensus? Defences Against Fifth Columns Expressed in Conwayist terms, the fifth column problem describes the way organisations mirror the miscommunication patterns of their participants when they fail to deliver designs of any sort. This pathology presents when the goal of the majority is antithetical to a small minority with a veto. Reticence of certain SDO participants to consider important problems is endemic, in part, due to open membership. Unlike corporate environments wh ## A New Resource and Blogroll Page for Performance-Oriented Web Development DevFeed: [A New Resource and Blogroll Page for Performance-Oriented Web Development]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-07-16T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Web Development](), [Front end](), [CSS](), [HTML](), [SVG](), [Astro](), [RSS]() Tags: [astro](), [css](), [frontend](), [html](), [links](), [performance](), [resources](), [rss](), [svg](), [web-development](), [webdev]() ### AI overview The author announces a new links and resources page for people interested in performance- and platform-oriented web development. It combines recommended resources, background reading, and a blogroll, with an OPML export and more than 250 pointers. The author also comments on creative CSS, HTML, and SVG work, and on the use of 11ty, Astro, and RSS/Atom styling. ### Source excerpt Frances has urged me for years to collect resources for folks getting into performance and platform-oriented web development. The effort has always seemed daunting, but the lack of such a list came up again at work, prompting me to take on the side-quest amidst a different performance yak-shave. If that sounds like procrastination, well, you might very well think that. I couldn't possibly comment. The result is a new links and resources page page which you can find over in the navigation rail. It's part list-of-things-I-keep-sending-people, part background reading, and part blogroll. The blogroll section also prompted me to create an OPML export , which you can download or send directly to your feed reader of choice. The page now contains more than 250 pointers to people and work that I view as important to a culture that is intentional about building a web worth wanting. Hopefully maintenance won't be onerous from here on in. The process of tracking down links to blogs and feeds is a slog, no matter how good the tooling. Very often, this involved heading to people's sites and reading the view-source:// FOMO Having done this dozens of times on the sites of brilliant and talented web developers in a short period of time, a few things stood out. First -- and I cannot emphasise this enough -- holy cow. The things creative folks can do today with CSS, HTML, and SVG in good browsers is astonishing. If you want to be inspired about what's possible without dragging bloated legacy frameworks along, the work of Ana Tudor, Jhey, Julia Miocene, Bramus, Adam, and so many others can't help but raise your spirits. The CodePen community, in particular, is incredible, and I could (and have) spend hours just clicking through and dissecting clever uses of the platform from the site's "best of" links. Second, 11ty and Astro have won the hearts of frontend's best minds. It's not universal, but the overwhelming bulk of personal pages by the most talented frontenders are now built with SS ## Conferences, Clarity, and Smokescreens DevFeed: [Conferences, Clarity, and Smokescreens]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-06-27T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [React](), [Framework](), [Accessibility]() Tags: [accessibility](), [browsers](), [conference](), [conferences](), [performance](), [react](), [talks](), [webdev]() ### AI overview The article contrasts JSNation with React Summit 2025, arguing that JSNation encouraged debate about measurable engineering problems while React Summit largely reinforced prevailing framework narratives. It presents the React community as facing a measurable quality crisis that was not sufficiently represented in the conference program. ### Source excerpt Before saying anything else, I'd like to thank the organisers of JSNation for inviting me to speak in Amsterdam. I particularly appreciate the folks who were brave enough to disagree at the Q&A sessions afterwards. Engaged debate about problems we can see and evidence we can measure makes our work better. The conference venue was lovely, and speakers were more than well looked after. Many of the JSNation talks were of exactly the sort I'd hope to see as our discipline belatedly confronts a lost decade, particularly Jeremias Menichelli's lighting talk. It masterfully outlined how many of the hacks we have become accustomed to are no longer needed, even in the worst contemporary engines. view-source:// on the demo site he made to see what I mean. Vinicius Dallacqua's talk on LoAF was on-point, and the full JSNation line-up included knowledgeable and wise folks, including Jo, Charlie, Thomas, Barry, Nico, and Eva. There was also a strong set of accessibility talks from presenters I'm less familiar with, but whose topics were timely and went deeper than the surface. They even let me present a spicier topic than I think they might have been initially comfortable with. All-in-all, JSNation was a lovely time, in good company, with a strong bent toward doing a great job for users. Recommended. Day 21 -- React Summit 2025 -- could not have been more different. While I was in a parallel framework authors meeting for much of the morning,2 I did attend talks in the afternoon, studied the schedule, and went back through many more after the fact on the stream. Aside from Xuan Huang's talk on Lynx and Luca Mezzalira's talk on architecture, there was little in the program that challenged frameworkist dogma, and much that played to it. This matters because conferences succeed by foregrounding the hot topics within a community. Agendas are curated to reflect the tides of debate in the zeitgeist, and can be read as a map of the narratives a community's leaders wish to see debated. My da ## Safari at WWDC '25: The Ghost of Christmas Past DevFeed: [Safari at WWDC '25: The Ghost of Christmas Past]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-06-13T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [browsers](), [Web platform](), [browser]() Tags: [apple](), [browsers](), [competition](), [technical](), [webdev](), [wwdc]() ### AI overview The article reviews Safari features announced at Apple's WWDC 2025, arguing that most were already available in Chromium-based browsers. It identifies a smaller set of areas where Safari may lead, while discussing uncertainty around beta availability and Apple's browser-engine requirements on iOS in the EU. ### Source excerpt At Apple's annual developer marketing conference, the Safari team announced a sizeable set of features that will be available in a few months. Substantially all of them are already shipped in leading-edge browsers. Here's the list, prefixed by the year that these features shipped to stable in Chromium: 2023: WebGPU 2020: SVG Favicons 2023: HDR Images 2024: CSS Anchor Positioning 2023: CSS text-wrap: pretty 2025: CSS progress() function 2023: Scroll-driven Animations (finally!!!) 2020: Trusted Types 2021: URL Pattern API early 2025: WebAuthN Signal API 2020: WritableStreams for the File System APIs late 2023: Scroll Margin for Intersection Observers 2025: CSS Logical Overflow (overflow-block and overflow-inline) 2024: CSS align-self and justify-self in absolute positioning 2025: a subset of Explicit JavaScript Resource Management 2021: AudioEncoder & AudioDecoder for WebCodecs 2020: RTCEncodedAudioFrame & RTCEncodedVideoFrame serialisation 2024: RTCEncodedAudioFrame & RTCEncodedVideoFrame constructors 2018: PCM format support in MediaRecorder 2017: ImageCapture.grabFrame() 2017(?): SVG pointer-events="bounding-box" 2015: In many cases, these features were available to developers even earlier via the Origin Trials mechanism. WebGPU, e.g., ran trials for a year, allowing developers to try the in-development feature on live sites in Chrome and Edge as early as September 2021. There are features that Apple appears to be leading on in this release, but it's not clear that they will become available in Safari before Chromium-based browsers launch them, given that the announcement is about a beta: Digital Credentials API: currently in Chromium OT. CSS contrast-color() margin-trim: block inline extends a neat Safari-only feature in useful ways. Apple's ALAC format for MediaRecorder. Audio Output Devices API. In progress in Chromium, but no launch scheduled. The announced support for CSS image crossorigin() and referrerpolicy() modifiers has an unclear ## Why the author argues new web projects should avoid React DevFeed: [Why the author argues new web projects should avoid React]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-11-29T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [React](), [Front end](), [Framework](), [Web Development](), [legacy](), [CSS](), [HTML]() Tags: [accessibility](), [css](), [development](), [frameworkism](), [frontend](), [html](), [javascript](), [legacy](), [performance](), [react](), [web](), [webdev]() ### AI overview The article argues that React and other modern frontend frameworks can create performance and accessibility problems, especially in new web applications. It recommends minimizing client-side complexity and favoring HTML and CSS over JavaScript where practical. ### Source excerpt Over the past decade, my work has centred on partnering with teams to build ambitious products for the web across both desktop and mobile. This has provided a ring-side seat to a sweeping variety of teams, products, and technology stacks across more than 100 engagements. While I'd like to be spending most of this time working through improvements to web APIs, the majority of time spent with partners goes to remediating performance and accessibility issues caused by "modern" frontend frameworks and the culture surrounding them. Today, these issues are most pronounced in React-based stacks. This is disquieting because React is legacy technology, but it continues to appear in greenfield applications. Surprisingly, some continue to insist that React is "modern." Perhaps we can square the circle if we understand "modern" to apply to React in the way it applies to art. Neither demonstrate contemporary design and construction. They are not built for current needs and do not meet contemporary performance standards, but pose as expensive objets harkening back to an earlier era's antiquated methods. Contents The Rule Of Least Client-Side Complexity OK, But What, Then? And Nothing Of Value Was Lost Vignettes Informational E-Commerce Media Social Productivity Other Application Classes "But..." "...we need to move fast" "...it works for Facebook" "...our teams already know React" "...we need to be able to hire easily" "...everyone has fast phones now" "...React is industry-standard" "...the ecosystem..." "...Next.js can be fast (enough)" "...React Native!" References In the hope of steering the next team away from the rocks, I've found myself penning advocacy pieces and research into the state of play, as well as giving talks to alert managers and developers of the dangers of today's frontend orthodoxy. In short, nobody should start a new project in the 2020s based on React. Full stop.1 The Rule Of Least Client-Side Complexity Code that runs on the server can be fully costed. Pe ## Platform Strategy, JavaScript-First Development, and the Web's Mobile Constraints DevFeed: [Platform Strategy, JavaScript-First Development, and the Web's Mobile Constraints]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-10-27T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [JavaScript](), [Front end](), [Web Development](), [Development](), [Mobile](), [Web](), [React]() Tags: [browsers](), [competition](), [cost](), [development](), [ecosystems](), [frontend](), [javascript](), [legacy](), [mobile](), [performance](), [speed](), [strategy](), [web](), [web-developers](), [webdev]() ### AI overview The article argues that JavaScript-first frontend practices and desktop-oriented tools have contributed to increasingly costly failures to deliver usable web experiences on phones. It frames platform strategy around making the web easier, faster, and more secure for everyday tasks. ### Source excerpt This post is an edited and expanded version of a now-mangled Mastodon thread. Contents Platforms Are Competitions ...and We're Losing Win Condition You Do It To Yourself, And That's What Really Hurts Groundhog Day Reboot Some in the JavaScript community imagine that I harbour an irrational dislike of their tools when, in fact, I want nothing more than to stop thinking about them. Live-and-let-live is excellent guidance, and if it weren't for React et. al.'s predictably ruinous outcomes, the public side of my work wouldn't involve educating about the problems JS-first development has caused. But that's not what strategy demands, and strategy is my job.1 I've been holding my fire (and the confidences of consulting counterparties) for most of the last decade. Until this year, I only occasionally posted traces documenting the worsening rot. I fear this has only served to make things look better than they are. Over the past decade, my work helping teams deliver competitive PWAs gave me a front-row seat to a disturbing trend. The rate of failure to deliver usable experiences on phones was increasing over time, despite the eye-watering cost of JS-based stacks teams were reaching for. Worse and costlier is a bad combo, and the opposite of what competing ecosystems did. Native developers reset hard when moving from desktop to mobile, getting deeply in touch with the new constraints. Sure, developing a codebase multiple times is more expensive than the web's write-once-test-everywhere approach, but at least you got speed for the extra cost. That's not what web developers did. Contemporary frontend practice pretended that legacy-oriented, desktop-focused tools would perform fine in this new context, without ever checking if they did. When that didn't work, the toxic-positivity crowd blamed the messenger.2 Frontend's tragically timed turn towards JavaScript means the damage isn't limited to the public sector or "bad" developers. Some of the strongest engineers I know find thems ## How teams can improve web performance by putting users first DevFeed: [How teams can improve web performance by putting users first]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-08-16T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [JavaScript](), [Front end](), [Web Development](), [Testing](), [dashboards]() Tags: [dashboards](), [frameworks](), [frontend](), [javascript](), [performance](), [testing](), [web](), [webdev]() ### AI overview This opinion article argues that excessive JavaScript contributes to poor web experiences, especially on smartphones, and that performance problems result from organizational choices across the production chain. It recommends critical-user-journey analysis, end-to-end automated testing, performance metrics, and dashboards to improve outcomes. ### Source excerpt Other posts in the series: Reckoning: Part 1 -- The Landscape Reckoning: Part 2 -- Object Lesson Reckoning: Part 3 -- Caprock Frontend took ill with a bad case of JavaScript fever at the worst possible moment. The predictable consequence is a web that feels terrible most of the time, resulting in low and falling use of the web on smartphones.1 Public data shows what I warned about, citing Google-private data, in 2019. In the US, time spent in browsers continues to stagnate while smartphone use grows, and the situation is even more dire outside the states. The result is a falling fraction of time spent. This is not a recipe for a healthy web. If nothing changes, eventually, the web will become a footnote in the history of computing; a curio along side mainframes and minicomputers -- never truly gone but lingering with an ashen palour and a necrotic odour. We don't have to wait to see how this drama plays out to understand the very real consequences of JavaScript excess on users.2 Contents Managers Engineers and Designers Public Sector Agencies Values Matter Everyone in a site's production chain has agency to prevent disaster. Procurement leads, in-house IT staff, and the managers, PMs, and engineers working for contractors and subcontractors building the SNAP sites we examined all had voices that were more powerful than the users they under-served. Any of them could have acted to steer the ship away from the rocks. Unacceptable performance is the consequence of a chain of failures to put the user first. Breaking the chain usually requires just one insistent advocate. Disasters like BenefitsCal are not inevitable. The same failures play out in the commercial teams I sit with day-to-day. Failure is not a foregone conclusion, yet there's an endless queue of sites stuck in the same ditch, looking for help to pull themselves out. JavaScript overindulgence is always an affirmative decision, no matter how hard industry "thought leaders" gaslight us. Marketing that casts highly ## Why JavaScript Client-Side Architectures Hinder Public-Sector Service Sites DevFeed: [Why JavaScript Client-Side Architectures Hinder Public-Sector Service Sites]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-08-14T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [JavaScript](), [Web Development](), [Single-page application (SPA)](), [Architecture & Design](), [Front end](), [web applications]() Tags: [architecture](), [frontend](), [javascript](), [performance](), [public-sector](), [scalability](), [webdev]() ### AI overview This opinion article argues that JavaScript-heavy, client-side-rendered architectures make public-sector service sites more complex, expensive, and difficult to operate. It says slow networks and low-end devices amplify the performance costs for users, while HTML-first progressive enhancement can improve scalability. ### Source excerpt Other posts in the series: Reckoning: Part 1 -- The Landscape Reckoning: Part 2 -- Object Lesson Reckoning: Part 4 -- The Way Out Contents Complexity Perplexity Carrying Capacity Should This Be An SPA? The Pits Aftermath Last time, we looked at how JavaScript-based web development compounded serving errors on US public sector service sites, slowing down access to critical services. These defects are not without injury. The pain of accessing SNAP assistance services in California, Massachusetts, Maryland, Tennessee, New Jersey, and Indiana likely isn't dominated by the shocking performance of their frontends, but their glacial delivery isn't helping. Waits are a price that developers ask users to pay and loading spinners only buy so much time. Complexity Perplexity These SNAP application sites create hurdles to access because the departments procuring them made or green-lit inappropriate architecture choices. In fairness, those choices may have seemed reasonable given JavaScript-based development's capture of the industry. Betting on JavaScript-based, client-side rendered architectures leads to complex and expensive tools. Judging by the code delivered over the wire, neither CalSAWS nor Deloitte understand those technologies well enough to operate them proficiently. From long experience and a review of the metrics (pdf) the CalSAWS Joint Management Authority reports, it is plain as day that the level of organisational and cultural sophistication required to deploy a complex JavaScript frontend is missing in Sacramento: Dora Militaru | Performance culture through the looking-glass It's safe to assume a version of the same story played out in Annapolis, Nashville, Boston, Trenton, and Indianapolis. JavaScript-based UIs are fundamentally more challenging to own and operate because the limiting factors on their success are outside the data center and not under the control of procuring teams. The slow, flaky networks and low-end devices that users bring to the party define t ## BenefitsCal's Performance Problems Compared with getcalfresh.org DevFeed: [BenefitsCal's Performance Problems Compared with getcalfresh.org]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-08-13T00:00:00Z Content type: article Language: en Sources: [Alex Russell]() Topics: [Web Development](), [Core Web Vitals](), [JavaScript](), [Latency](), [Chromium](), [Compression](), [Caching](), [configuration]() Tags: [caching](), [compression](), [configuration](), [core-web-vitals](), [javascript](), [latency](), [performance](), [web](), [webdev]() ### AI overview The article compares California's BenefitsCal public benefits portal with Code for America's getcalfresh.org. It argues that BenefitsCal delivers a substantially slower experience, with excessive JavaScript, multiple loading screens, and configuration problems, while getcalfresh.org uses a simpler HTML-first architecture and becomes interactive sooner. ### Source excerpt Other posts in the series: Reckoning: Part 1 -- The Landscape Reckoning: Part 3 -- Caprock Reckoning: Part 4 -- The Way Out Contents The Golden Wait The Truth Is In The Trace Zip It Near Peers Blimey JavaScript Masshattery Maryland Enters The Chat Chattanooga Chug Chug SNAP? In Jersey? Fuhgeddaboudit Hoosier Hospitality Deep Breaths The Golden Wait BenefitsCal is the state of California's recently developed portal for families that need to access SNAP benefits (née "food stamps"):1 BenefitsCal loading on a low-end device over a 9Mbps link with 170ms RTT latency via WebPageTest.org Code for America's getcalfresh.org performs substantially the same function, providing a cleaner, faster, and easier-to-use alternative to California county and state benefits applications systems: getcalfresh.org loading under the same conditions The like-for-like, same-state comparison getcalfresh.org provides is unique. Few public sector services in the US have competing interfaces, and only Code for America was motivated to build one for SNAP applications. getcalfresh.org finishes in 1/3 the time, becoming interactive not long after the BenefitsCal loading screen appears. WebPageTest.org timelines document a painful progression. Users can begin to interact with getcalfresh.org before the first (of three) BenefitsCal loading screens finish (scroll right to advance): & & Google's Core Web Vitals data backs up test bench assessments. Real-world users are having a challenging time accessing the site: BenefitsCal is a poor experience on real phones. But wait! There's more. It's even worse than it looks. The multi-loading-screen structure of BenefitsCal fakes out Chrome's heuristic for when to record Largest Contentful Paint. On low-end devices, BenefitsCal appears to almost load at the 22 second mark, only to put up a second loading screen shortly after. Because this takes so long, Chromium's heuristics for Largest Contentful Paint are thrown off, incorrectly reporting the end of the first loa ## How JavaScript-First Frontend Practices Struggled with the Mobile Web DevFeed: [How JavaScript-First Frontend Practices Struggled with the Mobile Web]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-08-12T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Front end](), [JavaScript](), [Mobile](), [Web Development](), [Chrome](), [WebView](), [Chromium]() Tags: [chrome](), [chromium](), [frontend](), [javascript](), [mobile](), [performance](), [webdev](), [webview]() ### AI overview This first part of a four-part investigation examines how JavaScript-first frontend culture developed alongside the mobile web. It describes browser development for Android, the challenges of Chromium's memory-hungry multi-process sandboxing, and the introduction of PWAs and Push Notifications, then argues that desktop-oriented JavaScript frameworks brought unnecessary bloat to mobile-first projects. ### Source excerpt Instead of an omnibus mega-post, this investigation into JavaScript-first frontend culture and how it broke US public services has been released in four parts. Other posts in the series: Reckoning: Part 2 -- Object Lesson Reckoning: Part 3 -- Caprock Reckoning: Part 4 -- The Way Out When you live in the shadow of a slow-moving crisis, it's natural to tell people about it. At volume. Doubly so when engineers can cheaply and easily address the root causes with minor tweaks. As things worsen, it's also hard not to build empathy for Cassandra. In late 2011, I moved to London, where the Chrome team was beginning to build Google's first "real" browser for Android.1 The system default Android Browser had, up until that point, been based on the system WebView, locking its rate of progress to the glacial pace of device replacement.2 In a world where the Nexus 4's 2GB of RAM and 32-bit, 4-core CPU were the high-end, the memory savings the Android Browser achieved by reusing WebView code mattered immensely.3 Those limits presented enormous challenges for Chromium's safer (but memory-hungry) multi-process sandboxing. Android wasn't just spicy Linux; it was an entirely new ballgame. Even then, it was clear the iPhone wasn't a fluke. Mobile was clearly on track to be the dominant form-factor, and we needed to adapt. Fast.4 Browsers made that turn, and by 2014, we had made enough progress to consider how the web could participate in mobile's app-based model. This work culminated in 2015's introduction of PWAs and Push Notifications. Disturbing patterns emerged as we worked with folks building on this new platform. A surprisingly high fraction of them brought slow, desktop-oriented JavaScript frameworks with them to the mobile web. These modern, mobile-first projects neither needed nor could afford the extra bloat frameworks included to paper over the problems of legacy desktop browsers. Web developers needed to adapt the way browser developers had, but consistently failed to hit the ## Third-Party Cookies, Single Sign-On, and the Limits of Browser Privacy Interventions DevFeed: [Third-Party Cookies, Single Sign-On, and the Limits of Browser Privacy Interventions]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-07-30T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Cookies](), [Web](), [Single sign-on (SSO)](), [W3C](), [browsers](), [Google]() Tags: [browsers](), [cookies](), [google](), [identity](), [privacy](), [sso](), [w3c](), [web](), [webdev]() ### AI overview This commentary critiques the W3C Technical Architecture Group's response to Google's decision not to imminently remove third-party cookies. It argues that the response underplays both the limited benefits of cookie removal and the unresolved effects on Single Sign-On, sign-in flows, advertising, and user tracking. ### Source excerpt The W3C Technical Architecture Group1 is out with a blog post and an updated Finding regarding Google's recent announcement that it will not be imminently removing third-party cookies. The current TAG members are competent technologists who have a long history of nuanced advice that looks past the shouting to get at the technical bedrock of complex situations. The TAG also plays a uniquely helpful role in boiling down the guidance it issues into actionable principles that developers can easily follow. All of which makes these pronouncements seem like weak tea. To grok why, we need to walk through the threat model, look at the technology options, and try to understand the limits of technical interventions. Contents Unmasking The Problem Fire And Movement Finding A Way Forward But before that, I should stipulate my personal position on third-party cookies: they aren't great! They should be removed from browsers when replacements are good and ready, and Google's climbdown isn't helpful. That said, we have seen nothing of the hinted-at alternatives, so the jury's out on what the impact will be in practice.2 So why am I dissapointed in the TAG, given that my position is essentially what they wrote? Because it failed to acknowledge the limited and contingent upside of removing third-party cookies, or the thorny issues we're left with after they're gone. Unmasking The Problem So, what do third-party cookies do? And how do they relate to the privacy theat model? Like a lot of web technology, third-party cookies have both positive and negative uses. Owing to a historcal lack of platform-level identity APIs, they form the backbone of nearly every large Single Sign-On (SSO) system. Thankfully, replacements have been developed and are being iterated on. Unfortunately, some browsers have unilaterally removed them without developing such replacements, disrupting sign-in flows across the web, harming users and pushing businesses toward native mobile apps. That's bad, as native app ## Why Browsers Get Built DevFeed: [Why Browsers Get Built]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-03-10T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [browsers](), [Web platform]() Tags: [browsers](), [competition](), [platform](), [strategy](), [web-developers](), [web-platform](), [webdev]() ### AI overview The article presents two-and-a-half reasons for building a browser and proposes ways to distinguish them. It argues that browser-building strategies differ by their relationship to operating systems, team composition, and whether the browser serves a broader web-platform strategy or another agenda. ### Source excerpt There are only two-and-a-half reasons to build a browser, and they couldn't be more different in intent and outcome, even when they look superficially similar. Learning to tell the difference is helpful for browser project managers and engineers, but also working web developers who struggle to develop theories of change for affecting browser teams. Like Platform Adjacency Theory and The Core Web Platform Loop, this post started1 as a set of framing devices that I've been sketching on whiteboards for the best part of a decade. These lenses aren't perfect, but they provide starting points for thinking about the complex dynamics of browsers, OSes, "native" platforms, and the standards-based web platform. Contents Web As Platform Distinguishing Traits The OS Agenda Browsers as Bridges Browsers as Moats Tipping Points Distinguishing Traits Searchbox Pirates Distinguishing Traits Implications The reasons to build browsers are most easily distinguished by the OSes they support and the size and composition of their teams ("platform" vs. "product"). Even so, there are subtleties that throw casual observers for a loop. In industrial-scale engineering projects like browser construction, headcount is destiny, but it isn't the whole story. Web As Platform This is simultaneously the simplest and most vexing reason to build a browser. Under this logic, browsers are strategically important to a broader business, and investments in platforms are investments in their future competitiveness compared with other platforms, not just other browsers. But none of those investments come good until the project has massive scale. This strategy is exemplified by the ambitions of Netscape, crisply captured by Andreesen's quip that the goal was to render Windows "a poorly debugged set of device drivers". The idea is that the web is where the action is, and that the browser winning more user Jobs To Be Done follows from increasing the web platform's capability. This developer-enabling flywheel aim [Next page]()