Back in the day…
The first ever WordPress site I built on was in 2010. It was just before WordPress 3.0 came out. I’d never worked in PHP before, but had experience working in other languages. I heard WordPress was a great way to build a website, and armed with $30 one could get a nice theme on Themeforest to hit the ground running.
My client asked for some changes and so I rolled up my sleeves and pulled up the code. I found the theme, functions.php, styles.css, and started working my way around. I was simultaneously learning PHP and WordPress.
Honestly, it was pretty easy!
I found that WordPress had this thing called “The Loop”, wherein you looped through one or most posts and had a bunch of functions such as the_title() and the_content() that did exactly what they sounded like. Easy!
I made the changes, slapped on some styles, and sent the changes to the client like a hero. 😎
Fast-forward
Later that year WordPress 3.0 came out. It brought something beautiful and shiny: custom post types. I felt like I could make anything now, and boy did I over the coming years. We, as developers, used custom post types in ways the original devs never even dreamed. We’re still kind of paying for it. Hahah!
But, that’s kind of the point, right? WordPress introduced these rather simple concepts: posts, pages, taxonomies, comments, and so forth. Armed with one of these objects and some meta, the sky was the limit. Scaling the meta might become an issue… but that’s for tomorrow Jason to handle! Nailed it!
As time went on we got more and more little features. Taxonomies even got meta! That was pretty cool!
Then, one day, Matt got on stage and told everyone to “learn JavaScript deeply.” And boy did he mean it.
Shortly thereafter development on Gutenberg back (or already had), and before we all knew it, WordPress 5.0 released with the Block Editor. WordPress would never be the same.
So… how’s that developer experience going?
The Block Editor came with very mixed reviews. Honestly, it’s not worth rehashing that again, suffice it to say that users and developers alike received the Block Editor with feelings ranging from burning antipathy to cautious optimism. Over the coming years, more folks came to embrace the vision than not. Let’s talk about the developers for a moment.
Being a “WordPress Developer” was something between a badge of pride and a derogatory title. It meant you at least knew PHP, CSS, and HTML — SQL, too, if you were cool beans. Amongst the PHP community it was looked down upon, but I think many people missed the point.
A person could do a remarkable amount with WordPress without having to be a highly skilled developer in the technical sense. You didn’t really need to know OOP or intimately know how databases worked. This came with a rub from time to time, but it was also pretty amazing. Unbelievable amounts of people were making a living with humble developer skills. Pretty amazing!
The Block Editor took those PHP skills and said, “Great! Now all you need to learn is React, attributes, block registration, JS transpilation, dynamic rendering, and a few others things, and you’re good to go!”
The PHP of WordPress was cozily 10 years behind. The JS was cutting edge and innovative. To make a custom block meant learning whole new concepts. Fortunately, if you had experience with React, data stores (e.g. Redux), and so forth, you had a leg up. No matter what, though, the bar was raised. Casual developers stood back, shocked, not even sure where to begin. Maybe they just don’t need to develop as much? Hope so.
Challenges along the way
I personally know developers that struggled to pick up block development. It was a constantly moving target. Even when you looked at the docs, it became apparent they were regularly behind. By the time the poor writers had gotten their documentation up, the APIs in the Block Editor had changed, and often there was a newly recommended way of doing something.
This isn’t a criticism to anyone. The Gutenberg team knew they had so much innovational ground to cover to really make the Block Editor the obvious answer forward. And to pull it off they needed to come up with brilliant ideas. The rub is that the folks building it were not your average “WordPress Developers” — they’re pros, building system that pros look at and go, “Niiice.”
The old community fell further behind.
A tension continued to grow. The Block Editor needed to be better and better. Blocks needed to be incredibly capable — how can a block pull and save in meta? in a custom table? be shared across more posts? As a user, we demanded capabilities; as developers we barely understood how they worked when we got them.
Underneath it all, there were challenges with how blocks fundamentally worked. They were React components. Sort of. But also a JSON configuration. Also a PHP file if you wanted to render dynamically. Also more JS if you wanted front-end interactivity.
Enter the Interactivity API
As people did more and more amazing things with blocks — such as donation forms, event calendars, and so forth — it became clear that blocks needed to be more than just static. As I write this text in a block, I know that block will come out in a paragraph tag — fine, that’s all I want — but interactive components should do more than just appear. We want users to interact with what they see in the block.
Smart and talented people got together and came up with a solution: the Interactivity API, released in WordPress 6.5. The idea behind this was that WordPress would have a first class way for developers to introduce interactivity within their blocks. Want a button in your block that makes a box appear? No problem! Such a cool idea!
I want to emphasize the talent behind the API. It’s smart and clever. As I critique it, I want to be abundantly clear I am in no way attacking any of its builders. They’re awesome.
Does it work like anything else?
It’s important to keep in mind that, by this point, much of the WordPress developer community struggled to keep up on the Block Editor journey. For those sticking around, they finally figured out JS and React enough to get their blocks together. And, fortunately, knowing React is just a good skill to have in today’s web dev world.
The Interactivity API used basically none of that. It’s a completely proprietary directives API built on Preact (which… is close, but why when React is already bundled in WordPress?) and requires a JS store.
It’s completely new and independent. It doesn’t build on what devs learned, nor does it use any existing directives API out there.
This means that not only do developers have to learn a completely new API, but when they do it doesn’t directly translate to anything else. Not only that, but you’re limited to whatever the API supports — it’s no where near as powerful or flexible as a raw React component. If you want to do more with it then the API itself will have to mature.
And that’s just it. We have yet another new API in WordPress that’s unique to WordPress. It adds a new dependency (Preact) and level of complexity and mental load to developers.
What’s the alternative?
Stepping off my soapbox, the reality is that it’s kind of a fair idea given the limitations of WordPress. The best case scenario would be that WordPress would further leverage the amazing interactivity framework it already has: React. That’s literally what React is for and good at.
Why don’t we? Well, to an extent I’m not sure. I think the minds behind the Interactivity API assumed people wanted a way to introduce interactivity in PHP without writing JS. But, ironically, to get the most out of the new API you need to write a custom store… in JS. WordPress could have provided some slick custom hooks or a way of loading React components on the front-end that are coupled to a block.
The other side of it is that it’s great when interactivity can begin on the server. This means setting the state of an interactive component on the server. Think setting the starting month to show in a calendar block; the calendar is interactive on the front-end, but you set the initial state of the calendar, the initial month to show, when making it on the server. The Interactivity API does this in its own way. We’re unable to use React on the server because we can’t assume there’s a JS runtime (e.g. Node or Deno) on the server in a WordPress environment. (Or can we? I wrote a post on why I think we could be bold and make it happen as the WP community.)
Conclusion
As much as I agree that WordPress blocks should be thinking about interactivity, I admittedly believe the way we went about it is a long-term mistake. It adds additional proprietary complexity to an already complex block system, requires new concepts for overwhelmed developers to learn, and limits capabilities by its own growth.
It’s certainly possible to introduce an alternative without necessarily having to remove it. The Customizer still exists, even though the Block Editor and Site Editor make it obsolete. So I do hope we consider alternatives moving forward. I admire the team that put in all the hard to work to imagine it and build it, but I remain unconvinced that it was the best solution to a real problem.