I am starting this issue in light of the recent announcement of dropping ReactJS support by Matt.

Since I believe the community is moving in the right direction here — this issue is where one could share their thoughts about different JavaScript Frameworks for Gutenberg (that goes into the WordPress Core).

🛳 JavaScript Frameworks!

IMHO there are two prominent contenders here.

1. VueJS
2. Preact
3. Other options (AngularJS, EmberJS, Polymer, MarkoJS, InfernoJS, Aurelia, etc.)

Just to kick-start the discussion, here're a few ideas off the top of my head.

⚡️ 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

🎯 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.

Also, a framework that's used outside of WP (such as Vue and its integration with Laravel), allows developers to use their experience in WP projects and non-WP projects.

There's already a large cross-over of Laravel/WP devs, so having the same js framework makes a lot of sense as those devs can contribute to help drive Laravel, Vue, and WP forward all at the same time.

⚡️ 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

🤔 Resources:

• Facebook Thread: Advanced WordPress Fb Group's Discussion & Poll.
• My Twitter Poll for 48 hours.
• Blog Post: WordPress-React Breakup: My Vue on P*react + WordPress Development!
• Next issue of The WordPress Takeaway Newsletter will have three survey results and other news.

🙌 Share Your Favorite JS Framework & the Reason Why?

Don't just share which JS framework you like but also share why and if time allows building an abstraction PR that shows how Gutenberg can be created with the JS framework of your liking?

Cheers!

UPDATE 2017-09-23

Plot Twist

Holly Molly! React is back in the business. WordPress did that? Not sure! It's 3 AM and I am super excited about this! What about you!

Relicensing React, Jest, Flow, and Immutable.js

Next week, we are going to relicense our open source projects React, Jest, Flow, and Immutable.js under the MIT license. We're relicensing these projects because React is the foundation of a broad ecosystem of open source software for the web, and we don't want to hold back forward progress for nontechnical reasons.

This decision comes after several weeks of disappointment and uncertainty for our community. Although we still believe our BSD + Patents license provides some benefits to users of our projects, we acknowledge that we failed to decisively convince this community.

In the wake of uncertainty about our license, we know that many teams went through the process of selecting an alternative library to React. We're sorry for the churn. We don't expect to win these teams back by making this change, but we do want to leave the door open. Friendly cooperation and competition in this space pushes us all forward, and we want to participate fully.

This shift naturally raises questions about the rest of Facebook's open source projects. Many of our popular projects will keep the BSD + Patents license for now. We're evaluating those projects' licenses too, but each project is different and alternative licensing options will depend on a variety of factors.

We'll include the license updates with React 16's release next week. We've been working on React 16 for over a year, and we've completely rewritten its internals in order to unlock powerful features that will benefit everyone building user interfaces at scale. We'll share more soon about how we rewrote React, and we hope that our work will inspire developers everywhere, whether they use React or not. We're looking forward to putting this license discussion behind us and getting back to what we care about most: shipping great products.

In my opinion, with MIT License and with the most active and biggest open source JS community behind it — React is the definite choice to stick with.

My vote is back with React now. — Faith in humanity restored.

Vote with 👍 instead of similar comments.

My vote is with VueJS

I choose VueJS

Vue has a great community and should be the choice forward.

Angular JS

I will vote for VueJS. As outlined above it's a beginner friendly and successfully used with Laravel. That makes it the perfect choice.

I will also vote for Vue JS

Please note that just shouting "I prefer Vue" or "I want XY" doesn't really help with any decision making here. If you want to vote, I'd suggest using emoji reactions or something like that instead of cluttering a thread that could possibly act as a place to document findings when evaluating different frameworks.

I'll go with Vue. It is easier to learn and adapt. Plus it's less controversial than Preact.

To the issue of "Key person dependency" coming up from time to time, isn't that what every WordPress feature plugin or unknown technology is? Koop built the old media handling, Weston did a ton of Customizer work, Matías and a few others are working on Gutenberg, just about every major change to WordPress that has happened in the last several years has had a tiny group of people working on it or understanding it.

I could be looking at this the wrong way but "key person dependency" for any choice seems like a red herring. With adoption, key person dependency is eliminated entirely. WordPress was once a key person(s) (Mike and Matt) dependency project also. I think that's a weak argument for avoiding adoption.

Again, I could be thinking about this entirely wrong, but it's a common thread of thought I see popping up from time to time and don't understand its seemingly high importance.

To add on to @swissspidy's comment, showing rather then telling is something that also can help. If people feel strongly about a replacement, demonstrate the change and what the code will look like in a branch (much as #2734 is doing for Preact ). No matter what the ultimate decision, Gutenberg will be better off with the exploration rather than cluttering of a discussion thread.

I would vote for VueJS! It's by far the easiest to adapt by the community.

I think web components (without Polymer, but with lit-html or similar if a virtual DOM is needed) should be considered seriously. Using the platform and standards is way better than any library or framework! Makes for a robust and future safe component structure, that is naturally interoperable with all frameworks. (Vue, Angular, React - to a different degree currently though: https://custom-elements-everywhere.com/ )

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go-long-on-web-components-b1e0689f64e4

I'm happy to help this project trying out Vue or web component if needed.

Also check out PR #2463 for Gutenberg "Framework-agnostic block interoperability (Vanilla, Vue)"

I'd suggest leaning towards Vue.js for a couple of reasons.

1. Proven track record within the PHP framework Laravel.
2. Seems to be easy to pickup and adopt so more people can contribute.
3. If we're moving away from React, lets make it a clean and definite shift away from it (Using Preact seems like we're clinging onto it (React) in a sense).

Just my opinion but it seems like the better choice and many other people seem to favour Vue as well as it's at least something to consider anyway.

Vue seems to have greater momentum and better community support than Preact. It solves more problems (because it comes with state management) and has a gentler learning curve. The documentation is excellent.

