On React and WordPress

Big companies like to bury unpleasant news on Fridays: A few weeks ago, Facebook announced they have decided to dig in on their patent clause addition to the React license, even after Apache had said it’s no longer allowed for Apache.org projects. In their words, removing the patent clause would "increase the amount of time and money we have to spend fighting meritless lawsuits."

I'm not judging Facebook or saying they're wrong, it's not my place. They have decided it's right for them — it's their work and they can decide to license it however they wish. I appreciate that they've made their intentions going forward clear.

We had a many-thousand word announcement talking about how great React is and how we're officially adopting it for WordPress, and encouraging plugins to do the same. I’ve been sitting on that post, hoping that the patent issue would be resolved in a way we were comfortable passing down to our users.

That post won't be published, and instead I'm here to say that the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library. It will likely delay Gutenberg at least a few weeks, and may push the release into next year.

Automattic will also use whatever we choose for Gutenberg to rewrite Calypso — that will take a lot longer, and Automattic still has no issue with the patents clause, but the long-term consistency with core is worth more than a short-term hit to Automattic’s business from a rewrite. Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.

I think Facebook’s clause is actually clearer than many other approaches companies could take, and Facebook has been one of the better open source contributors out there. But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.

The decision on which library to use going forward will be another post; it’ll be primarily a technical decision. We’ll look for something with most of the benefits of React, but without the baggage of a patents clause that’s confusing and threatening to many people. Thank you to everyone who took time to share their thoughts and give feedback on these issues thus far — we're always listening.

But Vue uses MIT Licence, which is worse than the React licence, no? The MIT license doesn’t grant any patents at ALL. They don’t have a revocation clause because they are not giving any patents away (or ensuring you they don’t have/won’t get any) so MIT-only is leaving devs in the dark – at least Facebooks license is clear on intent.

I personally feel Vue would be a better long-term option and already has buy-in in the PHP community through Laravel. It’s easier to learn and doesn’t require much outside the core to build most projects. We’re already using it internally on quite a few projects. Would love to talk about it a bit more next month in Seattle!

+1 on Vue, I was a previous Angular 1 Dev but Angular 2 is over engineered and has a greater learning curve. Vue also has great SSR support which we are using as well with our PHP code. PHP -> Node back to PHP to output the HTML.

I think Facebook’s clause is actually clearer than many other approaches companies could take, and Facebook has been one of the better open source contributors out there. But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.

I would go for Vue because it plays nice with PHP. The best alternative to React is Preact, many companies are switching to Preact right now as it’s almost identical but way smaller and even more performant.

Have you and the team looked into Preact https://github.com/developit/preact? Same API wrappers we expect from React, MIT license and smaller overhead. Without sparking debate, React teaches sane Javascript fundamentals. It’s a great tool and I would hate to see WordPress rewrite, from the ground up, two great projects that up the ante when it comes to how great WordPress can be.

I have something that will blow away React and all other cutting edge web frameworks. It’s brand new and based on a simple but consequential new mathematical theory. I use it to power ohayo.computer. I’d say odds are 50-50 it could be a viable option for your use immediately, but even if you don’t use it now I’d bet money you’ll be using it (or someone else’s derivative fork of it) in 2 years time. Happy to explain more to someone on your team over email or phone. I do everything over MIT license or public domain, if that works for you all.

Thanks for WordPress! WP is how I first got into developing seriously a decade ago.

One thing to note for commenters discussing Preact vs Vue.js is Vue.js appears to have a more active community, more commits (2x) and more individuals contributing to it’s Github project than Preact does. Developer community, and not just basing a decision on something having the same syntax as React, will be extremely important for any framework chosen by WordPress. But I don’t doubt that these are the types of things that will be factored into the decision.

Preact benefits directly from Reacts eco system. Vues eco system is tiny in comparision: https://npmcharts.com/compare/react,angular,@angular/core,ember-cli,vue Same applies to number of OSS packages/components available. The reason is obvious, Vue is the older technology. Not a steop back as large as with Angular for instance, but a regression nonetheless.

I love React! But definitely agree that their license should not be pushed out to ~28% of the web.

Vue definitely looks like the best option! Can’t wait to see how the Gutenberg team takes what they’ve learned so far building on React and applies their learnings to something new. It’s been a fun project to follow.

