How we think about browsers | The GitHub Blog

Google’s Prompt API

No web standard should require you to agree to an advertising company’s “terms of use.”

I’m genuinely disheartened and angry that the Google Chrome team have done this. Never assume good faith from them again.

This is, hands-down, the most insultingly transparent attempt at web standards bullying I’ve ever seen, including past ones from Google, which is — and I cannot stress this point enough — a company that sells advertisements. This is miles more eyeroll-worthy than AMP, where you’ll recall that a legion of tight-smiling dorks wearing Alphabet lanyards tried to assure us that the only means of survival for the web itself was to funnel all of it through Google’s servers, and only use their very good advertisements instead of those bad other ones.

No-stack web development – David Bushell – Web Dev (UK)

A stack is also technical debt, non-transferable knowledge, accelerated obsolescence, and vendor lock-in. That means fragility and overall unnecessary complication. Popular stacks inevitably turn into cargo cults that build in spite of the web, not for it.

The web platform does not require build toolchains. Always default to, and regress to, the fundamentals of CSS, HTML, and JavaScript. Those core standards are the web stack.

Web Day Out - 12 March 2026 — Polytechnic

This was another fantastic conference from the Clearleft team, and one that I hope is repeated next year. It is absolutely incredible what you can do in the browser these days, and even though I thought I was keeping up with the latest developments, it astounded me how far things have come.

An in-depth guide to customising lists with CSS - Piccalilli

Think you know about styling lists with CSS? Think again!

This is just a taste of the kind of in-depth knowledge that Rich will be beaming directly into our brains at Web Day Out…

JS-heavy approaches are not compatible with long-term performance goals

Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.

But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.

Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.