My concern with Preact is that it's too like React to feel legally safe (React's patents might cover Preact), and too unlike React to be a simple port (there's enough differences to break helper libraries, plugins etc).

Vue all the way baby!!

• Gitlab
• HN
• PixelJets

Github Stars -> Here
Would be absolutely thrilled for WordPress dev if Vue.js 🖖

Vue has developed a great community over time plus regular updates / upgrades to the framework.

PS. join https://chat.vuejs.org for awesome community experience.. some really dopeass devs there :)

@jbreckmckye I don't mean to derail the conversation, but do you understand what the patent clause is about? It's about protecting facebook from patent lawsuits from other companties. For example, let's say my company makes smart fridges and we use react in the UI. Let's say we have a patent on this, and then FB starts infringing on that patent...if we sue we can no longer use react.

It has nothing to do with patents in react (which I'm not even sure facebook has...otherwise preact, vue and anybody else with a similar framework would have gotten sued by now)

As a Vue.js core member, I would like to address the bus factor issue. We know this is currently a point raised very much, we are now putting measures in place to address some of the concerns.

1. Vue.js org account for npm, so we can publish as a team easier
2. Internally managing details to keep things running (websites, etc)
3. Initialising an open collective, to entice contributors and support the growing community. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4. The Vue ecosystem has rapidly grown, and more and more of the core repository contributions are coming from the community itself. https://www.youtube.com/watch?v=993X1kiisFE
5. When looking at the official Vue repositories you can see that actually lots of them are now maintained heavily by other core team members more than Evan

Overall Vue.js is rapidly growing and the 'Bus Factor' has significantly reduced. As @philiparthurmoore notes, Evan will always have a large involvement and that is a good thing.

There seems to be a lot of VueJS fans here. Has anyone actually migrated a large codebase from React to Vue? What is the migration path like?

From what I can see Preact seems like a much more pragmatic choice given that it is API compatible with React. Whereas migrating to Vue would require a much more extensive rewrite.

@patrickgalbraith That's actually the wrong reason for considering Preact. It should be judged on its merits and not because it's easier to migrate to it. I can see the following issues with Preact

• Smaller community as compared to VueJS
• Code Smells — The transition to a very similar library may force bad practices (for the obvious reason of it being the quicker path)
• Sticking with Preact is like sticking with React anyway (read it at a thread)

I have only use Preact in a limited fashion, so, this is just what I think.

@blake-newman Thanks for dropping by and clearing that up. 💯

It should be judged on its merits and not because it's easier to migrate to it.

Yup. This is a long term decision.

@patrickgalbraith if the whole project was complete, then i would consider that a fair argument. As it would be a migration piece to avoid licensing issues.

As the project is still in it's early stages, as @ahmadawais, its less of an issue.

Also Vue, React, and Preact have very similar paradigms. You can easily switch between the two, there will be differences.

There is also, although probably not totally practical in this case tools that can help the migration peace. https://github.com/SmallComfort/react-vue

Although this is not comparing the same tools, this article raises great points to consider. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@blake-newman is it really only early stages though considering it is over 6 months into development? Also keep in mind Calypso is over two years old as well.

Anyway I'm sure it will be a non issue as given what you have said that it it is easy to switch between React and Vue I'm looking forward to seeing the pull-request for it.

Stencil also looks promising.

https://github.com/ionic-team/stencil-starter

My opinion is that these 2 points make a strong case for Vue:

• Beginner friendly and..
• Huge amount of community support

Both are, in my opinion, 2 of the core pillars of the WordPress project.

I might be alone but I've been watching Evan's Patreon pretty closely over the last six months or so, and it read that if he couldn't get funding through it he would need to take on more work.

It's a real risk when a project has low funding AND it's written by basically one person (as of < six months ago). His Patreon numbers have in fact gone down recently. If the main guy says he might not be able to work on it if finances don't line up, then finances are a very real risk. A big, long term project's framework choice relying on whether one (awesome) dev can pay SF rent is a big deal.

Of course Vue could be supported generously by other companies but its hard to know that.

Community adoption doesn't guarantee framework longevity either, guys. If you haven't noticed, frameworks 'die' all the time.

That said, I'm impressed that a member of the core Vue team showed up to actually address the sole contributor issue/the bus factor, by name even, and gave some reasons that the single dev issue might be less of a problem. But it was a real problem in the very recent past.

i vote for Vue

• simple api / you can learn the most basic stuff under a week
• simple flux implementation via vuex
• fast results :P
• growing community
• MIT

Another vote for Vue, for all the reasons stated above. My apologies to anyone with mail notifications activated!

@michaelbdavidson7 , Vue will ultimately have Evan's input and the Patreon campaign was to support him to do more great Vue work. Him not getting enough via Patreon and taking on other work I don't think jeopardises Vue. As @blake-newman (a core Vue contributor) suggested (and Evan himself a couple of months ago), Vue is no longer dependent on just one person. As much as WordPress is not dependent on one person. We have Matt, yes, but WordPress can continue in some incarnation without Matt (sorry Matt ;) ). Same is true for Vue (sorry Evan ;) ).
@ahmadawais which I also feel is not accurate concerning "key person dependency".

If this goal is met, I can spend less time thinking about private monetization channels (e.g. taking on support/consulting contracts) and instead work more on content that benefits the entire Vue community...

^ That goal wasn't met and isn't even close. Assuming he meant what he said he might still be thinking about contracting, and if that's changed then it should be considered a very recent development. It's still up there as of right now. If the key person is contracting to pay rent there's risk he might not keep working on the framework, and if that's changed then its changed very recently.

All of you guys just yelling out frameworks by name have learned nothing over the past few years lol.

@michaelbdavidson7 The goal was met to support Evan working on it full time. The additional goal is there to help support him further and partly the community. Thus the birth of the open collective campaign, which is intended for the sole purpose to support the community.

I will also point out that the Patreon campaign isn't the only source of income via contributions, unfortunately Patreon isn't suitable for every company to sponsor through. Thus some contributions are paid and invoiced separably.

The reason the number went down, is because one of the sponsors was from China, and there is a limit on amount of money that can be expensed out from China in a Year. This is only temporary and will hopefully be back to support.

The other channels of income that Evan does get via doing workshops, is not only helpful to the communtiy but for him aswell. This way he can get direct exposure to support learning how the library will be and is used. So it is not actually as bad as it seems.

Vue is sustainable, and i don't speak on behalf of Evan, but i'm sure he is very happy with the current situation of finances.

One thing that I did appreciate about React was its accessibility documentation. I think this is something to be aware of and consider when thinking about new frameworks. There are accessibility principles mentioned here that apply to any defensively written web app, but having some framework-specific documentation could be helpful.

Vue.js has an open issue for accessibility. A quick look into Preact and I don't see much; is it safe to assume that the documentation from React applies?

Ultimately, it would be great to have a framework that makes programmatic testing for a11y simple and automatic so we can eliminate the majority of a11y errors and warnings.