Matt, I know this couldn’t have been an easy decision and I commend you on it, as well as for announcing it on a Thursday 🙂 The patent clause really is onerous to those of use building web apps for clients that someday plan on selling them to another party… I know that’s not the 96% of WP sites with a single user… but it’s important component of WP being “the OS of the web”. It’s got to stay unencumbered.

I think the vue ahead is clear! hehe…

I certainly vote for Vue, but appreciate taking a step back and really considering the landscape. I suspect a lot of the React components can be reused or salvage into Vue, but leave that to those that have been toiling tirelessly on Gutenberg.

Very happy to see this since React has never felt true to the spirit of GPL. But I think that begs the question. The next library can’t be considered only for it’s parity with React, you have to consider the licensing as well. That alone seems to make Vue.jsthe obvious front-runner, right?

I appreciate that you gave the Gutenberg developers lots of room and freedom and that they have done a great job. Thank you for making the hard decision. I think you said that after the initial work the team would stop and rewrite. It is not that uncommon. Now they can benefit from the experience and progress quickly. 5.0 is going to awesome.

Since we are talking also about Gutenberg and large community developers need to jump on board with that then VueJS is that one to use. It has clear syntax and everything needed.
Framework decision should also consider wide amount people. People who love WP because it’s easy to use. React and Preact are way too complex than it needs to be.

Yes may be Angular is not as easy to master Angular than Vue – I agree. The most tricky learning curve of Angular is probably the fact that Angular is heavily rely RxJS so you have to have a basic understanding of that and other thing Angular is relying on is Typescript, that some hardcore Javascript devs just do not want to get all that “type check system” etc. But knowing that RxJS and Typescript will pay off anyway in the long run anyway.

Typescript and RxJS was invented to solve a problem, not way around. If you do not want to learn that new stack that doesn’t mean that Angular is overengeneered.

It seems like most of people think easy learning is the most important factor. And it is really weird that most of people think Angular is hard to learn but the concept of Vue is actually pretty similar with Angular.

I bet if we ask people to use VueJS with Typescript and RXJS, they will say it is really hard to lean too.

It is a shame that lots of people don’t recognize the benefits from Typescript for large projects and the powerful of RxJS.

Anyway, I can’t agree with you more on if you do not want to learn that new stack that doesn’t mean that Angular is over-engineered. It is like a pilot walking into a future Enterprise spaceship and saying it is over-engineered.

I suggested using Mithril as a replacement when I posted the original GitHub issue “Replace React with Mithril for licensing reasons” in November 2015 (that Matt linked to for the lawyer’s opinion posted in the issue). Glad to see Automattic is finally seeing the light a couple years later. 🙂

I also outlined in that issue some ideas for developing software tools to support a rapid migration away from React to Mithril, suggesting some small amount of time/money spent by Automattic then on creating React to Mithril automated conversion tools, and perhaps also spent on even better Mithril training materials and even better Mithril third-party libraries, might be a relatively cheap “insurance policy” in case of legal disaster for WordPress developers using React.

Personally, I still feel Mithril.js is one of the best technical and social choices out there. It has only gotten better with time.

Ironically I use Slack all the time now for my day job writing UIs — but those UIs are not primarily intended to be open source communications tools the way WordPress is. So while I’d rather the company used in-house-hosted MatterMost or Matrix.org services for company communications, there is not so much of an moral conflict there.

I continue to work towards better communications tools in Mithril (e.g. Twirlip7) in my very limited spare time…

Too bad I did not apply for a job at Automattic a couple years earlier or I could have helped steer them away from React and Slack rather than just point out how poisonous those things were after a big commitment had been made.

Matt, it takes a big man to admit the need for a 180 degree course change on such a big project — so kudos for making a tough call. I hope some of the ideas I outlined in that GitHub issue and elsewhere like the link above can help you do the right thing and continue to make Automattic a great success supporting free and open source communication tools like WordPress and beyond.

I posted the following elsewhere before, but this explains the technical reasons why Mithril.js or other vdoms emphasizing the HyperScript API are the best choices.

Personally, I feel templating approaches to making JavaScript-powered UIs like React’s JSX or Angular’s own templating approach or the templating systems in many other UI systems [including Vue] are obsolete.

Modern webapps can use Mithril+Tachyons+JavaScript/TypeScript to write components in single files where all the code is just JavaScript/TypeScript. Such apps don’t need to be partially written in either CSS and some non-standard variant of HTML that reimplements part of a programming language (badly). (Well, there may be a tiny bit of custom CSS needed on top of Tachyons, but very little.)

