Our decision to move away from React, based on their previous stance, has sparked a lot of interesting discussions in the WordPress world. Particularly with Gutenberg there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.

I want to say thank you to everyone who participated in the discussion thus far, I really appreciate it. The vigorous debate and discussion in the comments here and on Hacker News and Reddit was great for the passion people brought and the opportunity to learn about so many different points of view; it was even better that Facebook was listening.

“Particularly with Gutenberg there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.”

What would be the consequences of having all those multiple libraries loaded at once on the same page?

Within Gutenberg itself, any library your plugin uses will be loaded, but these libraries are all quite small – Preact is 3KB, Vue is 20KB, React is 35KB, Polymer is also around 35KB. Even assuming a site has plugins installed that create blocks with every possible framework, this is still a fairly small addition. Of course, these files are rarely downloaded, as your browser is probably already caching a copy of them.

On top of that, the Gutenberg team are investigating loading Gutenblock components asynchronously, to ensure that sites with lots of blocks, or particularly heavy blocks, can get the same editing experience as everyone else.

For how they all these frameworks would interact, Gutenberg would take the block output and compile it down to a primitive form, though what the primitive form will look like is still being considered: Web Components are a potential option here, Preact has been doing some interesting work in this field, and there’s even some early specifications for cross-framework components.

Also the teams behind these libraries are all willing to collaborate in making this possible and performant. We just had a very nice open chat yesterday where a lot of these ideas and concerns were discussed. Ultimately, we want to offer WordPress developers that freedom while making sure we have the most sound technical foundation.

Thanks for writing about this, Matt. We have all been suffering a lot from this decision paralysis, it’s about time we move forward with Gutenberg and make WordPress a lot better.

After talking to the creators and core teams of lots of JavaScript frameworks, including React, Vue, Preact, Polymer, Ember, etc. I have come to this conclusion that each of these libraries have different set of strengths.

With React being MIT licensed we can move ahead with the progress that’s already been made with Gutenberg, while taking this issue to address the concern of frameworks by building a much better FW agnostic API.

I hope this gets decided soon than later since it’s been hurtful for the growth of this whole ecosystem. A clear decision and narrative will go a long way for helping join the two communities together.

For a better performance, single framework please. Imagine creating a page with included different guttenblocks by multiple authors using different frameworks. All them loaded in the browser and modifying the DOM in the same time.

I touched on some of the performance issues in another comment, but you bring up an interesting point about modifying the DOM. These frameworks all have different ways of constructing their internal DOM, but they all ultimately build a DOM that Gutenberg can take and apply to your browser DOM. The upshot of this is that Gutenblocks (and whatever framework a block is built with) should never need to directly manipulate the browser DOM, Gutenberg will do that for them.

As someone who has spent a significant amount of time learning React over the past several months, due in large part to WordPress, I do hope this news means a solid reaffirmation toward React. I know that ultimately you’ll do whatever is best to move the community forward. But I agree with Ahmad – whatever the decision is I hope it is a strong one and comes swiftly. At that point I’ll double down. Either way, thanks for making this happen!

This move of Facebook is smart. It does not only show that Facebook is listening to the open source community, where their libraries are used most, but also shows how the real open source world works in reality. I couldn’t agree more that re-licensing React, Facebook really pushes the whole ecosystem forward. I admire them to make this decision.

It’s really nice decision taken by Facebook for not making it proprietary or patented.
Thanks to WordPress that they pointed out the issue before it arises, so now it’s really nice that Facebook is taking back there decision and re-licensing it with regular MIT license.
Thanks Matt for sharing this good news with us.

Support for multiple different libraries sounds great for plugin developers that will be able to create new blocks for Gutenberg using what they’re most comfortable with.

However, I wonder how will that affect the end user’s experience eventually. Loading multiple big JS libraries will cause slowdowns and will increase the backends memory footprint for sure. While SAAS sitebuileders that compete with WP nowadays have full control over that and can easily optimize for better UX.

Just a personal opinion here but despite not being very democratic, having a single library that devs have to comply with may have a lot of benefits in the long run.

there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.

Maybe I got it wrong all the time, but isn’t one (if not the) idea behind the quest for the adoption of a modern JavaScript library that plugin and theme developers from now on can make use of it and don't have to ship stuff theirselves? It's just like with jQuery: Core is making (substantial) use of it, but no developer is (hopefully!? 🙂 ) shipping jQuery with their products (anymore).

Now, if Gutenberg blocks were framework-agnostic—which is generally a great idea—I'm afraid this will result in a massive amount of assets, which are not even tailored for their individual usage. I mean, it just doesn't sound good to load a page with jQuery, Backbone, React, Angular 1 and 2, Ember, Preact, three versions of Vue.js, Marko, and, of course, seven custom frameworks that all are the bestest there is—does it?

It is somehow like Pandora's box, with the difference that nothing bad is coming out of it when opened, but all kinds of semi-redundant stuff being shoved in. 🙂 Has this been considered?

It’s worth noting that this situation is strictly in the post editing interface. Even if a site had all of these plugins, the multitude of frameworks wouldn’t be loaded on the front end of the site, there are no bloat issues to be worried about there.

You’re right that there’s potential for this to be a problem, though you’re talking about a fairly extreme case, where a site has 18 different plugins installed that all happen to be using different frameworks!

