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…
Link tags: browser
882
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.
Reduce the JS Workload with no- or lo-JS options
This is an excellent one-stop shop of interface patterns:
This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.
What’s new in web typography? | Clagnut by Richard Rutter
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.
CSS in 2026: The new features reshaping frontend development - LogRocket Blog
Jemima runs through just some of the exciting new additions to CSS:
Replacing 150+ lines of JavaScript with just a few CSS features is genuinely wild. We’re able to achieve the same amount of complexity that we’ve always had, but now it’s a lot less work to do so.
And Jemima will be opening the show at Web Day Out in Brighton on the 12th of March if you want to hear more of this!
Try text scaling support in Chrome Canary - Josh Tumath
There’s a new meta tag on the block. This time it’s for allowing system-level text sizing to apply to your website.
699: Jeremy Keith on Web Day Out – ShopTalk
This episode of the Shop Talk Show is the dictionary definition of “rambling” but I had a lot of fun rambling with Chris and Dave!
dead framework theory | AI Focus
This is depressing.
The Main Thread Is Not Yours — Den Odell
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
Why we teach our students progressive enhancement | Blog Cyd Stumpel
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
NoLoJS: Reducing the JS Workload with HTML and CSS - Web Performance Calendar
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
The Web Runs On Tolerance – Terence Eden’s Blog
Spot-on observations from Terence linking the fundamental nature of parsing in web browsers with the completely wrong-headed takes of some technologists who have built on top of the web.
I’m speaking at Web Day Out 2026 - Manuel Matuzovic
The core idea of the event is to get you up to speed on the most powerful web platform features that you can use right now. I love that because it aligns perfectly with what I’ve been working on over the last couple of years: finding ways to break old habits to get the most out of CSS.
Web Backstories: Shadow DOM | Igalia
Eric Meyer and Brian Kardell chat with Jay Hoffmann and Jeremy Keith about Shadow DOM’s backstory and long origins
I enjoyed this chat, and it wasn’t just about Shadow DOM; it was about the history of chasing the dream of encapsulation on the web.
The only frontend stack we should talk about
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
Reimagine the Date Picker – David Bushell – Web Dev (UK)
This is a superb way to deprecate a little JavaScript library. Now that you can just use HTML instead, the website for Pikaday has been turned into a guide to choosing the right design pattern for your needs. Bravo!
Pikaday is no longer a JavaScript date picker. Pikaday is now a friendly guide for front-end developers. I want to push developers away from the classic date picker entirely. Especially fat JavaScript libraries.
A (kind of) farewell to the web – Web Directions
We’ve arrived at an industrialised process, one that’s like an assembly line for applications. Frameworks like React have become the machinery of that assembly line. They enable us to build efficiently, to build at scale, to build predictably. But they also constrain what we build.
But what aren’t we building? What new kinds of experiences, what new kinds of applications, what new kinds of interaction could we create if we were deeply exploring and engaging with the capabilities of the platform? I don’t know, because we’re not building them. We’re building what the frameworks enable us to build, what the assembly line can produce efficiently.
Collectively, as an industry and as a profession, consciously or not, we’ve chosen this maxima that we’re stuck on. We can build what React or Vue or Next or name your framework/library enables us to do.
I share John’s despair at this situation, but I don’t share his belief that large language models will save us.
ChatGPT’s Atlas: The Browser That’s Anti-Web - Anil Dash
I love the web, and this thing is bad for the web.
- Atlas substitutes its own AI-generated content for the web, but it looks like it’s showing you the web
- The user experience makes you guess what commands to type instead of clicking on links
- You’re the agent for the browser, it’s not being an agent for you
It’s very clear that a lot of the new AI era is about dismantling the web’s original design.
Write Code That Runs in the Browser, or Write Code the Browser Runs - Jim Nielsen’s Blog
So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”
V7: Video Killed the Web Browser Star | Rob Weychert
Grrr… it turns out that browsers exhibit some very frustrating behaviour when it comes to the video element. Rob has the details…