WordPress to Select New JavaScript Framework for Use in Core

WordPress core contributors have started collaborating more around their JavaScript efforts this year with regular core-js meetings. One item on the most recent meeting’s agenda was discussion on choosing a new JavaScript framework for use in core as an alternative to Backbone.

Contributors began by summarizing the criteria for evaluating framework options, includes factors like stability, longevity, maturity, adoption, accessibility, proven in a WordPress context, and extensibility, among others. Most of the discussion centered on the benefits and drawbacks of React vs Vue.

The majority of those who participated in the meeting seemed to favor React, as it is already used with several major WordPress projects such as Calypso, Gutenberg, and Jetpack. WordPress’ project lead, Matt Mullenweg, has publicly stated that Automattic is betting on React long-term. Mullenweg has also expressed a desire for Calypso, or a similar interface, to replace wp-admin in the future. The company has been building its products on React for several years and is pot committed at this point when it comes to the framework.

WordPress officially adopting a JavaScript framework will likely have a ripple effect that will influence how many products in the ecosystem are built and/or re-written. Proponents of Vue.js find it easy to learn and extend. Those who are advocating for React also cite its extensibility, stability, and its proven use with popular WordPress products.

Contributors present for the meeting agreed they would be hesitant to commit a new framework to core without using it in some way for a core feature. The decision has not yet been made. Anyone with experiences to share on implementing JS frameworks in the context of WordPress is invited to comment in the discussion on the meeting notes and join the next core-js meeting Tuesday, May 30, 2017, 8:00 AM CDT.

59

