Milana Cap, a WordPress engineer at XWP and active community contributor from Serbia, discussed two major developer features: the Interactivity API and the HTML API. Both are changing how developers build interactive, performant WordPress sites by reducing reliance on bespoke JavaScript solutions and bringing server-side capabilities back into play.
Who Milana Is
Milana works with enterprise clients at XWP, freelances via Toptal, and contributes to WordPress documentation and plugin review. She enjoys speaking at conferences and promoting practical features developers can use today.
Why the Interactivity API Matters
Before Gutenberg, PHP-generated pages had visibility across their parts—headers, footers, content could interact. With Gutenberg blocks, content became componentized: blocks were isolated, unable to communicate. Developers built many ad-hoc solutions to bridge blocks; those were inconsistent and hard to extend.
The Interactivity API provides a Core, standardized way for blocks to share data and react to one another. Blocks can broadcast data and other blocks can consume it via a common API. That solves problems like updating a cart count when a product button is clicked, syncing favorites, or keeping video playback running while navigating apparent page changes.
Notable examples:
– A “movie” demo (an introductory Interactivity API showcase) mimics a Netflix-like site where favoriting a movie updates counters, a trailer continues playing in a minimized player across navigations, and page changes feel instantaneous because only necessary parts are re-rendered rather than fully reloading the page.
– Core features already using Interactivity include the paginated Query block and the image block’s lightbox option.
– Typical Ajax use cases—pagination, lazy loading, UI toggles—can be implemented via Interactivity API to give the same “no full reload” user experience without bespoke JavaScript infrastructure.
Developer experience and adoption
Documentation is available and improving. The conceptual shift—understanding where to place interactive logic and how blocks communicate—can take some experimentation. A single line of code in the right block can propagate state to many consumers, so best practices and thoughtful placement matter. The API is not “finished” in the sense of ongoing improvements and new use cases, but it’s production-usable and already in Core. Contributors can explore the Gutenberg repo’s Interactivity API showcase issue to see ideas and get involved.
Why the HTML API Matters
The HTML API underpins Interactivity and enables server-side HTML processing. Two primary classes are available:
– HTML tag processor: lets PHP modify HTML attributes in Gutenberg block markup (useful for setting attributes on images, iframes, accessibility attributes, adding/removing classes).
– HTML processor: more powerful and aware of full tag structures; it can insert/remove nodes, wrap or unwrap elements, and modify inner content.
Previously, many HTML manipulations were done with client-side JavaScript or brittle regex. The HTML API lets developers perform robust DOM-like manipulations on the server using PHP, producing the final HTML directly and avoiding extra client-side rewrites. That reduces requests, improves load times, and avoids the pitfalls of regex-based HTML handling.
Practical benefits and examples
– Replace common JS DOM tweaks: things like adding classes or tagging certain internal links can be done server-side more reliably and faster.
– Enterprise gains: for high-traffic sites, reducing JavaScript and client-side processing saves milliseconds per request which, at scale, significantly improves performance and cost.
– Cleaner code: the API follows HTML standards, handles edge cases that regex misses, and produces maintainable server-side logic instead of obscure regex or client-side patches.
Status and maturity
– The tag processor is optimized and in use; teams have already deployed it to solve real problems (e.g., removing nofollow attributes on internal links with simple server-side rules).
– The fuller HTML processor still needs optimization and further work before being considered fully production-ready in every scenario, but development is ongoing.
– Interactivity API is shipping and used in Core features, though it will continue evolving as new needs arise.
When to use which approach
– Use Interactivity API when you need block-to-block communication or parts of a page to update without a full reload (e.g., favorites, cart counters, persistent video playback, paginated queries).
– Use the HTML API when you need deterministic, server-side HTML transformations—modifying attributes, wrapping elements, removing or inserting nodes—especially at scale or when avoiding client-side JS is a priority.
Getting involved
Developers interested in contributing or experimenting should check the Gutenberg repository and Interactivity API showcase issue for examples and community discussion. Playing with examples and placing logic thoughtfully across blocks helps learn optimal patterns.
Final thoughts
Both APIs bring WordPress closer to modern interactive expectations while preserving server-side robustness. Interactivity restores page-wide awareness to componentized content, and the HTML API provides a powerful, maintainable way to manipulate HTML on the server. For developers, especially those working on enterprise projects, these tools can simplify implementations, improve performance, and standardize interactive behavior across plugins and themes.
