Beneath Frameworks: Trust the Web's Primitives

Every time you add a framework dependency, you’re betting that library will outlast your project. Meanwhile, the web platform ships features that browsers commit to supporting forever. The gap between what frameworks provide and what native browser APIs now handle has narrowed dramatically.

This article examines specific web platform primitives that reduce framework dependency—and how to evaluate their readiness using Baseline as your guide.

Understanding Baseline Web Features

Before adopting any native browser API, you need a reliable way to assess cross-browser support. Baseline provides exactly this. A feature reaches “newly available” status when it ships in the latest stable versions of Chrome, Edge, Firefox, and Safari. After a sustained period of availability across those browsers (roughly 30 months), it becomes “widely available.”

This matters for progressive enhancement decisions. Baseline tells you when a feature is safe to use as a primary implementation versus when it should remain a fallback-enhanced experience.

You can verify the current cross-browser status of any web feature on the Web Platform Status dashboard at https://webstatus.dev, which tracks Baseline classification and browser support in one place.

Native Browser APIs Replacing Framework Patterns

The Popover API for Modal and Tooltip Patterns

React developers often reach for libraries like Radix or Headless UI to build accessible popovers. The Popover API, now a Baseline newly available feature, handles this natively:

<button popovertarget="menu">Open Menu</button>
<div id="menu" popover>
  <p>Menu content here</p>
</div>

The browser manages focus trapping, light-dismiss behavior, and top-layer rendering. No JavaScript required for basic functionality. Feature detection is straightforward:

if ('popover' in HTMLElement.prototype) {
  // Use native popover
} else {
  // Fall back to framework solution
}

View Transitions for Page Animations

Single-page applications exist partly because multi-page navigation felt jarring. The View Transitions API changes this equation by enabling smooth transitions between DOM states:

document.startViewTransition(() => {
  updateDOMSomehow();
});

For cross-document transitions, CSS alone can opt pages in:

@view-transition {
  navigation: auto;
}

The View Transitions family is now Baseline newly available for same-document transitions. Browsers without support simply skip the animation.

The Navigation API for Client-Side Routing

Framework routers like React Router exist because the History API was awkward. The Navigation API provides a cleaner model for intercepting navigation:

navigation.addEventListener('navigate', (event) => {
  event.intercept({
    handler() {
      return loadContent(event.destination.url);
    }
  });
});

The Navigation API is now Baseline newly available, but that doesn’t mean you should rip out your router tomorrow. It means you can start evaluating where native navigation primitives can simplify your stack—especially for lighter “app-like” experiences.

Modern CSS Features Eliminating JavaScript

Anchor Positioning

Positioning tooltips and dropdowns relative to trigger elements traditionally required JavaScript calculations. CSS Anchor Positioning handles this declaratively:

.trigger {
  anchor-name: --trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  top: anchor(bottom);
  left: anchor(center);
}

This feature is not yet Baseline-available across all major browsers, so use it strictly as a progressive enhancement with JavaScript fallbacks where needed.

Container Queries and :has()

Container Queries are widely available and let components respond to the size of their container rather than the viewport—removing a lot of brittle JS layout logic.

The :has() selector is newly available and unlocks patterns that previously forced JS-based “parent awareness” and state reflection. Because it’s not widely available yet, it may still warrant caution depending on your audience—but it’s now a real option to build on with measured fallbacks.

Declarative Shadow DOM for SSR Web Components

Server-side rendering Web Components previously required hydration gymnastics. Declarative Shadow DOM solves this:

<my-component>
  <template shadowrootmode="open">
    <style>/* scoped styles */</style>
    <slot></slot>
  </template>
</my-component>

The shadow DOM exists in the initial HTML payload—no JavaScript execution needed for first render. This is now newly available and usable in modern browsers, but older Safari versions in particular may require fallbacks.

Progressive Enhancement as Architecture

The pattern here isn’t “abandon frameworks.” It’s recognizing that web platform primitives now handle specific problems that previously required abstraction layers.

Feature detection enables this approach:

1. Check if the native API exists
2. Use it when available
3. Fall back to framework solutions when not

This follows long-standing progressive enhancement principles and reduces bundle size for capable browsers while maintaining functionality everywhere.

Conclusion

Audit your framework dependencies against current Baseline features. The Popover API, View Transitions, modern CSS capabilities, and Declarative Shadow DOM address real problems that justified framework code just two years ago.

The web platform evolves slowly but permanently. Features that reach Baseline status represent stable ground. Build on that foundation, and augment only where the platform genuinely falls short.

FAQs

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.