WordPress Core Interactivity API: What Changes for Plugin Engineering

WordPress core’s Interactivity API changes the default assumption plugin engineers have relied on for two decades: that front-end interactivity means either hand-rolled jQuery or a full framework bolt-on. Neither is true anymore, and the plugins that adapt first will ship lighter, faster front ends than the ones still shipping a framework runtime for a dropdown menu.

What actually changed

The Interactivity API gives blocks a standardized, declarative way to handle client-side state and reactivity directly through data attributes and a small, framework-agnostic runtime already loaded in core. No enqueueing React. No separate build step for a component that just needs to toggle a class on click.

What this means for existing plugin codebases

Plugins that shipped their own JavaScript framework for admin or front-end interactivity now carry dead weight core already solves. That’s not an urgent rewrite — but it’s a real signal for the next major version bump. We’re auditing every client plugin’s front-end interactivity layer against three questions: does this still need a full framework, does it duplicate something core now ships natively, and does removing it reduce the plugin’s total JS payload without breaking behavior.

The update-safety angle

The bigger win isn’t performance — it’s maintenance surface. Fewer custom JS dependencies means fewer things that break silently on a WordPress core update. Plugins built against core’s own interactivity primitives inherit core’s own update discipline instead of fighting it. That’s the actual argument for adopting this early: not because it’s new, but because it’s one less thing your engineering team has to keep in sync by hand.