Why Block Bindings & Interactivity API Usher in a New Era in WordPress

In the marketing hoopla for Etch you will get to hear Kevin Geary talk about “era 4 in page builders”. Kevin’s view of the “eras of page building” is interesting and worth considering. He talks about era 3 as effectively “reaching the limits” of what is possible with a UI and how in his view era 4 is a move towards a kind of hybrid development environment where the UI supports development, but where code is also available. There are aspects of this breakdown that I agree, but I come to a vastly different conclusion about what it means.

When I last heard some guy (who I won’t name because he seems like a polite and decent guy) bragging about how “everything is UI-based now in dev, and people with no coding experience can just do everything with an editor” I reacted about the same way as many others. Bewildered. As somebody who codes everyday and who makes UI’s that generate code, I view the no/low code as a market opportunity. However I also know that it takes upwards of 50K lines of professionally written code to empower non-coders to do basic things with a UI. I would describe the accurate % of capability of low/no code as being somewhere around 1-1.5%. Meaning whatever I can do with code, you can do 1.5% if you’re really, really advanced with your editor of choice. And that’s great. I’m glad you’re willing to buy tools, study docs, maybe even dedicate your career, to mastering 1% of a craft. You are what I would describe as, very special indeed. So no, I’m not in the camp of “UI’s can do everything, why bother coding”. In my experience in 23-years of site development I have never seen a project worth over 1M that didn’t meet the following criteria:

• Custom WordPress theme (the theme industry is huge, the marketing is big, but nobody ever made a profit using 3rd party themes)
• No page builder, or limited page builder usage in isolated parts of the site (the page builder market is huge, the marketing is big, but nobody ever made a profit using page builders).
• Site managed by a professional developer. Almost always under the management of a professional technical project manager or equivalent professional with strategic planning skills. I’ve seen founders with specific backgrounds fill that role temporarily, but not permanently. Knowing if you actually have the right skills to manage development is something not enough business owners ask themselves.

I will clarify that of course I’m not saying individuals cannot build basic websites, nor am I discouraging hobbyists or learners in any way. People start sites for lots of reasons aside from commercial, although how often somebody really wants to build site “just for fun” is a little bit questionable. Playing around with web dev may be fun for a few hours, but is it really fun when you’re hundreds of hours into it and you have a long list of bugs and issues to fix? The fun can definitely wear off. We’ve seen this for instance with Lovable, in one single month they lost nearly 50% of their entire user base. Why? According to most reports it was simply that people had tried it because it was fun to watch AI spit out partly functional stuff, but then most people realized this game is boring… there are no points, there is no levelling up, it’s just the same thing over an over again. Very boring game. And good luck trying to make 1 single penny from something you generate from AI. Why would that have any value?

Back to the “eras of page building” idea. To me this is the evolution of page builders (at least in WP specifically):

