A client came to me recently with a WooCommerce store that felt stuck in 2012. It looked fine on the surface, but the navigation was clunky, with a white flash between every page. A developer they had hired before me tried to “modernize” it by throwing a large JavaScript library at the problem to handle smooth page transitions. That library hijacked every internal link on the site, which broke their Google Analytics tracking and half of their checkout fragments.
My first instinct was to fix the JS bridge. I spent a few hours digging through lifecycle hooks, trying to force the scripts to re-initialize after each page swap, on the theory that the mess was patchable. It was a mistake. I was fighting the browser instead of working with it. What actually fixed the store was stripping the bloat out and leaning on modern CSS architecture.
What modern CSS architecture buys you
We are getting to the point where the browser handles things that used to cost 50kb of script. I have been keeping up with these changes through roundups like the one over at CSS-Tricks. Native View Transitions are the most useful shift so far. Instead of a heavy JS library, you trigger different transitions based on the URL context. Bramus has pointed out that CSS navigation matching is on the horizon, which would mean handling complex page flows without a line of JavaScript.
The other thing I watch developers get wrong is naming. They reach for generic classes like .btn or .card, then wonder why their styles leak everywhere. Namespace everything. If you are building a design system, give it a prefix. It keeps the CSS readable and it heads off the specificity wars that usually end in a hundred !important declarations.
/* The right way to namespace your UI components */
.bbioon-ui-button {
all: unset;
display: inline-flex;
padding: 0.5rem 1rem;
paint-order: markers fill stroke; /* A neat trick for SVG text effects */
}
@property --bbioon-accent-color {
syntax: '<color>';
initial-value: #0073aa;
inherits: false;
}There was also an interesting point about accessibility tokens. Geri Reid suggested annotating design system components with tokens for things like ARIA labels and zoom preferences. On a high-traffic site that is essential rather than optional, because you cannot afford a lawsuit or a frustrated user base. Bake accessibility into the HTML markup and the CSS tokens on day one and there is nothing to retrofit later when it breaks.
Work with the browser
paint-order for better text rendering, displacement maps for the showier effects (Ana Tudor has posted some wild demos of those on Bluesky): the point of both is less code doing more. Interop 2026 is the reason features like these behave the same in Chrome, Firefox and Safari, so the old heavy-handed workarounds are getting harder to justify.
This stuff gets complicated fast. If you are tired of debugging someone else’s code and you just want your site working with the browser instead of against it, drop my team a line. We have probably seen it before.
So, still relying on jQuery for page transitions, or ready to give the native View Transitions API a shot? Your Lighthouse score will notice the difference.