So, by writing UIs using HyperScript (plus a vdom library), you can potentially (with some work) replace a backend like Mithril with almost any other vdom or even a non-vdom solution. So, that is another way I mitigate this risk when I have a choice.

Granted, I know many web developers grew up on tweaking HTML and love HTML-looking templates and so they love JSX or whatever and are happy to ignore how hard it is to refactor such non-code stuff in the middle of their applications or validate it (granted, some IDEs are getting better at that). But I came to web development from desktop and embedded development working with systems where you (usually) generated UIs directly from code (e.g. using Swing, Tk, wxWidgets, and so on). I like the idea that standard tools can help me refactor all the code I work on and detect many inconsistencies.

This must have been a tough decision. But when you are doing it right it does matter. I also commend the move.

You folks met with Evan? That’s excellent news. Vue.js makes more sense now than ever. The best thing is it will make the transition easy.

But may I throw in Preact! It does have an added benefit of supporting the React eci system with having to support React. Though, it can make our code messier (in a way).

One thing that I think matters the most here, is that we transition the code with coding best practices in mind and not in a way that just saves us time.

✔︎ What I mean to say is, whatever new JavaScript framework we adopt, it’s essential that we do it right. Having Gutenberg implement this new code in the right way will set the foundation of how WordPress developers will learn it.

I have often seen the coding best practices being lost in the midst of converting projects from one framework to another.

I know several developers who had started learning ReactJS because of WordPress. Done even paid to start learning it.

While this is a good move, it’s a frustrating one for many of us. Transition to a new JS framework in the right way and also taking care of documentation (at least relevant to adopting THE new framework) would help mitigate the frustration.

That said, I am thrilled to read that the community is being heard. It’s the high time for us. I’ll play my role in helping with this transition as much as I can.

Gutenberg Boilerplate is already a resource for more than few hundred WordPress developers trying to learn to adapt Gutenberg. I’ll make sure to keep it updated.

I’m supporting the adoption of Vue.js right now, but I must add I have only use Preact in two projects.

The React patent issue continues to be a controversial topic among developers and I’m sure this wasn’t an easy decision. I immediately thought of Vue and preact when you mentioned looking for a replacement for React. Good luck and I’m sure whatever direction you end up going will be the best for WordPress and the community.

Thanks Matt for this decision. My vote is for VueJS as it’s very easy to learn and on the other hand Preact is bit complex and hard for newbies. I have used both ( React and Vue ) and to me Vue is more simpler than react and I hope, WP community can easily adopt vue.

even though most of the things I wanted to say have been mentioned (in some way) already, here they are…

If the (only) bigger problem with React is its license, then the next best, and also logical, choice would be Preact.

Having already two quite large React-based applications, Calypso and Gutenberg, and thus having invested a lot of time into learning (and teaching) these concepts and paradigms, something like Preact, with the same API, makes even more sense.

In my opinion, one should not compare the usage of Vue with the one of Preact alone, as there is a huge overlap between React things and Preact things.

What’s more, I suspect that if WordPress were to adopt Preact, one or the other developer and also company might make the move from React to Preact – and thus the Preact-specific community would grow.

So yes, I would like to see some React-ish library make it into Core, but I don’t mind having to spend quite a few hours digging (further) into Vue as well.

Licencing is a very important process and when you have a huge community it only gets more complicated. I kind of see why Facebook did that, but it’s going to affect us all.
I see that Vue already been suggested here and Preact as well. I think those 2 are some great alternatives with a supportive community as well.

I guess I would take a lot of hate comments for this but for the sake of choosing something conceptually clear, be careful with Vue with its angular-like `v-if`, `v-else-if`, `v-*` attrs and web-component like element definitions. Yes it can be used with JSX but something that documents itself by default with meta-language for logic in the template, is a red alert.

I haven’t looked in the patent clause but can’t you just use a react-compatible library and still use the available react-components like `react-select`?

If plugins are not important, a very simple, pure alternative is `inferno.js`. All-functional components. You can go also lower-level but I guess you want to keep it easy for plugin developers and tinkerers of WordPress ecosystem.

A valid point, and one I was a little wary about when I was evaluating Vue.

