#190 – Seth Rubenstein on Block Composability in WordPress’ Future

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, block composability, what it is and how it’s shaping WordPress’s future.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Seth Rubenstein. Seth is the head engineer at the Pew Research Center, where he leads a team of developers managing the organization’s WordPress based publishing platform for its news site. Passionate about open source, Seth ensures that everything his team builds not only meets the Pew Research Center’s needs, but also benefits the wider community. By actively contributing to the Gutenberg project, he strives to share their solutions, always asking how their work can be given back to help others in the WordPress ecosystem.

Seth shares fascinating stories from the work he’s been doing recently. He breaks down what block composability means, the ability to build modular, reusable, and even interactive blocks that work seamlessly together, empowering both developers and end users to create sophisticated web applications within the familiar WordPress block editor.

The conversation gets into some of WordPress’s newest, and most promising, features including the Block Bindings API, Block Bits, which is still very much in development, and the Interactivity API. Seth explains how these tools open a world of possibilities, like building interactive quizzes, dynamically updating content, or even prefetching data, all using blocks, without having to rely on custom React front ends, or heavy server side processing.

Seth also talks about the path forward for democratizing these advanced capabilities, discussing current limitations, the potential for new UI tools, and what’s still missing in the quest for truly responsive device contextual blocks.

Throughout the episode, Seth makes a compelling case for why now is a golden opportunity for developers and plugin builders to start experimenting, get involved, and shape the next evolution of WordPress as a cutting edge web application platform.

Whether you’re a developer curious about the future of Gutenberg, or an editor dreaming of more drag and drop web app power, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Seth Rubenstein.

I am joined on the podcast by Seth Rubenstein. How are you doing, Seth?

[00:03:40] Seth Rubenstein: Very good. How about you?

[00:03:41] Nathan Wrigley: Yeah, good. Nice to have you back.

[00:03:42] Seth Rubenstein: Yeah, second time.

[00:03:43] Nathan Wrigley: This doesn’t happen too many times. I’ve got to be perfectly honest with you, the audience, I’ve already said this to Seth. Each time I come to WordCamp US, I’m always confounded by how remarkably clever people are, and the depth of the content is sometimes beyond me. I think this is one of those examples.

I think there’s a high chance that you are going to have to shepherd me. There’s probably going to be a lot of editing, when I pause and you explain what you are talking about. So let’s get into it. First of all, tell us a little bit about you, where you work, what you do in the WordPress space.

[00:04:10] Seth Rubenstein: Sure. So I work for Pew Research Center. I’m the head of engineering there. I manage a team of four other developers, and I like to tell people that we work with and on WordPress every day.

We manage a publishing platform for a small news site in the US, Pew Research, but we also contribute to Gutenberg. Everything that we do, everything that we build day in and day out, we try to do from a perspective of how can we open source this? How can we contribute this back to Gutenberg in some way? What can we build to fulfill our needs that would also fulfill other people’s needs?

[00:04:39] Nathan Wrigley: You said a small organisation, the Pew Research Center. I don’t actually know what they do.

[00:04:44] Seth Rubenstein: We are a nonprofit, call ourselves a fact tank. What we do is we survey the American public on a variety of issues. Where are they on things like abortion, or religion, or crime, or the economy, or the use of AI, whatever. And we like to kind of say we hold up a mirror to the American public to tell them what they believe back to them.

[00:05:04] Nathan Wrigley: And so is the WordPress website that you have with them, is that a mechanism to distribute that data back to the public?

[00:05:09] Seth Rubenstein: Yes, yes.

[00:05:10] Nathan Wrigley: Okay, that’s interesting. So it’s a data heavy industry that you are dealing with.

[00:05:13] Seth Rubenstein: It is. It is. We’re very, a kind of academic research institution, but we publish in kind of a news oriented way.

[00:05:21] Nathan Wrigley: Okay. So we figured out a little bit about you, however you are here at WordCamp US to do a presentation. I actually don’t know if you’ve done it

[00:05:28] Seth Rubenstein: I have, yeah. I did it the other day.

[00:05:29] Nathan Wrigley: How did it go?

[00:05:29] Seth Rubenstein: It went okay. I had a problem with my speaker notes, so I had to ad lib a good bit of it. So it might not be as coherent, or clear as it should have been.

[00:05:41] Nathan Wrigley: Well we’re here to fix that. You can ad lib all you like here. So it was called, and forgive the pronunciation if I get this wrong, Block Composability: The Past and The Future. I’m actually just going to read the blurb into the record. And I’ll also make sure that there’s a link in the show notes to the page at the WordCamp US website where you can find out about the content. And also if by the time this comes out a WordPress TV episode with your presentation has landed, then I’ll mention that as well.

Gutenberg excels at crafting beautiful static content, but what if you could empower anyone to build dynamic, interactive web experiences directly within the Block Editor? This session dives into block composability, a powerful concept that enables the creation of rich, interactive content using blocks, making advanced web development accessible to even less technically inclined users, which begs the question, what is block composability?

