Reading List

The most recent articles from a list of feeds I subscribe to.

Put Names and Dates On Documents

Infrequently Noted

Anyone who has worked closely with me, or followed on social media [, ], will have seen a post or comment to the effect of:

Names and dates on docs. Every time. Don't forget.

This is most often tacked onto design documents lacking inline attribution, and is phrased provocatively to make it sticky.

Why do I care enough about this to be prescriptive — bordering on pushy — when colleagues accuse me of being Socratic to a fault about everything else? Because not only is unattributed writing a reliable time-waster, the careers of authors hang in the balance.

Having to work to find the best person to discuss a topic with is annoying, but in large organisations, the probability of authors having work appropriated without credit goes up when they fail to claim ownership of their writing. It should go without saying that this is toxic, and that functional engineering cultures look harshly on it. But to ward off bad behaviour, it helps to model what's healthy.

The best reminder to cite work is for authors to name themselves. Doing this increases their stature, unsubtly encourages others to link and cite, and leaves a trail of evidence for authors to reference when building a case for promotion.

The importance of evidence to support claims of design work in technical fields cannot be overstated. Having served on hiring and promotion committees for many years, I can unequivocally say that this collateral is often pivotal. The difference between "[x] promote" and "[x] do not promote" often comes down to the names on documents. Reviewers will pay attention to both the authors list and the propensity of design doc authors to cite others.1

In response to unsubtle nudges, several recurring arguments are offered against explicit authorship notices.

This is fair, but does not outweigh the needs of future readers who may be working to trace a chain of events or ideas. Nor does it outweigh the needs of authors for credit regarding their work at a future date.

This crutch fails in any number of ways:

  • PDFs and printed copies do not include authorship data that is not in body text.
  • Some systems (e.g. Google Docs) do not make the history available to non-editors.
  • Documents may be copied or re-published in ways that disconnect the content from the original revision tracking system; e.g., in a systems transition as part of an acquisition.

Moreover, design is a complex and collaborative process. Ideas and concepts captured in documents are not always the contribution of the person writing down the conclusions of a whiteboarding session. A clear, consistent way to give credit helps everyone feel included and encourages future collaboration.

This is usually offered as a claim of superfluousness. If everyone knows everything and everyone working in a system, why does attribution matter?

Perhaps a team is small now, but will it always be? I am not in a position to tell, and my interlocutors also lack crystal balls. Given the downside risks, attribution is a pittance of an insurance premium.

This is easily countered with invitations in comments and drafts for contributors to add themselves to the authorship section. Generous and collaborative folks — the sorts of people we want to promote — reliably add their collaborators to documents proactively and set the expectation that others will do the same. Over time, practice becomes habit, which crystallises into culture.

A final concern I hear is that these blocks require a great deal of upkeep. Long-form revision logs might be onerous, but the minimum viable attribution style only needs three elements: names, emails, and dates. These should be provided on the very first page, ideally just below the title.

The primary date always refers first drafting, even if that is before publication. If deemed necessary, authors can optionally add a "Last Updated" field below the primary date, but this is optional. Documents authored in a single sitting by a lone author should avoid extra visual noise.

Revision logs are generally unnecessary, and my personal view is that they distract from content; if they're a requirement (e.g., in a heavily regulated industry), record them in an Appendix, but do not remove minimum viable attributions.

Here's a screenshot of an explainer I helped draft many years ago showing the basic form2:

Minimum Viable Attribution in a Markdown document.
Minimum Viable Attribution in a Markdown document.

If a document is still an early draft, it can be helpful to put some indication in the title — I use a prefix like "[ Draft ] ..." — and invite collaborators to add themselves to the authors list by including an entry there of the form "Your Name <your_email@example.com>". Once a document is circulated widely, remove these inline markers.

Thanks to Andy Luhrs for his feedback on drafts of this post.

FOOTNOTES

  1. If you write technical design docs, it is always a good sign if you cite prior work and parallel efforts, including competing designs. Omitting those references is something that both technical and promotion reviewers are alert to and are primed to think poorly of. No design is entirely new, and it is a sign of maturity to give others their due. ⇐

  2. Don't worry, all of these email addresses are now inactive.

    On the question of emails and spam in authoring public documents, views are split. I favour always using them, but understand if authors prefer other sorts of contact information; e.g., their personal website. Best not to be too fussy about this sort of thing, except to ensure that internal documents always contain email addresses. ⇐

How Do Committees Fail To Invent?

Infrequently Noted

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.

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 where alignment is at least partially top-down, the ability of any firm to join an SDO practically invites subterfuge. This plays out calamitously when representatives of pivotal firms obfuscate their willingness to implement, or endlessly delay consideration of important designs.

Open membership alone would not lead to crisis, except that certain working groups adopt rules or norms that create an explosion of veto players.

These veto-happy environments combine with bad information to transmute opaque communication into arterial blockage. SDO torpidity, in turn, colours the perception of web developers against standards. And who's to say they're wrong? Bemoaning phlegmatic working groups is only so cathartic.

Eventually, code must ship, and if important features are missing from standards-based platforms, it becomes inevitable that developers will decamp to proprietary solutions.

Instances of the fifth column problem are frequently raised to me by engineers working in these groups. "How," they ask, "can large gatherings of engineers meet regularly, accomplish next-to-nothing, yet continue pat themselves on the back?"

The sad answer is "quite easily."

This dynamic has recurred with surprising regularity over the web's history,1 and preventing it from clogging the works is critical to the good order of the entire system.

The primary mechanism that produces consequential fifth column episodes is internal competition within tech giants.

Because the web is a platform, and because platforms are competitions, it's natural that companies that make both browsers and proprietary platforms favour their owned-and-operated offerings.

The rent extraction opportunities from controlling OS APIs are much more lucrative than an open ecosystem's direct competition. Decisions about closed platforms also do not have to consider other players as potential collaborators. Strategically speaking, managing a proprietary platform is playing on easy mode. When that isn't possible, the web can provide a powerful bridge to the temporarily embarrassed monopolist, but that is never their preference.

This competition is often hard to see because the decisive battles between proprietary systems and open platforms are fought behind the tallest, most heavily guarded walls of tech giants: budget planning.

Because budgets are secret, news of the web losing status is also a secret. It's a firing offence to leak budget details, or even share internally to those without a need to know, so line engineers may never be explicitly told that their mission has fundamentally changed. They can experience transitions away from the web as "Plan A" to "Plan Z" without their day-to-day changing much. The team just stops growing, and different types of features get priority.

OS vendors that walk away from the web after it has served their businesses can simply freeze browser teams, trimming ambitions around the edges without even telling the team that their status has been lowered. Capping and diverting funding away from new capabilities is easily explained; iteration on existing, non-threatening features is important, after all, and there are always benchmarks to optimise for.

Most fifth columnists are, therefore, unwitting and unknowing accomplices to corporate machinations well above their own pay grades. They cannot acknowledge that a vibrant web is not valuable to their firm because they will have never been told as much, and should they enquire, will hear only that the important work they are doing continues to be valued.