However, I came to the conclusion that my markup is FAR easier to read and maintain with a few basic flow-control directives (if/else and for) rather than context-switching between the template language and the host language (as one does for JSX, ASP, ASP.NET, PHP, etc.).

The context-switching is far more jarring visually, even with no-delimiter switching like JSX, and it encourages unhealthy mixing of template code and business logic.

While someone could certainly abuse the Vue directives by having very complex JS statements in them, having them in those attributes encourages keeping the template simple, describing the intent (e.g., ‘v-for=”button in buttonList”‘), and keeping complex business logic (say, deciding which buttons are in the list) separated into a more appropriate part of the component code.

I’m not “a little wary”. Vue.js is wanting to draw Angular-like things back in. And yes people that used and liked and aged with Angular had to change to something like React. These people really wants back into the “good old Angular-looking thing”. No. Just no.

Logic in template strings is a step back. Built-in data-binding is a step back. `var vm = new Vue({` instead of simple functions for components is a step back. Directives are a step back.

Yes to simple functions. Yes to props/arguments as input. Yes to JSX and babel plugins if you want to extend it. You can do anything with this combo. Super flexible and simple. If you don’t want to switch context for simple ifs and foreach then write a babel plugin. Here is one :https://github.com/AlexGilleran/jsx-control-statements.

Templates are limitations and to make them work there is absolutely unnecessary complexity.

“the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library”

While you’re at it, make Gutenberg just an editor, not a complete editor screen. Do not kill metaboxes, custom fields and whatever. WordPress is used as a CMS in many projects that need a simple way to insert custom data. We don’t need to use a rocketship like Gutenberg for such simple things. A LOT of my projects don’t even use the editor at all.

Gutenberg is great, I love it since the first time I saw it. I, like many developers before WordPress, created our own custom CMSs back then, and I DID use a blocks concept on my own, so I’m all into this. That being said, we should not kill backward compatibility on such important things like metaboxes just because we’re developing a fantastic new way of editing content. (It’s content, not meta)

The plan from the beginning was to redo the entire editing screen — you can’t make a great experience with taking the old TinyMCE-in-a-box approach to editing and customization. Metaboxes are there, and totally backwards compatible, there’s just FUD saying they won’t be. (I don’t know why this is so persistent, I feel like we’re fighting fake news.) My hope is many (not all) of the plugins using meta boxes upgrade them to Gutenberg boxes, but even if they don’t they’ll still work, it just won’t be as slick and integrated as the ones that update.

The learning curve of Vue.js and its approachability makes that this is a framework of choice of many developers. The same thing was with WP, which – in contrast to Joomla or Drupal – allowed us to create some simple but customized websites with very limited ‘dev’ knowledge, based only on one or two tutorials. It’s all about products that are easy to start and hard to master. So yeah, +1 for Vue

Vue.js FTW! The usage of Laravel and Vue in various projects are increasing in the WordPress community and a lot of businesses are already working on it. So, if our community chooses Vue as the framework of their choice it would be a lot easier for us to contribute as we are already familiar with it. Just my 2 cents 🙂

I think a lot of votes here are for Vue not realizing that Preact is also a decent option. Mine was that way like a month ago. As I think most major plugin developers are professional developers, I think that Preact is actually likely the better choice because Preact / React is a highly employable skill and thus developers are likely happy to learn it.

There appear to be about 7x-10x more *high-paying* jobs in React vs. Vue currently,

and based on the preliminary 2017 state of JS survey, as React is apparently still more satisfying to developers than Vue, it looks like Vue might never catch up. As someone who had once put in a vote for Vue, I think you should maybe lay out the case for Preact or for each library before taking feedback too seriously. Also, choosing an easy ramp-up library isn’t that important since plugin development isn’t that easy of a ramp up already. In total, Vue vs Preact feels like the difference between having to learn 7 things vs 8 things, but the one with 8 things opens up 10x as many job opportunities and pays you 30% per more year.

I am switching my vote to Preact. I think with WordPress backing, it would be better than Vue, and even better than Vue with WordPress backing.

Thank you for heeding the community feedback.

PS – please show us some under-content meta-boxes in Gutenberg to help the community finish relaxing back to normal

Preact may be great for existing professional developers but Vue is more inline with WordPress philosophy to lower the bar for learning how to extend WordPress.