[00:06:31] Seth Rubenstein: Block composability, I guess let’s define composability first. Composability in computer science and in software development is the idea that you can create and assemble web applications with reusable components in a modular way. That’s really all that means.

If you’ve ever used React, if you’ve ever written in React, it means React Component, really. It’s a self-contained modular unit that can act on its own, but when plugged in with other units, it becomes something new, or extend its functionality or changes its functionality in some way.

[00:07:01] Nathan Wrigley: When Gutenberg dropped, I had this notion that we were going to see mini apps inside of a block. So for example, I had this notion that right off the bat, so I’m going back to 2018 or something, when Gutenberg was still a, so prior to when it was in Core, let’s go with that. And I had this notion that you would drop in, let’s say a real estate block, and that block would encapsulate all the information about this particular house. And you would drop in the block and it would ask you a bunch of questions about the house and out would come a house custom post type, if you like.

However, what happened was we got paragraph blocks, and we got an image block, and we got these fairly, well, useful, but they do one thing. They do a paragraph. They do an image, and that seems to be kind of where it ended. Are you trying to draw a line in the sand where it’s possible to go beyond that simple, does one thing, paragraph, image, to more the, we have a real estate block with loads of different facets and capabilities?

[00:07:57] Seth Rubenstein: That’s right, yeah. I think where we’re at now is we’ve reached a point where the block editor, Gutenberg, in both its block editor and site editor kind of flavors, is you can build web applications. Blocks can do something now. They’re not just presenting text or an image and they’re kind of static and, you know, maybe you can style them differently from one post to another, but now they can actually do something.

And more importantly, they can communicate with one another. You know, one block is adjacent to another. It can tell that block what to do when you click on it. If it’s inside of it, it can change its functionality accordingly. So you might imagine, we have a quiz builder. That’s actually one of our, probably our most technical product.

And the way it works is there’s a results block where you can build out your results page for your quiz, but if you were to drop in a special block for, we have a special quiz that does scoring a very specific way, well, it changes the scoring functionality in the quiz builder. It doesn’t overwrite that. If you take that block out, the scoring functionality returns back to normal.

So now we’re at a point where it’s very much possible to build web applications in the block editor with blocks.

[00:09:00] Nathan Wrigley: So this little quiz block that you’ve described, if I was using, so ignore the developer experience and everything that you have built, the technicalities of all that. If I was somebody that was working for the Pew Research Center and I was, I don’t know, an editor and I needed to create a quiz, would that be my process? I drop in the quiz block, and boom, I have a quiz.

[00:09:20] Seth Rubenstein: It’s really simple. You would go into, we do kind of store it all in a nice post type. So there’s a quiz post type. And then you open that up, you say, I want to go make a new quiz. And by default, there’s a quiz, we call it the quiz controller block that’s there first. And we have a few templated things in there for you. So like a start page and a question, an answer, and all of those things are block. So a question is a block, and inside of that question goes the answers for that question. That’s a block.

Go further than that, we also have these kind of bindings. So you drop an answer in, well, there’s text for the answer, right? What if you want an image in there? What if you want a chart? What if you want a video? What if you want some other interactive piece of content to be corresponding to that answer? Well, you can drop that in too. And you can kind of freely move all these things within an answer, while still having that text bound to the answer block.

So it’s a highly technical product, but for the editors, for the designers, it is literally just drag, drop, drag, drop, drag, drop. Create a page, create a question, type in your answer.

[00:10:16] Nathan Wrigley: So in the world of 2018 that I alluded to a moment ago when the block editor launched, it feels like there were big missing pieces that prevented what you’ve just described. And maybe they’re APIs. I think possibly in some scenarios they are. What are the bits more recently, I don’t even know if it’s more recently in all honesty, but what are the bits that have enabled the features that you’ve just described?

[00:10:38] Seth Rubenstein: Sure. So I think it’s funny that you bring back to 2018 because we built Quiz Builder in 2019. I think I’ll go on the record here and say, I think it might be the first kind of product in Gutenberg that was drag and drop building web applications. So I think we kind of pushed really early on the idea of composability inside of Gutenberg.

And I see it as, there are kind of three waves in Gutenberg. First was, okay, Gutenberg is a CSS generator. That’s how I first kind of imagined it. You’re creating content and you have a style system and that outputs some CSS for your site.

And then we got, I think the kind of HTML part of that a few years later. With the site editor and the theming inside of the block editor and things like that.

And now we’ve gotten to the JavaScript part of Gutenberg. Where WordPress has the Inactivity API. And so this is a WordPress native JavaScript framework, so blocks can do something on the front end. And I think that is really the key innovation that’s really opened this up in just the last 12, 16 months.

[00:11:35] Nathan Wrigley: Are there any APIs that have enabled you to short circuit? So again, in 2018, I would imagine there was quite a lot of heavy lifting that you needed to do order to pull that off, to innovate in that way. Are there any things which have fallen, I think quite recently actually, that have enabled it to be more available to developers who don’t have the time available that you did?