Until recently, the impact of fifth column tactics was obscured in a haze of legacy engines. Web developers take universality seriously, so improvements in capabilities have historically been experienced as the rate at which legacy UAs fall below a nominal relevance threshold.2 Thanks to pervasive auto-updates, the historical problem of dead-code-walking has largely been resolved. Major versions of important browsers may have entire cradle-to-grave lifecycles on the order of two or three months, rather than IE 6's half-decade half-life.

This has clarified the impact of (dis)investments by certain vendors and makes fifth columnists easier to spot. Web developers now benefit from, or are held back by, recent decisions by the companies (under)funding browser development. If sites remain unable to use features launched in leading-edge engines, it's only because of deficiencies in recent versions of competing engines. This is a much easier gap to close — in theory, anyway.

Web standards are voluntary, and the legal structures that create SDO safe-harbours (PDF) create the space in, and rules under, which SDOs must operate. SDOs may find their designs written into legislation after the fact, or as implementation guides, but there is a strong aversion to being told what to design by governments within the web community, particularly among implementers. Some new participants in standards arrive with the expectation that the de jure nature of a formal standard creates a requirement for implementation, but nothing could be further from fact. This sometimes leads to great frustration. Enshrining a design in a ratified standard does not obligate anyone to do anything, and many volumes of pure specifiction have been issued to little effect.

The voluntary nature of web standards is based on the autonomy of browsers, servers, and web developers to implement whatever they please under own brand.

Until Apple's flagrantly anticompetitive iOS policies, this right was inviolable because, when compromised, erosions of feature sovereignty undermine the premise of SDOs.

When products lose the ability to differentiate on features, quality, performance, safety, and standards conformance, the market logic underpinning voluntary standards becomes a dead letter. There's no reason to propose an improvement to the collective body of the web when another party can prevent you from winning share by supporting that feature.

The harms of implementation compellence are proportional to market influence. iOS's monopoly on the pockets of the wealthy (read: influential) has decisively undermined the logic of the open internet and the browser market. Not coincidentally, this has also desolated the prospect of a thriving mobile web.

The Mobile Web: MIA

It's no exaggeration to say that it is anti-web to constrain which standards vendors can implement within their browsers, and implementation coercion is antithetical to the good functioning of SDOs and the broader web ecosystem.3

In a perverse way, Apple's policy predations, strategic under-investment, and abusive incompetence clarify the basic terms of the web's power structure: SDOs are downstream of browser competition, and browser competition depends on open operating systems.

Why do vendors spend time and money to work in standards, only to give away their IP in the form of patent licences covering ratified documents?

When vendors enjoy product autonomy, they develop standards to increase interoperability at the behest of customers who dislike lock-in. Standards also lower vendor's legal risk through joint licensing, and increase marketability of their products. Behind this nondescript summary often lies a furious battle for market share between bitter competitors, and standards development is famous for playing a subtle role. Shapiro and Varian's classic paper "The Art of Standards Wars" (PDF) is a quarter-century old now, but its description of these sorts of battles is no less relevant today that it was in '99.

Like this classic, most discussions of standards battles highlight parties with differing visions but similar goals — should margin-sizing or border-sizing be the default? — rather than situations where one vendor has a proprietary agenda and wishes to grow or maintain a capability gap versus standards-based alternatives. Denying features to open ecosystems makes high-tax proprietary platforms more attractive, and gridlock in standards is an effective strategy for accomplishing it. These cases are under-discussed, in part, because they're hard to perceive over short time periods or by observing a single working group.

Parties that maintain a footprint in standards, but are unhappy to see standards-based platforms compete with their proprietary offerings, only need a few pages from the Simple Sabotage manual (PDF).

Often, they will send delegates to important groups and take visible leadership positions. Combined with juuuuuust enough constructive technical engagement, obstreperous parties scarcely have to say anything about their intent. Others will raise their own hopes, and cite (tepid) participation as evidence of good faith. The fifth columnist doesn't need to raise a finger, which is handy, as doing nothing is the goal.4

Working group composition also favours delays at the hands of fifth columnists. Encouraged by defectors, they regularly divert focus from important problems, instead spending huge amounts of time on trivialities because few customers (web developers) have the time, money, and energy to represent their own needs in committee. Without those voices, it's hard to keep things on track.

Worse, web developers generally lack an understanding of browser implementation details and don't intone the linguistic airs and shorthands of committeespeak, which vary from venue to venue. This hampers their ability to be taken seriously if they do attend. At the limit, dismissing pressing problems on technicalities can become something of a committee pastime.5

There's also a great deal of opportunity for fifth columnists to misrepresent the clearly stated needs of web developers, launching projects to solve adjacent (but unimportant) sub-issues, while failing to address the issues of the day. This is particularly problematic in big, old rooms.

A competent fifth columnist only needs to signal in-group membership to amplify the impact of their own disinterest in topics they would prefer to avoid. Ambiguous "concerns" and scary sounding caveats are raised, and oven-ready designs which do arrive are reframed as naive proposals by outsiders. Process-level critique, in lieu of discussing substance, is the final line of defence.

Deflecting important work is shockingly easy to pull off because organisations that wish to defeat progress can send delegates that can appeal to rooms full of C++/Rust engineers as peers. The tripwires in web API design are not obvious to the uninitiated, so it's easy to move entire areas of design off the agenda through critique of small details.

The most depressing thing about this pattern is that these tactics work because other vendors allow it.

One problem facing new areas in standards is that chartered Working Groups are just that: chartered. They have to define what they will deliver years in advance, and anything not on the agenda is, by definition, not in scope. The window in many SDO processes for putting something new into the hopper is both short and biased towards small revisions of the existing features. Spinning up new Working Groups is a huge effort that requires political clout.

Technically, this is a feature of SDOs; they jointly licence the IP of members to reduce risks to implementers and customers of adopting standards-based products. Patent trolls have to consider the mutual defences of the whole group's membership and cannot easily pick off smaller prey. Most developers never give a second thought to patent portfolios and do not live in fear of being personally sued for infringement.

This is a sign web standards are a smashing success, but also makes it unlikely that working developers understand that standards processes are designed with bounded IP commitments in mind. Internet SDOs have been so successful at caging the beast that generations of developers have never considered the threat or how it intersects with their interests.

This creates a tension: over the long term, SDOs and the ecosystems can only succeed if they take on new problems that are adjacent to the current set, but the Working Groups they create are primed by their composition and history to avoid taking on substantial expansions of their scope. After all, a good v2 of a spec is one that fixes all the problems of v1 and introduces relatively few new ones.

To work around this restriction, functional SDOs create incubation venues. These take different guises, but the core features are the same. Unlike chartered Working Groups, incubation groups are simple to create; no charter votes or large, up-front IP commitments. They also feature low bars to participation, can be easily shut down, and do not produce documents for formal standardisation, although they can produce "Notes" or other specification documents that Working Groups can take up.