If you want easy transition just because of the license then one option you could consider is InfernoJS. https://github.com/infernojs/inferno it offers close to same API with smaller footprint and faster runtime. Its MIT licensed. I'm one of the maintainers of inferno and I could help with the transition.

@Havunen thanks for dropping by. I was looking into Inferno the other day, haven't tried it yet. Looks promising anyway!

For context, Inferno's author has been hired by Facebook

I vote for markoJS http://markojs.com/

Gutenberg uses some new React 16 features i.e Portals & possibly Fragments, that both Inferno and Preact do not support so that might be taken into consideration when talking about React-like libs if the use of these features are critical to gutenberg.

I'd suggest DIO 8 mostly because it is the closest thing to React 16 at this point in terms API.

That said, it might be a good curiosity experiment to setup Gutenberg aliasing the mentioned React-like libs and see if they work without any changes/issues for anyone willing.

I'm not sure if they are exactly the same, but for portals, there is vue-portal developed by @LinusBorg, one of vue core team members :)

@youknowriad I was hired by Facebook. @Havunen and the team behind Inferno are doing a great job without me. The work they are doing on Inferno is awesome and the project is worth checking out Inferno if you get a chance :)

I’m one of the authors of Marko.js and would like to throw Marko.js into the ring for consideration. A number of our community members have reached out to us and pointed us to this GitHub issue. Marko.js has an open source-friendly MIT license and it is being used to build eBay.com and it has a strong and growing community. It brings in a number of the good ideas from React and Vue, but we put in a lot of effort to make things simpler and faster (through compile-time optimizations) and we removed boilerplate wherever we could. I just wanted to highlight a few of the features below:

UI components

Marko’s component model is very similar conceptually to React’s (input, state, event binding, lifecycle events, virtual DOM rendering, DOM diffing/patching, etc.). A transition in Calypso wouldn’t require much cognitive overhead. Marko also supports single-file UI components. Here's what a Marko UI component looks like:

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

Syntax

Marko does not use JSX, but a superset of HTML that supports JS expressions. It is very similar to HTML, but not completely limited to HTML the way Vue is. This gives a nicer syntax for things like loops and conditionals and makes it more clear where expressions are being used vs a standard HTML string. We feel like Marko.js templates are extremely readable and maintainable (Marko also supports a concise, indentation-based syntax).

Server-side rendering

I don’t know how important it is for WordPress, but Marko also supports high performance server-side rendering under Node.js with support for asynchronous and streaming rendering.

Further reading:

• Marko vs React
• Server-side Rendering Shootout with Marko, Preact, Rax, React and Vue
• Why is Marko fast?
• 10 Awesome Marko Features
• Meetup: Building the UI - a comparison of React, Vue, and Marko (from the Marko creator) - Video | Slides

I vote for Marko!! 🙂

If anyone from the WordPress team ( @ahmadawais? @m? @swissspidy? ) would like to have a quick chat to answer any questions about Marko, we, the Marko team, would be happy to do that. 🤙 😸

@i commented this on @m's blog, but wanted to post it here in a more public form:

I recommend the Ember ecosystem including both Ember and Glimmer.js.
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 providesthe best toolset and ecosystem
With a large set of contributors: Ember's set patterns, addons, and build system help to keep applications performant and maintainable as applications scale.
Ember Engines and in-repo addons help to keep optional pieces of the application modular and installable to end users.

Ember is 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 on @m's blog, Ghost uses Ember for their admin and editor, but Ember is also used with Drupal headless, Cardstack, and content companies like Conde Nast, 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, 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.
Ember is built on customizable abstractions meaning that complexity can be abstracted from end developers and difficult code can be limited in scope to make customization easy and fun.
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.
There is an existing curation tool for Ember Addons called Ember Observer to help find the most popular, best maintained, and most stable addons.

Calypso and Guttenberg are large, ambitious projects with mature needs. The Ember community has mature solutions for accessibility, internationalization, and other requirements of modern web applications.

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.

I noticed that there was mention about React portals and would like to put in another 2¢ that Ember has a well maintained addon called Ember Wormhole to provide this functionality and many addons build on top of this to provide features such as dialogs, document head changes, and more.

I'd vote for Marko for it's native asynchronous rendering support and Fast server-side performance.!!!

@patrick-steele-idem & @mlrawlings — thanks for dropping by. I know for a fact that MarkoJS is very powerful. While I haven't had a chance to use it in a project, I did lead a project where devs were using MarkoJS for its fast animation rendering engine, of sorts. That was very different and impressive.

I'll dig in more.

I've worked with Ember.js both in a very large enterprise organization where apps were running within other apps and at a very small startup with small standalone applications. The strong opinions and conventions of Ember.js have helped keep a productive and maintainable codebase as teams and applications grow. It not only enables the ability to share code (via engines or addons) across projects but also allows a developer who has learned the conventions to be productive in and contribute to pretty much any Ember application.

The greatest benefit of Ember has been its stability without stagnation. Without having to change any of our templates, we got huge performance benefits when the new version of Ember was released that had totally refactored the rendering engine under us. The abstraction levels seem just right for modern rich web applications that may grow and need to scale into the distant future.

When changes are necessary, migration is a core concern and deprecation guides help every step of the way (most recently using JavaScript AST/CST transforms to automatically upgrade applications).

Other popular web applications that use Ember not mentioned by @rtablada include Twitch.tv, the Heroku dashboard, Travis CI, and Discourse.

@SaladFork thanks for the update, I started by naming mostly companies in the content management arena.

A few examples of large scale open source Ember Applications include:

• Travis CI
• Hospital Run - An EMR (Electronic Medical Record) system built for offline use especially in low connectivity in Africa
• Ghost

I'm not sure how much he can go into detail, but I'm pinging @tehviking to see if he could share some of his team's recent transition of an app from React to Ember.

I'd vote for Marko for its performance, flexibility and very clear, easily understandable syntax!

+1 for Marko, as well. Having done front-end work well before I started losing hair and going gray (like, a long time ago), it has been the front-end framework/library I've been searching for all these years. It's a big reason why I love to work at eBay with @patrick-steele-idem & @mlrawlings, too.

Marko JS has my vote. Extremely underrated considering it’s ease of use and performance.

I love marko-widget along with efficient marko. simply outstanding and lean framework. Its way faster than other frameworks. Benchmark is here

I vote for MarkoJS, we had been a handlebars shop for many years.

