On the WordPress UI library choice: extensibility over 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
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   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?
Fix extensibility first
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