[00:11:56] Seth Rubenstein: Yeah, I mean, so in 2019 when we did this, you know, all we really had was this ability to kind of scaffolded out these quizzes. The were pretty static in their layout. You drop a question and there were the answers in there, and you could type them in and that was it. No images inside the quiz, nothing like that.

Now, thanks to things like block bindings, block bits, which we can go into in a little bit.

[00:12:18] Nathan Wrigley: Yeah, we’d need to I think.

[00:12:19] Seth Rubenstein: And the Interactivity API, you know, it is, everything is less static. Everything is less set in stone now. With things like the HTML Tag Processor, you can say, oh, this answer has this flag on it so we’re going to change out some of the HTML in it, in kind of real time before it gets to the front end for users. That just really wasn’t possible before, without a lot of work. It wasn’t very performant.

Now all those things are in place for developers to really tap into. And the documentation and examples are there too, because that was the problem before, I think, is that a lot of people had to figure out how to do this, and now there are real world examples out there.

[00:12:52] Nathan Wrigley: So you mentioned, quickly skirted over three things there. So there was Block Bits, Block Bindings, which I think the full title would be Block Bindings API, and the Interactivity API, which I think is like a child of the HTML API. I’m not entirely sure about that, but.

[00:13:07] Seth Rubenstein: It utilises the HTML components.

[00:13:10] Nathan Wrigley: Okay. Let’s just go through what those three things are in whatever order suits the purposes of this podcast best, because I don’t know which one you’d start on.

[00:13:16] Seth Rubenstein: Let’s start with Block Bindings API. I would actually imagine a good number of people are familiar with this. This has come up a lot in the last year in the Gutenberg project. What that really lets you do is use Core blocks more effectively.

For example, before, if you wanted to have a button and you wanted to do a very specific thing and look a very specific way, well, good luck. You had to make your own button. Sure there was the Core button and you could style it to some degree, but what it did was it went to a link.

Now with things like Block Bindings, you can say, okay, well, I have my Core button and I’m going to style it however I want, but the interior text, you know, what it says, what it does, well, that can be done kind of programmatically on the backend. That’s where the Block Bindings API comes in. It lets you use Core blocks and change them, well, not Core blocks, any blocks, really, and change them to fit your needs.

[00:14:07] Nathan Wrigley: Can you give us a concrete example of that? So you’ve just talked about the button, you mentioned a sort of, I was struggling to grasp what you were meaning about changing the text programmatically. How would you do that? What would be an example?

[00:14:18] Seth Rubenstein: Let me give you an example of that, Core paragraph. Very useful with block bindings. And I mentioned answers. So we have this answer block, right? And before it just had a text field in it. You would type in the answer and that was it. That was all you saw. And that meant that you couldn’t do anything inside of the answer. You couldn’t provide any other content inside there, because that would then get rolled up as the answer.

So now with Block Bindings, what we have is we have this core paragraph binding that you can drop into the answer, and it is a text field still. You can type into it. It’s storing that on the answer block and then you can put other stuff inside the answer block because we’re not reading what’s in there as the content.

What that meant for us is that we didn’t have to go make another block called answer text. We have hundreds of these kind of scenarios in our system where, yeah, we need a very specific use case, and it’s usually just some text, right, somewhere. Why would I make another block that’s just a paragraph block, really?

So bindings, it makes blocks way more extensible. So one block can perform multiple functions if you need it to.

[00:15:19] Nathan Wrigley: So my takeaway from that, it may be ignorant, it kind of adds a layer where you can add more features into any block, Core or otherwise. So in the example of paragraph, it’s like paragraph plus. It’s extended paragraph if you like, and you then get to decide. And that is the binding bit. You bind things to the block.

[00:15:39] Seth Rubenstein: You bind attributes in a block.

[00:15:40] Nathan Wrigley: Attributes.

[00:15:41] Seth Rubenstein: That’s what it really effectively comes down to, is you bind attributes. So you could say that the text, the content attribute, in Core paragraph, well, that’s not coming from whatever you typed in there. It’s coming from some other programmatic interface somewhere in your system, your plugin, whatever.

So that lets you use Core paragraph as a layout element, put it wherever you’d like, but then what’s inside of it, and perhaps even what happens when you click on it, well, that’s decided elsewhere.

What’s nice about that is it lessens the number of controls that you need to present to the end user, to the designer, to the editor. For them, they just drop the block in there. The plugin handles the bindings. The plugin handles, okay, the text for this paragraph inside this answer should come from here. They don’t have to think about all that. So it’s less settings for them actually. It’s more just drop blocks in.

[00:16:27] Nathan Wrigley: You are very much in the weeds of all this, so I suspect the fact that you’ve done this and done this over and over again renders it fairly straightforward. How available is this? Is the documentation there?

[00:16:38] Seth Rubenstein: Oh yeah. The documentation is there. The WordPress Dev Blog has a number of tutorials on Block Bindings. And I think once you get started with it, it’s extremely easy to work with really.

[00:16:47] Nathan Wrigley: Okay, so that was Block Bindings. Next one was Block Bits. Now I’ve only heard this phrase a couple of times, so you’re going to have to go 101 on this.

