Which Parts of Today’s Framework Become Tomorrow’s Platform?

The Question I Started With

I started with a stronger assumption than the evidence supported: were standards bodies moving enough framework responsibilities into the platform that much of the framework layer could disappear?

The evidence pushed me toward a better question:

If more framework-era ideas become native primitives, how will responsibilities be redistributed across the browser platform, frameworks, compilers, libraries, servers, and application code?

The investigation is therefore about where responsibilities move, not whether frameworks vanish.

A Working Boundary Between Platform and Framework

The web platform tends to absorb capabilities whose semantics have become broadly understood across many architectures. Frameworks can coordinate those primitives and impose application policy above them.

As native primitives become more capable, frameworks may own less low-level machinery while retaining composition, policy, and application architecture.

Signals: A Primitive Below Framework Policy

The TC39 Signals proposal is revealing because its stated goal is narrower than a native framework-level reactivity system. As of September 17, 2026, Signals remains a Stage 1 TC39 proposal, focused on a common underlying signal graph and auto-tracking model that frameworks could build on top of rather than a complete developer-facing reactive runtime.

A standardized reactive primitive could reduce the need for every framework to implement the same low-level dependency graph semantics independently. It could improve interoperability between reactive libraries, give tooling a shared model to inspect, and potentially support future HTML or DOM work.

But the proposal deliberately leaves effect scheduling, ownership, disposal, batching policy, and rendering coordination above the primitive. That separation matters because it creates the possibility of shared reactive infrastructure without requiring frameworks to share the same rendering or scheduling model:

Web Components: Standard Components, Not Standardized Applications

Custom Elements, Shadow DOM, templates, slots, and related Web Components work give the web a standardized component substrate.

A component can have browser-recognized identity, lifecycle, encapsulation, styling boundaries, and reusable markup without belonging to a framework. But a component model is not an application architecture. Web Components do not determine application state and scheduling, routing and data coordination, server/client execution, compilation strategy, or the organizational conventions used to structure a large codebase.

That was a key correction to my original mental model: standard components establish portable component identity without defining how an application should be coordinated around those components.

Additional Signals From the Platform

Looking across TC39, WHATWG, CSSWG, WICG, the Web Components community, and Open UI, I do not see one unified roadmap whose stated destination is “make frameworks unnecessary.” I see multiple efforts moving different mechanisms into durable platform contracts.

User-journey primitives. The Navigation API provides a modern application-oriented model for navigation and session history, while the CSS View Transitions specification moves visual state-transition mechanics into browser-coordinated primitives. Routers and frameworks can build policy around those mechanisms rather than reconstructing all of them from lower-level browser APIs.

DOM update primitives. Proposals such as DOM Parts explore efficient handles to mutable positions in the DOM, while earlier template-instantiation work explored more reusable templating infrastructure. These remain exploratory, but they show continued interest in moving DOM-update machinery beneath framework-specific template systems.

Control primitives. Open UI studies common controls, component anatomy, state, behavior, styling, and accessibility patterns already repeated across frameworks and design systems, then considers which pieces may belong in HTML, CSS, JavaScript, ARIA, or related platform work.

What Frameworks Still Own: Coordination and Policy

These efforts move mechanisms downward while frameworks retain opinionated coordination. Those decisions cluster into three kinds of policy:

• Execution policy — when work is scheduled, how updates batch, how rendering composes, and how pending or error states propagate.
• Application architecture — how routing, data loading, nested layouts, and server/client execution fit together.
• Developer contract — which templating model, compiler strategy, optimization pipeline, conventions, and developer experience define how a team builds the application.

These are not all missing standards. Many are policy choices: the platform stays general while frameworks deliberately narrow the design space.

The Likely Recomposition

If repeated private mechanisms converge on durable semantics, some may become candidates for shared platform primitives. Frameworks can then reorganize around those primitives rather than privately rebuilding the substrate underneath them.

If that pattern continues:

• reactive libraries could share a standardized dependency graph while keeping their own scheduling, effect, and rendering policies
• routers could delegate more navigation and session-history mechanics to the Navigation API while concentrating on route matching, data loading, and layout conventions
• transition systems could coordinate application state around native View Transitions instead of owning the full visual-transition mechanism
• component systems, design systems, and compilers could increasingly target shared platform primitives while differentiating through composition, optimization, server integration, and developer experience

Framework differentiation then shifts upward: from privately reimplementing substrate to coordinating platform primitives into an application model.

Research Questions From Here

This investigation leaves four questions I want to keep pushing on:

1. What is the minimum useful framework if components, reactivity, navigation, transitions, and more templating infrastructure become native?
2. Which current framework responsibilities are truly missing platform primitives, and which are intentionally application-level policy?
3. Do compilers and meta-frameworks become more important as UI runtimes become thinner?
4. What does a serious application built deliberately around platform primitives reveal about which responsibilities still require framework-level coordination?

Primary Sources Reviewed

• TC39 Signals proposal
• TC39 Stage 1 proposals
• WHATWG HTML — Custom Elements
• WHATWG HTML — Navigation API
• WICG Web Components — DOM Parts proposal
• WICG Web Components — Template Instantiation proposal
• CSS View Transitions Module Level 2
• Open UI
• Open UI Charter