It’s still important to address this potential situation, though, particularly if we consider that some of those blocks might be loading massive libraries from some reason. To that end, the Gutenberg team are investigating loading Gutenblock components asynchronously, so that all these frameworks are only being loaded when they’re used, rather than with every page load.

Of course, the better solution is to reduce the number of frameworks being used – this seems like an area where plugin development best practices will evolve to make use of the latest version of frameworks, and potentially from a common source, for more comprehensive caching.

While it is true what you said, I was not only talking about Gutenberg here. Maybe I should have made that clearer.
I mentioned front end, yes, but I was also thinking about all the plugins integrating meta boxes in the (soon to be JavaScript-based) edit screen. 18 plugins, all with different framework( version)s, was a bit of a stretch, yes. But having 5 – 10 plugins create meta boxes is absolutely not.

Currently, people can do in their plugins whatever they like—and yes, this will always be the case.
If WordPress picks a modern JavaScript framework to adopt, people might just (in a not too far away future) switch over from whatever they were using, and do it with what WordPress ships. WordPress would make use of the framework, of course, and everyone else could, too. Yes, they don’t have to.
If now Gutenberg actually requires people to use the shipped JavaScript framework, say React, that might result in even more people switching, because it makes no sense to implement meta boxes with Vue, while having to do Gutenblocks in React.
If now Gutenberg, however, allows people to build Gutenblocks however they want, as long as they implement some interface (i.e., comply with the API), this might drastically reduce the number of people switching.

Since my previous reply, I’ve been thinking about this problem a bit. Thank you for the inspiration!

To begin with, I agree that there’ll be a bit of upheaval, and it might get a bit messy. People will be experimenting with different frameworks to find out what works for them, they’ll be learning how to work within this brave new JavaScript world, and we’ll also be seeing what needs to be changed in Core, so that developers have access to the tools and APIs they need.

I think that there are a few approaches we’ll be able to use to help settle this, though:

– Automated tools. The JavaScript world has embraced automation, particularly to tackle the problems around updating dependencies. Bots like Greenkeeper are frequently one of the most active users in repos. I think that we can do the same kind of of thing on WordPress.org – automated scanning can help remind plugin developers to upgrade their dependencies, it can ensure dependences are being loaded in a nicely cacheable way, as well as any other task we find that would encourage better practices.
– Build tools. The ecosystem is currently making a push towards being able to compile down to a set of common primitives, Preact even has a working demo of various template formats working in Preact. I expect plugin developers will be able to compile their release version to these primitives, so the framework they develop against won’t need to be loaded at all in production!
– Developer education. As the WordPress world becomes more adept at building JavaScript interfaces, we’ll certainly see common best practices start to form. Making those practices widely available and easily digestible will likely lead to better, faster code that interacts more smoothly with everything else.

None of these are a silver bullet, of course, but I think we have a reasonable set of options before us that both allow the ecosystem to experiment, grow, and mature; while also giving us the ability to encourage developers to work in ways that place nicely.

It’s been considered, certainly; and not just in the context of frameworks like Vue, React, and others, but also concerning large blocks generally. For example, we might want to implement a “Code” block which uses CodeMirror behind the scenes, but we wouldn’t want to load a large dependency like this one for every editor session, particularly for a user who might never intend to use the code block. There are some ideas being discussed here, most around detecting when the scripts necessary to displaying a block should be loaded (either when it already exists in the post, or is to be inserted), and only loading the dependencies in those circumstances. This becomes more feasible as block details and script definitions become more known to the server.

That’s really great news. But the greatest thing of all these is that the debate was very healthy for the community and as you said raise other possibilities, which I think we should take in account. There is no guarantee that FB will continue with this line of thinking in the future, post 16 versions, imagine a change , let’s say 3 or 4 years, after everything is build on React. Very dangerous !

jQuery was the clear winner of the “javascript library war” several years ago so it made sense to include it in WP.

Maybe the reasoning was that React is “the new jQuery” (i.e. the winner of the more recent “javascript library/framework war”) but this might not be the case.

Instead of adopting a JS framework that could be “dead” a few years from now, wouldn’t it be possible for WP to include polyfills for the latest Javascript standards plus a WP own light JS framework on top of that, designed to serve the needs of WP development?

This is actually one of the strongest arguments for Gutenberg to use Web Components internally, with a compatibility layer like Polymer or Stencil.

That said, Web Components only tackle part of the problem – how to define these custom blocks. Once we get beyond the most basic blocks, we need to think about issues like data binding, which isn’t part of the Web Components spec. This is where libraries like React or Vue have an advantage, as they’re built with the ability to handle these more advanced uses cases.

What Facebook gives, they can take away again later. Historically, they have made some not user-friendly decisions and then only change their mind on blowback. They seem to be trying to see what they can get away with.

I’m not entirely sure Facebook won’t change its mind again in the future. Having options might not be a bad idea.

That’s an important philosophical reason for Gutenberg’s framework agnosticism work – whatever framework ends up being used behind the scenes, we should be able to easily switch it out for any reason, while still maintaining backwards compatibility with all existing Gutenblocks.

That’s what I’m wondering too. If a lot of applications are bound to React in the future, can Facebook relicense it again? Like you either use the old release without security updates, or accept our new license?