WordPress Explores a JavaScript Framework-Agnostic Approach to Building Gutenberg Blocks

The discussion regarding WordPress’ JavaScript framework selection continues in the #core-js Slack channel ahead of next week’s meeting. One of the more recent topics is the possibility of framework-agnostic block rendering for Gutenberg, which would allow developers to extend the new editor using any JS library they prefer. This means that Gutenberg blocks, which are colloquially referred to as “Gutenblocks,” could be built with Vue, React, Preact, Angular, or whatever the developer feels comfortable using.

Proponents of this idea contend that pursuing a more flexible approach makes WordPress’ core JS framework decision less critical. While answering questions on the #core-js channel, Gary Pendergast explained how Gutenberg could be built to maintain the separation.

“I’m really not joking when I say that this decision doesn’t matter, even for people contributing to Gutenberg,” Pendergast said. “In #2463, the library is treated entirely as a utility library, much like we use lodash, for example. It performs a handful of tasks, and it can be relatively easily pulled out and replaced with something entirely different, with no disruption to the rest of the codebase. For people contributing to Gutenberg, they’re contributing in the Gutenberg coding style, not the style of whatever library we happen to import.”

When asked about a timeline for when the decision will be made and what factors are being considered, Pendergast replied that there is no timeline and that those interested in participating should blog about their experiences and write examples of things they can build with the JS frameworks they are familiar with.

“There is neither roadmap, nor timeline, nor does there need to be,” Pendergast said. “As Matt mentioned, it’s really just a technical decision – the important decision for the wider community was choosing ‘not React.’ Unfortunately, this decision has been blown way out of proportion, and heavily conflated with ‘what JS library will I be able to build my plugins with?’ and sometimes ‘what JS library’s practices will Gutenberg blocks resemble?,’ neither of which are related. Tweets and posts that treat it like a horse race are not helpful in this way.”

Pendergast said whatever library is selected will “continue to be wrapped by the WordPress element, the underlying library won’t be exposed.” The Gutenberg team is working to remove all library dependencies from its components so that plugin developers can use any library they choose.

However, other community members are not so eager to relegate the JS library selected for core to a simple technical decision or utility library.

“Most developers understand that their plugins are not bound by the framework chosen for core/Gutenberg,” Kevin Hoffman said. “But that doesn’t diminish the significance of the decision. If we want to encourage more contributors, we’d be well served to choose a framework in which a significant majority feel capable and confident. If this majority is out there developing plugins with one framework and has to learn another in order to contribute to core, then we’re limiting the number of potential contributors.”

Peter Booker contends that no matter how elegant Gutenberg’s separation is, having a decent understanding of the library chosen for core affects a developers’ ability to deeply troubleshoot certain issues.

“I do not think we should be so dismissive of the choice as a minor technical decision,” Booker said. “Understanding how PHP, JavaScript, and Backbone (among other things) work is essential to be able to properly debug problems with WordPress. The JS framework chosen for Gutenberg is going to impact a great many people, even if we are not core contributors. It will be essential knowledge to be able to fully troubleshoot issues. This is a decision which will impact far more people than just the Gutenberg team.”

What are the implications of providing a flexible, framework-agnostic approach to building Gutenblocks?

Jason Bahl asked if anyone has tried mixing React, Preact, Vue, and Angular in a single app to see if it is “a recipe for a performance nightmare.” He posed an example scenario wherein Gravity Forms builds Vue-based Gutenblocks, Yoast has React-based blocks, WooCommerce builds blocks with Preact, and another plugin uses Ember.

“It sounds kind of nice to be flexible and allow folks to use whatever but also like it could lead to a lot of division on best practices, and potentially performance issues,” Bahl said. “We’ll see tutorials pop up for how to build Gutenblocks in Vue, React, Preact, Ember, Vanilla JS, etc., which would be cool to see, but also confusing and potentially cause further divide in the community and accepted best practices. Flexibility is nice to a degree, but a strong opinion at some level is also good.”

