#144 – Damon Cook & Seth Rubenstein on the Transformational Interactivity API

Transcript

[00:00:00] 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, how the Interactivity API will transform your WordPress websites.

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 podcasts 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 Damon Cook and Seth Rubenstein.

Damon Cook is a developer advocate with WP Engine, and previously worked as a front end developer at several WordPress focused agencies.

Seth Rubenstein began his WordPress journey in college, and is now the lead engineer at the Pew Research Center, where he works on interactive WordPress applications.

This is the last of the podcast recorded at WordCamp, us 2024, and our focus today is the interactivity API. You may not be familiar with what this is and why it matters, so Damon and Seth will break it down, and explain how it might transform your WordPress websites in the future.

Damon starts off by defining what an interactive website is, giving examples such as single page applications, and dynamic elements like tabs and accordions. Seth adds his perspective on how interactivity aids both the end user, and website editors. Making for a more compelling user experience and efficient content creation.

We get into why WordPress needed an interactivity API, even though the platform already supports libraries, like React. The interactivity API provides a standardized way to create dynamic content, which is essential for modern web expectations.

We also highlight real-world examples, including faceted searching and filtering, which have been successfully implemented using this API.

The conversation also touches on performance improvements brought by the API, emphasizing how it can offload server resources by only updating necessary content.

Towards the end we explore how the API is being used in Gutenberg blocks, and how it supports both developers and site builders.

Damon and Seth also discussed the project’s development, encouraging more contributions and feedback from the community.

If you’re intrigued by improving your websites’ interactivity and performance, this episode is for you.

If you’d like to find 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 Damon Cook and Seth Rubenstein.

I am joined on the podcast today by Damon Cook and Seth Rubenstein. Hello.

[00:03:40] Damon Cook: Hey, how’s it going?

[00:03:41] Nathan Wrigley: Yeah, really, really nice thank you. That’s Damon.

[00:03:44] Seth Rubenstein: Hello, I’m Seth.

[00:03:45] Nathan Wrigley: Thank you so much. We’re at WordCamp US, it’s happening in Oregon. It is the month of September 2024, and I’m being joined by Damon and Seth so that we can talk about the Interactivity API.

Before we get into that, I think it’s probably important to paint a picture of both of you, what your background is with WordPress technology, et cetera. So we’ll just keep this very brief. Let’s go for Damon first. Damon, just tell us a little bit about you, your potted bio, if you like.

[00:04:10] Damon Cook: Sure, yeah. Well, I started out as a WordPress front end developer at WordPress. There’s several different WordPress focused agencies, and now I’m a developer advocate with WP Engine.

[00:04:21] Nathan Wrigley: Thank you very much. And Seth?

[00:04:23] Seth Rubenstein: My first time using WordPress was in college. I converted all of our websites to WordPress multi-site, as like the assistant web developer. And from there I just kept going, and that was just my career track from then on, just WordPress all the time. And now I am the lead engineer at the Pew Research Center, where we have a WordPress platform that we’ve made ourselves, and we work on a lot of interactive WordPress applications.

[00:04:43] Nathan Wrigley: Just staying on your bios just for a moment, what does the Pew Research Center do? I’ve not heard of them before.

[00:04:49] Seth Rubenstein: We are a non-partisan, non advocacy social science research organisation. So we basically study the American public and where they are, what they think on certain issues. And we do a lot of public polling and things like that, and we report that back. So we’re kind of like a nonprofit news organisation.

[00:05:04] Nathan Wrigley: Gosh, okay thank you. That’s really interesting.

Okay, let’s open it up and talk about the subject at hand today. So we’ve got both of these gentlemen here to talk about the Interactivity API. I think probably we should first deal with the topic of, what is an interactive website?

Probably, dear listener, if you’re listening to this, you might know this already, but I have an intuition that some people won’t. So, what are the benefits of having an interactive website? And whoever wants to answer that, pick up the mic and go for it.

[00:05:30] Damon Cook: I think the classic example is that of a single page application. So the idea of being able to navigate from page to page, or section to section even, and just have things that seem seamless, so the page isn’t refreshing, that is a pretty common scenario. But there’s also lots of other interactive pieces like tabs, accordions, all that stuff gets really helpful when you reach for the Interactivity API in creating stuff like that.

