WordPress UI library choice: extensibility vs. interoperability

In the upcoming weeks, WordPress will choose a UI rendering framework. I’ve heard many claims plugin / theme developers will still be able to use whatever they like, regardless of what WordPress chooses. I think we shouldn’t count on that, nor should we focus on providing interoperability at this point. Instead we should focus first on providing simple, reliable and flexible ways to extend the interface. Let’s make sure plugins can integrate well in the first place. 

We’re putting the frontend in charge of rendering

With the new Gutenberg editor we’re changing the way the WordPress admin is being built. Where we now render the interface with PHP, we will start rendering more and more on the client side with JavaScript. After the editor, this is likely to become true for most of the admin. That means that if you want to integrate with the admin interface, you’ll have to integrate with the JavaScript that renders the interface. If WordPress chooses Vue, you’ll have to feed WordPress Vue components to render. If WordPress chooses React, you’ll have to feed WordPress React components to render. These things don’t go together. React doesn’t render Vue components or vice versa. There is no library that does both. If WordPress uses a particular framework, everyone will have to start using that framework in order to be able to integrate, unless maybe…

Runtime interoperability, there is no standard…

There is currently no means of making the many different component rendering frameworks interoperable. Standardisation is still lacking. There are experiments [1] [2] that are looking into this, but I haven’t come across one that seeks to make different component frameworks interoperable on runtime. Most of them parse / transpile different component formats to a standard format as a build step, which actually covers 99% of usecases, except the WordPress one. This is because WordPress needs runtime interoperability…

Runtime interoperability is basically only needed on a web platform that allows independently bundled and distributed plugins to be installed natively. This is a rare thing, as even a WordPress-ish platform like Drupal has proper dependency management and build steps for modules. So basically I’d say WordPress is pretty much the only notable platform that I can think of that might need runtime interoperability between different view rendering frameworks.

Let’s not do it ourselves…

The above is without even asking what runtime interoperability would actually mean. I’m guessing it would be a disaster in terms of stability, speed, performance and maintainability. Let’s say we’d be able to render stuff with multiple frameworks. Wouldn’t this become an absolute mess very soon? How do you debug a UI where Vue is responsible for rendering a component somewhere and React is responsible for rendering its container? How do these things even interact with each other? What happens when the container component updates? Are lifecycle events going to be interoperable as well? Are components going to be aware of their children, even when the children are rendered in a separate virtual DOM?

I guess my main question is: is it really a primary concern for the WordPress community to facilitate usage of multiple view rendering frameworks on its platform? Interoperability is important to us for one reason only: we need WordPress to be easy to extend. When it comes to extensibility there are many different concerns. It needs to be flexible (interoperability is a part of this), fast, stable, reliable, easy, debuggable. Giving away control over rendering for the sake of interoperability will come at a cost in other area’s. I don’t think that would be the right tradeoff for us. I also don’t think we have enough skilled JavaScript engineers in the WordPress community to maintain a solution like that. And even if we did, it would be a waste of talent to the WordPress project if we let them spend time on maintaining this.

Fix extensibility first

The problem of making JavaScript rendered interfaces extensible has received too little thought in all of this. Most people haven’t realized yet that DOM manipulation using jQuery will become practically useless once we go down the functional reactive path. We’d be mixing declarative and imparative styles. This is definitely not a good idea and will undoubtedly cause great frustration if pursued.

Approaches towards extensibility

We’ll need to offer good ways to insert and modify interfaces that fit the new paradigm. On a higher level, I see three possible approaches:

• Allow plugins to integrate only in designated area’s. This is the idea that has received most consideration until now. We’d basically offer no flexibility in terms of manipulating the interface. But we’d reserve area’s in which plugin authors can render their own stuff using whatever technology they want. However, the loss of flexibility plugin authors currently enjoy with PHP hooks and jQuery would be unbearable.
• Allow plugins to modify the interface freely under well defined conditions. We allow plugin authors to insert and manipulate interfaces anywhere they’d like. We could enable setting extra conditions on particular parts of the interface to guarantee behavioral consistency. For example, let’s say someone wants to replace the title field with an interface of their own. We could set a condition which says that their interface should at least still dispatch the same hooks (or actions).
• A combination of the above. We allow plugins to modify the interface freely and at the same time offer API’s that cover the generic usecases. In case of the editor generic usecases would for example be adding blocks, metaboxes (not covered yet) or individual post settings (not covered yet). For list tables this could be adding columns and / or filters.

At the same time we need to think about how components will be able to interact. Not only the interface needs to be extensible, also view models should be observable and accessible. In a future blogpost I plan to write more extensively about extensibility in a JS rendered WP admin.

To React or Vue, that’s the question

I think we should more or less forget about providing interoperability for frontend libraries in WordPress. We simply have to choose a JS framework for rendering contemporary UIs and be done with it. We’ll have to go all-in, knowing that what we’ll choose could be a choice for the entire community. Then we need to start working hard on making it extensible on different levels.

If we want to have a functional reactive approach towards component rendering (and I think we do), we don’t have many choices. With React out of the picture, Vue was probably the only feasible option left for the WordPress project at the moment. It is clearly the most popular option within the broader WordPress community and it has a reasonable ecosystem. Preact and Inferno aren’t really alternatives. Both don’t really have the community backing needed for WordPress to rely on. To illustrate, the creator of Inferno now works on React for Facebook. Fortunately, React just moved back into the picture.

Needless to say, at Yoast we’ve always been big fans of React. We think it is far superior to its competitors both in terms of technology and ecosystem. React might have a slightly steeper learning curve, but is easier to master as it doesn’t mix up concepts like Vue does. So in the long run, it seems far more sustainable to me. Next week, I plan to write a blogpost about what I mean by this. The gist of it will be that a lot of developers in the WordPress community still approach a web application as a collection of HTML documents, thereby missing out on a lot of advantages that come with an application mindset.

We’re only still at the beginning

Whatever framework we choose as a community, we’ll need to become invested in it. That’s why Yoast has committed itself to sponsor the framework of choice. We encourage others to do the same. All in all, I think rendering interfaces and modelling interactions with JavaScript will be a major step forward for WordPress, both in terms of UX and technical soundness. I am really curious what others have to say about this. Please share your thoughts and feedback in the comments below!