Carl Hancock, co-founder of Gravity Forms, contends that offering a framework-agnostic approach to building Gutenblocks will have little influence on developers who are extending the project. The decision cannot be made less critical by offering more flexibility, because developers will inevitably adopt whatever WordPress core uses.

“People are going to end up adopting whatever core uses for the most part despite the rainbows and butterflies some are claiming as it relates to creating an abstraction layer so plugin/theme developers can use whatever they want,” Hancock said. “Which means however complex that core framework ends up being will have a direct impact on the barrier to entry for plugin and theme developers. That barrier to entry has been historically low to date and a direct contributor to the growth of WordPress as a self-hosted CMS. Dramatically raising that barrier to entry isn’t necessarily a bad thing. For example, Gravity Forms will use Preact, Vue, whatever, because we have the manpower and skillset to do so when we can finally decide to do so once core makes it’s decision.”

WordPress’ Opportunity to Advance the Web

WordPress currently powers 28% of all websites, according to W3 Techs, and whatever framework it chooses will make a major impact on which library many developers decide to learn in order to extend the software and advance their careers.

Matías Ventura, one of the technical leads on the Gutenberg project, encouraged participants in the discussion to look at the bigger picture and embrace the opportunity to work together and collaborate on a solution for WordPress that will advance the web. The team’s efforts to collaborate with representatives from competing frameworks stands apart in an ecosystem that is generally fragmented and fractious.

“I’m excited about the opportunity we have to advance web development in terms of JavaScript UI representation, in a similar way to how WordPress was a driving force for web standards during the past decade,” Ventura said. “That’s also where I see us having a responsibility as a project, as people will continue to learn web development through WP. Many people have been introduced to PHP through WordPress, originally just interacting with WP functions and APIs, eventually diving a bit more deeply into the language as needed. I do see our core remaining close to JS the language, as that gives the most meaningful tool to learn, spanning across all frameworks and libraries.”

Ventura assured participants in the ongoing discussion that the Gutenberg team is listening and working towards a solution that will push the web forward.

“We are absolutely aware that how we build and what we offer through Gutenberg is going to affect the dev community and we are not taking this lightly—quite the opposite,” Ventura said. “I’ve been talking with Evan (Vue) and Jason (Preact) because rather than having a ‘choose your framework’ contest, this seems an opportunity to collaborate and push the web forwards.”

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

I’m impressed that Facebook did such a volte-face! Now the question is: is it too late in regards to WordPress ? Will this just kill the debate about the JS Framework choice or will the discussion continue to make a real concerted choice agreed upon by the majority of the community ?

I think this announcement underscores (😉) the need to be framework agnostic – there are many possible ways for a framework to become unavailable to us in the future, so keeping our reliance on them as small as possible means we can more easily switch if necessary.

So, regardless of this announcement, the work on Gutenberg keeps on going, and the plan continues to be that you can build your plugins using whatever framework you prefer.

If Facebook has shown anything, it’s that React’s licensing is fluid and cannot be relied upon long-term. It’s one thing today, it’ll be another next week. Next year, who knows? Once they change the license, they’ll become a flip flopper. The precedent will have already been set for them to do it again in the future when this framework wars blow over / die down substantially.

Facebook doesn’t care about anyone’s project but they also don’t want to lose mindshare either. I would expect them to change the license again in the future when it will be much harder for projects (read – there is much more technical debt ) to make the call to switch frameworks.

Whatever framework Gutenberg chooses though regardless of the proposed agnostic approach or not should become part of the WordPress development guidelines. Then there is at least a standard set in writing. It can be followed or not. If not set, it will be more wild west chaos which will ultimately not benefit or better the community going forward.

I absolutely agree that we can’t assume that React’s license will stay the same, this is why the framework agnostic approach is so important. Whatever framework ends up being used behind the scenes, we need to work on the premise that we may need to seamlessly swap it out for something else in the future.

As Matt mentioned, this approach lets us treat many frameworks as officially supported options. Regardless of what Core uses internally, developers can create in whatever fashion they’re most comfortable with, forcing people into one particular method has never been a Core philosophy, we’re not about to start now. 🙂