59 responses to “WordPress to Select New JavaScript Framework for Use in Core”

  1. I hope whatever they choose they don’t choose React. It’s the ugliest thing I’ve seen in years.
    Vue.js proves that you can get the same performance while keeping your sanity. I can understand why React would be picked because of stability, but I think Vue.js is plenty stable at this point. Vue is just better than React in that it has a way lower barrier of entry. It also resembles Polymer a little bit, a direction where I hope we’re eventually going, instead of JSX.

    • Their post to discuss and select JS framework doesn’t matter, imo. They have already made a choice, Matt wrote that clearly as well. Gutenberg is written using React as well. They also already invested a ton of time in React, so I’m 146% sure that they are not *really* considering Vue. It will be unwise for them, expanding js dev sources to 2 frameworks.
      I know that “Automattic & WP.com vs WP.org” thing, but hey, the choice for them is obvious. And if I were on their side, I would not even ask and just use React, because it’s a business decision as well.

      • If a choice had been made, we wouldn’t be discussing it. We want to consider the arguments for and against the libraries before committing to a particular library.

        In fact, while Gutenberg is currently using React, the Editor team took special care to design it so that a different view library could be used if core decided on it. That is to say, there’s a conscious uncoupling of Gutenberg’s core functionality from the React view library.

        Also, really, Automattic really isn’t WordPress; there are Automatticians involved in the core JS discussions, but there are also plenty of others involved as well. The Automatticians who are involved act pretty independently. In addition, whatever we pick for the admin doesn’t really affect Calypso or WordPress.com in a huge way, since that a) already uses React, and b) connects to WordPress using the REST API anyway.

        • I wouldn’t call creating a half-hearted view abstraction “special care”. Gutenberg has already moved forward using React APIs and it sounds like the decision to remove the abstraction layer has already been made. See:

          https://github.com/WordPress/gutenberg/issues/876

          https://github.com/WordPress/gutenberg/issues/893

          I’m all for using React, but I agree with Slava. This decision was already made through the backchannels. The open public discussion is purely for optics.

        • Firstly: there’s no monolithic “.org”. It’s just a bunch of regular people who are spending time on core. Some people get paid time for that, some people volunteer their own time. Acting like there’s an us-vs-them doesn’t help the conversation, and as a contributor, it can be demoralising. There’s no “spin” that “.org” can put on this, because there is no “.org”.

          As to the specific Gutenberg points, the latter link specifically says “let’s see what the outcome of the core JS discussion is”. The former is an open ticket that doesn’t have any code merged. Right now, the discussion has led us to lean heavily towards picking React, so it makes sense to plan out the next steps assuming there’s no changes to the status quo.

          (I don’t monitor WP Tavern comments, so responses won’t be prompt.)

        • Ryan, the last thing I want is for you to feel demoralized. The REST API in my opinion has been one of the most important additions to WordPress, maybe ever.

          You’re right about the what the posts say, but if you read between the lines there is another story. Specifically, the people who are pushing React are Automattic employees and have the most commits to Gutenberg so far.

          We can pretend their votes are of the same value as everyone else but we all know that’s not the truth. Like others have been asking, what percentage of votes would it take for Vue to overrule Automattic’s desired for React? I know with certainty it’s not 51%.

          If this was truly meant to be a community discussion, then why is it taking place now? Choosing a view framework should have happened before the first line of Gutenberg was written. It was known from the start that a view framework would be needed. It was Matt’s desire to get it off the ground as quickly as possible. The best way to accomplish this was to utilize Automattic developers who have experience with React.

          For what it’s worth, selfishly my vote would be for React. But I fear the high barrier to entry will force many devs out of the WordPress ecosystem. I am no longer sure Automattic’s interests and the communities interests are aligned. I think the paths have been diverging for some time.

        • As someone who over the years has made numerous comments trying to convince people that the us-vs-them dynamic is unhealthy and inaccurate when people paint core devs as ‘not listening’ or agenda driven, some of the demoralizing statements made by Ryan today in the chat disappoint me very much:

          Again, what framework we pick primarily matters to _core contributors_

          Everyone has equal opportunity to join here and share their opinions, I don’t think a closed Facebook group’s poll matters

          (the Facebook community being mentioned is the
          Advanced WP group)

          These statements feel quite demoralizing to anyone who is not a core developer and certainly do not further the idea that all parts of the community have a role to play, even in decisions that are central to core development practices.

        • As to the specific Gutenberg points, the latter link specifically says “let’s see what the outcome of the core JS discussion is”. The former is an open ticket that doesn’t have any code merged.

          Really? I must have misunderstood when the latter referenced the former regarding this issue, and the former included this direct quote.

          Per recent discussion in core Slack, WP core has basically decided to adopt React.

          Silly me

    • That’s simply not true, React gives much more bang for the buck in the long term. it combines the best of every framework out there while reducing the damages of using a framework. It is the next big thing after sliced bread. Vue is an abomination to Javascript, I have used it and I prefer death over it.

      • Our company migrated to vue.js, 4 months ago. Our complex app is messy with JSX, router, and new dev can’t keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.

    • Another vote for Vue here. React would drastically limit the future innovation that developers could do on top of the WordPress.org platform, as patent-holding SaaS companies wouldn’t be able to use it safely. Mark Zuckerberg of Facebook has also shown himself time and time again to be a very shady character — did WordPress learn nothing from what he did to the Winklevosses when they asked him to help with their code and the terrible IMs that ultimately surfaced? Vue.js is becoming a useful skill to have in the job market as well. People started contributing to WordPress as it was open source and “free” in the GPL sense software, and I doubt they expected that Automattic would ever try to destroy that. I strongly recommend that it stay un-limited with Vue, which is booming among developers, and is on-pace to overtake React in popularity: https://trends.google.com/trends/explore?q=vue.js,react.js,reactjs

      • That link is slightly misleading, and more of an example of how analytics can be tricky. Here is a more accurate link to show the prominence of React. React a JavaScript library is recognized as an entity on its own, where Vue, as a keyword, is more associated with a chain of cinemas than the JavaScript library.

        https://trends.google.com/trends/explore?q=vue.js,react.js,reactjs,vuejs,%2Fm%2F012l1vxv

        Here is a better view of React vs. Vue.js. Vue is not gaining traction compared to React. Vue js is great, but, as far as ecosystems go, React is by far the largest, for UI rendering libraries.

        • The best way to actually compare the two in my view regarding the popularity and adoption is to look at their respective Watch, Star and Fork counts.

          Vue.js
          React

          You will see that even though, Vue came to be later than React and has ten times less contributors and 4 times less commits, it is 60 to 70 percent as popular as React.

          Also, form WikiPedia:

          More recently Vue was featured as a Rising star in GitHub having gained the most stars of any Open Source Project on the popular website. It recently clocked 2,793 Watchers, 48,505 Stars 6,340 Forks[11] which makes it among the most popular open source projects on GitHub in general having far surpassed other popular libraries such as Backbone.js (26,178) Angular 2 (22,471)[12] or even jQuery (44,104).[13]

          Now, if you want charts, here is one:

          Vue.js vs React

          Please, let me know what you think about it.

  2. I’d be surprised if it was anything other than React due to its perceived longevity. I think ultimately this will be the key deciding factor.

    Popularity of Backbone.js dropped off sharply not that long after it was introduced into WordPress core, and nobody wants to see that happen again.

    Whatever library/framework is chosen it must be robust enough to withstand the next 3-5 years, at least, of competition from existing, and new offerings.

    At the moment the only framework I see being able to do that is React, and that’s by no means guaranteed.

    • I respectfully disagree. The Laravel community is backing Vue.js. GitLab and PageKit are backing Vue.js. And if there is anyone that would ensure longevity for Vue.js it would be Alibaba. They have even created their own app framework built on Vue.js.

      Check out https://weex.apache.org/ (not to be confused with WiX :D)

    • That link is slightly misleading, and more an example of how analytics can be tricky. Here is a more accurate link to show the prominence of React. React a JavaScript library is recognized as an entity on its own, where Vue, as a keyword, is more associated with a chain of cinemas than the JavaScript library.

      https://trends.google.com/trends/explore?q=vue.js,react.js,reactjs,vuejs,%2Fm%2F012l1vxv

      Here is a better view of React vs. Vue.js. Vue is not gaining traction compared to React. Vue js is great, but as far as ecosystems go, React is by far the largest, for UI rendering libraries.

      • Vue is not gaining traction compared to React.

        It is gaining traction compared to React. It’s clear React is further along in terms of size & adoption as a function of age. If you take into account the age of React vs Vue and you look at rate of interest, Vue seems to be outpacing React.

        Current github stats:

        React: Watching 4,474 Stars 67,689 Forks 12,567
        Vue: Watching 3,112 Stars 54,883 Forks 7,488

        And Vue gained over 26k stars in 2016 while React gained just under 23k.

  3. Like Slava Abakumov I wonder if feedback matters. If 70% of the devs who gave feedback preferred vue would core use it? If they ask for feedback they need to pay attention to it because if, say, Vue was the overwhelming choice but they come out and say “yeah, it’s React” then people will simply not bother to give feedback in the future.

    I’m not saying that it should be strictly up to a vote but that asking for feedback if the choice really is already made is harmful and loses trust.

    The problem is that they’ve biased the criteria: “stability, longevity, mature, well-adopted, proven in a WordPress context, accommodating to accessibility requirements, interoperability with existing code, architected to support predictable data flows and composability, alignment with efforts like Calypso, composable, extensible, testable and ease of developer adoption”

    Alignment with Calypso, proven in a WP context… those are a thumb on the scale in favor of React.

  4. React vs Vue

    Vue gets my vote but ultimately for me it comes down to this…

    Using non GPL compatible code in WordPress.com is fine for the for profit, business arm – Automattic.

    Doing so with the non-profit, open source WordPress.org and WP Foundation, perhaps not so much.

      • Comparing React and Vue’s licensing isn’t a direct comparison. React has a copyright license (BSD), and an additional patent grant. Vue only has a copyright license.

        The effect of Facebook’s licensing is that you have a copy of the code under the BSD, and additionally, Facebook says “if we hold any patents that apply to this, you are free to use them”. This is a blanket patent license that Facebook applies to their open source projects, and doesn’t necessarily mean they do hold any relevant patents. If they do, you’re assured to be safe.

        Vue’s license contains no such guarantees, as do most open source projects. If it turns out that Evan You (or his former employer, Google) do hold patents on the processes used by Vue, you have 0 protection from patent litigation.

        This whole topic has been argued at length by armchair commentators, but Automattic has investigated this previously for Calypso licensing, and the outcome was that it didn’t matter.

        • I am really happy Automattic are satisfied that, as far as they are concerned, it didn’t matter…

          So Facebook grants users of the software perpetual royalty free use of the software until….

          The license granted hereunder will terminate, automatically and without notice,
          if you (or any of your subsidiaries, corporate affiliates or agents) initiate
          directly or indirectly, or take a direct financial interest in, any Patent
          Assertion: (i) against Facebook or any of its subsidiaries or corporate
          affiliates, (ii) against any party if such Patent Assertion arises in whole or
          in part from any software, technology, product or service of Facebook or any of
          its subsidiaries or corporate affiliates,

          So I’m incorrect in assuming this means that if any company building with React ever has to protect their patents against Facebook, their license to use React will be revoked?

          Hate being an armchair commentator, but you know… you would think for something to be included in core, it wouldn’t include wording such as this in its license…

          Anyway, it doesn’t matter to Automattic, so that’s that right?

  5. WordPress becomes mainstream for masses (still hungry for more market share), so it’s no more “cool” from my point of view. It is full of themes, plugins and WP gurus. I believe that something new and fresh can come as there is space for it.
    Anyway I am waiting for Mark’s judgement ;)

    • lol thought about skipping my usuall “get off my lawn” on this, but if people so eagerly waiting for what I have to say…. ;)

      The problem is not so much as which framework to select, the problem is the decision making process that is based on hype instead technical merits and understanding of wordpress needs.

      First there was backbone which was supposed to get WP to be fully JS. right now wherever it used is the least understandable, least extendable, least maintained parts of wordpress.

      Then there was HHMV. lots of effort to make wordpress compatible but the real world usage is zero.

      Then REST API. 6 months after it was officially merged in core there is still no place it is used in core itself, and you will find very little usage in a wild.

      (and lets not mention the lesser evils of emoji and oembed)

      Now it is obvious that the decision for react was already taken, just disregarding the actual needs for modularity and extendability need of wordpress plugin and themes.

      If wordpress wants to get anywhere it needs to grow its own JS framework that fits WP needs, but the core way is to quickly hack something, you can’t blame core in long term thinking and design, it requires too much effort :(

      • This just isn’t true:

        Then REST API. 6 months after it was officially merged in core there is still no place it is used in core itself, and you will find very little usage in a wild.

        It’s used by several popular plugins already including one of my favorites (Formidable Pro). The inclusion of the REST API is one of the main reasons I’m sticking with WP.

        I agree with the rest of your points though.

        • ah…. how many users do they have?

          I didn’t say there are no uses at all, but there is no mass adoption… i am unlucky enough to use ninja forms and just from seeing all the UX bugs, I learned a lot about what JS APP core should be.

          In the end of the day people that know how to write code can and will use anything appropriate, the question is about the people who have only “some” familiarity which is 99% of wordpress developers, were they able to do something non trivial with it?

  6. Anyone who has thoughts on libraries should join the official discussion and mention your thoughts there. WP Tavern comments are not an official feedback channel. :)

    Fundamentally, this is a discussion about adopting a library for WordPress core development. It does not stop anyone from using other libraries in your own code at all, just as the current use of Backbone doesn’t force you to use it yourself. (Obviously, there are flow-on effects from core adopting a library, such as libraries, tooling, etc.) Choosing a library is about a) making core development better for those working on it, and b) helping new contributors to join by reducing onboarding.

    The current state of core is not great for JS. It is essentially a large, bespoke framework with not much documentation, and which is far behind the start of the art (even that of several years ago). This is why most of the JS discussions so far have been about other things, such as modularising the code, adopting new build tools, incorporating libraries (like moment.js), and more. Switching to a new framework helps here, by reducing how much custom code we have, in favour of a more widely used library with better documentation.

    As to React vs Vue (vs Angular vs …), we’ve been discussing the arguments for and against each in the weekly chat, and we’re intentionally taking it slow. The key criteria that we’ve picked come from what the project needs, and are not intended to bias the decision in a specific direction. Calypso and other projects are a strong signal towards React, but they’re not the ultimate argument (if they were, we wouldn’t even be discussing it).

    Generally speaking, there’s more knowledge of React than any other library in the core teams, especially those working with JS (such as the Editor team). At the end of the day, we need to make a decision on what to use in core, and that decision directly impacts the people working on core. Picking one framework over another doesn’t mean the others are worse, it’s just us (as core contributors) trying to make our own development easier.

    (Personally: I prefer React, and I have much more experience with it than Vue, but I don’t want to see the admin become a React-powered SPA. We need to ensure there’s always flexibility for the community to adopt new libraries and tooling, because the community is the one exploring on the bleeding edge. I think the best path for the admin is a collection of SPAs, where some might be React, some might be Vue, and some might be the regular old jQuery and PHP.)

  7. The “modern” JS frameworks like Angular, React, Vue etc are all capable of making very good front-end applications. If WP decided to do with something more esoteric it could be an issue – but I’d say to people worried between these frameworks: any of them is up to the job, what’s more important is just a somewhat arbitrary decision to just chose one.

    If you think your framework is objectively the best, you probably need to get our the bubble and try some others. Most of it is down to preference of how you prefer to program. Personally I like React / JSX – but I’d be happy to contribute to Core in Angular if that decision were made.

    As it happens I think there is not a lot of value taking too much time to compare all the specifics of the aforementioned frameworks beyond, if it has an ecosystem, energy behind it and been used in production apps I’m happy to learn it and use it.

    • Seriously.

      you probably need to get our the bubble and try some others.

      Oh please.

      It’s not an arbitrary choice of some favoured tool.

      This is choosing a future direction that impacts whether people are going to find it easier or harder to get into WordPress.

      It’s whether developers are going to feel free to use their own tools without a platform that has been traditionally unopinionated forcing the decision on them.

      This is about whether we are going to hitch our wagons onto a Facebook project which operates contrary to the spirit of the open web and some of the most deeply held organizing principles found in the WordPress community.

      Trivialising this as some kind of superficial pragmatic choice to be made is deeply ignorant in my view.

      And even if it were just another choice to make, no 2 frameworks are the same. Nobody is holding a referendum on the quality of the frameworks. This is about fit.

    • The discussion by itself is just an elitistic discussion disconnected from the wordpress grass roots. It is nice that in the end the automattic developers and their VIP partner will be able to drop the names VUE or REACT or whatever, when they need to sell something to prospecting client. for 99% of wordpress developer the only question they should ask (they do not follow the discussion at all so they do not even know about it to actually ask), is how easy will they be able to move the pricing above the product picture in their woocommerce site, and neither of the frameworks are likely to make it easy.

      The power of wordpress comes from the fact that any site owner that wants to rearrange the category list in the “meta” section of a post display, can google it, find some snippet, copy paste into the theme’s function.php and he is done. Can you see any non full time developer being able to set the tool chain to work with react or vue or whatever?

      It is not like JS standardization is bad, it is actually a very much needed thing, but the original point of the whole discussion which was about mimicking PHP APIs for translation, hooks etc in the JS world was very fast highjacked to serve as a platform for frameworks wars, without even giving a lip service to the original goal. So @joe how exactly having react or vue or whatever you prefer will help with letting me “remove_action” on one of the theme actions, or set mine to run before it?

      Isn’t it bad enough to have the backbone framework in core? why do we need two frameworks? why can’t wordpress just solve the problems associated with backbone instead?

      As for react, I am with @peter, whatever are the technical merits of the framework, if used, the wordpress license will have to change to “GPL as long as you do not sue facebook”

      • the original point of the whole discussion which was about mimicking PHP APIs for translation, hooks etc in the JS world was very fast highjacked to serve as a platform for frameworks wars, without even giving a lip service to the original goal

        This is definitely not the case. We had several weeks of meetings where we discussed this, and pretty uncontroversially decided we wanted them. The discussion has since moved on, because we made decisions.

        Isn’t it bad enough to have the backbone framework in core? why do we need two frameworks? why can’t wordpress just solve the problems associated with backbone instead?

        By doing so, we end up with our own bespoke JavaScript framework that someone has to maintain. We don’t have a great history of this; for a while, the media library was completely unmaintained because no one understood it. We’re much better off picking a stable, well-maintained, well-used framework with good documentation and established learning paths, rather than trying to invent this ourselves.

        In addition, plugins and themes have the ability to use it themselves as well if they choose, which would be much harder if we invented our own framework.

        • @ryan, if by “we made a decision” you mean this post – https://make.wordpress.org/core/2017/05/24/javascript-chat-summary-for-may-23rd/ then maybe it is my english but I fail to see any actual decision there about anything related to the hook system. molecularity is nice etc etc, but the “inter-process” like communication is the core of the problem, and if it has been decided upon, then please share the link.

          By doing so, we end up with our own bespoke JavaScript framework that someone has to maintain. We don’t have a great history of this; for a while, the media library was completely unmaintained because no one understood it.

          No disrespect intended, but this sounds like core contributor do not know how to write a maintainable JS code. The problem is not realy with them, the problem is with JS being a lisp like language and it is hard to avoid falling into the traps of dynamic inheritance, function assignment etc etc which people that are too clever for their own good fall into.

          The original media library was bad? the current one is as bad (even weston had to ask for help for the media widget) and the customizer code is also unreadable.

          Focusing on a framework remind me the old saying about the dancer and the floor. Core needs to first define the API it wants to expose at JS level, and once it is done the framework actually become an insignificant technical decision as @joe claims it is.

          In addition, plugins and themes have the ability to use it themselves as well if they choose, which would be much harder if we invented our own framework.

          No one is going to use it, at least not as a free product. React (and it probably applies to other frameworks) requires too much of a learning curve, setting the tollset, and debugging effort, for someone to be able to use it is his spare time project. People that have the knowledge have a day job and will not have the time to do free work (only to get 1 star reviews because they do not have the time for support).

          The process here is typical to how core does things, it is always “lets select the easiest way to hack something right now”, and disregard any future concerns, or all the people that do not have the time to spend on slack and github and trac.

          Wasn’t the rest api a lesson good enough about the importance of planning before coding? Was there no soul seeking at all how did we end there with code that can not be used by core itself, and core needs to be rewritten to adopt to it?

      • is how easy will they be able to move the pricing above the product picture in their woocommerce site, and neither of the frameworks are likely to make it easy.

        The power of wordpress comes from the fact that any site owner that wants to rearrange the category list in the “meta” section of a post display, can google it, find some snippet, copy paste into the theme’s function.php and he is done. Can you see any non full time developer being able to set the tool chain to work with react or vue or whatever?

        What does any of this have to do with the administration backend in WordPress? As I understand it the JS choice has nothing to do with replacing the current theme engine.

        • @andrea
          1. the separation between admin and front end is totally artificial. When you have the admin bar you are at admin, no matter what url you look at.

          2. The whole discussion comes from the need to communicate between various plugins, on the basic level have some hood system in JS which is parallel to the PHP one. If there will be such a thing on “admin” it is a no brainer that it will be applied to front end, obvious candidate the rest API.

          3. OK, maybe not the greatest example, but you should follow guttenburg development…. right now the meta is JS driven, how does a user disable the display of the meta box he do not need without rebuilding the whole guttenburg project?

Newsletter

Subscribe Via Email

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