[00:16:54] Seth Rubenstein: Sure. So Block Bits is, this is an API that is very much in development. It’s a concept more than anything else right now. So with Block Bindings, we can kind of take over a whole paragraph block and change it all out. Well, what if you just need to change one word inside that paragraph? That’s where Block Bits comes into being.

So this could be you have typed out your sentence, and maybe there’s a name in the sentence. And you need to change that name dynamically based on whatever the user’s choosing in this front end interface. Well, Block Bits, you just select the text, you go to the toolbar, you say, I’m going to bind, quote unquote, this to this thing.

And Block Bits, the concept is, okay, we’re going to look inside of a block, down to a bit, maybe just a character and do something with that. Change it, make it a button, whatever. That’s really all it is. It’s a fancy name for taking Block Bindings to the next level, which is kind of inside a string of text.

[00:17:50] Nathan Wrigley: Okay. So it is, again, forgive me if I’ve parsed it incorrectly, but a Block Bit is a binding inside of some other thing. So in the example you gave, swap out this string for a different string, or it could be swap out this image dynamically for a different image, or, I don’t know, insert a dollar sign here instead of a pound sign or.

[00:18:15] Seth Rubenstein: Well beyond that, beyond just the switching things out, the other kind of powerful part of the concept, and that’s where I think the API part is really still in development, and this will take a little bit further is, one of the examples used in the Gutenberg project is things like ISBN numbers.

So you can imagine that, you know, maybe you’re running some sort of library like site, you type in an ISBN number. Well, what you want to happen on the front end is maybe a little bit more complex than that. So you type in your ISBN number and the block bit could see that that is an ISBN formatted number, and maybe on the front end it becomes a link with a little popup that goes to the Library of Congress, point to that thing, right?

So it’s very analogous to Block Bindings, but it’s very much very specific small string inside of a larger string. So they give it as sub block bindings. Maybe that’s even a better term for it. Maybe that’s what would be called in the future. But I really think of it as sub block binding.

[00:19:10] Nathan Wrigley: And presumably then you can just chain these together inside, well, let’s go with a paragraph. You could just have a one sentence just full of these block bits. So one followed by another, followed by another. Okay, that’s really interesting. So you could have a whole sentence, for example, just made up of bits from all over the place.

[00:19:28] Seth Rubenstein: Well, and you could imagine that, beyond just like pulling information, it could be really useful when what we’re using it for currently is templating, right? So you want this string, this sentence to have these parameters. Maybe it’s got the format of your post type, and then maybe it’s got the title in there, and then maybe the date. But maybe that’s all on one line and not three different blocks.

One of the things that drives me crazy right now is, let’s say I want to do a post date, post type, kind of above the post title. I insert a row block, and then I insert my date block, and then I insert my meta block. That’s like a lot of divs, that’s a lot of markup for that. It’s like, why isn’t that just one paragraph line with that bit of information in there? That’s where block bits comes into play.

[00:20:08] Nathan Wrigley: So it feels like, again, forgive me, it feels like the kind of thing that we would’ve used custom fields for in past. And we would’ve had, I don’t know, dozens of custom fields, each containing their own discreet bit of data, and we would’ve had to have figured out a way to drop those into this paragraph. Now this is all handled natively.

[00:20:25] Seth Rubenstein: Yeah, and visually in the editor.

[00:20:26] Nathan Wrigley: Visually in the editor. And so it could be anything. It could be markup, it could be text, it could be an image, it could be, I don’t know, XML, anything you like. That’s really powerful.

[00:20:36] Seth Rubenstein: It’s exciting. It’s very powerful, and it’s the API that I am most looking forward to seeing completed. I think it will really, without getting too technical, you go a little bit further, Block Bits, Block Bindings. These things I think are kind of critical for responsive blocks. If we’re going to change attributes at kind of a micro level based on certain conditions, like those are the kind of frameworks that we need to be able to do that.

So beyond just like the content and templating stuff, there are deep technical reasons that these APIs continue to be developed out.

[00:21:07] Nathan Wrigley: Okay, I think I’ve grasped what that is. Just running the clock back a couple of minutes, you imply, no, I think you said that this is in development more so than Block Bindings. So the block bits is ready to use.

[00:21:20] Seth Rubenstein: No. There’s very much in a conceptual phase, and I think there’s a lot of other technologies that need to be finished out. There are work on the HTML APIs, even though they’re really well advanced now over the last couple years, there’s more work being done on those. I think those things are kind of blockers to keep pushing forward with the Block Bits. But you can start doing Block Bits today. And I do go over that in the presentation.

What it really comes down to, fundamentally today is, it’s a rich text custom format, which you can do today. You can go in and make your own kind of custom formats inside the rich text component. You know, that might be bold or italic, a custom format. So it’s really simple as like, okay, well, I have a custom format that adds a class name to something, and then the HTML tag processor, I look for that class name and I change it out. Bingo, bango. So simple.

But of course, like I said, Block Bits is much bigger than that. There’s an idea of kind of like a library of bits and, you know, you can plug it into different data sources and post meta and this and that and the other thing. But right now at least, you can start to experiment with this idea, with templating and kind of getting dynamic bits of content into a string.