Instead, they tend to have substantial contributor-only grants of IP, ad-hoc meeting and internal debate mechanisms, and attract only those interested in working on solutions in a new problem space. In functioning SDOs, such "fail-fast" groups naturally become feeders for chartered Working Groups, iterating on problems and solutions at a rate which is not possible under the plodding bureaucracy of a chartered Working Groups's minuted and agenda-driven meeting cadence.

And that's why these sorts of groups are a first priority for sabotage by fifth columnists. The usual tactics deployed to subvert incubation include:

  • Aspersions of bad faith by those working in incubation venues, either on the grounds that the groups are "amateur", "not standards-track",6 or "do not have the right people."
  • Avoidance of engagement in incubation groups, robbing them of timely feedback while creating a self-fulfilling "lack of expertise" critique.
  • Citing a high fraction failed designs within these groups as an indicator that they are not useful, obscuring the reality that the entire point of incubation is to fail fast and iterate furiously.7
  • Accuse those who implement incubated proposals of "not following the process", "ignoring standards", or "shipping whatever they want"; twisting the goals of those doing design in the open, in good faith, under the SDO's IP umbrella.
  • Demanding formalities akin to chartered Working Groups to slow the pace of design progress in incubation venues that are too successful to ignore.

The fifth columnist also works behind the scenes to reduce the standing and reputation of incubation groups among the SDO's grandees, claiming that they represent a threat to the stability of the overall organisation. Because that constituency is largely divorced from the sausage-making, this sort of treachery works more often than it should, causing those who want to solve problems to burn time defending the existence of venues where real progress is being made.

The picture presented this far is of Working Groups meeting in The Upside Down. After all, it's only web developers who can provide a real test of a design, or even the legitimacy of a problem.

This problem becomes endemic in many groups, and entire SDOs can become captured by the internal dramas and preferences of implementers, effectively locking customers out. Without more dynamic, fail-fast forums that enable coalitions of the willing to design and ship around obstructionists, working groups can lay exclusive claim to important technologies and retreat into irrelevance without paying a reputational cost.

The alternative — hard forking specifications — is a nuclear option. The fallout can easily blow back into the camp of those launching a fork, and the effort involved is stupendous. Given the limited near-term upside and unclear results, few are brave or foolish enough to consider forking to route around a single intransigent party.

This feeds the eclipse of an SDO's relevance because legitimacy deficits become toxic to the host only slowly. Risk of obsolescence can creep unnoticed until it's too late. As long as the ancient forms and traditions are followed, a decade or more can pass before the fecklessness of an important group rises to the notice of anyone with the power to provoke change. All the while, external observers will wonder why they must resort to increasingly tall piles of workarounds and transpilers. Some may even come to view deadening stasis, incompatibility, and waste as the natural state of affairs, declining to invest any further hope for change in the work of SDOs. At this point, the fifth columnist has won.

One of the self-renewing arrows in the fifth column's quiver is the tendency of large and old working groups to indulge in survivorship bias.

Logically, there's no reason why folks whose designs won a lottery in the last round of market jousting8 should be gatekeepers regarding the next tranche of features. Proposing winning designs in the past is not, in itself, a reliable credential. And yet, many of these folks become embedded within working groups, sometimes for decades, holding sway by dint of years of service and interpersonal capital. Experience can be helpful, but only when it is directed to constructive engagement, and too many group chairs allow bad behaviour, verging on incivility, at the hands of la vieille garde. This, of course, actively discourages new and important work, and instead clears the ground for yet more navel-gazing.

This sort of in-group/out-group formation is natural in some sense, and even folks who have loathed each other from across a succession of identically drab conference rooms for years can find a sort of camaraderie in it. But the social lives of habitual TPAC and TC39 attendees are no reason to accept unproductive monopolies on progress; particularly when the folks in those rooms become unwitting dupes of fifth columnists, defending the honour of the group against those assailing it for not doing enough.

The dysfunctions of this dynamic mirrors those of lightly moderated email lists: small rooms of people all trying to solve the same problem can be incredibly productive, no matter how open. Large rooms with high alignment of aims can make progress if leadership is evident (e.g., strong moderation). What is reliably toxic are large, open rooms with a mix of "old timers" who are never moderated and "newbies" who have no social standing. Without either a clear destination or any effective means of making decisions, these sorts of venues become vitriolic over even the slightest things. As applied to working groups, without healthy norms and strong chairing, interpersonal dynamics of long-standing groups can make a mockery of the responsibilities documented in a charter. But it's unusual for anyone on the outside to get any the wiser. Who has time to decipher meeting minutes or decode in-group shorthands?

And so it is precisely because fifth columnists can hire old timers9 that they are able to pivot groups away from addressing pressing concerns to the majority of the ecosystem, particularly in the absence of functional incubation venues challenging sclerotic groups to move faster.