[00:05:59] Seth Rubenstein: I don’t have anything to add to that. I guess what I would say is, on the other side of it besides the front end user, the kind of, your visitor, I think the interactivity part of a website kind of also can help out your editors, and how they’re building content, and making more engaging content.

I think this will be interesting because I think, you know, Damon might have a kind of perspective of the front end user, and I’m definitely coming from a perspective of, how can I scale up my editorial team’s ability to create interactive content? And not so much like what it looks like on the front end.

[00:06:27] Nathan Wrigley: So there’s an interesting distinction there. So, does the work that you are doing touch on both the front end and the back end? So it’s not just for the forward facing, user facing part of a WordPress website. This is things that you can do in the back end, the admin side of things too.

[00:06:40] Seth Rubenstein: Yeah, it’s how editors create interactive bits of content, and how those interactive bits of content might interact with each other. Because I think right now, without the Interactivity API, that kind of content is static and siloed on the page.

[00:06:52] Nathan Wrigley: We will link in the show notes to all of the different places, and no doubt one of the first links will be to the project itself, the Interactivity, API. But I guess I have to ask the question, why is this even a project in WordPress? Is it that WordPress historically wasn’t particularly adapted towards interactive content?

I mean, we know how to publish posts and pages, and once you’ve done that, that’s kind of it. You’ve done it, and there’s no interactivity there. Is this something that has been, I don’t know, more recently thought was necessary? Is this something that you think should be in Core? Let’s just take that. Has WordPress been bad at interactivity historically?

[00:07:28] Damon Cook: I don’t think that it’s been bad historically, I think that it’s more of kind of a, I guess a technology trend of leaning into libraries like React or Preact, which Interactivity is built upon. So I think it’s more of a trend, but also, yeah, a necessity in Core, because folks are trying to build these types of experiences, and we want to have a standardised way for them to be able to do that, and not have to pull in a bunch of different libraries. And although they still can, you know, there’s a standardised and backwards compatible way for them to do it. So that’s the idea.

[00:08:05] Nathan Wrigley: Thank you. Seth, anything to add?

[00:08:06] Seth Rubenstein: Yeah. I don’t think WordPress has done a bad job on interactivity in the past, you know, ships with jQuery, ships with React, that’s all available to you. I think the Interactivity API is kind of looking at how developers have been creating front end experience with React, and narrowing that down to be like the right tool set for blocks and for block developers specifically.

[00:08:26] Nathan Wrigley: So it’s about having the right tooling. Something standardised that everybody can get their teeth into, that every developer understands.

[00:08:32] Seth Rubenstein: Yeah, and something that fits the blocks kind of model I think, a little bit better than some of these other frameworks.

[00:08:38] Nathan Wrigley: Okay, that’s great. So give us some examples of good interactivity on the internet. So we could limit ourselves to WordPress, but let’s not do that. Let’s just go out there and try to pick good examples.

Really, I guess we could be talking about Google Docs, we could be talking about websites, we could be talking about anything. Do you want to just rattle off a few things where you’ve seen and you’ve been impressed, and thought, ah okay, there’s a good example. The only reason I’m asking this really is so that the listener can just get an idea of what interactivity means.

[00:09:05] Damon Cook: Sure. And I’m actually going to set up Seth, because I think a lot of the things that his organisation is creating are representative of what folks kind of need. So I’ll set him up for that.

[00:09:17] Seth Rubenstein: And I’ll say the word that he’s probably thinking of, facets. Amazon, you’re browsing Amazon, you want to narrow down the content that you’re looking at. Those facets on the left hand side, filters, aggregations, whatever you want to call them. I think this has probably been our biggest success with the Interactivity API, is developing out facet blocks.

And with the Interactivity API what that would let you do is just server side hydrate data before it gets back to the client. And you can browse through all this content, and do it in a performant way that you just couldn’t do before. Or you could, but it would take a lot of work on your part to build out the framework and the technology to handle all that.

And so now that’s just in the box in WordPress free to use. So we can probably touch on facets a little bit more later, but I think that’s probably the best use case for the Interactivity API thus far.

