Infrequently Noted

JavaScript overindulgence remains an affirmative choice, no matter how hard industry 'thought leaders' gaslight us. Better is possible, but we must want it enough to put users ahead of our own interests.

I have worked with dozens of teams surprised to have found themselves in the JavaScript ditch. They all feel ashamed because they've been led to believe they're the first; that the technology is working fine for other folks. It isn't.

SNAP benefits sites for more than 20% of Americans are unusably slow. All of them would be significantly faster if states abandoned client-side-rendering, and along with it, the legacy JavaScript frameworks (React, Angular, etc.) built to enable the SPA model.

It would be tragic if public sector services adopted the JavaScript-heavy stacks that frontend influencers have popularised. Right?

Armed with new powers to rein in the worst excesses of mobile's duopolists, regulators around the world are struggling to find their footing. The UK's CMA is only the latest to pose capitulation as success. Far from unlocking growth and dynamism, regulatory timidity is reducing enforcers' future room for manoeuvre and hampering home-grown competitors to Big Tech. Unleashing the web would fix a great deal of what's broken, but regulators are falling down on the job. It's time we spoke plainly about it.

Apple and Google's app stores stand for nothing and will stand up to no-one. Good riddance.

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, and it's rotten to the core.

I've been hearing confusing reports 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.

By subverting the voluntary nature of open standards, Apple has defanged them as tools that users can employ against the totalising power of native apps in their digital lives. This high-modernist approach is antithetical to the foundational commitments of internet standards bodies and, over time, erode them.

Apple vs. Facebook is, and always was, kayfabe. In reality, Apple is Facebook's chauffeur; holding Zuck's coat while Facebook wantonly surveils iPhones owners. How can we be sure? Because Apple continues to allow wide-scale abuse of In-App Browsers.

Apple's Developer Relations folks want you to be grateful to Cupertino for unlocking features that Apple has been the singular obstacle to. Don't fall for it.

Cupertino's attempt to scuttle Progressive Web Apps under cover of chaos is exactly what it appears to be: a shocking attempt to keep the web from ever emerging as a true threat to the App Store and blame regulators for Apple's own malicious choices. By hook or by crook, Apple's going to maintain its home screen advantage.

Under regulatory pressure, mobile OSes are opening up and adding features that will allow PWAs to disrupt app stores ... Yet with shockingly few exceptions, coverage accepts that the solution to crummy, extractive native app stores will be other native app stores. ... The press fails to mention the web as a sustitute for native apps, and fail to inform readers of its disruptive potential. Why?

What's going on with WebKit is not 'normal'. At no time since 2007 has the codebase gotten this much love this quickly; but why? Time for a deep dive.

Some folks claim that Apple's mandated inadequacy for browsers and their engines is somehow beneficial to the cause of ensuring a diverse pool of web engines. Nothing could be farther from the truth, but to understand why, we need to understand how browsers are funded. With that understanding, we can see that not only has Apple has starved its own browser team of resources, but has done grevious damage to Mozilla along the way.

Apple has demonstrated shameless contempt in ignoring the spirit of pro-competition regulation. The web could serve as a counterbalance to this sort of gameplaying, but only if broad, effective, and widely adopted rules are put in place.

If you live or do business in the UK or the US, what you do in the next seven days could define the web for decades to come. By filing public comments with UK regulators and US legislators this week you can change the course of mobile computing more than at any other time in the past decade. Read on for why this moment matters and how to seize the day.

A deep dive into the arguments offered by Apple and others to defend a lack of browser engine choice on iOS. Instead of raising the security floor, Apple has set a cap whilst breeding a monoculture that ensures all iOS browsers are vulnerable to identical attacks, no matter whose icon is on the home screen.

Mobile OSes and their most successful apps have drained browser choice of meaning for more than a decade. This has lead to confusion for users and loss of control over data. Web developers, meanwhile, face higher costs and reduced ability to escape walled gardens. It's time for the charade to end.

Apple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store. This is a bold assertion, and proving it requires examining the record from multiple directions.

Embedded in this year's network and device estimates is hopeful news about the trajectory of devices and networks. It has never been easier to deliver pages quickly, but we are not collectively hitting the mark. Indeed, the latest CrUX data shows not even half of origins have passing Core Web Vitals scores for mobile users. Browsers will need to provide stronger incentives. This will be unpopular, but it is clearly necessary.

How much HTML, CSS, and JavaScript can we afford? More than in years past, but much less than frontend developers are burdening users with.

To serve users at the global P75 of devices and networks, we can now afford ~150KiB of HTML/CSS/fonts and ~300-350KiB of JavaScript (gzipped). This is a slight upgrade on last year's budgets, thanks to device and network improvements. Meanwhile, web developers continue to send more script than is reasonable for 80+% of the world's users, widening the gap between the haves and the have-nots. This is an ethical crisis for frontend. Meanwhile, the most popular tools and frameworks remain in stubborn denial, but reality is not moved by ignoring it: when digital is the default, slow is exclusionary.

Despite advances in browser tooling, automated evaluation, lab tools, guidance, and runtimes, modern teams struggle to deliver even decent performance with today's popular frameworks. This is not a technical problem per se. It's a management issue, and one that teams can conquer with the right frame of mind and support.

Is there a generic, unform way to think about web performance? What is web performance? What's it for? A humble attempt to answer those very deep questions. [republished]

A lot has changed since 2017 we I last estimated a global baseline for total page resource limits of 120-170KiB. Thanks to progress in networks and browsers (but not devices), the new baseline is much more generous: ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS. But the devil's in the footnotes, and modern web development practices push the median page well above these guidelines.

We cannot continue to use as much JavaScript as is now normal and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS...until it's too late. Lightweight, effective tools are here, but we're stuck in a rhetorical rut. We need to reset our conversation about 'developer experience' to factor in the asymmetric cost of JS.

Performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a time budget of less than 5 seconds first-load Time-to-Interactive and less than two seconds for subsequent loads. We further constrain ourselves to a baseline device and network configuration to measure progress. 2017's global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time ('RTT'). This translates to ~130-170KB of critical-path resources, depending on composition; the more JS you include, the smaller the bundle must be.

Working Groups do not invent the future, nor do they hand down revealed truths by divining entrails like prophets of the House of Iamus. In practice, they are diligent, thoughtful historians of recent design expeditions. 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.

Conway's Law is generally discussed in the context of organisations trying to solve a problem. But what if there are defectors? And what if they could prevent all progress without paying a price? This problem is rarely analysed for the simple reason that such an organisation would be deranged. But what if it happened regularly, and even threatened the basis of web standards?

It's attractive to think that design can (or should) happen within a formal Working Group. A well-functioning WG should include both developers and implementers, after all. Those groups often have face-to-face meetings, and the path toward standardisation is shortest in those venues! But it doesn't work; not often enough to be useful, anyway.

The web standards process fails us too often. This series explores the forces at work, how we're improving the situation, and how you can shape new features more effectively.