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.
A few years ago, Automattic used React as the basis for the ground-up rewrite of WordPress.com we called Calypso, I believe it's one of the larger React-based open source projects. As our general counsel wrote, we made the decision that we'd never run into the patent issue. That is still true today as it was then, and overall, we’ve been really happy with React. More recently, the WordPress community started to use React for Gutenberg, the largest core project we've taken on in many years. People's experience with React and the size of the React community — including Calypso — was a factor in trying out React for Gutenberg, and that made React the new de facto standard for WordPress and the tens of thousands of plugins written for WordPress.
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.
Update: This post received an incredible response from the wider web and open source community, and a few days later Facebook reversed their position.
We think this is a wise decision, Matt. We look forward to seeing what framework/library is chosen moving forward.
Wonder if they will look at Vue.
Exactly what I’ve first thought of too! Vue is awesome.
Agreed! Vue would be a friendly alternative that is powerful, yet similar to React.
Seconded (or thirded?) – Vue would be my hands-down go-to.
Um… yeah, my first thought too… VueJS!
I think Vue.js is prepping to grow https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
It’s likely that Vue would infringe on patents Facebook may hold on React related tech, so if you’re afraid of Facebook React patents, Vue would be a very bad choice.
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.
Vue is awesome, I hope they decide to use it.
Is this going to be a problem with Vue? https://github.com/vuejs/vue/blob/dev/package.json#L85
Have you guys evaluated Oracle JET?
Honestly that hasn’t come up yet, but I’ll note it.
Then, please, burn the note…
Really? Lol
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!
That’s been a frequently suggested one and the team has met with Vue’s lead developer.
Excellent! I’m biased, but I love it!
Yes! Vue all the things! I’m currently in the process of converting all of our React components to Vue because they’re so much easier to work, more flexible and progressive
Yeah, if a ReactNative equivalent isn’t critical, Vue or Marko are both great choices.
+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.
That’s so cool. And moving away from React is a wise choice.
Vue +1
Already used by the Laravel community, currently the go to PHP MVC framework
Will this allow for plugins be developed in Vue – or the new language chosen?
+1 for vue
Vue please
Oh happy day!
Respect the decision Matt. Not easy but that’s leadership.
Any reason why the team wouldn’t go with something like Preact? https://preactjs.com/
Preact is definitely one that’s being considered.
Also check out Inferno (MIT Licensed).
I was going to say the same thing. Preact is pretty much drop-in replacement (using preact-compat), fully migrating is relatively straightforward too.
Any Facebook patents related to React are likely to infringe Preact and Vue, so that seems like a dumb move if the whole motivation of moving away from React is protection against patents.
With React, at least Facebook can’t sue you for patent infringement if you are meeting the license conditions. With Vue and Preact you have no such protection.
That’s not the motivation — take another read of the post.
Wow! Big decision. This point is particularly resonant:
Kudos on making a tough but important decision.
Are you considering API-compatible alternatives like Preact?
I wonder if the complete lack of a patent grant is better or worse than an explicitly revokable one.
The lack of explicit and revokable Grant is technically worse as any given tech might infringe, regardless of copyright license. Getting people to understand that is easier said than done though.
I would probably leave towards preact as I feel the model for react components combined with redux or similar is much better than alternatives for testable and composeable code.
Here comes Vue 🙂 But excellent decision by Automattic on the rewrite. Logical decisions shock us as much as outrageous ones these days
This is great news! +1 for Vue.
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.
Hi Matt,
Please consider Vuejs as the JS library for Gutenberg. It’s open source and having a huge community.
A bit worried on “it’ll be primarily a technical decision”. I hope the new framework is not just have a good architecture but also friendly for the WordPress developers.
You’re not worried at all. Just trying to bring toxic liberal politics into the mix.
Well that was quite the non-sequitur.
mustache.js is probably a better choice for WordPress given that it is the only JS compatible with AMP HTML. Many well know sites are using mustache.js https://github.com/janl/mustache.js/wiki/beard-competition
Ghost went with Ember and I think they’re pretty happy with it 🙂
I though I was alone thinking in Ember 😀 Currently working in a React project and I just keep missing Ember so much.
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’ve switched to Preact (MIT) instead of React.
3Kb is impactful for our mobile users, and it doesn’t require hacks to use custom HTML attributes.
I’m very curious to see what happens there. I feel like Vuejs has a pretty good run at taking over the React pieces.
While the re-write of code will take a while this is likely to be a blessing in blessing in disguise.
Considering how large the WordPress Development Community is the onboarding of another lib such as Vue (hint hint) is an easier path for developers.
Good decision. I’m for Vue as well.
Vue.js would be good alternative have been using it and would love to see that being used with WordPress 🙂
Hi Matt,
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.
Cheers,
Breck
Oh please. Don’t over-react.
There has been enough turmoil & churn in the WP ecosystem in the last 5, 6 years.
Fb’s business size & range makes the clause scary. They will have to give it up, eventually.
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.
+1
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.
Thanks for the update, Matt. I’ve always appreciated your candor.
Casting my vote for Vue.js.
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.
Happy to read it, Matt. Thanks a lot for taking the step.
One option is to not rewrite, and use preact https://github.com/developit/preact. Same API re-implemented with a clean MIT license.
That’s another one the team has been spending a lot of time with.
+1 for Preact
Another +1 for Vue! 🙂
I know there’s too many already but had to add my +1 for Vue.
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?
Preact is MIT licensed and a drop in replacement
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.
I know this must have been a hard decision. Kudos to you again for making the right call.
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.
Happy to read it and Thanks Matt. Vue.js is also one of the good options.
@Dan Orner How Angular is over engineered?
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.
Why bring in the gorilla and a jungle when all you want is a banana?
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.
What do people think of Mithril?
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.
Now if only Automattic would also come to see Slack as a competitor for the WordPress community like I explained when I turned down a job interview with Automattic over their insistence of using Slack for the interview: https://web.archive.org/web/20160601144053/https://narrafirma.com/automattic-javascript-engineer-application-by-paul-d-fernhout/
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.)
Here is an example of a coding playground I wrote that way with several examples in it which use that approach: http://rawgit.com/pdfernhout/Twirlip7/master/src/ui/twirlip7.html
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.
Cheers!
Thanks you Matt for taking action. You prevent with the decision a deep split of the WordPress Community! Now we have it behind us and can focus on the next big thing “Gutenberg”!
I just blogged about this topic: WordPress-React Breakup: My Vue on P*react + WordPress Development! — this also includes the links to resources and threads where the community is voting for and discussing different JS frameworks.
Another +1 for Vue!
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.
I’d suggest going down the road of Vue.js. It seems to be the most popular choice. A pain to rewrite but a fresh start moving forward.
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.
A very honest decision.
Thank you, Matt!
Hi Matt,
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.
Cheers,
Thorsten
@Matt
You have taken a tough decision already. Kudos for it!
Please finish it by choosing Vue.
Preact may be tempting as it will reduce refactoring efforts, but it will be job half done.
Most people who favoured Vue over React, did not do it because of Facebook’s patent clause. Vue has many advantages.
For me #1 is easy to learn. I believe, WordPress, which is so easy to learn itself, should use a JS library which is also equally easy to learn.
I have nothing against Preact but I wonder what will happen to Preact if few years down Facebook steps back on patent issue!
This.
Vue is much more in line with WordPress philosophy in my opinion. We’ve settled on Vue for our website frontends precisely because of the low overhead of Vue.
Exactly. +1 for Vue.
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’m sure that wasn’t an easy decision but I think it’s the right one! Intresting days laying ahead!
Marko seems to be a better choice.
Very wise and brave decision. Thank you!
Vue +1
+1 for Vue.js
A very hard and brave decision. Thank you!
Vue +1
Awesome news! +1 for Vue of course! Go for it!
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.
Preact enables you to use the available React components. I agree with you about Vue’s angular-like weird meta-language. Preact would be a better alternative than Vue
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.
I like that this post is in the “Asides” category 🙂
It would be interesting to see VueJS being used. It would make the adoption of some of my project a little faster.
I’ve seen all the +1s for Vue & Preact however Inferno (https://infernojs.org/) is a contender too in terms of license and parity, not to mention far better performance.
WordPress community is not ready for react yet. People get what they want. Good or bad.
This is something going to change the entire ecosystem of WordPress coding standards, I vote for VueJs.
It’s tough and wise decision.
“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.
Thanks of the clarification. Last time I installed the latest Gutenberg beta, the metaboxes were not there, so I assumed it was decided to kill metaboxes. If this is not the case, my bad.
Perhaps you should be clearer about it Matt: “other things like Metaboxes there will be no problem to provide a legacy interface for a few releases. But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.” (https://ma.tt/2017/08/we-called-it-gutenberg-for-a-reason/#comment-587619)
But why only now?
License has always been the same.
I had really hoped the license would change, and had hints that it would.
I think license is changing. I hope it is not fake news.
Please check https://code.facebook.com/posts/300798627056246
Great to hear!
Preact benefits directly from React’s large number of OSS packages/components available. Vue’s eco system is much smaller in comparison.
Matt, this decision must suuuuck.
But you were mature enough not to flame Facebook.
Kudos to you.
My vote is for Vue
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
Worked at places. Migrated to React because, well React. Training provided and everything. Devs didn’t actually like it. Everything is in Vue.js now.
Remember script.aculo.us? Yeah me neither…
Place your bets.
VueJS all the way!
Vue vs Preact.. I am keen to see WordPress team’s analysis and evaluation of these two libraries.
A lot of people are voting for Vue and I can see its growing with new features also.
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 🙂
Matt, how does using Preact, Vue, etc., address the patent issue? My understanding is that you are still at risk of FB’s patents even if you don’t use React, as explained here:
https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268
add the following to your webpack config and you’re done:
alias: {
‘react’: ‘preact-compat’,
‘react-dom’: ‘preact-compat’,
‘create-react-class’: ‘preact-compat/lib/create-react-class’
},
One thing to consider if you really care about the patents, is to think about what Facebook has patents on, and is there a chance your next choice might infringe on them.
We earlier migrated our projects from React and Angular to Vue, we found Vue is really amazing!
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,
https://www.indeed.com/jobs?q=react+javascript&l=Chicago%2C+IL
https://www.indeed.com/jobs?q=vue+javascript&l=Chicago%2C+IL
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.
Well said Matt! I look forward to seeing where the course correction takes our community.
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.
+1 for Preact.
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.
Is there any reason you can’t redistribute React without including the PATENTS file?
That would be violating Facebook’s IP rights — IP rights are the basis of all open source including the GPL so it’s something we wouldn’t do.
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…
I’d seriously consider it.
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.
+1 elm . having amazing debugging, speed, and IMHO helps a team think better together
Inferno.js +1
+1 for Preact.
Preact is a pretty good choice if you have an existing React code base. The API is almost the same and preact-compat makes migration easy.https://preactjs.com/
It seems that Vue will be the champion.
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.
You have the community’s overwhelming support for this decision. Thanks for the humility and excellent response to the issue.
I am pro-Vue, but happy to support whatever framework gets adopted.
I don’t get it. I tried to understand what all this patent jargon even means, and based on what this guy said (https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562) it doesn’t seem to make much of a difference.
Any thoughts on using Polymer? It’s a web component library created by Google https://github.com/Polymer/polymer
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.
Am I the only one that thinks this is complete garbage?
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.
…or if I missed something, please correct me @matt
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.
Best.
He… didn’t.
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?
Please take a look anf giuve a chance to aurelia.io
Has no one else here used or like Aurelia? Would you guys consider Aurelia Matt?
Haven’t come across it before but will add it to the list.
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.
another plus one for Vue, React in my view is overly complex for what it does.
Web Components ftw!
Aurelia JS
Way to go Matt. It’s high time open source teams start putting nails in the coffins of tools that don’t support their cause. Especially ones that have sneakish licenses.
Stay away from Vue, keep it clean from WP hands, P.L.E.A.S.E!
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.
It’s annoying as hell that React (really awesome library) have such crappy licence :/ But they have they own reasons thou
Sorry for asking annoying questions.. do you even consider looking into new Angular (4.x)? It’s really good for serious applications, and can be flexible enough with LazyLoading and AOT.
Well Done Matt, very wise decision. Gutenberg will be delayed like you said but happy to wait for it.
Choose Elm!
http://elm-lang.org
Elm! http://elm-lang.org/ It’s what React / Redux has always wanted to be.
Please take into consideration compatibility with Web Components standards. Helpful website tracking various frameworks: https://custom-elements-everywhere.com/ (currenlty Vue scores there better than Preact)
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.
Matt will do the right thing, He already has.
+1 for Vue.js if you go this way Matt.
I also wanted to ask a rather naive question: should we expect any future improvement around back-end as well with the help of Node.js or have I just asked a really silly question? lol
I think the server-side of WordPress will remain PHP for a long time to come, especially with the improvements in performance PHP has in the past few years and its continued ubiquity.
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.
Angular+1
So glad to read this, Matt! I’ll also say Vue would be my choice for using in Core. Cheers!
VueJS.org :]
@matt Have you consider using Polymer by google as an option. As web components will be a next big thing due to immense reusability of components
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.
NIce article about the patent stuff:
https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268
Why not using preact instead? The best of both worlds: using React, without this patent issue. Plus it would make you avoid rewriting everything.
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… 🙂
Great decision Matt.
InfernoJS is indeed a very good alternative for React, if you are thinking of switching because of license issue.
https://github.com/infernojs/inferno
Shiva
https://www.npmjs.com/package/shiva
Elm.
As a huge fan of Aurelia, it’s saddening to see no one has even mentioned it :/
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.
Hmm, searching for Aurelia again I notice a few people actually _have_ mentioned it 😛
back to angular, maybe?
angular 4 😀
+1 for Vue.js!!! Great opportunity for this now!
AHEM –> https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/
I’m curious if this will change Matt’s and WordPress position towards moving away from React
Facebook really blundered on this one -wow!
I definitely would drop React because we now know how they believed their heavy-handedness can push around the development world. What’s the future hold when they try this prank again?
But licensing aside, we should look at the long term. I’m thinking the benefits of switching to a better platform still outweigh the challenges.
Vue has my vote for its ease and user base.
Will you use React now after they changed license to MIT?
Hey, Matt!
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.
Peace!
I came here to ask the same thing 🙂
With Facebook’s announcement today that they will relicense React under the MIT license, will WordPress reconsider their decision to abandon it?
https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/
Now what…
They’re relicensing react under MIT only, no more patents. Does this mean back to React then?
https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/
Thanks for taking a stand.
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.
With the latest announcement from Facebook, will WordPress consider React again? If React is under MIT, then there is no more concern, right?
Facebook news
https://code.facebook.com/posts/300798627056246