[00:10:00] Nathan Wrigley: Let’s dig into that a little bit. So when you say facets, my head is immediately going to things like, I don’t know, the posts and pages, table layout, or something like that. And the fact that, if I want to get to post number 11, I might have to click a button, wait for a moment whilst the page refreshes, there’s obviously something going on there, page refresh, I’m contacting the server and what have you. Is the idea here that, a bit like, I don’t know, if I scroll on Google, I would be able to automatically upload more pages, more posts, that kind of thing? And then be able to, I don’t know, say filter them, show me only the ones that are authored by me, or ones with featured images, and that would all happen on the fly.

[00:10:35] Seth Rubenstein: Yeah. So, you know, you can filter by author, by taxonomies, category, custom taxonomies, whatever, date, et cetera. And those results just update in real time, without you having to refresh the page.

You can paginate through those results without having to refresh the page. That, of course, is great for the end user, but it’s also great on the backend because you’re saving server resources without having to re-render that entire page every single time. So you’re only rendering out what’s changed.

So in that way, great for the end user and great for you as a website operator, because the Interactivity API kind of offloads some of that performance overhead that way.

[00:11:07] Nathan Wrigley: Yeah, okay. I have children, and they have been born in a world where the mobile phone is completely ubiquitous. And the idea of anything refreshing to them just seems like an anathema, just a pointless thing. You know, you want to open an app, and from that moment just everything happens. You scroll, there’s more to see, you press back, it just immediately loads and what have you.

Is that kind of where we’re going with the internet? And what I mean by that is, sites where you’ve got to click a button to see another further piece of content, or for your shopping cart to be updated, or whatever it may be, that just seems like the 1990s almost.

Is it a bit of that? Is it just we’re kind of keeping up with the times? And the expectation from the next generation of users is going to be, well, if it isn’t interactive, I’m not sticking around. So if I’ve got a, I don’t know, a WooCommerce store or something like that, it’s going to be painful for a user to have to refresh, click a button to go to a cart, wait for it to load and all that. It’s just, like I said, the 1990s.

[00:12:05] Damon Cook: Yeah, I think a lot of it does touch on that and, yeah, just reaching out to that kind of experience. But, yeah, I think Seth touched on this, but the performance impact is pretty great about the Interactivity API because you’re only updating the sections, or components on the page that are really relevant to what the user is doing. So that has a performance impact. It makes things feel seamless, faster, and I think that’s a lot of probably what we’re all looking for at the end of the day.

[00:12:30] Nathan Wrigley: It feels like something more native to the device that you are on. So it feels like a Mac app, or a Windows app, or an Android, or an iPhone app. Does that kind of make sense? It just feels like we’re in the modern world, not in the old world where any kind of refresh just seems bizarre, frankly. Anything to add, Seth?

[00:12:46] Seth Rubenstein: You know, I think the coolest part about this is it basically lets you take a PHP application and turn it into a single page JavaScript app. I mean, that’s really what the Interactivity API as a whole is doing. And I think that’s what developers are looking for these days. Look at, you know, Next.js, and frameworks like that that are really grown and are really popular. And I think that this kind of API just is an answer to those for WordPress developers.

[00:13:06] Nathan Wrigley: So if I were a developer and I was, I don’t know, creating plugins, themes, blocks, whatever it may be, where do I go and find out about this? How do I get my teeth into the project? So you might want to drop a URL at this point, wherever you want to point us.

[00:13:20] Damon Cook: Sure. Well, I can tell you how I find it because I Google it. I Google it myself. Interactivity API Handbook, I’m pretty sure that’s where you’ll find it, and developer.wordpress.org. The documentation is very thorough, and up to date, and complete. And I think that’s what’s excites me about this API because it’s a very discreet project that kind of got pulled together and, yeah, the documentation is really up to date and great, so that’s where I’d go.

[00:13:47] Nathan Wrigley: Okay, I will link to that in the show notes. And probably a good idea, dear listener, to pause at this point, go and check that out and then come back and hit play.

So from the developer sort of point of view, how baked is it? How complete is it? Is there a lot that you have achieved already? Is there a big roadmap for things that you want to achieve?

