The Boring Internet | Terry Godier
You cannot kill a federated thing by killing one node, the way you can kill a platform by changing one company.
Link tags: form
1079
WebKit Features for Safari 26.5 | WebKit
Fixed an issue on iOS and iPadOS where
datalistsuggestions were presented directly over the associated input, obscuring it.
Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions - Jim Nielsen’s Blog
I really like the thinking that goes into this approach. It seems so counter-intuitive at first, but there’s no arguing with the snappy resilient results.
Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.
Two Paradigms for Enhancing HTML Tags | That HTML Blog
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.
The end of responsive images - Piccalilli
Hallelujah! Support for sizes="auto" is finally landing in Firefox and Safari! Praise be!
Alistair Davidson / validation-enhancer · GitLab
Here’s another nice progressive web component for your forms, this time for showing error messages.
Never Lose Form Progress Again :: Aaron Gustafson
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.
The Great CSS Expansion | Butler’s Log
Web development follows a familiar cycle. First we glue together a solution with whatever we have — JavaScript, image hacks, Flash, anything. Then the platform matures, and CSS or HTML eventually makes that same workaround native. Rounded corners, custom fonts, smooth scrolling, sticky positioning: all of these started as JavaScript-heavy hacks before CSS turned them into a single declaration.
We are in another one of those transition moments. A new wave of long-requested CSS features is finally landing, and many of them are explicitly designed to replace patterns that used to require JavaScript. Not as approximations — as first-class platform primitives that handle the edge cases, run in the right thread, and need zero dependencies.
What we think is a decline in literacy is a design problem | Aeon Essays
The choice isn’t between books and screens. The choice is between intentional design and profitable chaos. Between habitats that cultivate human potential and platforms that extract human attention.
ZIP Code First
I mean, I would ask for the country first (because not all countries have zip/postal codes), but the point stands…
Constraints and the Lost Art of Optimization — Den Odell
The entire intellectual and creative output of a team that reinvented personal computing fits in a space that, today, we wouldn’t think twice about wasting on a single font file.
Somewhere in the years that followed we’ve lost the creative solutions, the art of optimization, that being constrained in that way produces.
The best engineers I’ve worked with carry this instinct even when others might think it crazy. They impose their own constraints. They ask what this would look like if it had to be half the size, or run twice as fast, or use a tenth of the memory. Not because anyone demanded it, but because just by thinking there could be a better, more efficient solution, one often emerges.
Performance-Optimized Video Embeds with Zero JavaScript – Frontend Masters Blog
This is a clever technique for a CSS/HTML only way of just-in-time loading of iframes using details and summary.
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.
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.
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.
CSS-in-JS: The Great Betrayal of Frontend Sanity - The New Stack
This is a spot-on analysis of how CSS-in-JS failed to deliver on any of its promises:
CSS-in-JS was born out of good intentions — modularity, predictability and componentization. But what we got was complexity disguised as progress.
Escape Velocity: Break Free from Framework Gravity — Den Odell
React is no longer just a library. It’s a full ecosystem that defines how frontend developers are allowed to think.
Browsers now ship View Transitions, Container Queries, and smarter scheduling primitives. The platform keeps evolving at a fair pace, but most teams won’t touch these capabilities until React officially wraps them in a hook or they show up in Next.js docs.
Innovation keeps happening right across the ecosystem, but for many it only becomes “real” once React validates the approach. Which is fine, assuming you enjoy waiting for permission to use the platform you’re already building on.
Zing!
The critique isn’t that React is bad, but that treating any single framework as infrastructure creates blind spots in how we think and build. When React becomes the lens through which we see the web, we stop noticing what the platform itself can already do, and we stop reaching for native solutions because we’re waiting for the framework-approved version to show up first.
If your team’s evolution depends on a single framework’s roadmap, you are not steering your product; you are waiting for permission to move.
I Built the Same App 10 Times: Evaluating Frameworks for Mobile Performance | Loren Stewart
A very, very deep dive into like-for-like comparison of JavaScript frameworks. The takeaway:
Nuxt demonstrates that established “big three” frameworks can achieve next-gen performance when properly configured. Vue’s architecture allows competitive mobile web performance while maintaining a mature ecosystem. React and Angular show no path to similar results.
And the real takeaway:
Mobile is the web. These measurements matter because mobile web is the primary internet for billions of people. If your app is accessible via URL, people will use it on phones with cellular connections. Optimizing for desktop and hoping mobile is good enough is backwards. The web is mobile. Build for that reality.
Is it Time to Regulate React? – David Bushell – Web Dev (UK)
React exists as a profound perversion of the web platform. React has failed upwards to widespread adoption because it provides a “developer experience” that bypasses the hard parts. Like learning HTML, or CSS, or JavaScript. Even learning React itself is discouraged; that’s for adults, you should use meta-frameworks. React devs are burdened with multi-megabyte monstrosities before they’ve written a single line of code. You cannot fix “too much JavaScript” with more JavaScript and yet React devs are trained to
npm installuntil their problems become their users’ problems.