There are many reasons why WordPress runs greater than 25% of the web, but one of the more important ones is that it is makes development easier. Choosing Preact would be a move in the opposite direction.

P.S. I have been a professional developer for over 25 years so clearly I am looking out for what would be best for WordPress as a whole and not just what would pay me more on non-WordPress projects.

Also, please have your lawyers do some good research on Google patents to make sure Facebook doesn’t have any JS-related patent filings that might be dangerously incorporated Preact / Vue before deciding.

This is something to look out for. While the core libraries and CLIs for Preact and Vue don’t use any FB licensed dependencies (from what I have found), because of the sharing of popular libraries between React, Vue, and Preact these popular libraries could include/incorporate either React itself or other BSD + Patents dependencies.

Please consider that there are other developers in the WP community who have adopted React because it was adopted by WP. To switch from React to Vue is essentially saying to these developers that they should migrate their codebase as well if they want to be doing things the “WordPress way.”

I agree with Thorsten Frommen, if WP switched to Preact, the Preact community would grow. Here are some other advantages of React/Preact:
– It would also be easy to switch back to React if Facebook revised their license again
– The React ecosystem is much larger
– There are more React developers so businesses have an easier time hiring talent
– It’s pretty much a drop-in replacement!

Vue may be a great language and I sympathize with WP developers who prefer it to React. But React is a great language too. And I believe that switching to Vue, when you’ve already made the commitment to React and there’s a drop-in replacement for React available, would just further fuel business-minded worries of instability in WordPress.

I realize that this change is being prompted by external forces, but I hope that you decide to respond in a way that respects those developers and businesses who try to do things the WordPress way.

+1 for Vue! I’m a Angular to Vue convert, and I have NEVER been happier writing code than I am now with Vue. It is such a breath of fresh air. It is amazing how much you can get done in such a short time, with clean, concise code using Vue. I highly suggest you take a good look at Vue, it won’t disappoint. It’s just a such a joy to use.

Nobody has mentioned Elm yet, which I think is the best replacement for React (actually, way better than React): no runtime errors, super friendly compiler, fast and it will make wordpress engineers even happier because programming Elm apps is a delightful joy…

Elm would be awesome, but the requirement of a compiler would make it a non-starter for many WordPress developers who do not have a local build system set up nor the skills to do so. Also, being a functional language it has a much higher learning curve than most JavaScript frameworks.

That said I would love to see core use Elm for all its unit-testable functionality.

Good move Matt and team, though I’m sure it stings. I don’t have enough experience to put a +1 in any particular bucket… however, the more I’ve become familiar with Vue and seen the projects being build on it the more I’m impressed by it.

I’ll throw my hat in for Elm. I’ve been using it at work for two medium-size apps and it’s great. The interop with JS is good so I can re-use existing libraries. Out of all the not-JS things out there, Elm has the best documentation.

Matt, I think it is a strong but difficult decision you and the team are making and I support the decision since the legality of this is tricky at best and you are looking out for many users that could be affected by the BSD + Patents clause.

I would like to recommend the Ember ecosystem including both Ember and Glimmer.js.
I think for smaller web components such as drop in editors and other content behaviors, Glimmer provides a great experience and creates drop in web-components that can run outside of a framework.

For larger projects like Guttenberg and Calypso where routing, complex state management, access control, content management, and more come in to play: Ember provides what I think is the best Ecosystem.
Especially with a large set of contributors; the set patterns, addons, and build system help to keep applications performant and maintainable as the application scales.
Also, the ecosystem with Engines and in-repo addons can help to keep optional pieces of the application modular and installable to end users.

Ember is also being used heavily by other content management systems and that effort can be built upon, learned from, and shared.
As mentioned in an earlier comment, Ghost uses Ember for their admin and editor, but Ember is also used by Drupal headless, Cardstack, and content companies like Conde Naste, Bustle, and more.
This means that common features like tag lists, component based editors (specifically the Mobiledoc editor), and more are available as part of the Ember Addon ecosystem.

From a community and developer experience I think Ember best matches the WordPress ecosystem (as a developer that worked in WordPress for over 5 years).
Ember has many best practices either built in, well documented, or available via addons; this reduces the question of “will this work with my app” and helps to better reduce possible security or performance bugs.
From a newcomers perspective, I think Julia Donaldson’s recent article says alot to Ember’s architecture: https://medium.com/this-dot-labs/ember-mentorship-and-the-confidence-gap-8c0b93dc1ccd.
Ember is also built on customizable abstractions meaning that complexity can be abstracted from end developers and difficult code can be limited in scope.
Ember addons closely match WordPress plugins and themes as they are auto-discovered and have default configuration out of the box, but can be further customized to meet the end user’s needs.

