Cancel

Sarah Gooding

WordPress Abandons React due to Patents Clause, Gutenberg to be Rewritten with a Different Library

photo credit: Lalesh Aldarwish

This evening Matt Mullenweg announced on his blog that WordPress has decided to move away from React due to its BSD + Patents clause licensing. Gutenberg engineers will be rewriting the new editor to use another JavaScript framework and Automattic plans to rewrite Calypso as well:

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.

Mullenweg clarified that Automattic has been happy with React and that the company’s general counsel didn’t think they would ever run into the patent issue. He also commended Facebook on being “one of the better open source contributors out there” and for making their intentions clear. Ultimately, Mullenweg decided that he wasn’t comfortable with the larger WordPress community inheriting the patents clause:

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.

After the Apache Software Foundation added Facebook’s BSD+Patents license to its Category X list of disallowed licenses, many open source project leaders and developers petitioned Facebook to consider re-licensing React, as many React-based projects are now having to be rewritten. Facebook decided it wasn’t budging on the patents clause and opted to continue protecting its own interests, fully recognizing that it may lose some React community members.

In the past Mullenweg has been outspoken about how Automattic was betting on React. Many in the community considered WordPress adopting React to be a foregone conclusion, given that both Calypso and Jetpack’s new admin interface were built on it, as well as WordPress’ new Gutenberg editor. In making the costly decision to rewrite Gutenberg and Automattic’s products in another library, Mullenweg has demonstrated he is willing to lead the WordPress project in a direction where the community can feel confident about continuing to use and extend the software.

“The decision on which library to use going forward will be another post; it’ll be primarily a technical decision,” Mullenweg said. “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.”

Gutenberg could certainly use the extra time and may gain a new crop of contributors, given that the learning curve for the new library isn’t likely to be as steep as learning React.

At the end of May, WordPress core contributors had narrowed their considerations for a new JavaScript framework to React and Vue. It appears that Vue is still a strong contender. After a commenter on Mullenweg’s post suggested switching to Vue, he replied that it has been frequently suggested and that the team has met with Evan You, Vue’s lead developer.

When I interviewed Evan You in June, he said he didn’t have enough perspective on WordPress core to make an unbiased recommendation but offered feedback on some technical issues being discussed at the time. He also clarified some common misconceptions about Vue, which WordPress’ React proponents had been using as leverage in their arguments against adopting it.

Mullenweg also confirmed in the comments of his post that Preact is another library under consideration. Preact.js is a lightweight 3kB alternative to React that uses the same API but is MIT-licensed. Some are already speculating about Preact being the front-runner for the replacement, as Gutenberg already has a branch devoted to trying it.

https://twitter.com/carlhancock/status/908510738066657281

Also, Mullenweg’s comment that the decision “will likely delay Gutenberg at least a few weeks, and may push the release into next year,” seems to only be feasible if the team rewrites the project using Preact.

Public reactions to the news that WordPress is shifting away from React have so far been overwhelmingly positive. Many are thankful and relieved that Mullenweg made the tough decision to change course and select another library after investing so heavily in React.

The discussion regarding the new framework continues behind closed doors and is not open to the public, although a pull request for using Preact in Gutenberg is open on the project’s GitHub repo and some community discussion regarding the library selection is happening there.

Category: ,
Tags: , , , ,
55

