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.
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.
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.”