I know that’s going to be difficult to encapsulate in a few sentences, but just tell us the state of the project now for developers listening to this, they might have some intuitions as, okay, that sounds like something I could use right now, as opposed to the roadmap features that are still going to come.

[00:14:17] Damon Cook: Sure. No, it is quite complete and ready to use, and the documentation can even step you through how to integrate it into an existing block. You can even spin up a new block with the Interactivity API already baked in.

Some of the future roadmap areas is, I know that we’re still working on like client side navigation, and then pulling in kind of different modules. Like I know one experiment that’s being explored is, there’s a package for accessibility. So just the general idea of speaking, screen reader, passing along. So these APIs have been in WordPress for a while, like some of the accessibility packages. So there’s explorations in kind of porting that over, and pulling it in, because the Interactivity APIs uses JavaScript modules for a lot of this. So it’s kind of re jigging, I guess, some of the code and pulling in some of these packages so that developers can use kind of those old, not old, but accessibility features, and have all that compatibility baked in.

So that’s some of the areas that are still getting integrated, and I’m excited for them. And I think that’s on the roadmap right now, and there’s folks contributing towards it.

[00:15:24] Seth Rubenstein: The modules area is probably, I think probably the area that it needs the most work, and hopefully the most amount of work is going into. I would say that’s probably one of the roughest parts of the Interactivity API right now is, if you need to use an external script, or kind of library, or framework, it’s a little difficult to get that in. So I think that’s probably where the most amount of work’s going to be going.

And I think there’s some work going on WordPress URL, bringing that in as well. And there’s a few more directives too, to the API, that are being added like wp-show which should be interesting, that should let you dynamically hydrate elements on the page in a different way. I won’t go to like all the technical details on that, but there are some additional features that are coming to the Interactivity API, beyond just the module stuff. So there are, in the Interactivity API parlance, there are new directives coming soon.

[00:16:05] Nathan Wrigley: I think for anybody who is a developer, you’re going to be fine looking at the documentation. But if I say any acronym on this podcast, I always get some pushback from people who are not developers, WordPress end users. So let’s address that.

Is there going to be functionality within the Interactivity API, although it’s there, and it is part of the Interactivity API, will be available to just builders of websites? People who have their own blog, or their own property, they’re not interested in WordPress from a technical point of view. Is there anything that they can do with it so that they can have this sort of dynamic content? Or is it mainly going to be through the work that developers do, through plugins, and blocks, and what have you?

[00:16:44] Seth Rubenstein: Right now. It’s live, already on your site if you’re running kind of the latest version of WordPress. The light box in the image block is using the Interactivity API. So site builders are already gaining that Core query, already has interactivity built in. So does the pagination block. So your publication pages can already be kind of a single page JavaScript app. So Core is adding that stuff in and, yeah, obviously plugin developers will also hopefully add interactivity to their plugins, but it’s already there for site builders.

[00:17:11] Nathan Wrigley: It feels like we’ve gone down the road in WordPress where everybody’s done their own thing with interactivity. The page builders have done, well, not just the page builders as one block, but each page builder has done a different thing. You’ve got these multitude of plugins that do the sort of facet searching and all of that kind of thing.

The idea that there’s just going to be this one thing, I suppose in a sense you kind of want the Interactivity API to not really be that well known about. The idea is for it to sort of fade into the background and nobody even realise that there’s a thing. Is that sort of doing down the project a little bit, or is that kind of the point? If nobody knows it exists, but it works, that’s kind of the ideal.

[00:17:45] Damon Cook: Yeah, I mean these APIs are in the background, yeah, for developers to explore, and use, and pull in, and integrate. But yeah, at the end of the day, the end user shouldn’t know about it, have to know about any of this, and just, have a great experience. So yeah, I think that’s the idea.

[00:18:00] Nathan Wrigley: Where do you learn what you should be working on? So the team of volunteers and seconded people that are working on the Interactivity API, who are you listening to? Where do you get your feedback from? And I know in the open source world, it’s hard to get that feedback. And you might be just listening to a dozen voices, interested people, or there may be, I don’t know, hundreds of people talking to you. But to drive it forward, who are you listening to? Where do you get your intuitions as to what should be on the roadmap?