[00:22:28] Nathan Wrigley: This feels very much to me, like the kind of thing that needs more eyeballs.

[00:22:31] Seth Rubenstein: It does.

[00:22:31] Nathan Wrigley: It’s one of those things where you let loose a thousand developers and suddenly some curious thing that nobody thought of occurred and it was like, oh, it does that.

[00:22:40] Seth Rubenstein: Yeah. I really want to get people to experiment with this concept further, because I think we need to push it further because it’s just so powerful.

[00:22:48] Nathan Wrigley: Yeah, really interesting. Okay, so we did Block Bits. We did Block Bindings. I think the final one that we mentioned was the Interactivity API.

[00:22:55] Seth Rubenstein: Yeah. So the Interactivity API, that is about, it’s probably about two years old, I think, at this point. I won’t go into all the history of that, but it is effectively a WordPress native, Preact framework. It’s really easy to work with. You kind of just write basic HTML and the JavaScript is very easy to get into.

And what that allows you to do is really add interactions at an atomic level to blocks. You can write all sorts of functions. So you might imagine you have a form block, and it has an on submit action. Not every form does the same thing, right? So maybe you have another block, could be send to Firebase. You drop that in there and it changes, it can actually hoist up its own on submit function into that blocks interactivity. And so it makes it really easy to kind of swap JavaScript functionality in and out, and extend functionality across all your blocks.

[00:23:47] Nathan Wrigley: So it, I guess the easiest way that I parse this was it enables you to have things doing things to other things. That was profound. Things doing things to other things in the same interface.

[00:23:59] Seth Rubenstein: Yeah.

[00:23:59] Nathan Wrigley: You click a button and, I don’t know, the cart increments by one or something like that. So this kind of thing that really, in the year 2025, given that we’ve had mobile phones in our hands for decades, this sort of stuff feels like it should have been in websites for decades, but it wasn’t.

[00:24:12] Seth Rubenstein: Yeah. And the other exciting thing about it is it’s not just about telling blocks what to do. I find it very interesting that it can communicate data across blocks. So I’ll come back to Quiz Builder as a really good example. We just rebuilt that with all of these things, Block Bits, Block Bindings, Interactivity API. That just got completely revamped in the last couple months. Before that, what we were doing is we were building out a custom React front end for every single quiz.

So the users would go in, they would drag and drop, you know, build up these quizzes. And then on top of that, we were recreating all that for a new front end interface. And we had all this service side processing to kind of build up a data model for the quiz and then score the quiz, and we made a performant as we could be, but it wasn’t.

[00:24:55] Nathan Wrigley: It’s a lot.

[00:24:55] Seth Rubenstein: Yeah, it’s a lot. And it’s a lot of like duplicative work and you’re like, what for? With this, it’s now the Interactivity API. Those blocks actually, you know, the answer block just hoists its answer into this larger data model using the Interactivity API.

So now all that happens client side. So now all these things that we were doing server side, we can do client side with the Interactivity API, and that saves us money, that saves us performance. It yields a better experience for the end user.

[00:25:19] Nathan Wrigley: So over the last 10 minutes or so, we kind of atomised these three things, Block Bits, Block Bindings, Interactivity. We kind of talked about them as separate things, which I guess they are. But from your experience, I’m guessing that they work in concert really well. In other words, if you understand, if you get into the weeds of those three things, and maybe some other things, you prize open capabilities in WordPress which are pretty profound.

[00:25:43] Seth Rubenstein: Yeah, well, obviously one of the things that I love most about WordPress is it’s flexibility. Let’s use Block Bits as an example. This kind of pseudo block bits I’ve just described, where you register a custom format and then you use the HTML Tag Processor to switch that out. Well, the way that we’re switching it out is using the Interactivity API.

So all we do is we say, okay, we look for that class name, we use the HTML Tag Processor, and we add the Interactivity API bits that we need to it. We just say, well, the text value should be this, state dot button text, right? That’s really easy. But you could do it with block context too.

So there are all these tools in WordPress, all these different APIs related to blocks that once you start to connect them together, you get composability. I mean, that’s what it really comes down to. This ability for developers to build blocks that can be, one, reusable, that’s really important concept for composability, two, stand on their own, right? A button block should do something if it’s on its own. It should go to a link or something. But if that button block is dropped into another block, it’s nestable, well its configuration changes. Now it submits for the form, right? It doesn’t go to a link.

We’re at this place where just, there’s all these tools available to you when you start plugging them all together, really powerful stuff happens.

[00:26:53] Nathan Wrigley: Yeah. And I guess it’s like anything, once you’ve made those connections in your own head and done the hard work to understand them all, suddenly ideas begin occurring to you that maybe in a podcast like this, you get to the very edge of that, but you don’t get into the weeds of that. But once you’ve peeled it back and understood it, suddenly, aha, I didn’t realise WordPress could do all of this.

