The JavaScript you can delete in 2026
Tooltips, scroll animations, modals, page transitions - a wave of native CSS features hit Baseline and replaced the libraries. Less code, faster sites.
5 min read
The fastest, most reliable interaction code you can ship in 2026 is the code you don't ship. A run of CSS and HTML features - anchor positioning, scroll-driven animations, the Popover API, cross-document View Transitions - reached cross-browser Baseline this year. Each one replaces a category of JavaScript that a typical site still loads: tooltip libraries, scroll-effect libraries, modal managers, single-page-app routers used only for a page-fade. Deleting that code isn't just tidier. It's one of the highest-leverage performance wins available, because JavaScript is uniquely expensive.
Why this matters now
Two numbers frame the opportunity. First, weight: the median page shipped 697 KB of JavaScript to mobile home pages in 2025, per the HTTP Archive Web Almanac. Second, and more important, cost of execution: the Web Almanac's performance chapter reports a median main-thread time of 1,916 ms on mobile versus 92 ms on desktop - a more-than-20x gap driven largely by script execution on cheaper phones.
That second number is the one worth sitting with. A kilobyte of image is cheap to decode; a kilobyte of JavaScript has to be parsed, compiled, and run on the main thread - the same single thread that handles layout, painting, and every tap the user makes. When that thread is busy, the page looks loaded but ignores input. It's why Total Blocking Time rose even as other metrics improved.
The features below moved this work off the main thread, or removed the need for it entirely. As of 2026 they're not "cutting-edge CSS" - they're Baseline, supported across current Chrome, Safari, and Firefox. Interop 2026, the annual agreement where browser vendors align on a shared test suite, locked several of them in.
The mechanism: where the work actually runs
Take scroll animations - the single clearest example. The old pattern attaches a JavaScript scroll listener that fires constantly and mutates styles as the user scrolls. Every one of those callbacks runs on the main thread, competing with everything else.
The native replacement, animation-timeline: scroll(), hands the entire animation to the browser's compositor thread - a separate lane that keeps running smoothly even when your main thread is busy.
Same visual effect. Completely different performance profile. One competes for the thread that also handles user input; the other doesn't touch it.
What you can delete
Here's the honest before-and-after. Each of these is Baseline in 2026:
| What you were loading JS for | Native replacement | What you gain |
| --- | --- | --- |
| Tooltip / popover positioning | CSS Anchor Positioning (anchor(), position-anchor) | No positioning library; tethering handled by the browser |
| Scroll-reveal / parallax effects | Scroll-driven animations (animation-timeline) | Runs on the compositor; 60-120fps, no scroll listeners |
| Modals, menus, tooltips (show/hide, focus, escape) | Popover API (popover attribute) | Top-layer, focus and dismiss behaviour built in |
| Page-fade transitions (a reason many sites reach for a SPA) | Cross-document View Transitions | Smooth transitions between plain HTML pages - a normal link click is enough |
| Responsive components based on parent width | Container Queries | Components adapt to their container, not the viewport |
Anchor Positioning alone illustrates the shift: it reached Baseline covering roughly 91% of global browser traffic in 2026. A tooltip that used to justify a dependency - with its own bundle, its own bugs, its own main-thread cost - is now three CSS properties.
The cheapest millisecond is the one you never spend. Native platform features aren't just less code to maintain; they run in places your JavaScript can't reach.
Our opinion
We don't think "no JavaScript" is the goal, and we're wary of the absolutism that shows up whenever a new platform feature lands. JavaScript is how you build genuinely interactive products, and frameworks earn their keep on complex, stateful apps. We build plenty of both.
The point is narrower and, we think, harder to argue with: stop paying a JavaScript tax for behaviour the browser now does natively. If a dependency exists only to position a tooltip, animate on scroll, or fade between pages, it's a candidate for deletion in 2026 - and deleting it usually makes the site faster, not just smaller, because you're removing main-thread work on exactly the devices that can least afford it.
The catch worth naming: these features are Baseline, not universal. If you must support older browsers, treat them as progressive enhancement - the tooltip still shows without anchor positioning; it's just positioned more simply. That's a feature of the approach, not a bug. Native degrades gracefully; a broken library usually doesn't.
How Ashvara helps
We build fast websites by default - the kind that pass Core Web Vitals because performance was a design constraint, not a cleanup task. In practice that means reaching for the platform first, measuring real main-thread cost, and only adding JavaScript where it genuinely earns its place. We did it on ashvara.io itself, and it's how we approach every web build.
If your site feels heavy - slow to respond on a mid-range phone, a bundle that's grown for years - a good first pass is often subtraction, not addition. Talk to us and we'll tell you honestly where the weight is and what's safe to remove.
Sources: HTTP Archive Web Almanac 2025 - Page Weight and Performance; Interop 2026; Baseline (web.dev).