I am part of the Ember.js Learning Team and work closely with core contributors, I would love to talk or set up a conversation with other Ember Team members on how Ember and Glimmer could fit your needs.

Look, WordPress started developing Calypso in 2014/2015. Back then, the license to React was more restrictive/ambiguous than it is today. It was modified Summer of 2016 after strong push back from the (non-wordpress) community (and pretty sure it was Google, but don’t have the link handy — google it).

No issues from WordPress yet… still promoting Calypso like it’s the best new thing since sliced bread.

At some point through all this they begin work on Gutenberg. Again, React still had the same, clear license that it has today.

STILL no problems raised by WordPress team. And in fact, as @matt himself stated in this article, he had a blog post typed up ready to trumpet how everything should be using React — plugins, themes, etc.

Fast forward to today and, to quote @Matt, “Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.”

W T F??

Call me crazy, but the way I see it, there’s only 1 of 2 things that caused this about-face:

1. Terrible management/vision. Did you just “hope” Facebook would change their licensing clause just-in-time? You had zero hope of this. Facebook has been adamant about their BSD + Patents license, and have made their reasons clear time & time again. So it’s not like this just appeared out of thin air. If anything, Facebook has been very transparent on this issue.

2. You’re only pulling the usage of React in Gutenberg because of perceived community blow back. And therefore, it’s a marketing decision. Fair, but then be honest about it. Don’t get on some high horse and pretend like you’re taking up some pseudo moral crusade. You aren’t. You’re making a business decision, and I respect that. But again, call it for what it is and don’t hide behind some feel-good rhetoric.

Regardless of whether we’re here today because of #1 or #2 really doesn’t matter. Neither of them inspires confidence, but maybe that’s just me…

Sorry if that comes across as harsh, but truth is truth. And people need to see through the BS that this article spits out.

You can certainly interpret things in that way if you like, it’s a very cynical and worst-case assumption approach. I don’t think it’s true, but also not sure what I could say to change your mind. The key difference may be that you’re mixing up Automattic, the commercial entity, with WordPress, the open source project, and the respective decisions for each.

Thanks for the reply @matt, Indeed, I was confusing Automaticc’s Calypso with Core’s Gutenberg project, assuming they were being worked on together in tandem. Or, at the very least, Core would have thought through these issues before trumpeting the use of React for Gutenberg. So in that sense, the point of my comment remains. But I will admit that my assumption that Calypso & Gutenberg were being developed in tandem lead to a bit more of a cynical comment than it should have been.

Again, I do appreciate your reply, and I hope the Core community can learn from this and not make decisions on frameworks until all issues are resolved to prevent so much wasted time & effort, not to mention confusion… because there’s no doubt the WP community is facing a lot of changes in the months/years ahead that alone are difficult for many to handle. Adding uncertainty and a perceived lack of research/leadership by Core before embarking on a major new direction hardly exudes confidence. Especially when people’s businesses are on the line.

But fingers crossed this becomes just a minor misstep along the way, and not indicative of future Core decisions.

Yes, you’re likely in the minority of people that thinks it’s “complete garbage,” assuming you’re not just operating in rhetorical hyperbole. Many might disagree with Matt’s conclusion, but this is a nuanced, complicated and significant issue. Are you arguing that Facebook’s license is merely superficial?

Facebook’s license creates a “toll,” requiring broad indemnity in return for the privilege of utilizing their product. This is well within their rights, but given the fact that Core’s decisions act as an implicit guide and endorsement, it’s a decision that has far reaching implications for the entire ecosystem: both users and devs alike. Because of this, if there are competent alternatives that don’t require materially restricting the community’s legal standing or rights to remedy, shouldn’t it be well considered?

Honestly Matt, I see this as a win. Now the developers can take a look back and see if they can do things better.

Please be careful about “few weeks” timeline estimations. I’d rather Gutenberg take into consideration some of the comments of the community rather than just a quick rewrite. We have a chance to make things a bunch more performant here.

