Today WordPress contributor Carlos Bravo officially announced the merge of the Interactivity API into Core for WordPress 6.5. Introduced last year, the team behind the Interactivity API has been releasing builds through the Gutenberg plugin in preparation for this pivotal moment.

What is the Interactivity API?

One of the challenges with interactivity in WordPress right now is that there is no set standard in how developers can approach it. Today, developers pick their tools. They define their approach to integrating with WordPress. They decide on inter-block communication. And, they make choices (and compromises) around frontend performance for every new project they deliver.

The Interactivity API aims to solve these problems. It provides developers with an opinionated approach that standardizes building interactive elements. The hope is that this will make it easier to focus on what to build and not how to build it.

From the original proposal post on Make WordPress Core..

What does this mean for users?

The team behind the Interactivity API use a movie website in their demo. They showcase some of the functionality that users may soon be able to enjoy. Such as the way that multiple blocks can work together to share data. In the demo, clicking a heart button on movies in a list makes a heart counter go up. 

All of this is done instantly. It doesn’t reload the page and no developer or engineering team needs to dive deeply into layers of code.

Imagine building a recipe website. You want a site visitor to build their shopping list with price estimates in their local currency. The Interactivity API would facilitate being able to create all of the dynamic elements using the Block Editor. It lets a list grow and the total cost change as a visitor adds and removes ingredients from their shopping list.

What are the implications for developers?

Beyond the code layer of the API, let’s take the shopping list example a step further. Let’s say the blocks needed to build it have been created by three different developers. The Interactivity API has standardized the way that blocks load and communicate with each other. It creates a consistent, performant user experience.

The original proposal calls this composability and compatibility. It mentions a future state where interactive blocks can be combined and even nested in structures with defined behaviors.

Users have a knack for making code do what they want. Not what it was intended for, ask any QA tester right after a launch. In the future, interactive blocks will work together. They won’t be limited by their original developer. Users will be able to create patterns and interactions that go beyond their original purpose.

The Interactivity API and how it uses WordPress could be a pivotal moment in the Project’s history. It could create a new way of working with WordPress. 

Consider the concept of single-page applications (SPAs). Today SPAs are often complex, expensive and inaccessible to most users. The Interactivity API, once more developed, could lead to a whole new kind of application category built with WordPress. How exciting would it be to unlock these types of patterns for everyday users?

What are the implications for WordPress businesses?

Everyday users will see the most impact from the Interactivity API. As blocks become more interoperable, the kinds of interactions that users can access will grow. Consequently, demand for more feature-rich or complex interactions may also grow.

The Interactions API could unlock a whole new product category to monetize. It could lead to new partnerships as product businesses migrate their interactions to the block level. Think of the enterprise user who may be able to work with a suite of approved blocks. They could build performant, secure, and reliable applications in the stack and user interface they already know.

This is likely only scratching the surface of what could be possible. But it is clear that for WordPress to continue to outpace its rivals, innovations like the Interactivity API will need to continue.