1. Page Builders 1.0 were the clunky horrible things that were particularly terrible for developers to have to work around and were used almost exclusively by cheap clients who were hoping to replace their developers. For most this did not have good results at all. In this era only the most unhinged idiots adopted the page builders and then put a sign up outside that read “Professional Developer for Hire”. At this point pretending to be a developer by clicking around a UI was very difficult. It would have made more sense to just learn how to copy/paste, which is what real developers did at the time.
2. Then there was Elementor. My view of page builders changed the moment Elementor arrived. I wasn’t alone. Clients were thrilled by this new tool. And yes it even won over developers. I looked at the PHP code in Elementor and thought wow, this is impressive. I’m still impressed by the principled engineering that forms the foundation of Elementor. As for the UI, well it was first time I saw a UI where you could actually match a design. And this (technically) was driven by it’s control system, the inputs (PHP classes at their root) which were then automated to build out CSS and JSON storage. It was a masterpiece of engineering. I am always rather shocked about how people act as if Elementor is some underpowered or weak tool. I think it suffers (reputationally) the same challenge as WP and PHP. Nobody respects things that dominate the market. PHP is still number 1 in web dev, but everybody says it’s dead. WP is still number in CMS, everybody says it’s outdated and deprecated. People talk about Bricks and Gutenberg, but Elementor is so firmly in #1 and nothing has even dented its positioning. Elementor’s weakness however is that it is a “2d/limited” approach. It’s really precise in terms of design control, but it does not fully support the hierarchical (3d) structure of the web which the latest editors try to do.
3. Levels Up. The concept is put things inside of things and then put things inside of those things. Or as Jerry from Seinfeld once said “I’m working with levels now Jerry, nothing is on the floor, it’s all levels and more levels”. Supporting the same hierarchy that the web is actually built with makes sense. Every widget/element/block should effectively be like an HTML tag, or like a React component. Imagine how limiting React would be if it didn’t support infinite hierarchy. Nobody would have ever bothered with such an approach, because when working with code we expect to be able to build trees without any limitation. Now in theory, a page builder like Bricks would just entirely wipe Elementor off the map. But did it? No. Because it turns out that at least so far, making page builders work more like the web, makes them complexified and annoying. If people wanted to slowly build up a structure of HTML one element at a time, they would probably download a code editor. The tedious nature of nesting stuff and configuring it, only to realize you need slightly different structure so now you have to shift everything around again and now the styling is wrong again… most people don’t actually want to do that. Elementor let’s them drop stuff in and it more or less just works. Each thing fills part of the screen, and it’s therefore quite rapid to just drop in more stuff. Currently the Gutenberg editor despite having the theoretical advantage over Elementor through the support of infinite hierarchy, has only a fraction of the design control. Therefore the only real competitors Elementor has are still other commercial options like Bricks. And while many professional users lean towards Bricks and are willing to invest more time into learning and accept higher level of complexity, Elementor is still the easiest tool for the sea of dumb masses.
4. RAV (Rapid Visual Automation) tools. The most powerful tools of the future (both inside and outside WordPress) will combine the weapons new and old rather than entirely replacing anything. AI is a powerful machine for building any software, site or plugin. At any level AI can be leveraged to generate code, test code, debug code, provide developers with massive increases in efficiency, and ultimately build vastly more complex systems than what was possible before. It is of course worth noting that the limiting factor in AI usage is that it requires a fairly big investment into tooling to restrain, guide and manage AI tools. You can build something partway by just firing up Claude Code. You can never finish anything, not even the simplest project, without some kind of guardrails. And while the world is fascinated by “generation” (using AI) the old but stable concept of “automation rules” is more true than ever. For instance we find that despite all the hype around MCP, which might be useful in some rare instances, it’s usually better to communicate with a system by having AI create it’s own functional access using traditional methods like REST API’s. Yes, REST for the win again as usual. It’s like with PHP and WP, the more things change, the more we keep winning. And yes, you can invest into MCP and connections to MCP, or you can just build more API routes and get AI to write code that utilizes them. Using AI to write code, taking that code through a principled development process, results almost always in a more valuable and reliable end result. And so automation continues to be the way. And what RAV tools will do is give users more visual insight (observability) during development processes where are moving quickly, and the goal is to build things fast, without entirely breaking everything you already have in the process. And because AI coding has the strength of speed, we find the most helpful tools are not focused around increasing speed. We already have the speed. AI is already generating code faster than we can really test and process it anyway. So what we need is tools more fitted to the workflow of development. And of course many great tools exist already. ClickUp with it’s big brain is doing some amazing things, using that big bankroll to snap up several important AI ventures. I personally want to see, and hope to build, tools that live in WP and that are available through open source so that the long tradition of OS leading the way in web development continues. Which I think it will. And Gutenberg, despite it taking a long time to mature and still lacking some really important capabilities, is going to be a big part of that continued evolution of WP.

Thank you for reading the introduction to my post. I just realized now that I have not actually mentioned Block Bindings or the Interactivity API yet. My bad. How do these API’s affect the future of page building in WordPress? Both involve working with dynamic data. They work in very different ways, and while they have some overlapping use cases they are designed to solve different problems. What they will do in reshaping the marketplace for page builders is that they make “dynamic data” free. It may have taken a long time, about 9-years if you go right back to the origins of Gutenberg, but they are at or near the game changing moment where the support for dynamic solution in the editor is equal or greater than any other tool. From my perspective as a developer, Gutenberg already vastly surpasses anything else in the market in this specific category.

The data sources aspect of Block Bindings is well designed. It makes it possible to access and feed any data, including arbitrary data or remote fetched data, into the editor where blocks can access it. It won’t be long until every single plugin that has data will feed it through data sources into the editor. Every single column from the WP database can also be fed into the editor through data sources, although core might not decide to support this kind of blanket coverage. Is a list of passwords from the user table a good idea anyway? But you get the point, if you know a bit of PHP you can make a SQL query, call a function to create a new data source and bam, you have just integrated that data into the editor. Currently the support from core blocks in accessing that data is relatively weak, but expected to increase in 7.0. More important longer term however is that every block kit and anybody building blocks, can make their blocks bindable and the core does provide a UI. Making bindable attributes is not that difficult (achievable for a moderate level dev), and although AI isn’t trained on this now with some context provide it’s not impossible to vibe code a custom block with binding support. The UI is really the crux in making this all accessible and fostering adoption. Developers, mostly 3rd party commercial devs will handle providing the sources and the blocks. Having the UI from core means consistent and immediate capacity without any tedious or costly work that would slow down adoption.