[00:18:25] Damon Cook: There is a Make Slack Group, it’s Interactivity API I believe, or Core Interactivity API room. But there’s some great contributors in there, and I’m probably going to mess up all their names but there’s Jon Surrell, I believe, and Greg Ziółkowski. I apologise Greg, I tried. But they are very active contributors and I probably feel like the least contributor. But, yeah, they’ve been doing a great job.

I think what it comes down to historically, the Frontity team, I’m not sure if you’re familiar with that project, but back in the day they kind of got integrated. All these smart folks into Automattic as full-time contributors, and a lot of them have been driving this project daily and contributing towards it, and they’ve been doing an amazing job. Some other folks, I think from Google, also contribute a lot towards Interactivity API. So that’s what I follow, they’re all in that room a lot and very active.

[00:19:20] Seth Rubenstein: That’s almost everybody. I don’t know if you mentioned Luis, he’s kind of my main point of contact. I ping him with questions, or ideas or, hey, we’re going to try to do this, does this sound crazy to do with the Interactivity API? And he’s pretty receptive.

[00:19:32] Nathan Wrigley: Would it be fair to say that you could do with some more helpers though? I think in the open source world we could always use some more people flocking around any particular given project. Is that something that you’d be interested in? I don’t know, one of the intentions of a podcast like this is to make things like that happen but, yeah, is that a thing?

[00:19:47] Seth Rubenstein: I would like to see a lot more people using an API. You know, we’re trying to push the limits of the API, and I think it’s important that we all kind of try to push the limits and see where it needs additional work, or where we might need extra functionality. So I’d love to see a lot more people using it because I just don’t think it’s gotten kind of the critical mass yet.

[00:20:04] Nathan Wrigley: Can you give us some nice examples that I could link to in the show notes of situations where you’ve seen, specifically the Interactivity API. We mentioned earlier about, you know, general websites and what have you.

Are there any good examples where you’ve seen somebody using it, so that if there is a developer looking at this, they can go, oh okay, that’s the kind of thing we’re talking about.

[00:20:21] Damon Cook: I certainly can share some links. I have some repos on GitHub where I’ve built custom blocks and I’ve done, I believe there’s a YouTube, at least a recording of a presentation where I’ve gone step through building, some of these custom blocks and they’re all in my repo.

I was going to hand it off to Seth, I guess again, because I know one block that stood out to me that him and his team have created is like a, well, I think you have a poll, but also like a table filtering. I mean, I think those are pretty common experiences that we see on sites, and they’ve done a great job in creating that seamless experience of filtering.

[00:20:56] Seth Rubenstein: I can just gush for a moment. If you want a good example, www.pewresearch.org, almost everything that you’re going to see there is using the Interactivity API. Mega Menus, MailChimp newsletter signups, facets, pagination, table of contents. That updates as you scroll through the page, because the chapter blocks report using the Interactivity API to the table of contents block, which is separate, their position. Data tables, charts, quizzes, you name it, pretty much everything that we have on our website is using the Interactivity API at this point.

There’s a few plugins that we still have to convert, it’s actually only two. But almost everything that you see there is using the API, and almost all that code is available for free open source on github.com/pewresearch.

[00:21:39] Nathan Wrigley: Did you do that yourself because you are knee deep in the weeds of this, and so you could understand easily how to do that? Or would it be true to say that the developer documents that you’ve just mentioned would steer any, air quotes, competent developer to be able to achieve that? Or is it just that you know, you’ve got the Interactivity API, you also work for this organisation, so the two met.

[00:21:58] Seth Rubenstein: I think it’s because we wanted to provide learning resources, we wanted to provide a use case of, here’s what is possible. Obviously I’m talking about a lot of blocks that are interactive, but one of the things that I could really go into is our concept around the Interactivity API.

I think a lot of examples that people can point to, it’s a very specific use case. This block is a collapsible block, you click on it and it expands. We’ve taken a different approach, something that we call Atomic Interactive Blocks. And so we’ll make a block and it will have some interactivity instructions and functionality, but the point of that is to be dropped into another block, which has its own interactivity, and instructions, and functionality, and so on and so forth.

And so what we’ve really done is made a library of interactive blocks that kind of act like React components, and that you can drop them in other use cases and style them however you want, but what they do is defined maybe higher up.