When we made the strategic move to go into micro-services and enabling component based architecture for our platform, we were looking for the right framework to have a balance of both server side rendering and client rendering. We are a platform that has classifieds in 6 different markets including emerging markets like south africa and mexico, where data is a big concern and we need to have a site that really honors the user's browsing requirements on devices that are few years old and also using less data. Also, the user will be navigating the site back and forth till he finds an item he likes to buy, which means we need to have a really fast server rendering happening as the user navigates.

After careful consideration, we picked MarkoJS with the fact it supports:

1. Fast server rendering with good server performance
2. Pushes out the first byte as soon as possible
3. Ability to build minor components and render them asynchronously as and when data is ready
4. Ability to build a plug and play component architecture
5. Maximize client rendering with same or better architecture from React/Vue.
6. Component driven tests that can be used not only for testing rendering, but state of the component

(A success story from eBay Classifieds)

+1 for Angular (NOT AngularJS).

The Angular CLI is by far the best out of all of the frameworks, and the with migration plans in store for seamless migration between versions it would fit very well.

Plus Angular is highly adopted well in the enterprise realm, where WordPress could use some love if WordPress will continue to grow as a platform for consultants and freelancers, and cease to be just a race to the bottom.

It's got a robust community of developers of all levels. The core team is always awesome to talk to whether they work for Google or not. WordPress is largely (for most high level devs) a community they are involved in, so I'll say that community wise, Angular has a great fit

I did a talk recently on Vue in Server-Rendered Environments recently (slides here), and having worked w/ Vue in a .NET environment for the past few months, I'm convinced there isn't any other option for working in environments like that. You get a really excellent combo of being able to componentize what needs to be pulled into JS for heavy interactivity while allowing the back-end to continue to mostly control the site.

Which means it's pretty much perfect for building on top of what WordPress has now. Any other server-rendered JS library is going to most likely require node. Vue doesn't; you can register a component like <gutenberg-editor> and have WordPress literally send <gutenberg-editor> in the HTML. Vue can use the HTML sent by WordPress to bootstrap the page. It's a bit like web components in that regard, and doesn't require another piece of BE technology to get server rendering.

It's one of the reasons a framework like Laravel chose it as its default: it's super easy to integrate into non-Node back-ends. I think WordPress should adopt it for the same reasons.

I voted for Vuejs.
The same case with @borantula on his comment

My CTO introduced Vuejs to the team - newcomers to the Front-end, and they quickly get into it, now they are having happy with Vuejs. My team uses WordPress in many projects.
Currently, we are using Vuejs and Custom Element to make the front-end for a project that uses WordPress in the backend. It works very smoothly.

As @blake-newman and Evan have said, Vuejs no longer depends on a single key person anymore, so it can be said that the CONS that @ahmadawais mentioned has no longer existed.

MARKO works well in our web app. Progressive rendering works like a charm.

I cannot say anything about for Preact or MarkoJS (heavily referred on comments) but I can talk for Vue as I introduced it to our team (mainly working on php+jQuery back then) a year ago and it gradually change their understanding of javascript, getting out of the jQuery state of mind.

I think it would be a good choice not only for Gutenberg but for the long term goal of WordPress, transitioning to a more API oriented platform with more javascript on interfaces. It's easier learning curve and familiarity will encourage other WP devs to step in as well.

I saw how VueJS thrive in Laravel community and almost became a defacto choice for most, I believe it will also be like that in WordPress community.

Backbone.js

/s

No point to switch now then.
I think Vue is offering a better perspective but it would mean re writing everything

Ahh! Come on people, just give Aurelia a chance will you!
It was created by one of the lead devs from the Angularjs team.
You can go from small adoption to full framework just like Vue.js

Even the @Azure portal team said if they would have started now they would've chosen Aurelia over knockout!
And who knows?! they might be migrating to Aurelia little by little now.

Start little, I know you'll like it!

Nirmal4G,
Your thesis sounds so salesly that it's ridiculous.
In fact I believe the whole framework has the same flaws as this 404 page you directly link to in your post.
http://aurelia.io/get-started.html

@bovas85 Not salesly, I'm not even part of that team. They don't even know I'm using their framework.

@cr101 /cc

Don't judge the book by it's cover

I've used many popular frameworks before even I knew about Aurelia. If I had to stack'em by balancing every criteria out there, for my application (believe me It's a large application) then Aurelia tops the list and followed by Vue.

I believe the whole framework has the same flaws as this 404 page you directly link to in your post.

Every link I posted never goes to a 404 page. It's github's fault for redirecting a http to https site. It's fixed now. See, a bug. Tell me any framework that has no bugs, I dare you.

It's just that with other frameworks you have a lot of redundant (yet useful) abstractions. The W3C community never adopts a public framework design in their API, so there you have it, A lot of abstractions.

Every framework is so focused on backward compatibility they lose forward compatibility but Aurelia does not do that, as long as you are sticking to W3C and ECMAScript specs of HTML, JS your code works fine.

If there is no Aurelia then I wouldn't mind sticking to Vue. It's the next best thing.

It's just a matter of accepting a standard than creating a new way to reinvent it.

@Nirmal4G please provide proofs of your claims or avoid names. I hardly believe, specially when it comes to LOC, Vue was less than hyperHTML. Everything I've written in hyperHTML compared to vue was less LOC, putting together the layout and the logic. As much as I don't even believe in LOC as metric relevant to anything, reading unproven FUD doesn't seem fair to me.

@WebReflection Hold your horses, I didn't say you are worse than Vue. Sorry If I have offended you.

My application uses everything you can throw at it. I tried a prototype with many frameworks, one of the criteria I had was the LOC but from visual point of view, It's not for the reason you think, any framework performance can be improved but it's the design choices, that comes with the name.

I evaluated HyperHTML, The performance was impressive, no polyfills is great, but sadly for my requirements it didn't make the cut.

Every framework has one better thing, My wish is that if anyone can stich together the best of all frameworks out there with better design that would be divine, but that won't happen. So, I have to find that balance where a framework can improve itself in the future and where it won't.

It's really good to hear that React is now going to be MIT.
Makes me very excited about this project and I am looking forward to start using WordPress again after long time, once React and WP API will be fully supported. :)

Let`s wait and see what the actual React license will be. MIT, or MIT+ Patents..? ;)

Personally I like React but find Vue more productive. I`d be happy with either, but...

... bearing in mind the strong support for Vue by the community, I would suggest taking that into consideration, in addition to licensing.