Then there is the Interactivity API. If you haven’t used it as a developer you might think of it as being mainly for effects or animations etc. And while it can be used to replace front-end JS that in WP is still often jQuery based, that’s not the only monumental innovation in the interactivity API. The use of interactivity revolves around “stores”. Not only can stores hold functions that might run an animation or process the click from a button, but just like in React land, stores can be thought of as “data stores”. They can house and make data available via context. And this makes them huge problem solvers. Because when you want to build sophisticated modern interfaces, you need to solve the ever-changing nature of data. The old school handling of data found in PHP-oriented templating is “load it, render it”. That’s it. Need to change it? Write jQuery or custom vanilla JS. Not great, in fact I feel great pain if there are any humans on the planet still doing that. Not only is it very limiting to layer JS on top of what is effectively “dead rendered markup”, but it’s actually far more work to write small JS solutions in such a situation than it is to learn React. And for me personally, I went with the “learn React” approach and today nothing is faster for me than building UI’s in React. But that doesn’t mean we should build everything in React. There is still no way (so far?) to build create a composable approach to building a UI, and have it rendered out in React. One could in theory build “React rendered Gutenberg blocks”, which is something I once experimented with, but it is very, very tedious. By nature, React requires a build process. On the other hand one of the most important aspects of React is available via the Interactivity API, and that is “reactivity”. React may have a similar name, but it does not own the concept of “reactivity”. This is the capability of having pieces of the DOM bound to the state of the application. In practice this means the user creates a new record, and the grid table updates to show the new record. And it does this not because a developer manipulated the DOM to insert the new record, which would be an error-prone and very cumbersome bit of code to write, but instead the table is showing a list of records it access via state, and the state has now been updated. And this means everything in the UI include the count of records is just “magically” (reactively) updated in an instant.

Although the Interactivity API doesn’t have a UI aspect to it, developers can leverage custom blocks to output reactive elements. They can also trigger store creation. As a simple example you can have a parent loop block that fetches data and loops over the child blocks. The child blocks can then be bound to the data store. This is a powerful alternative to block bindings. It not only leverages the power of dynamic data, but it adds in application style UI capabilities. As a result you may soon see WordPress interfaces that look like React apps, but are built instead with the Interactivity API.

Now before touting this too rigorously, I’ll repeat what I wrote earlier which is to me as a PHP/React dev, it’s still vastly faster for me to just work directly in React. So my go to for building a UI for my own site will still tend to be React because I can just build it, enqueue it into my custom WordPress theme. I could go headless if I really wanted to wander around without a head. I view headless in the same category as GraphQL… interesting theory, now prove it. It works for some, but again my case despite working with React heavily I see no point to trade in the very consistent functionality of WP routing and structure for headless which comes with tonnes of new costs and problems that I don’t have with a React-based WP theme. The challenge to building a UI entirely out of blocks is that it still takes a lot of planning around how those blocks will interact and form a structure. There are a lot of questions to answer about how far you go in making the blocks flexible. What styling options to include? Provide fixed styles or dynamic options or?

The limiting factor in Gutenberg adoption for layout use in my opinion is the same as it was several years ago and will never change. People want that “wow I can make useful stuff” reaction when they open it. And it doesn’t have that, because to have that you need 100% CSS coverage. You can’t dabble in styling. You can’t have “a few carefully selected” options. At least, I don’t think that is the way. Maybe it can be, if it’s at the level we see in some of the commercial block kits where they manage to cross the threshold into “matching professional designs”. Right now, I suspect most agencies that use blocks just either make custom blocks so they can style them as needed, or ship separate style sheets. The lack of a coherent “style management system” in Gutenberg is unfortunate. It perhaps belies that in the shorter term the editor was a “work of the ecosystem” but in the long haul, only devs are going to be able to understand it and keep it going. Thus it ends up having “brilliant engineering” and “terribly styling”. The “vast arctic wasteland” design concept for Gutenberg is also widely hated by nearly everybody, and for some reason never changes despite millions of requests for dark mode, or at least some eye drops for every unfortunate soul forced to use the damned thing.

Wait was this supposed to be a pro-Gutenberg article? Well I do really hate using it. I’m using it right now, and it hurts my eyes. At least I’m using it for writing, and in my view it is great for writing. I actually prefer writing in Gutenberg over the Google Drive docs that I actually pay monthly to access. And it is objectively better than Google docs given it has slash-based inserting, and only recently Google added something similar but much weaker.