One useful lens for discussing the fifth column problem is the now-common Political Science analysis of systems through "veto points" or "veto players" (Tsebelis, '95; PDF):

Policy stability is different from both government stability and regime stability. In fact ... they are inversely related: policy stability causes government or regime instability. This analysis is based on the concept of the veto player in different institutional settings.

If we substitute "capability stability" for "policy stability" and "platform relevance" for "government/regime stability," the situation becomes clear:

Capability stability is different from platform relevance. In fact ... they are inversely related: capability stability causes platform irrelevance.

Any platform that cannot grow to incorporate new capabilities, or change to address pressing problems, eventually suffers irrelevance, then collapse. And the availability of veto points to players entirely hostile to the success of the platform is, therefore, an existential risk10 — both to the platform and to the SDOs that standardise it, not to mention the careers of developers invested in the platform.

This isn't hard to understand, so how does the enterprising fifth columnist cover their tracks? By claiming that they are not opposed to proposals, but that they "need work," without either offering to do that work, develop counter-proposals, or make any commitment to ship any version of proposals in their own products. This works too often because a pattern of practice must develop before participants can see that blockage is not a one-off rant by a passionate engineer.

Participants are given wide berths, both because of the presumption of voluntarity implementations,11 and the social attitudes of standards-inclined developers. Most SDO participants are community-minded and collaboration-oriented. It's troubling to imagine that someone would show up to such a gathering without an intent to work to solve problems, as that would amount to bad faith. But it has recurred frequently enough that we must accept it does happen. Having accepted its possibility, we must learn to spot the signs, remain on guard, and call it out as evidence accumulates.

The meta-goal is to ensure no action for developers, with delay to the point of irrelevance as a fallback position, so it is essential to the veto wielder that this delay be viewed as desirable in some other dimension. If this sounds similar to "but neighbourhood character!" arguments by NIMBYs offer, that's no accident. Without a valid argument to forestall efforts to solve pressing problems, the fifth column must appeal to latent, second-order values that are generally accepted by the assembled to pre-empt the first-order concern. This works a shocking fraction of the time.

It works all the better in committees with a strong internal identity. It's much easier to claim that external developers demanding solutions "just don't get it" when the group already views their role as self-styled bulwarks against bad ideas.

The final, most pernicious, building block of Working Group decay is the introduction of easy vetoes via consensus decision-making. When vetoes are available to anyone in a large group at many points, the set of proposals that can be offered without a presumption of failure shrinks to a tiny set, in line with the findings of Tsebelis.

This is not a new problem in standards development, but the language gets muddy. I perceive two distinct versions:

  • Strong Consensus refers to working modes in which the assent of every participant is affirmatively required to move proposals forward.
  • Weak Consensus are modes in which preferences are polled, but "the sense of the room" can carry a proposal forward over even strenuous objections by small minorities.

Every long-term functional SDO operates by some version of Weak Consensus. The IETF bandies this about so often that the phrase "rough consensus and running code" is synonymous with the organisation.

But not every group within these SDOs are chaired by folks willing to overrule objectors. In these situations, groups can revert to de facto strong consensus, which greatly multiplies the number of veto holders. Variations on this theme can be even less disciplined, with only an old guard having effective veto power, whilst newer participants may be more easily overturned.

Strong consensus is the camel's nose for long-term gridlock. Like unmoderated mailing lists, things can spiral without anyone quite knowing where the error was made. Small groups can start under strong consensus out of a sense of mutual respect, only to find it is nearly impossible to revoke a veto power once handed out. A sense of fair play may cause this right to be extended to each new participant, and as groups grow, affiliations change, and interests naturally diverge, it may belatedly dawn on those interested in progress that the very rooms where they once had so much luck driving things forward have become utterly dysfunctional. And under identical rules!

Having found the group no longer functions, delegates who have invested large portions of their careers to these spaces have a choice: they can acknowledge that it is not working and demand change, becoming incredibly unpopular amongst their closest peers in the process. Or they can keep their heads down and hope for the best, defending the honour of the group against attacks by "outsiders". Don't they know whose these people are?

Once it sets in, strong consensus modes are devilish to unpick, often requiring a changing of the guard, both among group chairs and influential veto-wielders. Groups can lose internal cohesion and technical expertise in the process, heaping disincentive to rock even the most unproductive boats.

The ways that web ecosystem SDOs and their participants can guard against embrittlement and fracture from the leeching effects of fifth columns are straightforward, if difficult to pull off socially:

  • Seek out and remove strong consensus processes.

    The timeless wisdom of weak consensus is generally prescribed by process documents governing SDOs, so the usual challenge is enforcement. The difficulty in shaking strong consensus practices is frequently compounded by the status of influential individuals from important working groups who prefer it. Regardless, the consequences of allowing strong consensus to fester in rooms big enough to justify chairing is dire, and it must be eliminated root and branch.

  • Aggressively encourage "counterproposal or GTFO" culture.

    Fifth columnists thrive in creating ambiguity for the prospects of meaningful proposals while paying no cost for "just asking questions." This should be actively discouraged, particularly among implementers, within the social compact of web SDOs. The price for imposing delay must be higher than having vague "concerns".

  • Require Working Groups to list incubators they accept proposals from. Require they prove it.

    Many groups that fifth columnists exploit demonstrate a relative imperviousness to new ideas through a combination of social norms and studious ignorance. To break this pattern, SDOs should require all re-charters include clear evidence of proposals coming from outside the group itself. Without such collateral, charters should be at risk.

  • Defend incubators from process attacks.

    Far from being sideshows, incubation venues are the lifeblood of vibrant SDOs. They must be encouraged, nurtured, and highlighted to the membership as essential to the success of the ecosystem and the organisation.

    In the same vein, process shenanigans to destabilise successful incubators must be fended off; including but not limited to making them harder to join or create, efforts to deny their work products a seat in working group chartering, or tactics that make their internal operations more veto-centric.

It takes a long time, but like the gravitational effects of a wandering planet out in the OORT cloud, the informational content of the fifth columnist's agenda eventually becomes legible by side effect. Because an anti-web agenda is easy to pass off under other cover, it requires a great number of observations to understand that this part of the committee does not want the platform to evolve. From that point forward, it becomes easier to understand the information being communicated as noise, rather than signal.

Once demonstrated, we must route around the damage, raising the cost of efforts to undermine the single most successful standards-based ecosystem of our lifetimes; one that I believe is worth defending from insider threats as well as external attack.

FOOTNOTES

  1. The most substantial periods of institutional decrepitude in web standards are highly correlated with veto players (vendors with more than ~10% total share) walking away from efforts to push the web forward.

    The most famous period of SDO decay is probably the W3C's troubled period after Microsoft disbanded the Internet Explorer team after IE 6.0's triumphant release in 2001. Even if folks from Microsoft continued to go to meetings, there was nobody left to implement new or different designs and no product to launch them in.

    Standards debate went from pitched battles over essential features of systems being actively developed to creative writing contests about futures it might be nice to have. Without the disciplining function of vendors shipping, working groups just become expensive and drab pantomimes.

    With Microsoft circa 2002 casting the IE team to the wind and pivoting hard to XAML and proprietary, Windows-centric technologies, along with the collapse of Netscape, the W3C was left rudderless, allowing it to drift into failed XHTML escapades that inspired revulsion among the remaining staffed engine projects.

    This all came to a head over proposed future directions at 2004's Web Applications and Compound Document Workshop. WHATWG was founded in the explosion's crater, and the rest is (contested) history.

    The seeds of the next failure epoch were planted at the launch of the iOS App Store in 2008, where it first became clear that other "browsers" would be allowed on Cupertino's best-selling devices, but not if they included their own engines. Unlike the big-bang of Microsoft walking away from browsers for 3+ years, Apple's undermining of the W3C, IETF, and ECMA become visible only gradually as the total global market share of mobile devices accelerated. Apple also "lost" its early lead in the smartphone market share as Android ate up the low end's explosive growth. The result was a two-track mobile universe, where Apple retained nearly all influence and profits, whilst most new smartphone users encountered the predations of Samsung, HTC, LG, Xiaomi, and a hundred other cut-price brands.

    Apple's internal debates about which platform for iOS was going to "win" may have been unsettled at the launch of the App Store13, but shortly thereafter the fate of Safari and the web on iOS was sealed when Push Notifications appeared for native apps but not web apps.

    Cupertino leveraged its monopoly on influence to destroy the web's chances, while Mozilla, Google, and others who should have spoken up remained silent. Whether that cowardice was borne of fear, hope, or ignorance hardly matters now. The price of silence is now plain, and the web so weakened that it may succumb entirely to the next threat; after all, it has no champions among the megacorps that have built their businesses on its back.

    First among equals, Apple remains at the vanguard of efforts to suppress the web, spending vast sums to mislead web developers, regulators, legislators, and civil society. That last group uncomfortably includes SDOs, and it's horrifying to see the gaslighting plan work while, in parallel, Cupertino sues for delay and offers easily disproven nonsense in rooms where knowing misrepresentation should carry sanction.

    All this to preclude a competent version of the web on iPhones, either from Apple or (horrors!) from anyone else. Query why. ⇐

  2. The market share at which any browser obtains "blocking share" is not well theorized, but is demonstrably below 5% for previously dominant players, and perhaps higher for browsers or brands that never achieved market plurality status.

    Browsers and engines which never gain share above about 10% are not considered "relevant" by most developers and can be born, live, and die entirely out of view of the mainstream. For other players, particularly across form-factors, the salience of any specific engine is more contextual. Contractual terms, tooling support, and even the personal experience of influential developers all play a role. This situation is not helped by major sites and CDNs — with the partial exception of Cloudflare — declining to share statistics on the mix of browsers their services see.

    Regardless, web-wide market share below 2% for any specific version of any engine is generally accepted as irrelevance; the point at which developers no longer put in even minimal effort to continue to support a browser except with "fallback" experiences. ⇐

  3. It's not an exaggeration to suggest that the W3C, IETF, and ECMA have been fundamentally undermined by Apple's coercion regarding browser engines on iOS, turning the entire organisation into a sort of Potempkin village with semi-independent burgs taking shape on the outskirts through Community Groups like the WICG, which Apple regularly tries to tear down through procedural attacks it hopes the wider community will not trace back to the source.

    When competitors cannot ship their best ideas, the venues where voluntary standards are codified lose both their role as patent-pooling accelerators for adoption, as well as their techno-social role as mediators and neutral ground.

    The corporeal form continues long after the ghost leaves the body, but once the vivifying force of feature autonomy is removed, an SDO's roof only serves to collect skeletons, eventually compromising the organisation itself. On these grounds, self-aware versions of the W3C, IETF, and ECMA would have long ago ejected Apple from membership, but self-awareness is not their strong suit. And as long as the meetings continue and new drafts are published, it hardly deserves mention that the SDO's role in facilitating truly disruptive change will never again be roused. After all, the membership documents companies sign do not require them to refrain from shiving their competition; only that everyone keep their voices down and the tone civil.

    What's truly sad is how few convening services, or reciting liturgies from the pews, seem disturbed their prayers will never again be heard. ⇐

  4. This is about the point where folks will come crawling out of the walls to tell stories about IBM or Rambus or Oracle or any of the codec sharks that have played the heel in standards at one point or another. Don't bother; I've got a pretty full file of those stories, and I can't repeat them here anyway. But if you do manage to blog one of them in an entertaining way without getting sued, please drop a line. ⇐

  5. You know, in case you're wondering what CSS WG was doing from '04-'21. I wonder what changed? ⇐

  6. It's particularly disingenuous for fifth columnists to claim proposals they don't like are "not standards track" as they know full-well that the reason they aren't being advanced within chartered working groups is their own opposition.

    The circularity is gobsmacking, but often works. This reduces pressure from credulous web developers. Excusemaking is only possible because other vendors fail to call bullshit. Apple, e.g., would not be getting away with snuffing out the mobile web's chances were it not for a cosy set of fellow travellers at Mozilla and Google. ⇐

  7. Internet APIs and protocols do not spring fully-formed from the head of Zeus.

    Getting to good, or even good-enough, requires furious iteration, and that means testing and prodding at proposals. The only way to get miles under a proposal is to try things, and that's what incubation venues specialise in. It is not a sign of failure that many proposals change shape in response to feedback, or that certain evolutionary branches are abandoned altogether. Much the opposite.

    It is only by trying, testing, iterating, and yes, abandoning many designs that we arrive at productive progress in web specs. Anyone who tells you differently is carrying water for fifth columnists and should be put on notice. They may not personally intend to undermine the web's future, but that's what treating iteration in design as failure does by proxy. ⇐

  8. Most Web API design processes cannot claim any kinship to the scientific method, although we have tried mightily to open a larger space for testing of alternative hypotheses within the Chromium project over the past decade.

    Even so, much of the design work of APIs on the web platform is shaped by the specific and peculiar preferences of powerful individuals, many of whom are not and have never been working web developers. ⇐

  9. Hiring "known quantities" to do the wrangling within a Working Group you want to scupper is generally cheaper than doing constructive design work, so putting in-group old-timers on the payroll is a reliable way for fifth columnists to appear aligned with the goals of the majority while working against them in practice. ⇐

  10. One rhetorical mode for those working to constrain the web platform's capabilities is to attempt to conflate any additions with instability, and specifically, the threat that sites that work today will stop working tomorrow. This is misdirection, as stability for the ecosystem is not a function of standards debates, but rather the self-interested actions of each vendor in the market.

    When true browser competition is allowed, the largest disciplining force on vendor behaviour is incompatibility. Browsers that fail to load important web pages lose share to those that have better web compatibility. This is as close as you can get to an iron law of browser engineering, and every vendor knows that their own engine teams have spent gargantuan amounts of time and money to increase compatibility over the years.

    Put more succinctly, backwards compatibility on the web is not seriously at risk from capability expansions. Proposals that would imperil back compat12 are viewed as non-starters in all web standards venues, and major schisms have formed over proposed, incompatible divergence, with the compatibility-minded winning nearly every skirmish.

    No SDO representative from these teams is ignorant of these facts, and so attempts to argue against solving important problems by invoking the spectre of "too much change, too fast" or "breaking the web" are sleights of hand.

    They know that most web developers value stability and don't understand these background facts, creating space for a shell game in which the threat of too much change serves to obscure their own attempts at sabotage through inaction. Because web standards are voluntary and market share matters tremendously to every vendor, nothing that actually breaks the web will be allowed to ship. So armed, you can now call out this bait-and-switch wherever it appears. Doing so is important, as the power to muddy these waters stems from the relative ignorance of web developers. Educating them to the real power dynamics at work is our best bulwark against the fifth column. ⇐

  11. There's no surer sign of the blindness many SDO participants exhibit toward the breakage of the voluntary implementation regime than that they extend deference on that basis to Apple.

    Cupertino's SDO delegates do not bear a heightened presumption that they will implement as soon as other ship. To the contrary, Apple have so thoroughly lowered expectations that nobody expects timely feedback on proposals, let alone implementation commitments. Even when Apple is the last holdout. Cupertino sullies the brands they force to use WebKit's worst-of-the-worst implementation. It has been going on so long that it is now simply accepted as the status quo.

    This is entirely backwards, and Apple's representatives should, instead, be expected to provide implementation timelines for features shipped by other vendors. God knows they can afford it.

    Until such time as Apple allows engine competition worldwide, it's only fair to expect (and demand) parity. Every Apple employee should feel the heat of shame every as they mutter "Apple does not comment on future product releases" while indefensibly harming the web. ⇐

  12. The browser and web infrastructure community have implemented large transitions away from some regretted technologies, but the care and discipline needed to do this without breaking the web is the stuff of legend. Big ones that others should write long histories of are the sunsetting of AppCache and the move away from unencrypted network connections.

    Both played out on the order of half a decade or more, took dozens of stakeholders to pull off, and were games of inches adding up to miles. New tools like The Reporting API, Deprecation Reports, and Reverse Origin Trials had to be invented to augment the "usual" tool bag of anonymised analytics trawls, developer outreach, new limits on unwanted behaviour, and nudging UI.

    In both cases (among many more small deprecations we have done over the years), the care taken ensured that only a small fraction of the ecosystem was impacted at any moment, lowering the temperature and allowing for an orderly transition to better technology. ⇐

  13. Your correspondent has heard different stories from folks who had reason to know about the period from '08-'10 when Apple pulled its foot off the gas with Safari.

    Given the extreme compartmentalisation of Apple's teams, the strategic import of any decision, and the usual opacity of tech firms around funding levels ("headcount") to even relatively senior managers, this is both frustrating and expected.

    The earliest dating puts the death of the web as "Plan A" before Steve Jobs's announcement of the iPhone at Macworld in June 2007. The evidence offered for this view was that a bake off for system apps and the home screen launcher had already been lost by WebKit. Others suggest it wasn't until the success of the App Store in '09 and '10 that Apple began to pull away from the web as a top-tier platform. Either way, it was all over by early 2011 at the very latest.

    WebKit would never again be asked to compete as a primary mobile app platform, and skeletal funding for Safari ensured it would never be allowed to break out of the OS's strategic straightjacket the way IE 4-6 had. ⇐

Links? Links!

Infrequently Noted

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://

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 SSGs that put them in total control. React, Next, and even Nuxt are absent from pages of the folks who really know what they're doing. This ought to be a strong signal to hiring managers looking to cut through the noise.

Next, when did RSS/Atom previews get so dang beautiful?

The art and effort put into XSLT styling like Elly Loel's is gobsmacking. I am verklempt that not only does my feed not look that good, my site doesn't look that polished.

Last, whimsy isn't dead.

Webrings, guestbooks, ASCII art in comments, and every other fun and silly flourish are out there, going strong, just below the surface of the JavaScript-Industrial Complex's thinkfluencer hype recycling.

And it's wonderful.

My overwhelming feeling after composing this collection is gratitude. So many wonderful people are doing great things, based on values that put users first. Sitting with their work gives me hope, and I hope their inspiration can spark something similar for you.

Conferences, Clarity, and Smokescreens

Infrequently Noted

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 day-to-day consulting work, along with high-visibility industry data, shows that the React community is mired in a deep, measurable quality crisis. But attendees of React Summit who didn't already know wouldn't hear about it.

Near as I can tell, the schedule of React Summit mirrors the content of other recent and pending React conferences (1, 2, 3, 4, 5, 6) in that these are not engineering conferences; they are marketing events.

How can we tell the difference? The short answer is also a question: "who are we building for?"

The longer form requires distinguishing between occupations and professions.

In a 1912 commencement address, the great American jurist and antitrust reformer Louis Brandeis hoped that a different occupation — business management — would aspire to service:

The peculiar characteristics of a profession as distinguished from other occupations, I take to be these:

First. A profession is an occupation for which the necessary preliminary training is intellectual in character, involving knowledge and to some extent learning, as distinguished from mere skill.

Second. It is an occupation which is pursued largely for others and not merely for one's self.

Third. It is an occupation in which the amount of financial return is not the accepted measure of success.

In the same talk, Brandeis named engineering a discipline already worthy of a professional distinction. Most software development can't share the benefit of the nominative doubt, no matter how often "engineer" appears on CVs and business cards. If React Summit and Co. are anything to go by, frontend is mired in the same ethical tar that causes Wharton, Kellogg, and Stanford grads to experience midlife crises.3

It may seem slanderous to compare React conference agendas to MBA curricula, but if anything it's letting the lemon vendors off too easily. Conferences crystallise consensus about which problems matter, and React Summit succeeded in projecting a clear perspective — namely that it's time to party like it's 2013.

A patient waking from a decade-long coma would find the themes instantly legible. In no particular order: React is good because it is popular. There is no other way to evaluate framework choice, and that it's daft to try because "everyone knows React".4 Investments in React are simultaneously solid long-term choices, but also fragile machines in need of constant maintenance lest they wash away under the annual tax of breaking changes, toolchain instability, and changing solutions to problems React itself introduces. Form validation is not a solved problem, and in our glorious future, the transpilers compilers will save us.

Above all else, the consensus remains that SPAs are unquestionably a good idea, and that React makes sense because you need complex data and state management abstractions to make transitions between app sections seem fluid in an SPA. And if you're worried about the serially terrible performance of React on mobile, don't worry; for the low, low price of capitulating to App Store gatekeepers, React Native has you covered.5

At no point would our theoretical patient risk learning that rephrasing everything in JSX is now optional thanks to React 19 finally unblocking interoperability via Web Components.6 Nor would they become aware that new platform APIs like cross-document View Transitions and the Navigation API invalidate foundational premises of the architectures that React itself is justified on. They wouldn't even learn that React hasn't solved the one problem it was pitched to address.

Conspicuously missing from the various "State Of" talks was discussion of the pressing and pervasive UX quality issues that are rampant in the React ecosystem.

Per the 2024 Web Almanac, less than half of sites earn passing grades on mobile, where most users are.
Per the 2024 Web Almanac, less than half of sites earn passing grades on mobile, where most users are.

We don't need to get distracted looking inside these results. Treating them as black boxes is enough. And at that level we can see that, in aggregate, JS-centric stacks aren't positively correlated with delivering good user-experiences.

2024's switch from FID to INP caused React (particularly Next and Gatsby) sites which already had low pass-rates to drop more than sites constructed on many other stacks.
2024's switch from FID to INP caused React (particularly Next and Gatsby) sites which already had low pass-rates to drop more than sites constructed on many other stacks.

This implies that organisations adopting React do not contain the requisite variety needed to manage the new complexity that comes from React ecosystem tools, practices, and community habits. Whatever the source, it is clearly a package deal. The result are systems that are out of control and behave in dynamically unstable ways relative to business goals.

The evidence that React-based stacks frequently fail to deliver good experiences is everywhere. Weren't "fluid user experiences" the point of the JS/SPA/React boondoggle?7

We have witnessed high-cost, low-quality JS-stack rewrites of otherwise functional HTML-first sites ambush businesses with reduced revenue and higher costs for a decade. It is no less of a scandal for how pervasive it has become.

But good luck finding solutions to, or even acknowledgement of, that scandal on React conference agendas. The reality is that the more React spreads, the worse the results get despite the eye-watering sums spent on conversions away from functional "legacy" HTML-first approaches. Many at React Summit were happy to make these points to me in private, but not on the main stage. The JS-industrial-complex omertà is intense.

No speaker I heard connected the dots between this crisis and the moves of the React team in response to the emergence of comparative quality metrics. React Fiber (née "Concurrent"), React Server Components, the switch away from Create React App, and the React Compiler were discussed as logical next steps, rather than what they are: attempts to stay one step ahead of the law. Everyone in the room was expected to use their employer's money to adopt all of these technologies, rather than reflect on why all of this has been uniquely necessary in the land of the Over Reactors.8

The treadmill is real, but even at this late date, developers are expected to take promises of quality and productivity at face value, even as they wade through another swamp of configuration cruft, bugs, and upgrade toil.

React cannot fail, it can only be failed.

And then there was the privilege bubble. Speaker after speaker stressed development speed, including the ability to ship to mobile and desktop from the same React code. The implications for complexity-management, user-experience, and access were less of a focus.

The most egregious example of the day came from Evan Bacon in his talk about Expo, in which he presented Burger King's website as an example of a brand successfully shipping simultaneously to web and native from the same codebase. Here it is under WebPageTest.org's desktop setup:9


As you might expect, putting 75% of the 3.5MB JS payload (15MB unzipped) in the critical path does unpleasant things to the user experience, but none of the dizzying array of tools involved in constructing bk.com steered this team away from failure.10

The fact that Expo enables Burger King to ship a native app from the same codebase seems not to have prevented the overwhelming majority of users from visiting the site in browsers on their mobile devices, where weaker mobile CPUs struggle mightily:


The CrUX data is damning:


This sort of omnishambles is what folks mean when they say that "JavaScript broke the web and called it progress".

Is waiting 30 seconds for a loading spinner bad?<br>Asking for an industry.
Is waiting 30 seconds for a loading spinner bad?
Asking for an industry.

The other poster child for Expo is Bluesky, a site that also serves web and React Native from the same codebase. It's so bewilderingly laden with React-ish excesses that their engineering choices qualify as gifts-in-kind to Elon Musk and Mark Zuckerberg:


Why is Bluesky so slow? A huge, steaming pile of critical-path JS, same as Burger King:


Again, we don't need to look deeply into the black box to understand that there's something rotten about the compromises involved in choosing React Native + Expo + React Web. This combination clearly prevents teams from effectively managing performance or even adding offline resilience via Service Workers. Pinafore and Elk manage to get both right, providing great PWA experiences while being built on a comparative shoestring. It's possible to build a great social SPA experience, but maybe just not with React:

If we're going to get out of this mess, we need to stop conflating failure with success. The <em>entire point</em> of this tech was to deliver better user experiences, and so the essential job of management is to ask: does it?
If we're going to get out of this mess, we need to stop conflating failure with success. The entire point of this tech was to deliver better user experiences, and so the essential job of management is to ask: does it?

The unflattering comparisons are everywhere when you start looking. Tanner Linsley's talk on TanStack (not yet online) was, in essence, a victory lap. It promised high quality web software and better time-to-market, leaning on popularity contest results and unverifiable, untested claims about productivity to pitch the assembled. To say that this mode of argument is methodologically unsound is an understatement. Rejecting it is necessary if we're going to do engineering rather that marketing.

Popularity is not an accepted unit of engineering quality measurement.
Popularity is not an accepted unit of engineering quality measurement.

The TanStack website cites this social proof as an argument for why their software is great, but the proof of the pudding is in the eating:


The contrast grows stark as we push further outside the privilege bubble. Here are the same sites, using the same network configuration as before, but with the CPU emulation modelling a cheap Android instead:

An absolute rout. The main difference? The amount of JS each site sends, which is a direct reflection of values and philosophy.
An absolute rout. The main difference? The amount of JS each site sends, which is a direct reflection of values and philosophy.

Site Wire JS Decoded JS TBT (ms)
astro.build 11.1 kB 28.9 kB 23
hotwired.dev 1.8 kB 3.6 kB 0
11ty.dev 13.1 kB 42.2 kB 0
expo.dev 1,526.1 kB 5,037.6 kB 578
tanstack.com 1,143.8 kB 3,754.8 kB 366

Yes, these websites target developers on fast machines. So what? The choices they make speak to the values of their creators. And those values shine through the fog of marketing when we use objective quality measures. The same sorts of engineers who care to shave a few bytes of JS for users on fast machines will care about the lived UX quality of their approach all the way down the wealth curve. The opposite also holds.

It is my long experience that cultures that claim "it's fine" to pay for a lot of JS up-front to gain (unquantified) benefits in another dimension almost never check to see if either side of the trade comes up good.

Programming-as-pop-culture is oppositional to the rigour required of engineering. We need to collectively recalibrate when the folks talking loudest about "scale" and "high quality" and "delivery speed" — without metrics or measurement — continually plop out crappy experiences but are given huge megaphones anyway.

There were some bright spots at React Summit, though. A few brave souls tried to sneak perspective in through the side door, and I applaud their efforts:

If the Q&A sessions after my talk are any indication, Luca faced serious risk of being ignored as a heretic for putting this on a slide.
If the Q&A sessions after my talk are any indication, Luca faced serious risk of being ignored as a heretic for putting this on a slide.

If frontend aspires to be a profession11 — something we do for others, not just ourselves — then we need a culture that can learn to use statistical methods for measuring quality and reject the sorts of marketing that still dominates the React discourse.

And if that means we have to jettison React along the way, so be it.

FOOTNOTES

  1. For attendees, JSNation and React Summit were separate events, although one could buy passes that provided access to both. My impression is that many did. As they were in the same venue, this may have simplified some logistics for the organisers, and it was a good way to structure content for adjacent, but not strictly overlapping, communities of interest. ⇐

  2. Again, my thanks to the organisers for letting me sit in on this meeting. As with much of my work, my goal was to learn about what's top of mind to the folks solving problems for developers in order to prioritise work on the Web Platform.

    Without giving away confidences from a closed-door meeting, I'll just say that it was refreshing to hear framework authors tell us that they need better HTML elements and that JSX's default implementations are scaling exactly as poorly ecosystem-wide as theory and my own experience suggest. This is down to React's devil-may-care attitude to memory.

    It's not unusual to see heavy GC stalls on the client as a result of Facebook's always-wrong assertion that browsers are magical and that CPU costs don't matter. But memory is a tricksy issue, and it it's a limiting factor on the server too.

    Lots to chew on from those hours, and I thank the folks who participated for their candour, which was likely made easier since nobody from the React team deigned to join. ⇐

  3. Or worse, don't.

    Luckily, some who experience the tug of conscience punch out and write about it. Any post-McKinsey tell-all will do, but Anand Giridharadas is particularly good value for money in the genre. ⇐

  4. Circular logic is a constant in discussions with frameworkists. A few classics of the genre that got dusted off in conversations over the conference:

    • "The framework makes us more productive."

      Oh? And what's the objective evidence for that productivity gain?

      Surely, if it's large as frameworkists claim, economists would have noted the effects in aggregate statistics. But we have not seen that. Indeed, there's no credible evidence that we are seeing anything more than the bog-stock gains from learning in any technical field. The combinatorial complexity of JS frameworks may, in itself, reduce those gains; we don't know, so we can't make claims either way.

      Nobody's running real studies that compare proficient HTML&CSS or jQuery developers to React developers under objective criteria. In the place of research, personal progression is frequently cited as evidence for collective gains, which is obviously nonsensical.

      Indeed, it's just gossip.

    • "But we can hire for the framework."

      😮 sigh 😮‍💨

    • "The problem isn't React, it's the developers."

      Hearing this self-accusation offered at a React conference was truly surreal.

      In a room free of discussions about real engineering constraints, victim-blaming casts a shadow of next-level cluelessness. But frameworkists soldier on, no matter the damage it does to their argument. Volume and repetition seem key to pressing this line with a straight face.

    ⇐

  5. A frequently missed consequence of regulators scrutinising Apple's shocking (lack of) oversight of its app store has been Apple relaxing restrictions on iOS PWAs. Previously, PWA submissions were rejected often enough to warn businesses away. But that's over now. To reach app stores on Windows, iOS, and Android, you need is a cromulent website and PWABuilder.

    For most developers, the entire raison d'être for React Native is kaput; entirely overcome by events. Not that you'd hear about it at an assemblage of Over Reactors. ⇐

  6. Instead of describing React's exclusive ownership of subtrees of the DOM, along with the introduction of a proprietary, brittle, and hard-to-integrate parallel lifecycle as a totalising framework that demands bespoke integration effort, the marketing term "composability" was substituted to describe the feeling of giving everything over to JSX-flavoured angle brackets every time a utility is needed. ⇐

  7. It has been nearly a decade since the failure of React to reliably deliver better user experiences gave rise to the "Developer Experience" bait-and-switch. ⇐

  8. Mark Erikson's talk was ground-zero for this sort of obfuscation. At the time of writing, the recording isn't up yet, but I'll update this post with analysis when it is. I don't want to heavily critique from my fallible memory. ⇐

  9. WPT continues to default desktop tests to a configuration that throttles to 5Mbps up, 1Mbps down, with 28ms of RTT latency added to each packet. All tests in this post use a somewhat faster configuration (9Mbps up and down) but with 170ms RTT to better emulate usage from marginal network locations and the effects of full pipes. ⇐

  10. I read the bundles so you don't have to.

    So what's in the main, 2.7MB (12.5MB unzipped) bk.com bundle? What follows is a stream-of-consciousness rundown as I read the pretty-printed text top-to-bottom. At the time of writing, it appears to include:

    • A sea of JS objects allocated by the output of a truly cursed "CSS-in-JS" system. As a reminder, "CSS-in-JS" systems with so-called "runtimes" are the slowest possible way to provide styling to web UI. An ominous start.

    • React Native Reanimated (no, I'm not linking to it), which generates rAF-based animations on the web in The Year of Our Lord 2025, a full five years after Safari finally dragged its ass into the 2010s and implemented the Web Animation API.

      As a result, React Native Renaimated is Jank City.

      Jank Town. George Clinton and the Parliment Jankidellic. DJ Janky Jeff. Janky Jank and the Janky Bunch. Ole Jankypants. The Undefeated Heavyweight Champion of Jank.

      You get the idea; it drops frames.

    • Redefinitions of the built-in CSS colour names, because at no point traversing the towering inferno of build tools was it possible to know that this web-targeted artefact would be deployed to, you know, browsers.

    • But this makes some sense, because the build includes React Native Web, which is exactly what it sounds like: a set of React components that emulate the web. This allows RN project to provide a subset of the layout that browsers are natively capable of, but it does not include many of the batteries that the web includes for free.

      Which really tells you everything you need to know about how teams get into this sort of mess.

    • Huge amounts of code duplication via inline strings that include the text of functions right next to the functions themselves.

      Yes, you're reading that right: some part of this toolchain is doubling up the code in the bundle, presumably for the benefit of a native debugger. Bro, do you even sourcemap?

      At this point it feels like I'm repeating myself, but none of this is necessary on the web, and none of the (many, many) compiler passes saw fit to eliminate this waste in a web-targeted build artefact.

    • Another redefinition of the built-in CSS colour names and values. In browsers that support them natively. I feel like I'm taking crazy pills.

    • A full copy of React, which is almost 10x larger than it needs to be in order to support legacy browsers and React Native.

    • Tens Hundreds of thousands of lines of auto-generated schema validation structures and repeated, useless getter functions for data that will never be validated on the client. How did this ungodly cruft get into the bundle? One guess, and it rhymes with "schmopallo".

    • Of course, no bundle this disastrous would be complete without multiple copies of polyfills for widely supported JS features like Object.assign(), class private fields, generators, spread, async iterators, and much more.

    • Inline'd WASM code, appearing as a gigantic JS array. No, this is not a joke.

    • A copy of Lottie. Obviously.

    • What looks to be the entire AWS Amplify SDK. So much for tree-shaking.

    • A userland implementation of elliptic curve cryptography primitives that are natively supported in every modern browser via Web Crypto.

    • Inline'd SVGs, but not as strings. No, that would be too efficient. They're inlined as React components.

    • A copy of the app's Web App Manifest, inline, as a string. You cannot make this up.

    Given all of this high-cost, low-quality output, it might not surprise you to learn that the browser's coverage tool reports that more than 75% of functions are totally unused after loading and clicking around a bit. ⇐

  11. I'll be the first to point out that what Brandeis is appealing to is distinct from credentialing. As a state-school dropout, that difference matters to me very personally, and it has not been edifying to see credentialism (in the form of dubious boot camps) erode both the content and form of learning in "tech" over the past few years.

    The term "professional" continues to leave me uncomfortable for many of the affective connotations it now carries. But I do believe we should all aspire to do our work in a way that is compatible with Brandeis' description of a profession. To do otherwise is to endanger any hope of self-respect and even our social licence to operate. ⇐

Safari at WWDC '25: The Ghost of Christmas Past

Infrequently Noted

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:

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:

The announced support for CSS image crossorigin() and referrerpolicy() modifiers has an unclear relationship to other browsers, judging by the wpt.fyi tests.

On balance, this is a lot of catch-up with sparse sprinklings of leadership. This makes sense, because Safari is in usually in last place when it comes to feature completeness:

A graph of features missing from only one engine. Over the past decade, Safari and WebKit have consistently brought up the caboose.
A graph of features missing from only one engine. Over the past decade, Safari and WebKit have consistently brought up the caboose.

And that is important because Apple's incredibly shoddy work impacts every single browser on iOS.

You might recall that Apple was required by the EC to enable browser engine choice for EU citizens under the Digital Markets Act. Cupertino, per usual, was extremely chill about it, threatening to end PWAs entirely and offering APIs that are inadequate or broken.

And those are just the technical obstacles that Apple has put up. The proposed contractual terms (pdf) are so obviously onerous that no browser vendor could ever accept them, and are transparently disallowed under the DMA's plain language. But respecting the plain language of the law isn't Apple's bag.

All of this is to say that Apple is not going to allow better browsers on iOS without a fight, and it remains dramatically behind the best engines in performance, security, and features. Meanwhile, we now know that Apple is likely skimming something like $19BN per year in pure profit from it's $20+BN/yr of revenue from its deal with Google. That's a 90+% profit rate, which is only reduced by the paltry amount it re-invests into WebKit and Safari.

So to recap: Apple's Developer Relations folks want you to be grateful to Cupertino for unlocking access to features that Apple has been the singular obstacle to.

And they want to you ignore the fact that for the past decade it has hobbled the web while skimming obscene profits from the ecosystem.

Don't fall for it. Ignore the gaslighting. Apple could 10x the size of the WebKit team without causing the CFO to break a sweat, and there are plenty of great browser engineers on the market today. Suppressing the web is a choice — Apple's choice — and not one that we need to feel gratitude toward.