An example of that is the customizer. It’s SLOW when things get bigger. I wish that could be completely rewritten to be more performant.

Please give hyperHTML a chance. It has an ISC license (a simplfied MIT) and absolutely nothing in common with React and other libraries.

It’s based on latest JS standards so it requires zero tooling.

It’s compatible with IE9+ and older Mobile platforms too.

It can pick-up forms and content, so it plays wonderfully with SSR.

It’s fast by default and it weights less than 5K with all its capabilities.

It’s just a young project, but it has 100% code coverage (AFAIK the only one out there) and every benchmark and example shows its muscles VS any alternative you can mention.

I’m also fully committed to this project, and as old Zend Certified Engineer, and after my recent experience with Word Press and UK publishers, I think you would rarely regret this choice. Here to help with any extra clarification, example, or improvement.

I knew that Automattic would be choosing a JS framework soon enough. However, I am surprised that React was even on the roster. I began a project over a year ago where my partner and I began replacing the templating engine with Angular. It makes the most sense to me aside from building something in-house…

We eventually gave up when the API was not making strides like we had expected.

Hopefully Automattic builds something amazing in house to replace PHP templating or leverages an existing MVC framework to take advantage of the ongoing API efforts.

Something I personally would really like to see is a direction away from global variables, “the loop” and magic functions like wp_reset_postdata. I realize these would need to be kept for backwards compatibility but a true OOP approach like $post->title() rather than the_title() (etc) as a new standard would be very nice to see.

Not to pile on, Matt, but I’m a huge Vue fan (having come by way of several other libraries), and I’m confident it would be a good choice. I know it has been for my own projects (corporate intranet stuff mostly, and my personal site).

Of course, Web Components are getting close to being a reality without shimming. So, I’d suggest that one strong consideration in making your choice is looking into how easy it is to write a “proper” Web Component and then wrap it in a component for the chosen JS framework.

That way, as web components take over, the component framework is less about being a template language and more about syntactic sugar and state management.

WordPress is so influential that for the long-term welfare of the web and the JS community in particular, I hope your decision is Preact.

React community is 10x bigger than Vue’s and 99% of that can be reabsorbed by Preact.

People say Vue is simpler to learn but that’s not necessarily true anymore. React is moving more and more towards the use of stateless functions. Nothing can be simpler than that. Pure Javascript functions with inputs (props) and a string output (html). Easy to write, reason and test. Redux will be replaced with better state management tools like mobx-state-tree, which are in fact easier to write, reason and test than Vue’s mvvm pattern. That’s really hard to beat in terms of simplicity, performance and developer experience.

WordPress support of Preact would mean the React community would start moving from React to Preact even more (that’s already happening by the way) and FB would have added pressure to remove the patents file from their repo.

And finally, WP support would also mean more and more people would start using a React-like API and help to finally have a JS framework king within we can all (JS devs) collaborate together.

Indeed, there are most or less compatible libraries like Preact or Inferno. This would certainly reduce the workload of the change. Not sure if FB’s patents extend to them…
Vue.js is indeed a nice alternative.
I don’t know if you use TypeScript already, but it might be a good idea to adopt if, it is well suited to large projects…

I wonder, will React be discarded for other Automattic projects? I am thinking about Simplenote… 🙂

I would cast a vote for Aurelia and AdonisJS. The two together are a fabulous match. Aurelia fully supports JS&Typescript, is fully webCompliant, and will shortly have SSR.
It can easily leverage your existing/re-written React/Preact webComponents.

With the recent announcement from Facebook — it looks like your stance about WordPress-React just might have made them rethink the whole licensing issue.

Which I believe is a good thing? Ain’t it? Does that also mean we get to keep React in the Gutenberg core now?

After a week of research for an alternate JS Framework, I happen to always end up with React. Also, after listening to what folks at Facebook had to say about the new bytecode compiler for React and React 16 — I must say we are in good company with this framework.

Not sure where we end up, but having the WordPress community learn React helps them get far more superior jobs, salaries, and everything than any other JS FW has to offer. And that’s just one concern. I am sure you have many, in the posts that never got published.

I am looking forward to how this all ends being a one week of ups and downs that I’d very much want to forget.

It took a lot of courage for you and the WordPress community to do what you did. Many of us in the broader web community are happy to see that your actions among others led Facebook to decide to relicense React. Let’s hope that this another step towards diminishing the value of software patents.