Vue just seems to be a more appropriate choice for WordPress.

Facebook has removed 4 items from their suite of litigation traps. These are now all MIT licensed:

• React
• Jest
• Flow
• Immutable.js

Meanwhile, Facebook's Category X license still applies to:

• React Native
• GraphQL
• Yarn
• Relay
• Atom IDE
• and likely anything else made by them and "open" sourced

I still say go with Vue. It's worth it in the long run. React never made any sense to me for Wordpress anyway. It's so heavily embedded in the PHP community, Vue always seemed like the most sensical choice (plus it's not painful to use like React).

Meanwhile, Facebook's Category X license still applies to:

React Native
GraphQL
Yarn
Relay
Atom IDE
and likely anything else made by them and "open" sourced

@TheJaredWilcurt sorry but you maybe want to remove yarn from that list.. yarn does not have such "Facebook Category X" license -> https://github.com/yarnpkg/yarn

@atanas-angelov-dev

People on Reddit have raised concerns that MIT only covers copyright so developers will NOT have a patent grant when using React which I would assume is still a problem.

MIT is a great license. jQuery is MIT Licensed too. I hope you know that.

@vinayakkulkarni I still think going with Vue would be a better choice as you've seen a perfect example as how fickle React licensing can be, first they had BSD + Patents license now, switching over to MIT. Who knows in the near future they might switch back to some FB owned License / Patent and then everyone will be hung out to dry. Vue has been MIT since the beginning and is more community driven than a major corporation driven one.

That's not how it works. I read Samuel's comment on Facebook to a similar question. Once you license it MIT you can either fork it to change the license or you just can't. I am not a lawyer though.

Also, personally I think Facebook has done this as a gesture of good faith and not to trick people. That means something to me.

Also, personally I think Facebook has done this as a gesture of good faith and not to trick people. That means something to me.

That isn't a very logical statement. You are rewarding one group because they stopped doing something negative, rather than rewarding the group that never did the negative thing at all. Also, as mentioned above, they are still using Category X licensing in other similar projects, which is not a sign of good faith to me.

Vue has a LOT gentler learning & adoption curve.
And that has been the main underlying idea of WordPress from the start.

@ahmadawais I know - MIT is as good as licenses get but, and this is a big "but", Facebook apparently has patents on React and while MIT allows you to use the code for whatever purpose, you may still end up infringing on Facebook's patents (take all of this with a boulder of salt - IANAL)

And in order to stay on topic, I have to say I see a lot of what made WordPress great in Vue as well - in my humble opinion no other suitable library is as easy to learn and use as Vue.

Facebook apparently has patents on React

what part of React do you think is patented? (nothing in React is patented, try to do a research first) show links, not just "apparently".., this is the kind of comments that does not help at all. if you want to recommend your favorite library do it the right way, showing its merits, not just spreading FUD.

Why the original move to BSD + Patents if none of React has patents behind it? Facebook have not said what they are, or what they are not.

Why mess around with licensing for 2 years and only make a change for part of their portfolio, having consistently said they would not change it, and said "just deal with it, we don't care if you use it or not".

Why exclude React Native, GraphQL etc etc from the "new" licensing? What is a future version of React going to switch to? There are no guarantees when you have two-tier licensing from Facebook, depending on who complains about it...

What if part of React Native code is rolled into React. Where do you stand if a GraphQL implementation works its way into a codebase..?

This action by Facebook raises more questions than it answers, and still means that every single usage of React is a potential risk to true Open Source projects.

Just adopt the library with no baggage that is already established in the PHP world - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 I guess!

Yet another +1 to Vue. Facebook still uses two licenses throughout their projects. That's not good.

@PericlesSouza you clearly just ignore the big effort that a company like facebook is doing to improve things and move the web forward, all your questios can be answered if you just read the post about the change to MIT. I don't really know why are you still raising this irrational concern with the MIT license, with the change, React is in the same position that any other "True Open Source" project (i dont know what you call a True Open Source project btw).

@Raymonf well, basically any modern framework out there is violating that patent already (including Vue) so anyone is in the same position no matter if you use React, Vue or other framework that implements the concept described in the link (btw basically any web project out there is already violating two or three patents owned by other companies, you will be surprised to know what kind of things are patented by companies in the current time). If you are really worried about that, it means that you cant use any framework that updates UI in that way.. so in this legal context there is no better or worse alternative.

I dont want to get involved in these kind of conversations again because it will be imposible to get to an agreement so i will stop my comments. The React community is happy with the change to MIT (even the greater detractors of the original license)

Good luck to the wordpress team in the decision, the main issue about the React BSD + Patents license is solved, it is now their job to decide.

So Facebook just recently changed their licensing for React. Does that mean WordPress will continue to use React or still change the default front end framework?

@bjrmatos this is not true at all

basically any modern framework out there is violating that patent already

for instance, hyperHTML does not use virtual DOM, it uses directly the DOM API (un-patent-able) through regular callback calls (un-patent-able) and the only diffing algorithm to morph childNodes:before to childNodes:after in lists of nodes is based on Levenshtein distance (un-patent-able) and the least amount of splice operations (un-patent-able, I wrote that and it's ISC).

And while at this point I think this thread is obsolete and pointless, I don't understand the need to keep spreading FUD. If you made a choice and you like it, there's no reason to tell everyone else they are doing something wrong or are in same troubles you are. I wish we could agree on this.

@noncototient that's a million dollar question, isn't it? 💯

I just unsubscribed here as the discussion is getting a bit pointless.
I think lots of good points were moved forward and it was a learning experience for everyone who carefully read this issue.

I agree, this is now pointless. I suggest this thread be locked (or perhaps Contributors only). There has been enough feedback on this issue, and now it is reaching the point where it will only lead to non constructive argument.

Will this issue be closed?
Seems @WordPress isn't interested to migrate to new JavaScript Framework now. 🤔

For me, I personally like @vuejs. But seems it doesn't matter now. 😅

Personally I would much prefer Vue regardless.

For me, and I believe many other people, it was never about the licensing. This was just an excuse to move away from React.

Marko is insanely powerful and easy. We are currently completing a complete rewrite of a dynamic web-store with 50,000 products and it is blazing and hugely deep in features. Go this route and don't look back.

Marko is good but Prarko is 100 bytes smaller (GZipped), and is 0.01% faster on a self-optimised test, so we have to use that instead, even if no-one else does. Although tomorrow Plarko will be released, with added Fibre, which makes everything redundant.

Sorry, but that is the way the rest of this thread is headed.

Lets wait and see what the actual licensing is when it comes out, what the implications of Facebook's two-tier licensing are, and see what decision the WordPress team decide once they have investigated the issue thoroughly.

I mean, originally it asked for input on engines the community likes. And that seems to be what people are posting, yet some people just jump all over people for sending in comments that are inline with what was asked. Kinda odd.

All of the libraries / frameworks mentioned here are excellent; some are more suited to some scenarios than others. Each will have their advocates, each will be leapfrogging the others in terms of performance / features, depending on their development cycles.

Perhaps start with a simple question, as I do on most projects:

1. Do we need an SPA framework?

If the answer is yes, detail why. That gives you a set of criteria to evaluate the potential candidates against; perhaps for server side rendering, perhaps routing, etc.

If not, ask the next question:

2. Is what we really need a template engine?

VanillaJS has the largest community on the planet, and no licensing issues. It's also standards compliant ;), and with ES6 modules, might offer a suitable basis for the core development, with the ability to plugin support to use template engines such as React, Vue, Preact, Aurelia etc. etc. whatever will be released in the coming years, as required by developers.

Matt Mullenweg posted his response ...

I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.

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

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

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

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

That situation would seem like a win for everyone. Let's wait and see how this actually pans out.

Just close this issue now.. it just goes to see how fickle the world is.. sad to see people not staying by their word.

[ Edit: removed due to offensive statement ]

Good luck to everyone who has to use Gutenberg and the heavy learning curve of learning React with it.

Peace.

👋 I think we have all had a lot of discussions here. I'd like to thank everyone, who cared enough to talk and comment on this issue. IMHO it looks like that all the options we have right now are good options.

If we end up with a better framework agnostic API, one would be able to use any JS Framework they want in their apps. With MIT License, React has as strong a position to be used in the core as any other library with a good (read compatible) open source license.

🎯 If you are rooting for a particular JavaScript Framework, or have built one (core teams) I suggest you build actual examples for the WordPress developers so that people can start toying with the idea of using your preferred JavaScript framework in the WordPress based apps they build.

I am closing this ticket for now. And hoping to contribute more towards the success of WordPress both as a platform and as a community. Expecting the same from everyone here. I truly believe that this is going to be a rollercoaster adventure for anyone who works with the WordPress software.

Some time from now, we just might end up improving the software to help make it easier for its users(~30% of the internet sites) like it was a couple of years back. I rooting for WordPress here, like all of you!

Cheers!

Its not really clear from Matts comment if the decision to move away from React has been rescinded.

Firstly the actual license that Facebook will use has not yet been published, so, pretending it is all over is not really a sensible move.

Secondly, it does not address the two-tier licensing that Facebook is following: React might be MIT, but React Native will be + (undisclosed) Patents.

So.. what about the components that are shared by both?

What about React Native code being used within React? Is Fiber going to be shared between two different licenses? Or GraphQL code finds into way into React?

What happens to WordPress if it goes down the React route, with all these related Facebook projects published under a different license, and then Facebook decides that some aspects of React are actually subject to, for example, a React Native Patent Grant, or a Fiber Patent Grant?

Seriously, think very very carefully about this. The two-tier licensing is going to bite you eventually. Why risk it when there are alternatives that the majority prefer to use, that do not have this issue - Vue.

I wouldn't trust a licensing agreement that changes with the wind, instead of being properly thought out. Facebook's lawyers could turn this around on a whim.

Stick with genuine Open Source.

@PericlesSouza The license will be exactly what people here imagine from the blog post's description: a standard MIT license, nothing more. React does not depend on React Native. The pieces that are shared by both live in the React project, not in React Native. React and its FB-owned dependencies will be available under MIT as soon as our team has the time to commit the changes. We're not planning any funny business.

@sophiebits

You work for Facebook. If you are not a lawyer authorised to speak on behalf of Facebook, it doesn't matter what you claim. It doesn't even matter what code you write. Sorry.

"Imagining" licenses doesn't stand up in court.

For example, can you categorically state why Facebook adopted the Patent Grant, what the Patents were (or were not), or why they say they are changing it now, without saying 'IANAL' (I Am Not A Lawyer)?

The pieces that are shared by both live in the React project, not in React Native

But can you say that with a legal guarantee? No?

React and its FB-owned dependencies will be available under MIT as soon as our team has the time to commit the changes

What parts are being removed to allow React to be published under MIT? What non-FB-owned dependencies that presumably were not MIT compliant were you already using..? Will Facebook's lawyers be guaranteeing that everything is really compliant with MIT? How long will it take Apache Software Foundation to certify this?
.

It seems I was right to highlight that code is shared between two projects that will apparently have two-tier licensing.

You're twisting my words. Code shared between React and React Native will be licensed under MIT. All of what you think of as Fiber will be licensed under MIT. React will not include or depend on any code licensed under BSD + Patents or any other patent grant which you so despise. We're not removing parts from React. React's only non-FB-owned dependency I'm aware of is object-assign which is also under MIT.

I'm not suggesting you take my words as a legal guarantee. We're both aware that my comments here do not themselves change React's license. You can choose to be skeptical and don't have to believe me now, but in a day or two you'll see that what I'm saying here is true.

@sophiebits

I am not twisting your words - and I respect both the work you do, and your readiness to engage here.

I am simply saying that unless and until we get legal commitments from Facebook, by authorised officers of the company, verified by external open source bodies, then we are still in the same position we started in - nobody can be certain what the actual legal situation is, as you agree by stating:

I'm not suggesting you take my words as a legal guarantee. We're both aware that my comments here do not themselves change React's license.

And:

All of what you think of as Fiber will be licensed under MIT.

It doesn't matter what I think of as Fiber, it wholly depends on what the Facebook lawyers and filed patents define as Fiber.

Why is React Native currently intended to be licensed differently to React, when it shares code with React? Does that not render (pardon the pun) the MIT license invalid?

I also note that you did not mention GraphQL. Anything else I missed?

The whole point of the React licensing debacle, is the lack of legal certainty.

@sophiebits

I note your edit in response to my points:

React will not include or depend on any code licensed under BSD + Patents or any other patent grant which you so despise. We're not removing parts from React. React's only non-FB-owned dependency I'm aware of is object-assign which is also under MIT.

But you said you were removing parts from React, and would be checking the code in "in the next few days".

React and its FB-owned dependencies will be available under MIT as soon as our team has the time to commit the changes

And you forgot the IANAL... :-)

Oh, actually you said it long form:

I'm not suggesting you take my words as a legal guarantee. We're both aware that my comments here do not themselves change React's license.

Once again:

The whole point of the React licensing debacle, is the lack of legal certainty.

I agree with the point that there is still no legal certainty. But I personally believe this thread has run its course; best to mark it as contributors only, and wait until the actual License is published, and the team can make their assessment.

Unsubscribing now.

Please don't dump React, Facebook made their desision https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Whilst I understand being passionate about something, it's not a reason to make a comment like you did. A public space (which GitHub comments are), should be a safe place for anyone. Your analogy was offensive and as such has been edited. In the future please think that all genders, all types of people use this space and how what you say may offend them.

@sophiebits just a little note to say thank you for coming into this thread, it's appreciated.

This might be a topic for a new thread, but unfortunately the MIT license (even the standard one) does not clear the "uncertainty" issue with patents, which led to WordPress decision earlier.

Does the MIT license give you the right to use patented IP? Read what a lawyer has to say about that: The MIT License, Line by Line

— Frans Bouma (@FransBouma) September 23, 2017

MIT apparently doesn't grant you a patent license. Facebook has patents in React, which it says it grants you in its current license. With the current license, at least you know you are granted whatever licenses there are, and know what conditions revoke them. With an MIT, you don't even get a license grant.

The patents grant means that there are involved patents though (or what does it grant?). Except no one even knows what the patents are. Facebook didn't tell, not even when it granted them, and not when it announced removing the grant.

Regardless of what I personally or the WordPress team might think this means, what seems to be present still is the confusion around the legal situation of the (yet non-listed) Facebook patents it has on React, which anyone using it [[ may -or- may not ]] need to worry about violating, when suing Facebook today, or just by using React after the new license.

Again, may or may not, the problem is the uncertainty, and that's what I'm suggesting is not resolved.

As a reminder, the majority that offered their opinion on this thread want a Vue based solution.

There are several reasons for this, not restricted to the fact that Vue has no Licensing confusion (which still remains with Facebook's two-tier license policy):

1. Vue is designed from the ground up to be added incrementally, with islands of functionality, allowing gradual enhancement of a code base.

2. Additionally, and optionally, it provides officially supported state management and routing solutions.

3. It supports multiple processors for HTML, giving developers a choice of template language - HTML, JSX, Pug, etc, or render functions.

4. Single file components and scoped CSS (Stylus, SASS, SCSS, PostCSS, CSS Components) - in the easiest possible way. Literally just add the scoped attribute to your components Style declarations, and its done.

5. Support for computed properties (with memoization) built-in (i.e. without dependencies such as MobX).

6+. Superior performance to React, much lower learning curve, higher adoption in the PHP community, check out Laravel Mix for example - you can use that without using Laravel itself. Or just include Vue via https://unpkg.com/vue and start coding.

Vue is simply more suited to WordPress.

React:

76,364 Github Stars
571 Open issues (!)
4325 Closed issues
178 Open Pull Requests (!)
5,644 Closed Pull Requests

Vue:

68, 246 Github stars (trajectory is to overtake React by Christmas)
62 Open issues (much more responsive to bug fixing, adding requested features)
5,629 Closed issues
17 Open Pull requests
863 Closed Pull requests

@Meligy

MIT apparently doesn't grant you a patent license. Facebook has patents in React, which it says it grants you in its current license. With the current license, at least you know you are granted whatever licenses there are, and know what conditions revoke them. With an MIT, you don't even get a license grant.

The patents grant means that there are involved patents though (or what does it grant?). Except no one even knows what the patents are. Facebook didn't tell, not even when it granted them, and not when it announced removing the grant.

Therein lies the problem with not-quite-Open-Source from a big corporate. Ultimately their lawyers will overrule whatever the development teams nice intentions might be, either now or in the future.

Facebook framed their + Patents license as an aggressive defence of 'something or anything', and now we are asked to believe that very same 'something or anything' does not actually exist for React, but, still does for React Native and GraphQL etc.

Can Automattic promise they will take burden on itself and carry React, fork, develope it on its own, when Facebook again change its licence and opinion about React ?

For me it looks like Facebook is setting a trap for WordPress. 25% of all websites in the world is big catch.

please mark this thread as contributors only ASAP, it'd be great to read any contributor outcome, instead of just FUD and speculations, without needing to fully unsubscribe. Thank you.

@WebReflection Wordpress' stakeholders are not just its core developers, but the extended community too.

@PericlesSouza citing Github stars doesn't amount to anything. And that this issue is being bum rushed by people throwing ridiculous claims around doesn't mean we should ignore facts: https://npmcharts.com/compare/react,angular,@angular/core,ember-cli,vue

Vue isn't much more than a blip on the radar. The staggering majority uses React and would most certainly not agree with your bullet points either.

@PericlesSouza citing Github stars doesn't amount to anything. And that this issue is being bum rushed by people throwing ridiculous claims around doesn't mean we should ignore facts: https://npmcharts.com/compare/react,angular,@angular/core,ember-cli,vue

Vue isn't much more than a blip on the radar. The staggering majority uses React and would most certainly not agree with your bullet points either.

NPM stats? You mean the very same stats they admit count every single request to check whether or not you are using the latest version, or via every dependency, as a request for a download? (They admitted this on their blog when people laughed at their "billions of packages a month" claims).

If you want to go that route, then everybody is using jQuery.

Perhaps try figures for packages that don`t have that dependency distortion field:

https://npmcharts.com/compare/vue-cli,create-react-app

Completely different picture to the one you chose to present.

Or how about website usage:

https://w3techs.com/technologies/comparison/js-react,js-vuejs

Which is backed by BuiltWith stats:

Oh, and I`ll just leave this picture here - from when the team asked the Community themselves. You should listen to them rather than treat them with contempt.

@PericlesSouza It makes no sense to compare vue-cli against create-react-app since there are other very popular build tools for React like Next.js and GatsbyJS.
Many React devs don't even use a CLI and instead use their own custom Webpack build scripts just like Gutenberg and Calypso do.

The reality is that the React ecosystem is much bigger than Vue's. Take for example Material UI for Vue.js which has 4,339 stars while Material UI for React has 29,078 stars.

A native select box component that provides similar functionality to Select2 without the overhead of jQuery: Vue select has 1,348 stars while the React select has 8,493 stars.

@PericlesSouza, @drcmda, all this data can be contested in a lot of ways, even the npm stats with the cli's, if you add AngularCLI and EmberCLI you will see totaly diffent data, which does not mean anything:

Source: https://npmcharts.com/compare/vue-cli,create-react-app,@angular/cli,ember-cli

Source: https://w3techs.com/technologies/comparison/js-angularjs,js-react,js-vuejs

Source: https://insights.stackoverflow.com/survey/2017#technology-frameworks-libraries-and-other-technologies

But this conversation shouldn't be about which framework is most used, but which will be better for Wordpress environment as a whole.

@PericlesSouza @willgm The rules apply to both. Both get counted in the exact same way, pretty disingenuous to claim it isn't fair. Clinging to optional CLI's or suggestive websites counting "likes" and "stars" is futile. Even stackoverflow is highly subjective and i haven't even heard of the "builtwith..." site until today, and CLI stats, well, reflect how many use a CLI (the majority doesn't).

The data from the most obvious and important source, reflecting real production environments under the same exact circumstances is the one statistic you don't like i get that, doesn't change the way it is.

But this conversation shouldn't be about which framework is most used, but which will be better for Wordpress environment as a whole.

And i take it you know which one is the better suited. You think the 400.000 people per day getting React off npm are all mistaken. Vue could compete on its own, doesn't really need a mob rushing into issue trackers.

@PericlesSouza @willgm The rules apply to both. Both get counted in the exact same way, pretty disingenuous to claim it isn't fair. Clinging to optional CLI's or suggestive websites counting "likes" and "stars" is futile.

Nope. React has 16,800 dependent packages that skew the figures. NPM admit that all they count as a download is a 200 result code when calling a URL, as a result of a dependency check, or a bot, or a mirror, or anything. Incidentally, they also say that most downloads in China, where Vue is highly popular, are from mirrors, and are not counted.

Judging by your use of language - 'clinging', 'suggestive websites', 'futile', you don't have any real arguments on this subject, whereas, as requested by the Team, I have posted the positives of using Vue (see above).

Counting Stars - others do that when pointing to the success of React, yet you decry their value when used to indicate the popularity of Vue? You also do not make any mention of the much higher number of outstanding issues (571), and quite remarkable number of outstanding pull requests (178) still pending for React, which when compared to the higher responsiveness of the Vue community in bug fixing and adding features, is a valid cause for concern when proposing use of React.

Which brings me to:

Counting Likes - well, that was the whole point of this thread, as started by the team and asked of the Community - I guess you simply do not like the result. Here it is again, and very conclusive it is:

Nope. React has 16,800 dependent packages that skew the figures.

@PericlesSouza How do you get to that conclusion. It means what it's supposed to mean: 16.800 packages have declared React as their dependency in package.json. Not bots, not China, ... packages. Vue has about 2580, that means it has a much smaller eco system and userbase. Why are we even arguing this? It is directly reflected by the usage stats. Updates, real persons or bots, it applies to both packages. Unless you assume bots are deliberately skipping Vue for some reason.

To single out one package in a tracker that treats each package the same makes about zero sense. On the other hand counting likes means nothing more than that community XY knew where to vote.

@dcrmda

I think what he means is that every time you install a package that has a dependency on React, and it hits NPM to check versions and dependencies, that NPM count that as a download of the package, even if it's not downloaded.

If that is what he means, then he is quite correct; it is explicitly stated by NPM that they do this; they describe their 'methodology' as 'intentionally naive' (they do also mention that bots and mirrors can skew the figures as they have no mechanism for determining what a request is for, they just count it). And React has more dependent packages, therefore this effect is more pronounced.

As for lots of dependent packages - yes React being an older framework it has more, and it kind of needs them. I develop with both React and Vue, and with Vue you tend to need less additional packages, as the core is pretty complete, and the official Router and Vuex also follow the philosophy of low-dependencies. Vue itself is not dependent on any packages, React is dependent on a few. They have different approaches in this regard.

Another example is that people tend to use an integration package between say Bootstrap and React, or use libraries such as styled-components, classnames etc. With Vue you generally don't need to, although such projects do also exist. I find Vue much easier to work with as I can have component scoped CSS out of the box without additional libraries or configuration, and I can write my own simple integrations with CSS frameworks as needed, rather than importing a whole integration library and then trying tree-shaking out the 75% I don't need.

@PericlesSouza you missed a couple of pretty relevant items off your 'Pros of Vue' post:

Named Slots to allow reusable template components such as standard Forms, Inputs, Layouts etc, which is more flexible than Reacts use of children.

Conditional components with the optional ability to Keep-Alive local state without destroying the non-active component.

The HTML element 'Is' a Vue component syntax for string templates, which prevents hoisting of rendered HTML elements that result in invalid HTML.

One way data flow with props, but with the addition of a much simplified 'emit' and 'event bus' flow to notify or update sibling or parent. This can be useful for intercommunication between:

Multiple Vue instances on a page, controlling specific regions. This technique is useful for dynamic dashboards or pluggable widgets, and memory management.

Global and local component and custom directive registration.

Chainable Filters in addition to computed properties.

All the above are part of the core Vue library.

React is a great framework, and I enjoy using it, but personally I think Vue is more suitable for this proposed use case.

@mcquiggd

Yeah, I was rushed and did not have time to make a complete list of Vue's advantages.

It`s interesting that you mentioned React having dependencies as I notice it is dependent on fbjs. I added some emphasis to parts that should set off alarm bells if people are considering React, with Facebooks two tier licensing strategy while sharing code between differently licensed projects. Hint everything about it is worrying especially when you see the list of projects that depend on it, but have different licenses.

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

Purpose

To make it easier for Facebook to share and consume our own JavaScript. Primarily this will allow us to ship code without worrying too much about where it lives, keeping with the spirit of @providesmodule but working in the broader JavaScript ecosystem.

Note: If you are consuming the code here and you are not also a Facebook project, be prepared for a bad time. APIs may appear or disappear and we may not follow semver strictly, though we will do our best to. This library is being published with our use cases in mind and is not necessarily meant to be consumed by the broader public. In order for us to move fast and ship projects like React and Relay, we've made the decision to not support everybody. We probably won't take your feature requests unless they align with our needs. There will be overlap in functionality here and in other open source projects.