One of the things that I’m curious about, because I’m no developer, I kind of have a desire for this stuff to become available to non-developers. And at the minute it feels like you would really need to be a developer to build this stuff. Obviously you can surface it in a way that a non-developer can access. So your quiz, for example, I’m guessing I could interact with that almost immediately and understand it. Would there be any utility in building a UI for this so that these kind of things can be accessed?

[00:27:36] Seth Rubenstein: I think so. We have our own UI for this. We have an Interactivity API panel that we actually have on all of our blocks that have interactivity enabled. And what it does is it does allow us some interesting things for end users that they don’t have to know about.

So one of those things is you can drop a block into a block that supports interactivity. And the panel shows you all the blocks in the hierarchy that you can connect to. And so you might say, okay, well I want to connect to this, and then I want to pull this action from that interactivity store for this block.

So now we’ve enabled it so that it’s not the developers making all the Interactivity API connections. You know, this does this when it’s in this block. Actually, you can go in there and decide that for yourself if you want.

Now obviously that does still require a developer to hook that all up, but what you already see today with Block Bindings is a very similar panel. When you go use a Block Binding today, there’s a little panel called attributes. You click it, it shows you all the attributes you can connect up to a binding. That’s part of Gutenberg and WordPress Core right now.

So I think that interface is already there, and I think as more Block Bindings and plugins start to utilise that, the interface is already there for really people to kind of make these interactivity connections themselves.

[00:28:50] Nathan Wrigley: I suppose I’m kind of thinking back to the day when WordPress shipped for the first time, custom post types. I presume lots of people made use of them. It might be analogous to where we are at now with this, you know, people who are experienced can use it. But then somebody, some bright spark, came up with the idea of a custom post type plugin with a UI, and this way of just making it visually appealing and straightforward.

And when you were talking about this sort of, it felt almost like a flow chart that you were building there, where you’ve got, here’s the options, just sort of clicking on them with a mouse and dragging it so this feature now goes to this feature, and I’m binding this to this, that’s what I was imagining. You know, something really straightforward. Drop dead simple, non developery.

[00:29:29] Seth Rubenstein: Well, I will give a plug for my friends at Automattic. Part of my session was also sharing a product that we’ve built called Remote Pivot Table, which lets you kind of make really quick pivot tables out of Google Sheets so the data’s not living inside of WordPress, so that our researchers can really quickly update these data sets, and we don’t have to do a thing to get the updates. Well, that’s built on Automattic’s new Remote Data Blocks. And it actually does exactly what you’re saying.

You go in there, you tell it what your data sources are. Airtable, Google Sheets, Shopify, Custom HTTP endpoints if you want, and it will go create the blocks for you. It will create the bindings for you, and it’ll create the interface for you so that you can select, okay, well, when I’m building out my interface, you know, this text goes to this binding. It should pull from this value from that Google sheet. So that’s actually already out in the wild right now.

[00:30:18] Nathan Wrigley: What was it called?

[00:30:18] Seth Rubenstein: Remote Data Blocks.

[00:30:19] Nathan Wrigley: Okay.

[00:30:20] Seth Rubenstein: It’s on the WordPress plugin repo. I think they just published it this week.

[00:30:23] Nathan Wrigley: I’ll remember to put that into the show notes. I will dig that out and make sure that that gets into the show notes.

Yeah, I kind of feel like, even if we were to build the perfect UI, I still feel for most people this may end up being the domain of, get the developer to do it.

[00:30:38] Seth Rubenstein: Yeah, it is very much in the domain of the developer. These are all developer APIs for them to build out tools for others. And I think ultimately what these APIs allow is for developers to make products that are easier to use for the end user. Like I said, less settings, less controls, less all these sidebar panels and stuff, and more just, you drag and drop the block in and in the background, through the Interactivity API, through Block Bindings, through Block Bits, you’re configuring how that application should work. So it’s more of just drag and drop for the end user.

[00:31:09] Nathan Wrigley: The features exist, you’d need to sort of go and figure out how to make it work. I guess we’ve got all these Block Bindings, we’ve got all these Block Bits, we’ve got this enormous complexity that we could get into. How performant is all of this?

[00:31:22] Seth Rubenstein: Extremely.

[00:31:23] Nathan Wrigley: So my fear is you just get carried away and you bind everything to every other thing, and where a bit is available, you make a Block Bit. I can’t summon up an example, but you get the point. You just get totally carried away. The performance, I would assume there is some hit, but it sounds like not so much.

[00:31:40] Seth Rubenstein: I don’t think so. I think the performance is actually better for a lot of these things. All of our Interactivity API projects, like technical performance is substantially better than if we had just built out a React frontend ourself.

Because think about the weight of that. I mean, React is pretty heavy, one. Preact on the other hand, which the Interactivity API is built on is very lightweight. But additionally you have this, I guess the other element which we really kind of haven’t defined is the HTML Tag Processor. That is what underpins all of these things, all of these APIs, even the Interactivity API, even though that’s JavaScript,

When you are writing in the Interactivity API, you can write state and context and all these values in HTML, the HTML tag processor that’s reading that, that’s processing it. And it does it so extremely fast. You know, if you’ve worked with a PHP DOM document, it’s slow, it’s very bad. This is not that. This is extraordinarily fast.