55 responses to “WordPress Abandons React due to Patents Clause, Gutenberg to be Rewritten with a Different Library”

    • Reinventing the wheel is not necessary + it’s better to adopt some existing framework and gain some contributors/contributions along the way.

      I would love for Vue to be used but I’m afraid that lack of time for the rewrite dictates otherwise.

      Create forum topic from comment

    • @Eugene Kopich, obviously not. A sign of maturity is the ability to reflect on your past mistakes and try to avoid doing them again. WordPress was burned with the decision of using backbone, a library which the usage off resulted in an unmaintainable unreadable code. Selecting React/preact or vue is likely to end up the same as JS libraries are getting in and out fashion faster then woman cloths.

      There are two JS libraries used in wordpress that work well, tinymce and jquery. The first is because it is actively maintained by a company which has a core interest in maintaining it, and the second is because it is relatively simple.

      For react, preact and Vue, there is no reason to believe they will be around in 5 years, and it is obviously better to have something that is of lesser quality but you can iterate on at your own pace. But obviously the great core thinkers prefer to switch libraries in 5 years over having their fate in their own hands. Oh wait, no one is going to convert now the backbone mess into a modern library so expect in 5 years to end up with a gutenberg no one can maintain, just like the media library now.

      Create forum topic from comment

      • I suggested Mithril.js as an alternative in November 2015 when I filed Calypso issue #650 “Replace React with Mithril for licensing reasons” linked in the article (the one with Automattic’s lawyer’s comment).

        I still feel Mithril.js is a great choice. But the more important decision factor is to use any vdom like Mithril, Maquette, or Inferno supporting the emerging “HyperScript” API instead of a library like Vue or Angular that emphasizes HTML-ish templating. That way, people can code their UIs entirely in standard JavaScript/TypeScript which makes maintenance and refactoring easier. And in a worst case, you can always replace the vdom backend with another that also supports the HyperScript API while most application code using that API can stay the same.

        See my comment here for more details on why using the HyperScript API instead of HTML-ish templating makes sense:
        https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330076576

        Create forum topic from comment

      • @Paul
        Personally I think Vue’s HTML-ish templating adds value here over the other alternatives, because it is more approachable to a wider number of people. But Vue let’s you render however way you want, devs can code using their own render functions and even adopt jsx if they want. Vue works just fine alongside jQuery as well, which is a plus.

        @mark

        You make it sound like Backbone was an foreseeable error. I don’t think we were burned by adding Backbone, it just didn’t work out. As Gary mentions on this page, back then JS expertise inside WP was still evolving, we know much more now and have more models to choose from as the JS community has worked things out over time.

        I would have preferred to see WP build out our own tailor made JS framework/library but there’s no appetite for it as far as I can see.

        Create forum topic from comment

      • @peter, no need to twist my words. I didn’t say that using backbone was an obvious mistake that could have been avoided at the time, all I said that having the experience, repeating the same state of mind which lead to that mistake is a problem and sign of immaturity.

        WordPress refuses to grow as a software development organization, and the same state of mind of “hacking something quick using the hip tools de jour” is still prevalent. Just the fact of wordpress not being able to actually enforce its coding standard on its own code is a sure sign for that.

        The media library is something that was not designed and was just hacked, under the assumption that if the code works it is good enough. Same is happening with the customizer that it is basically a long number of hacks with no design, the rest API which also was not designed for the community but only for the needs of whoever worked on it, and it is in core only because its developers were deemed to not be mature enough to accept “it is not ready” call made by matt (in retrospect his reasons were wrong, but that is not the point here), and now we have gutenberg which even before its 0.1 release started to suffer from feature creep.

        As basically it is the exact same people being driving core through all this mishaps, it is not clear why one should assume any lesson would be applied today when you did not see all those people learning much before.

        If whatever framework is selected without moving all the core to it (which is basically what pento and others advocate), it does not matter which one it will be as it will be a long term fail, incurring technical debt for other people to handle because “We are not mature enough to do boring things”.

        Create forum topic from comment

  9. “The discussion regarding the new framework continues behind closed doors and is not open to the public”

    I want to strongly counter this. The discussion on library choice has been ongoing for months and occurs across Github tickets, Make/P2s, and in the weekly JS meetings. Anyone who would like their view (Vue?) heard in the decision is welcome to contribute at any of those venues.

    I am certain the eventual decision will not make everyone happy, but it will be informed by everyone’s views.

    Create forum topic from comment

  10. Now could we take a moment, and reflect how it all turned out? You see almost like 100% people are reacting about it positively! From the start because of the Patent clause choosing React was always wrong, as per ecosystem I understand the point of choosing React, but that license was always a big no-no. Nowing choosing anything other Vue will be mainly Ego or justing thinking about only a few people’s learning curve! Keep in mind I am not saying Vue is the best in the world, there are other really good frameworks, and there will be in future too, but as it’s a community driven project, you have to look for overwhelmingly strong positive support for Vue!

    Create forum topic from comment

  11. It’s a tough decision but one I support. I have created a GitHub issue to discuss Choosing the JavaScript Framework for Gutenberg (~WordPress).

    I am rooting for VueJS here. 🎯 I truly believe that WordPress can do a lot better with VueJS. VueJS has a huge set of followers and it’s easier for beginners to adopt. This can also turn into a big win for WordPress if done right. I have used VueJS myself, in several projects, and I love it.

    VueJS:

    PRO: Beginner friendly
    PRO: Proven track-record of success with Laravel
    PRO: Way more popular as compared to Preact with a great amount of community support
    PRO: More contributors than Preact
    CONS: Key person dependency

    Preact:

    PRO: Easier transition
    PRO: Evolving community with about the same amount of monetary support as of VueJS
    PRO: A subset of React based libraries would still be well supported with Preact and with compat.
    CON: Transition could lead to messy code and confusion (for beginners)
    CONS: Key person dependency

    P.S. I have also blogged about this, – Blog: WordPress-React Breakup: My Vue on P*react + WordPress Development! — https://ahmda.ws/WPVuePreact

    Create forum topic from comment

    • Another possible blocker for Preact was brought up on hackernews: some people/businesses concerned with the legal implications of React’s license might have the same concerns with preact considering how much it resembles React. If we’re going to avoid the baggage of that we might as well do it properly.

      Create forum topic from comment

  14. I think the way that Matt’s original post was structured and how comments/replies have been careful to walk a specific line, that it’s subtly setting a path towards Preact being the replacement library.

    Not my choice, I can’t see why WordPress would want to use a second-tier library (i.e. one based on another but lacking features).

    Create forum topic from comment

  18. This is the right decision, and it could not have come soon enough.

    Moving forward, I think VueJS is the right framework for WordPress core, not just because it is a solid option without problematic licensing issues, but because WordPress can invest in VueJS and grow it to be a framework fitting the needs of the WordPress community.

    Create forum topic from comment

  19. Apart from the big main decision here, this stood out to me: “It will likely delay Gutenberg at least a few weeks, and may push the release into next year.”

    I can’t believe we’re even considering a release of Gutenberg in 2017. Given how incomplete it still is, how little documentation there is, and how little thought has still been given to backwards compatibility and impact on the theme/plugin ecosystem, releasing Gutenberg in the next few months would be a disaster. And that was before the decision to change libraries.

    While I’m not opposed to Gutenberg overall, the timing here is deadly. Given the magnitude of the change, Gutenberg should be completely done, with all documentation in place, for at least 3-6 months to give the ecosystem time to adjust. I beg you to slow down please.

    Create forum topic from comment

    • Beat me to it. This bothers me – 5.0 has always been positioned as a “when it’s ready” release and it sounds from that phrasing like there’s always been a date, at least a rough one, in mind.

      Come on, folks – share a roadmap. What major things are left to be done before we have a release? Whats the plan for testing against existing sites and code? What does that include (i.e. will there be testing against sites made with page builders? Which ones? What versions?) Same issue for plugins. What happens to themes that aren’t Gutenberg aware? etc… All of this should be on a central, easily seen doc, not scattered in tickets etc.

      For that matter, why isn’t the same approach as the REST API release being done here? Release a version of core with Gutenberg as a plugin. Let us all download it, test it, catch things, but not use it for sites where there are breaking bugs AND let us deploy it for clients who really will benefit from the new editor. Catch things, fix things, refine things. Do this for a release or two. Then put it in core.

      On the React issue – Kudos. Seriously. That reversal was the right thing to do even if not easy and it’s great to see it done. I’d like to see Vue but again, a set of requirements for the candidates should be public.

      Create forum topic from comment

    • It’s worth clarifying here a little, as I totally get that there’s a lot of information going on. 5.0 always was aimed for 2018. What was planned for 2017 was the ‘merge proposal’. This is simply when the project is ready to be considered, not merged.

      Create forum topic from comment

      • Tammie, is this your interpretation of what Matt said or are you directly speaking for him? I think part of the communications problem is that Matt has been saying different things than the Gutenberg team. When someone says “release” that means launch, not merge proposal. In order for your statement to be accurate, that would mean Matt used the incorrect words. I don’t consider Matt to be a poor writer, so I’ll continue to take his words at face value.

        Create forum topic from comment

      • I am not speaking for Matt, I am speaking as someone involved in the project. My comment comes from both the roadmap:
        https://make.wordpress.org/core/2017/08/11/revised-suggested-roadmap-for-gutenberg-and-customization/

        Matt also says the following in the most recent post:

        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.

        Create forum topic from comment

      • He used the words “may push the release into next year”. This doesn’t align with your “5.0 always was aimed for 2018” at all. How can a release be pushed into 2018, when it was intended for 2018 all along?

        Create forum topic from comment

      • Matt has been adamant in saying that Gutenberg would not be merged into core unless he and the team decided it was ready. It needs way more testers/testing. Optimistically, the merge proposal would have happened with 5.0 near the end of this year but now we know that 5.0 is the target version for Gutenberg and it won’t happen without it. Both are pushed back to next year.

        Create forum topic from comment

    • No, it never going to be released this month. WP v4.9 has yet to be released and Gutenberg is scheduled for v5. If there was any chance of it making it this year, it now looks like it will be next year. This is actually a very good thing.

      Create forum topic from comment

  27. Speaking just as an in-the-trenches-builder, not a dev, I’d say anything that delays Gutenburg ending up in core is a good thing for WordPress users. I wish the delay was to make it more user-ready but I guess we take whatever we can get.

    Maybe the good reaction to this difficult decision will encourage rethinking forcing us all to live with Gutenberg right away. How about another bundled plugin like Hello Dolly?

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.