Yeah, so I think to me that’s really the power of the Interactivity API, because what that allows us to do is, as developers, is just maintain a small library of blocks that are programmed to do a lot of things, and interact with a lot of other blocks, but then hand off styling, and content, and all that stuff to designers and other people.

For me, that’s been the coolest part about the Interactivity API, is this abstraction out of a block of what it does. We can go into it more, but the interactive stores can communicate with one another, and so you can have block A do a very specific thing, you click on it and it opens. And maybe you put that inside of block B, and block B is aware, well, when block A is set to be open, when its state is set to be open, I need to do this. And so, you know, you can imagine, you can make a button block, and use that in infinite applications.

The way that we approach it though, that block can dynamically target an interactive store rather than statically being set to just do this one thing in this one interactive store. So all of those GitHub repos will provide examples of how that kind of system works, and how you might approach the same thing for your organisation or website.

[00:23:48] Damon Cook: I think what Seth touched upon is interesting because I think it says a lot kind of to how the API has been built to abstract some of these ideas, and just shared state between components. So like you touched on, a button can be shared, and so many are used in so many contexts, but to be able to abstract that and share state, and the interactivity between these components is, it shows a lot of, the API has been built smartly so that it can be explored and experimented with, which is neat.

[00:24:19] Nathan Wrigley: I think one thing about this topic is that it is possible, probably, to go a bit overboard with being interactive. I’ve got the API, I know how to use it now, I’m going to make everything interactive. And I guess there’s a point where you’ve got to tell yourself, slow down, not everything needs to be interactive. So let’s just go into that. Are there any uses which you would say, yeah, you could do that interactively but we probably shouldn’t? Are there any times where you think, let’s put the brakes on?

[00:24:45] Damon Cook: I mean, I think any developer will kind of realise when they’ve maybe over-engineered something. There’s always going too far and making everything, yeah. You’ll know I think if you’re trying to make everything interactive, every paragraph or, you know, it’s just kind of pointless. But the exciting part is that you can experiment and explore, interact with these APIs and see what you can do. And find the edges of what you can do, and what you should do, or shouldn’t do, that’s the fun part.

[00:25:10] Seth Rubenstein: Yeah, I will say that, is it possible that you can do too much? For sure. Technically speaking though, is it possible that you can do too much? I don’t think so. Like I said, we have a lot of interactivity blocks on a page, and the performance has been great. So I don’t think there should be a concern of like, oh, I’m overdoing it with using the Interactivity API in terms of performance. I think the more things you make with the Interactivity API, the better performance you’re going to get.

[00:25:33] Nathan Wrigley: Let’s just speak to the performance side of things because you mentioned technically how it’s achieved a little bit, but could we just develop that a little bit? And you’ve definitely said performance isn’t affected, or performance is really great a number of times. What does that actually mean? So if I’m using this, is it a more performant website because it’s, I don’t know, it’s loading content asynchronously or what have you?

Has there been any situations where you’ve had to, I don’t know, refactor things because the performance took a dip. Performance at the moment is everybody’s big worry, isn’t it? Because, you know, Google takes those metrics and ranks you accordingly. So we kind of want to know that if we make this thing interactive, it’s not going to suddenly impact our score. And I know that Google does take note of these kind of things.

[00:26:11] Seth Rubenstein: Yeah, I think on the performance bit, I mean, to get a little technical, what makes it so performant is kind of that idea of server side hydration, right? You click on something and that element changes, and that can happen client side, but if it needs a new data, that in the past has meant refreshing the page or doing something really kind of complex and technical.

Now when the data changes and when that element needs to change, that one element re renders on the server, and then it’s returned back to the client, not the whole page. So that right there is an immediate performance savings because you’re not having to render a whole page out again, just to get this one little bit of changed information on a page.

[00:26:45] Nathan Wrigley: Let’s get into probably the final thing for today, and that is the accessibility perspective of things. It’s become the watch word I think of 2023, 2024, and probably it’ll carry on, rightly so.

Has there been any accessibility concerns? Because obviously if you’re updating content live on the page, is there anything that we need to be concerned about if we’re developing with the Interactivity API in terms of the accessibility, I don’t know, screen readers or other assistive technologies.