In addition, on the technical performance, when you’re using the Interactivity API, you get speed on the front end as well, because what you can do is you can pre hydrate information into your JavaScript application before it even loads, on the server side, which is really exciting.

You can see this today actually. Core query, the query loop, and the pagination. Those use an Interactivity API. When you hover over the two or the next page, what’s happening is there’s an Interactivity API function for prefetch. So you’re prefetching the next page of results. So for the user, boom. They click on it, boom. The results are already there. You go a little bit, further, you can cache that information. So now the user has pre fetched the next page and they’ve cached it for the next person to come to this page. That just really wasn’t possible before.

[00:33:18] Nathan Wrigley: No. Is that kind of leaning into sort of core browser technologies as well?

[00:33:22] Seth Rubenstein: Oh yes.

[00:33:22] Nathan Wrigley: Yeah, I’m just thinking of things like.

[00:33:25] Seth Rubenstein: Well, the prefetch thing is part of the browser technology. I’ll give you an example. We have this very large religious census we do every decade called the Religious Landscape Study. It’s extremely complex database with a lot of querying, and a lot of SQL logic. If we were to, you go to a page on this database and there’s maybe like 12 charts. Well, if we were to load all those 12 charts on page load, like it would take a couple minutes to load the page. The site would probably crash.

But what we do is, as a user hovers over a chart before they click on it, we prefetch, it and we cache it. So for them, they click it, it’s instantaneous. But also we’ve now done the extra work of waiting for the next person, that’s already waiting there ready for the next person. I cannot state how important this innovation has been for the performance of our site and the Interactivity API.

[00:34:12] Nathan Wrigley: That is actually fairly profound, isn’t it? Yeah. Sometimes when you are explaining these things, the penny kind of half drops. And then a moment later, the penny drops fully and that one’s just hit. That’s actually really profound, isn’t it? Especially on a high traffic site where you don’t really want to be doing that thing a thousand times a second, just do it once, more or less.

[00:34:34] Seth Rubenstein: I have a philosophy of if I can offload it to the end user, I’m going to. You know, I’m going to use your computer if I can.

[00:34:41] Nathan Wrigley: That’s fascinating. Okay, so pivot slightly. Do you think there’s a opportunity here? I expect there’s a bunch of developers listening to this who either haven’t experienced this before, haven’t played with it, and are thinking, okay, I want to wrap a UI around that. I want to build a plugin to make this stuff available. We kind of alluded to this a minute ago. Do you think that there is an opportunity there for developers to kind of neaten this interface up?

[00:35:02] Seth Rubenstein: Oh, yeah. Oh, yeah, absolutely. I would be very excited to see where the future of this lands for the WordPress ecosystem. You think of plugins like Advanced Custom Fields and what that did for WordPress, right? It was obviously possible to register post meta and all this stuff before, but what a hassle. It just was. And it really opened up WordPress as a content management system in a way that no other plugin had really done before.

So some very smart person, some enterprising person out there, there is an opportunity here to kind of build out something that would do that for the Interactivity API and empower less technically inclined people and maybe just not technical people at all to use this.

[00:35:39] Nathan Wrigley: Yeah. Because despite the fact that you’ve explained it really clearly, and I’ve got a grip on it, I suspect that I wouldn’t want to go through all of the weeds to connect all of those pieces. And I don’t want to open up a code editor. I want everything to be point, click, type, inside of WordPress, in a really straightforward, well-designed, beautifully thought through interface. Kind of like gold rush territory I think. Maybe there’s an opportunity here for someone, maybe multiple people.

Yeah, and it’s what you said before about these kind of custom post type plugins, there’s many of them and I think without them, nobody would’ve been using custom post types, well, not nobody, but a tiny proportion of the people would’ve started to use them. And I feel the same a bit here. I feel like the things that you’ve described, they’re fabulous, technically, conceptually brilliant, but if somebody was to come up with a UI that made them not just conceptually brilliant, but drop dead easy to use, we’ve got something really incredible.

[00:36:35] Seth Rubenstein: Yeah, absolutely. Yeah, I mean, look, when I first started in WordPress, I didn’t know how to do custom fields, custom post types. You know, ACF helped me out there. And I do them all by hand now, right? I register all my post types and my post meta by hand. But those sort of plugins that make it easier for, well, not even if you’re less technically inclined, you’re busy, you don’t have the time to learn all these new APIs, it really does help out adoption down the road.

[00:37:00] Nathan Wrigley: And also you can imagine scenarios where people build out pre-configured versions of a thing. So that you might have templates for, I’m struggling to conceptualise that but, you know, you download this plugin, whatever it may be, and they’ve pre-configured useful scenarios that are repeatable. And you just, okay, click a button, that gets me 90% of what I want to do and then I go from there, kind of thing. Yeah, that’s interesting.

In terms of the bits and pieces that you’ve described, is there anything which you think might be missing? I know that’s a difficult question to answer because I’m asking you to stare into a crystal ball and come up with the future. But is there any kind of concept in here that you’ve thought, you know what, it’d be really handy to have that?

