Stop shipping JavaScript for things browsers now handle natively. A practical audit guide covering dialogs, scroll behaviour, and the Baseline API signal.
The average production web app is still hauling JavaScript for problems the browser solved two years ago. Not because the engineers are lazy — because nobody stopped to re-read the spec.
Smashing Magazine’s Jad Joubran put it cleanly: the gap between “you need a library for this” and “the browser does this” keeps closing, and most teams aren’t auditing fast enough to notice. The Baseline project — a cross-browser compatibility signal maintained by web.dev — now offers a structured way to determine which web platform features are safe to ship without polyfills or JS workarounds. The practical implication is straightforward: before you reach for a dependency, check whether Baseline marks it as widely available. For Southeast Asian teams shipping to heterogeneous device ecosystems across Indonesia, Vietnam, and the Philippines, where mid-range Android hardware is still dominant, this matters doubly. Smaller bundles translate directly to faster Time to Interactive on constrained networks.
The <dialog> Element Is Production-Ready — Stop Rebuilding Modals in JavaScript
CSS-Tricks contributor Geoff Graham recently published a thorough audit of the <dialog> element, and the nuances are worth sitting with. The element ships native focus-trapping, backdrop rendering, and accessibility semantics that teams routinely rebuild from scratch in React or Vue. The showModal() method handles stacking context correctly — something custom modal implementations frequently get wrong, especially when layered over third-party widgets. The ::backdrop pseudo-element gives you CSS control over the overlay without a DOM node. Baseline marks <dialog> as widely available. If your codebase contains a custom modal component built on div + aria-modal + a focus-lock library, you’re shipping code the browser replaced. The migration path isn’t trivial — you’ll need to audit existing ARIA attributes and keyboard behaviour — but the dependency reduction is real and the accessibility baseline actually improves.
CSS scroll-axis-lock: none Replaces a Whole Category of Scroll Hacks
Bramus Van Damme documented a newly shipping CSS property — scroll-axis-lock — that disables the browser’s default scroll railing behaviour, allowing immediate diagonal scrolling in 2D scroll containers. Scroll railing is the mechanism that prevents accidental horizontal drift when you’re scrolling vertically; it’s helpful until you’re building a spatial interface, a map component, or a drag canvas where diagonal movement is intentional. Previously, teams patched this with JavaScript touchmove event handlers, often introducing 16ms+ input latency penalties on mobile. A CSS property declaration costs nothing at runtime. For teams building app-like experiences on Shopee’s mini-program infrastructure or LINE’s LIFF environment — where smooth scroll performance is a visible quality signal — this is the kind of platform primitive worth tracking. The property is currently in the process of landing in Baseline; check the compatibility table before shipping to production without a fallback.
The Baseline Audit Workflow: A Practical Starting Point
The mechanism Joubran outlines is essentially dependency archaeology. Take a mid-sized marketing site: run a bundle analyser, isolate the top five dependencies by size, and cross-reference each against the Baseline API. You’ll typically find at least one or two libraries that were added to solve a browser compatibility problem that no longer exists. Common culprits include: dialog polyfills, custom focus-management utilities, ResizeObserver shims, and scroll-behaviour libraries. The process isn’t glamorous, but the output is measurable. Joubran’s examples consistently surface 20–40KB of removable JavaScript — which, on a 3G connection delivering to a Vivo Y-series device in Jakarta, translates to roughly 300–500ms of parsing time. That’s not a marginal gain. One structural caveat: Baseline’s “newly available” tier (features supported across all major browsers for less than 30 months) still warrants a usage-share check against your specific analytics. If 8% of your traffic runs Chrome 98 on Android, “newly available” may not be your threshold.
Design Architecture Is a Performance Decision
The Chems Studio case documented on Codrops — a film-led archive built on a quiet, flexible digital framework — illustrates something the JavaScript-reduction conversation often misses: performance isn’t only a bundle-size problem. It’s an architectural decision made at the design stage. A site that presents creative video work to a Southeast Asian audience needs to load fast enough that the first frame of video actually plays. That means the surrounding shell — the navigation, the archive grid, the modal overlays — needs to cost as little as possible so the media budget can be spent on the content itself. The choice to build a “flexible digital framework” rather than a feature-heavy CMS shell is, in performance terms, the correct one. Native <dialog> for lightboxes, CSS scroll properties for archive navigation, and a ruthlessly audited JavaScript payload aren’t aesthetic choices — they’re what makes the experience viable on the devices your audience actually holds.
Key Takeaways
- Run a Baseline audit against your top five JavaScript dependencies before your next sprint — the browser has likely replaced at least one of them natively.
- Migrate custom modal implementations to
<dialog>for native focus-trapping, backdrop handling, and accessibility semantics without additional JS weight. - Treat bundle-size reduction as a design constraint from the start, not a post-launch optimisation task — especially for media-heavy experiences targeting mobile-first Southeast Asian audiences.
The interesting pressure here is organisational, not technical. The browser platform is moving faster than most teams’ dependency-review cadence. The spec keeps shipping. The question is whether your frontend audit process moves at the same pace — or whether you’re still carrying polyfills for a web that ended two years ago.
At grzzly, we regularly surface exactly this kind of payload bloat during technical audits for brands across Southeast Asia — the JavaScript that made sense in 2022 and silently costs conversion rate today. If your team wants a structured look at what your front-end stack is actually shipping to users, let’s talk.
Sources
Written by
Stormy GrizzlyStress-testing email open rates, dissecting Apple's Mail Privacy Protection, and auditing the JavaScript payloads quietly leaking signal. The analyst who reads the spec, not just the summary.