If a team is working in relative isolation, I would argue that the community direction doesn’t matter much. So long as the framework of choice can accomplish the specific business goals of the project, a team can choose React, Vue, Angular n, or whatever else they want. It’s an injustice to the larger community for developers to push their favorite framework rather than having an unbiased discussion about the most appropriate tool for the ecosystem.
My framework journey
I began in the Angular 2 space. Typescript was cool, Angular 2 was exciting, and having Google’s backing meant a lot to me at the time. I wanted Angular 2 to the the framework of choice for The Symphony Agency, but it would have required too much overhead for the team. No one wanted to learn TypeScript and Angular, while great for applications, was too much for the range of use cases (mini view components to larger applications). I loved working with Angular 2 on experimental internal tools, and I wanted it to work out, but in the end, it wasn’t the right tool for the job. It’s not you Angular… it’s me.
Despite making amazing development tools, I had an aversion to getting to know React. However, I refused to let myself avoid it if I didn’t have a real argument. I began building things in React and quickly fell in love again. I began testing for what WordPress needs, with the intention of creating a full featured React theme. The first critical road block was the inability to render templates asynchronously returned from WordPress. There are valid arguments for why you wouldn’t want to do this, but being able to output components added in the editor is a key feature for WordPress. WordPress is a Content Management System, and therefor the content needs to be able to be managed from Admin. Without this feature, content returned from WordPress is limited to basic HTML. What if I want a shortcode that outputs a React component?
Aside from the previous issue, React apps expect that functions and components are imported directly into the scope where they’re used. From what I’ve found, there is no concept of a global component registration. The explicit nature of React is a dream for application development and testing, but it introduces the need for ridiculous workarounds in an open extendable system like WordPress. If there are solutions that I’ve missed, I would love to see it shared below.
Note that while I enjoyed writing components in Vue (just as much as Angular and React), that’s not a good enough reason to make a choice.
This is not an exhaustive list, but below I try to cover my major concerns. Each framework has items it does or does not handle well, so I’ll attempt to be unbiased.
Extendable without a build pipeline*
Extendability is paramount. WordPress core, themes, and plugins are built with this as a core focus. Without it, the community is missing out on, what I consider, the most important aspect of WordPress. A developer should be able to add features to plugin or theme without editing and rebuilding its’ source. Adding global components to be used in the template syntax makes this particularly easy for isolated components, and having references to Redux or Vuex would allow a plugin extension to add data changing features to a 3rd party product.
Display a component template from a database stored string*
WordPress is a Content Management System (CMS), and as a CMS it needs to be able to actually manage content. A developer needs to be able to allow their fancy new component to be output from WYSIWYG. This can currently be done by providing an ID to an element in all frameworks, but, as far as I can tell, can only be rendered as template syntax in Vue.
Automatically display a component within a template, or as an app
jQuery is all over the web, and especially on WordPress sites. Sometimes a developer can get away with this when it’s interacting with a component inside a framework, however if the framework decides to re-render a view and destroy a targeted element, jQuery functions lose their references to that element. The community needs an approach to increase compatibility.
WordPress developer experience*
(THE FOLLOWING ARE SPA SPECIFIC)
Server Side Rendering
Dynamically define page/post templates passed via string*
For Single Page App (SPA) themes, a framework’s routing engine of choice needs to be able to handle dynamic templating of views. While it’s not possible, without getting hacky, to dynamically change the page template list in the page editor, the framework itself should be able to receive a template name or template type identifier(page, post, cpt, archive, 404 etc) and render the content appropriately. The routing engine should allow a developer to hook into the returned post content and determine what router view component to display.
Anchor to router conversion*
Menus are defined in WordPress, but the output will be full urls. A developer needs a solution to be able to intelligently convert appropriate links to router links instead. The routing engine should be flexible enough to dynamically adjust for this. Note that this is an issue whenever content is returned, not just with menus.
* Marks items that I’ve been able to solve with Vue, but are not necessarily limited to Vue.
Ultimately, I don’t care what framework the community settles on. As a developer I just want a tool that hits all the marks for allowing me to provide as much business value as possible. I enjoy Vue, React, and Angular, but currently Vue hits more marks than the others (noted with * above). In the end, extendability and compatibility with existing tooling is key. I hope the community is able to work out the issues and bring modern tooling to WordPress development.
If you have any concerns or solutions, leave a comment below.
Also published on Medium.