[00:37:37] Seth Rubenstein: I think it’s responsive. Responsive blocks, responsive attributes.

[00:37:41] Nathan Wrigley: Describe what that is because in my head, as soon as I hear responsive, I think viewport width.

[00:37:45] Seth Rubenstein: Yeah, and I think that’s exactly what I’m talking about. You know, I think all of the APIs are here. All the bits are in place to make that happen, the work just needs to be done. There’s actually a function in the Gutenberg source code for, I think it’s called update attribute on screen size or something like that, where you can kind of, desktop, tablet, mobile changes attribute to match for that viewport size.

I think this has been the Achilles heel for Gutenberg. It’s the constant complaint that I hear out of people. And I think that is really the missing link, the, last thing that would really make Gutenberg perfect.

[00:38:19] Nathan Wrigley: So scenarios where you could literally change anything based upon, I don’t know, we’re on a tablet now, so what we had on a desktop is no longer appropriate. Again, I’m struggling to conceptualise what that might be, but again, the same on mobile.

[00:38:32] Seth Rubenstein: I’ll give you a good example. We have our own grid block, columns block. We made our own grid block because we do this responsive attribute stuff. You might have three columns that are x width on desktop, and then on tablet, well, you might want that middle column actually to move to the first position to be 100% width, right? That’s a really easy example, but doing that right now is next impossible without having a developer build out that system for you. That’s just one thing I can think of, but there are a myriad of instances like that.

[00:39:01] Nathan Wrigley: Yeah, the domino fell a bit there. I understand what you mean. So yeah, it could be width, it could be background colour, it could be font size or content, anything.

[00:39:09] Seth Rubenstein: A number of things, yeah. Well, it could be also in the Interactivity API. It could be that, you know, on tablet, actually I want, when you click on this thing, I want it to do something else entirely.

[00:39:16] Nathan Wrigley: The button does a different thing.

[00:39:17] Seth Rubenstein: Yeah.

[00:39:17] Nathan Wrigley: Yeah, okay. That’s really interesting.

[00:39:18] Seth Rubenstein: Well, I’ll give you another example. We do that. Well, not to that degree, but Core social links. We wrap that in another block called Navigator Share Link. So when you’re on mobile and you click on the Facebook button, we’re not taking you to the Facebook share little window. We just open up the little native browser share thing. You just send it off to your app or whatever, friends, your iMessage, whatever you want to do.

So I think that kind of device contextuality is one area where there’s not a lot of guidance or APIs or anything, and that is kind of entirely on the developers to figure out themselves. But I think that’s probably what’s missing most from Gutenberg, is that kind of idea of screen or device contextuality.

[00:40:01] Nathan Wrigley: I just think this is all so fascinating. Essentially, during the last 40 minutes or so, you’ve prized open, I think a really different future for WordPress than I had previously thought. I knew all these things existed. I hadn’t really connected the dots. And it feels to me as if suddenly you go from building a bunch of websites to anything. Literally anything. If it’s possible to put in a browser.

[00:40:27] Seth Rubenstein: It’s a web application framework.

[00:40:28] Nathan Wrigley: Right. There you go. Yeah. A web application. Build anything inside of WordPress, which is not something that I was all that familiar with. Gosh, the future is bright.

[00:40:37] Seth Rubenstein: I mean, we have blocks where people are, you know, drag and drop them together and they’re building out little calculators. You know, one of our more popular content types is like, put in your income and where you live, and then we’ll tell you some information about you, you know, about your area or whatever. That’s a web application. That’s not a blog post. That’s not content. That’s a web application that someone just drag and drop built.

Yeah, we’re at a place, you know, the content management stuff of WordPress, man, that’s rock hard. That’s settled. Now we’re going into another era, a new direction where WordPress is this web development framework, first and foremost. For you, the developer, but also your end users to build web applications with, inside of.

[00:41:19] Nathan Wrigley: Yeah, absolutely fascinating. So my intuition that I alluded to at the beginning of this podcast, in 2018 or whatever it is, that promise has now become reality. The year 2025, we got there. And now it just needs a bunch of developers, hopefully, dear listener, if you’re listening to this, get on board and try to figure this out and make it straightforward so people like me can use it.

Seth, I think that’s probably the sweet spot to end it. That’s a very optimistic future you’ve painted there. Where do we find you, if somebody’s listening? I would imagine that there’s a bunch of people listening to this thinking, I need to speak to Seth.

[00:41:51] Seth Rubenstein: You can find me at sethrubenstein.info. And you can find me on Twitter or Bluesky. Please find me on Bluesky, though, I hate Twitter.

[00:41:57] Nathan Wrigley: We will drop the links into the show notes. So if you head to wptavern.com, search for the episode with Seth Rubenstein, that’s S-T-E-I-N, search for that and then the links will be there for Seth’s socials, plus anything to do with the talk that we’ve been mentioning as well. Seth Rubenstein, thank you so much for chatting to me today.

[00:42:15] Seth Rubenstein: Thank you for having me.