[00:27:12] Damon Cook: Sure, yeah. I think it’s always a challenge in building your components, and making sure they’re interactive. So I think that it’s really kind of just abstracting things, trying to figure out what your HTML is, what your CSS is, and then layering on the Interactivity API. I know that some of the extensions of pulling in like strings of information that are being updated on the page, like some of the older packages, like the accessibility, or a11y, for the acronym. Some of these packages that have been in Core for a while, they’re being ported over into the Interactivity API.

That’s something that’s kind of on the roadmap and being explored right now, so that we can have some of these screen reader updates for components, and on the page be integrated with the Interactivity API. So that’s, yeah, definitely something that’s being explored.

But also, yeah, a lot of it is more of just the approach because just the markup and the CSS alone, having the knowledge of how to make that accessible is always a practice, an art form, and something that is always, can be improved.

[00:28:17] Nathan Wrigley: Okay, thank you. Anything, Seth?

[00:28:19] Seth Rubenstein: I think that there’s actually probably better accessibility that you’re going to get out of the Interactivity API. You know, I know that screen readers and assistive technologies have come a long way, but if a lot of your website relied on React, and other JavaScript frameworks that render after the page has been rendered, that could pose a problem for accessibility technologies. Here, all that stuff is pre-hydrated and pre-rendered before the page even loads. So your markup’s ready to go as soon as the page loads, which is actually great.

[00:28:46] Nathan Wrigley: I think probably time has caught up with us. But before we go, we did mention the URLs and where you can find the project. Let’s just, firstly, go through where we can find you individually. So that might be an email, a Twitter handle, or whatever it might be. So let’s go to Damon first. Where can people find you if they’re interested in catching up?

[00:29:03] Damon Cook: I think probably the easiest is X, I still call it Twitter. I am dcook. I’m always open. Yeah, reach out. I think 99% of my Twitter timeline is sharing WordPress ideas, outreach links. So yeah, you’ll find me for any WordPress stuff there.

[00:29:21] Nathan Wrigley: Thank you so much. And, Seth?

[00:29:22] Seth Rubenstein: You can also find me on Twitter, which I refuse to call X. Twitter.com/sethrubenstein. And I also share a bunch of Interactivity API and WordPress stuff.

[00:29:29] Nathan Wrigley: Thank you. So this is the bit where I ask, is there anything that we missed? Is there something that you desperately wanted to get across that I failed to ask?

[00:29:36] Damon Cook: To go back just a little bit, he was touching on performance. So one thing actually I wanted to speak to was the idea of the Interactivity API is a standard means for developers to pull in these kind of libraries and do interactivity experiences. And so using this API, you’re relying on, you know, a simple small bit of source code that is going to be integrated on every page. So that performance impact of not having to pull in an entire library, so it makes it a smaller source code that’s being pulled in, so that has a huge performance impact as well.

On the podcast today we have Damon Cook and Seth Rubenstein.

This is the last of the podcasts recorded at WordCamp US 2024, and our focus today is the Interactivity API. You may not be familiar with what this is and why it matters, so Damon and Seth will break it down, and explain how it might transform your WordPress websites in the future.

Damon starts off by defining what an interactive website is, giving examples such as single-page applications and dynamic elements like tabs and accordions. Seth adds his perspective on how interactivity aids both the end-user and website editors, making for a more compelling user experience and efficient content creation.

We get into why WordPress needed an Interactivity API, even though the platform already supports libraries like React. The Interactivity API provides a standardised way to create dynamic content, which is essential for modern web expectations.

We also highlight real-world examples, including faceted searching and filtering, which have been successfully implemented using this API. The conversation also touches on performance improvements brought by the API, emphasising how it can offload server resources by only updating necessary content.

Towards the end, we explore how the API is already being used in Gutenberg blocks and how it supports both developers and site builders. Damon and Seth also discuss the project’s development, encouraging more contributions and feedback from the community.

If you’re intrigued by improving your WordPress site’s interactivity and performance, this episode is for you.

Useful links

Pew Research Center

Interactivity API Handbook

WordPress Developer Resources

Frontity

Pew Research Center on GitHub

Damon’s X

Seth’s X