I can’t understand how we got to this place with “app culture”! Software companies are happy to make their lives harder (and more expensive: deploying to the big app stores isn’t free!), in order to deliver HTML content to fewer people and with fewer features than if they just published directly to the Web in the first place!
So instead of asking “why not React?” we asked: Which of our actual problems would React solve? We went through the list. There were none.
Also, this is good advice when you’re about to make a web component:
Every component starts with the question “does a semantic element already exist for this?”, and remarkably often the answer is yes.
Digital memory is fragile not because bits decay (though they do), but because someone else owns the shelf.
Alex takes issue with my post giving kudos to Apple for concentrating on bugfixes in the latest version of Safari, and he brings receipts. He makes a very compelling case, backed up with data.
But when it comes to Chrome’s shipping of the half-baked prompt API, I’m not sure he gets just how badly it has soured the developer community’s feelings towards Google. This isn’t something to be countered with data; it’s much more visceral than that. Alex says:
So if Jeremy has a problem with specific features, I hope he’ll come to us with a critique of their qualities, rather than their optics.
In this case though, the optics are really, really, really bad.
This is a great case study featuring a really useful HTML web component called validation-enhancer.
The results? When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures. It was a flood!
The browser is the security boundary. Websites operate within it. Native apps bypass it.
But there’s still one thing that native apps do better than the web. If you want to be able to monitor and track users to an invasive degree, the web can’t compete with the capabilities of native apps. That’s why you’ll see so many websites on your mobile device that implore to install their app from the app store.
This piece goes into the details:
Most native apps collect far more data than their website equivalents ever could. They request permissions to hardware, sensors, and background processes that browsers deliberately restrict. The third-party software embedded in these apps frequently transmits your location, device identifiers, and behavioral data to third parties before you even see a consent prompt.
Fixed an issue on iOS and iPadOS where
datalistsuggestions were presented directly over the associated input, obscuring it.
This really gets to the heart of one of the biggest benefits of HTML web components: composability. You can nest your regular markup inside multiple custom elements; something that is can’t do.
The other exciting approach doesn’t exist yet: custom attributes. Again, they’d be a great way of using composability to turbo-charge your existing HTML in all sorts of ways.
Here’s another nice progressive web component for your forms, this time for showing error messages.
Here’s an excellent progressive web component from Aaron—wrap a custom element around your exising form and your good to go:
At its core,
form-saveris a small web component that wraps a form, keeps an eye on it, stores values inlocalStorage, and restores them when the page loads again. Better yet, it clears out saved data after a successful submission so you’re not accidentally resurrecting stale information the next time someone stops by.
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.
Not sure I buy the argument here, though I do very much look forward to local language models getting better so we can ditch the predatory peddlars of today’s slop. But this trip down memory lane to the early web of the 1990s could’ve been describing my own experience:
But the thing I do remember was the first time I came across Derek Powazek’s Fray online magazine. It was the first time I had seen a website look beautiful. This was without CSS and without Javascript. I still remember quite clearly an “issue” of Fray that used frames to create some kind of “doors” you could slide open to reveal an article inside.
Fray was what made me want to make websites:
I distinctly remember sites like prehensile tales, 0sil8 and the inimitable Fray triggering something in my brain that made me realise what it was I wanted to do with my life.
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.
Never forget:
- The time Apple lied to the UK regulator
- The time when Apple told the EU that Safari is 3 different browsers
- When Apple tried to shut the UK investigation down
- When Apple’s VP of Finance got caught lying under oath
- When Apple tried to wreck all EU Web Apps
I’m slapping my forehead—progressive web components is a perfect name for what I’ve been calling HTML web components. Why didn’t I think of that?
A Progressive Web Component is a native Custom Element designed in two layers: a base layer of HTML and CSS that renders immediately, without JavaScript, and an enhancement layer of JavaScript that adds reactivity, event handling, and more advanced templating.
A lovely post from Remy about State Of The Browser and Web Day Out.
I feel very seen here. This describes how I built The Session:
There are still people building the web by hand, very much like we did it in the early days. They know all about what’s possible using modern tooling, yet they choose to expend their time and attention to the craft of doing it by hand. They care about the craft, and they care about what they’re making. They believe in their unique skill and vision over engagement strategies and analytics and content algorithms. They don’t need a platform, or they’ll build their own.
There’s a power imbalance at work here that’s hard to ignore. Large “AI” companies, the ones with billions in venture capital, send their bots to harvest free content. Not only from big publishers or Wikipedia, but from small, independent websites, too. But we, the people running these sites – often as passion projects, as ways to freely share what we’ve learned, as digital gardens we tend in our spare time – we’re the ones paying for the bandwidth and server resources to handle all those additional requests while those companies profit from the training data they extract. It’s an asymmetric battle: small systems absorbing the demands generated at an entirely different, industrial scale.
There have been so many advances in HTML, CSS and browser support over the past few years. These are enabling phenomenal creativity and refinement in web typography, and I’ve got a mere 28 minutes to tell you all about it.
I’ve been talking to Rich about his Web Day Out talk, and let me tell you, you don’t want to miss it!
It’s gonna be a wild ride! Join me at Web Day Out in Brighton on 12 March 2026. Use JOIN_RICH to get 10% off and you’ll also get a free online ticket for State of the Browser.
I really enjoyed this chat with Marc:
I recently sat down with Jeremy Keith for a spontaneous conversation that quickly turned into a deep dive into something we both care a lot about: events, community, and why we keep putting ourselves through the joy and pain of running conferences.