What WordPress needs from a JavaScript framework

JavaScript developers in the WordPress community are splitting into camps and taking up arms in the fight for the future of WordPress JavaScript development. Most of the arguments I’ve read have little to do with how the frameworks would work with WordPress, and instead focus on mostly irrelevant features of the frameworks themselves. Yes, there are many good (and bad) arguments for why each framework should be used in isolation, but WordPress isn’t popular for working on isolated projects. The power and popularity of the CMS is the theme and plugin ecosystem. Even if a team is developing custom themes and plugins from the ground up, the majority of developers are leveraging plugins and themes made by the community.

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.

My last-ditch  effort was to check out that Vue thing. I didn’t want to go through the pain of learning another framework, but an hour of reading the docs had me interested. Vue was easy to learn and didn’t require a lot of JavaScript expertise, which is good for a growing team at an agency. A Vue component could be written in plain JavaScript without a build process, which was good for quick one off solutions on older sites (technically this can be done with the others, but who’s actually going to do that?) Template syntax was easy, component definitions were clear, project setup didn’t require any magic tooling, and overall it was flexible.

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.

What the WordPress community needs in a JavaScript framework and approach.

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

A plugin developer should be able to write a component that can exist independently as its’ own app, or within the template of another app. Most themes aren’t using a JavaScript framework, so a developer needs to be able to determine how the component/app will be initialized. Without the community coming together on a standard, I can’t think of a solution that would work in all situations (with current APIs).

jQuery compatibility

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*

It’s a hard to swallow truth for some, but most that categorize themselves themselves as WordPress developers aren’t great developers. It’s not to say that they don’t produce a great product, and it’s not that you have to be a JavaScript or PHP wizard to be great. However, the JavaScript world uses a lot of development approaches that are entirely foreign to many WordPress devs. A framework should be powerful enough for experience JavaScript developers to work their magic, but easy enough to understand for developers who are trying to get their feet wet. If a junior developer without a ton of JavaScript experience needs to jump in and start working with components in a pinch, they should be able to do so. For the community to settle on a common framework, it needs to be something that most developers can actually work with.

(THE FOLLOWING ARE SPA SPECIFIC)

Server Side Rendering

SSR for JS frameworks requires the ability to run JavaScript on the server. This is a big problem for shared hosting as it often requires installing V8 on the server. Without this, a theme would have to create alternate pages just for search engines to read. That approach isn’t an issue with standard posts and pages (easy to do), but SSR becomes important when the site has a lot of custom templates and dynamic content.

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.

Conclusion

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.

Leave a Reply

Your email address will not be published. Required fields are marked *