Gutenberg: Choosing the JavaScript Framework for Gutenberg (~WordPress)

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!!

• [x] [Gitlab](https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN](https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets](http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

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. :call_me_hand: 😸

@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

I wanted to throw my support behind MarkoJS.

Two years ago I moved my companies infrastructure from ExpressJS and Jade (now PUG) to Marko JS. My company wanted to create complicated and reusable components across our entire ecosystem. Developers wanted speed and reusability. Designers wanted a decreased design load. We haven't looked back since.

We now have multiple client facing websites written in Marko and an entire CMS system as well.

Ultimately, I chose MarkoJS for the following:

• Fast server rendering even with frameworks like Koa and or ExpressJS
• Handles asynchronous rendering of page data
• Ability to build plug and play components for a larger ecosystem
• Better performance than React/Vue
• Extremely easy template syntax

I'd also like to point out that the MarkoJS team has literally been stellar. @patrick-steele-idem and @mlrawlings have always been on-board to institute new ideas, fix problems, and help individuals.

👍 for MarkoJS

Preact is a React-API compatible library which means Preact benefits directly from React's eco system and the large number of OSS packages/components available. Vue's eco system is much smaller in comparison. The documentation for third-party Vue packages/components is in Chinese.

Please, no more "I vote XYZ", they do nothing to add to the conversation apart from send needless replies to people subscribed to this issue

🔥 Angular

• PRO: Biggest competitor to React
  For many people. the question is often "Angular or React?" / "React or Angular?". The Angular community is arguably the biggest among React alternatives, and growing rapidly.

• PRO: Lots of learning resources
  In addition to official API docs and guides, Angular probably has the biggest ecosystem of educational materials, blog posts, books, and many many video courses, both free and commercial in every major learning platform, plus Google GDEs teaching it in workshops and conferences.

• PRO: Integrates well with Redux
  Either directly, or via RxJS empowered Ngrx (supported by member of the Angular team)

• PRO: Best in class tooling support

  • CLI has way more features than others

  • Very good editor support in VS Code especially with the language service

  • Written for TypeScript, provides best TypeScript experience

• PRO: Feature rich, opinionated, and organized by default
  Logical separation via Angular Modules (NgModule), as well as standard features for forms, HTTP calls, routing, etc makes it easier for other developers to read code and contribute to it

• PRO: Best integration with RxJS
  Useful for many API streams, and many streams of events in one page in general

• PRO: Built-in DI (Dependency Injection) system
  Useful for creating extensibility points and maybe even a plugin-system, especially when combined with RxJS

• PRO: Ticks many other boxes other libraries cover

  • UI libraries with permissive licenses
    There are PrimeNg, Angular Material 2, ngx-bootstrap, and many more...

  • Lazy loading
    Built-in support for lazy loading routes, and supports lazy loading modules manually as well

  • Component-specific CSS
    Ensures CSS is scoped only to component, loaded only when the component is loaded, and has hooks for global CSS

  • Server-side rendering
    Already working with Node and ASP .NET Core, and getting better focus these days

  • Testing
    Angular provides unit-test-framework agnostic test helpers that makes unit testing very easy. They generates tests by default from the CLI using Jasmine, that can be easily switched to Jest. They also provide an optional Selenium wrapper Protractor to make E2E testing easier (even though you don't need it really, I use Selenium .NET for my Angular apps, nothing Angular specific, but they try to make it even easier).

  • Mobile / PWA support
    Google is the biggest supporter of PWAs, and the support is showing in Angular CLI already with Service Workers and Universal (server-side support), and Ionic (Cordova support), and NativeScript (Native apps)

• PRO: Focus on browser support
  With a dedicated polyfills page in docs, and inserting (commented) polyfills by default in CLI, Angular keeps you in the loop of what exact polyfills you need for say IE<=11, so you don't need to load a much bigger polyfill set for no reason. That's because they care about browser support.

• PRO: Big company backing
  Angular is one of the few libraries discussed here (the only one?) that is backed by a big company.
  By backing here, not just a company that used it in a few projects and contributed back to the ecosystem, but being official maintainers who pay developers and technical writers to work full-time, and invest in community leaders (GDEs and DevRel in the case of Google).
  This is PRO not a CON because it comes with MIT license with no extra clauses, no revocation notes, or anything else that can be confusing or scary to some people.

I've implemented Vuejs for some projects such as plugins, REST API. I must say that it's easy to learn, have a lot of features, huge community and its ecosystem is also good.

Nowadays, Vuejs is growing rapidly. It's will be a wise choice if Vuejs is integrated into WordPress code.

@cyberwani @thephilip @evoratec and others.

@ntwb has already replied following comment:

Please, no more "I vote XYZ", they do nothing to add to the conversation apart from send needless replies to people subscribed to this issue

So, please stop making useless comments. To show your support, you can use github emojis to like a comment favoring your library.

Vue.

By the way, there is Alibaba behind Vue now, as well as Weex Apache project which enables Vue api on mobile.

I'd really put some moderation here, too many fan boys with no clear arguments

This is the final warning, the next step is that we start deleting comments...

Me, myself, I've not used Marko, Preact, or Vue.js, I'm not familiar with any of them to be honest, I'd love to hear and read what the WordPress Community has to say about these frameworks, each of them, the technical merits of each, the surrounding ecosystem of each, the build tooling, and last but not least the people and communities behind these projects. 😄

I don't want to read "My vote is for XYZ", if you'd like to add a vote, scroll up and add an emoji _thumbs up_ reaction to your framework of choice that has already been mentioned above. 👍

It didn't take long for two new comments to appear since my previous comment 😞

To that end... If your comment was added after https://github.com/WordPress/gutenberg/issues/2733#issuecomment-329705942 and all you've said is _"I vote for XYZ"_ or text to that effect your comments have a very high chance of being deleted, future comments of the same ilk will also be removed.

If you're returning to this issue and wondering why your comment has been deleted, this is why

@ahmadawais I have a few comments.

Gutenberg's migration from React to ... ?

Regarding:

@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 think when you have a project with a non-trivial number of lines of code, you need to be very careful. Engineers like to rewrite things, to learn new languages and frameworks, and think they will do a better job if they can rewrite that code... Joel spoke about the danger of rewrites quite eloquently long time ago.
Using Preact will save you a lot of time. You may underestimate the time it will take to move to a completely new framework. I am not sure why you wrote "That's actually the wrong reason for considering Preact". As an engineer, costs and time to market are high on the list of the criteria that I use to evaluate and choose solutions.
If the problem is really the Facebook patent, Preact solves it minimizing the costs. Preact is more performant than React and even Vue: smaller footprint and faster runtime rendering. Check also Addy Osmani's write up on it.

I am not sure how you evaluated the size of the Preact community. If we are talking about the ecosystem and the components available, using Preact enables you to use most of the React's open-sourced components. So for a practical matter, you have people that even if they are not explicitly working on Preact, they are still producing code that you can take advantage of. You can still consider React's ecosystem part of Preact's ecosystem.

Why is Vue still your favourite option?

I feel that the 3rd point here "Sticking with Preact is like sticking with React anyway" is probably the main reason you are hesitating to choose Preact. Am I wrong? What is wrong with React beside its patent?

Looking at the big picture

I read that whatever you pick for Gutenberg will be also used for Calypso.
Gutenberg is only using React on the frontend. When you look at server side rendering, the situation become more complex but Preact still seems an easier migration option.

I think you need to look at your criteria. If you are seriously considering a rewrite and keeping the isomorphic rendering is important, MarkoJS seems high on the list of candidates.

If I started from scratch and was willing to ignore React ecosystem, MarkoJS is a no brainer.

I am looking at the performances and MarkoJS seems not to have any rivals. 40x faster than React, 10x faster than Vue and 6x faster than Preact is insane. In my book, 30% improvements are irrelevant but when you have more than a 10x improvement, you need to seriously paying attention.
When you have a modest successful presence and you can use 10 servers instead of 100, or 2 instead of 20, it makes a big difference.

Full disclosure I do not have any emotional attachment to either Preact or MarkoJS. I just think that they make more sense than the alternatives from an engineering prospective.

Good luck with your decision 😃

@ChrisCinelli those are ssr numbers...

I am from the Drupal world(we're watching this issue :D) so I have no stakes in this. But reading the comments, it is obvious that there are about 5 "top" frameworks in here and everybody likes the one they've chosen so they will give props to it.

The speed aspect is irrelevant these days, really. The only two factors that should be taken into account are a) do you really want to rewrite everything and b) how will transition for React devs be like and how will learning the winning fw be like for new devs.

There are preact-compat, inferno-compat... layers for easy transition but the performance will suffer. On the other hand it will make transition graceful over time, not everything has to be rewritten at once. From business POV this is a no brainer. From community POV and future it makes no difference.

Now the DX is where it all lies. Anyone experienced in reactive fws should have no issue transitioning to new fw simply because the concepts are the same, only the syntax differs. But the novice, that is the one who matters. How hard/easy is to be productive in new fw. How hard/easy is to read and understand existing code. And this lies solely on a) good documentation and b) community(forums, SO, chatrooms, blogs..).

I won't say which FW I'd prefer since as I've said, I'm not a WP guy. But I wanted to give my 2c as to keep your head cool when it comes to such big decision that will influence thousands of devs around the world.

@ntwb : I did not have my comment deleted but I think deleting comments, even those of the fan boys, as some kind of censorship.

Why:

If your comment was added after #2733 (comment) and all you've said is "I vote for XYZ" or text to that effect your comments have a very high chance of being deleted, future comments of the same ilk will also be removed.

I see a lot of fan boys' comments above that. Why do they stay?
It seems a double standard.

Angular, it's a clear choice. I think Roy and Meligy make fantastic points and support them 100%. WordPress is moving into the Enterprise realm not just in use, but also in terms of the methodology of its development.

I'm going to link a fun source: https://vuejs.org/v2/guide/comparison.html and in particular: "... the complexity of Angular is largely due to its design goal of targeting only large, complex applications...". That simple statement hits the nail on the head. WordPress is, and it's future direction will continue to be, a robust complex application.

@ChrisCinelli Simply because that's when we asked people to refrain from saying "I vote for xyz", I do understand where your coming from though but I think removing those comments would be poor form, I'm not fond of the fact I had to remove any of them

I didn't bring this earlier because I didn't want to be attacking frameworks I didn't recommend (having recommended Angular above), but just for completeness, there's something that needs to be cleared out with Preact and other React-like libraries. I'll put it here, and it's up to WordPress to decide whether it is a concern.

The following is a quote from a post written by a Patent / IP Attorney on React license, (bold highlight is copied from the source):

I’ve gotten a lot of “well then let’s just all use [alternative framework here].” Hold on a second. If Facebook patents cover React (diffing, componentization, etc), those patents likely cover Preact/Vue/et al.

But React gives you a patent grant! With an alternative framework, you’re an infringer from day one. This all comes down to whether Facebook has patents and their desire to enforce them, but if you want to war game this to the nth degree, a React alternatives are more risky.

Now, if my understanding is correct, WordPress is not leaving React because it's worried about a the license itself, but only about having to carry this license on to its users, and hence bringing the confusion and the need to defend the decision to itself.

Going to a React alternative, there might be less to defend if the alternative license is permissive, but there might also be some confusion carried upon WordPress still.

It's up to WordPress to decide whether this is or is not something to worry about.

@ChrisCinelli thanks for your constructive criticism. I welcome it with open hands.

As an Engineer, I know cost and time are high on the list. But here's the thing. This is not a project of a particular corporate Enterprise. Goals here are different.

The goal is to find a JS FW which is good for the community. Gutenberg hasn't launched yet. If it works have, then Preact would have been the clear winner.

Right now we need to take care of this:

• JS FW is easy to adopt for the larger set of community
• JS FW that we choose must have its own community and ecosystem
• A proven track record with a PHP based production FOSS software is a plus. Vue + Laravel
• Choosing JS FW based on its merits and not only because it is easier to migrate to

In 11 years that I have spent with WordPress, and that as a regular core contributor, I believe that choosing Preact would create a lot of mess. The learning curve is already huge for intermediate/new devs.

Putting them through the mess of Preact-React compatibility right at the start of this new phase of WordPress improvement can cause them to leave the WordPress community and learn something else with the similar learning curve. (_HINT_: Laravel + Vue instead of WordPress + Preact + React) And BTW are you forgetting that's what happens with Drupal 8?

Please don't remove civil comments. There is obviously an overwhelming need or desire to express an opinion on this issue. I see it as a good thing as people are saying they care about WordPress and they want to be heard. Remeber that the WordPress community, not just its devs, were directed to Github to give feedback. If we really, really cannot tolerate +1 comments then add a tally at the top that preserves the usernames.

If you are just looking for reasoned discussion, then a lot of "I vote for X, Y, or Z" comments may just seem like noise, but there is a clear pattern emerging of people supporting Vue.js. My take on that is that we have a hundred, or a few hundred, people who will contribute code to Gutenberg, but tens of thousands who will write plugins and themes that interact with it. The success of Gutenberg won't just be the end user experience, but also the dev experience. It's not the only thing, but an important thing that makes WordPress successful is that it is easily extensible.

While I don't have a specific framework in mind I would say that one thing we should keep in mind is that browser support is starting to fall into place with web components, a framework that utilizes web components or at least their own components built like them would be future proof. There are also polyfills out there to bring web components to browsers that don't support it.

I was mentioned earlier and I just came here to turn notifications off, but I'll weigh in a bit.

If you're building a single page app from scratch, time is of the essence, and you want a well-supported, documented, and testable framework, I have a lot of concrete experiences that show it's vastly less expensive in time and treasure to go with Ember.

If you're building more of a PWA or dropping components into a server-rendered page, Ember is a poor choice, and I can see why something like Vue would be appealing.

I’ll add in that from a convention driven side of things, I have created a few PWAs with >90 lighthouse scores using Ember.

On our last project where we needed to do this, the process took <1hour to get that lighthouse score and deploy the app with server side rendering enabled.

SSR and service worker cache needed for high lighthouse scores can be a very tricky process.
With Ember, this process is very easy and only requires the installation of a few well documented and maintained addons (for most apps).
From my experience Preact does come with both of these features out of the box in Preact CLI, however there are popular (P)React conventions that can break SSR results.
With Vue the official docs recommend using Nuxt.js or following the complete SSR guide; both of these introduce more patterns that need to be followed beyond the basic Vue documentation.

Not telling anyone off, but let's hold off on deleting comments on issues unless they are profanities or abusive. I totally get people wanting to help and focus the conversation, but we shouldn't get into the spiral of deleting comments.

I'm not sure what's "well documented" about Ember compared to VueJS @rtablada .

I personally would have an issue jump starting into Ember compared to Vue or even React.

@ahmadawais Everyone forgets that this decision will have great impact and you will want to change framework anyway in few years time. So you would like to use modern framework goodness but not be tied to it for live and death. Sounds impossible? It's not!

Some time ago I had similar problem and after research and attempts I come up with solution that tries to connect water with fire. In few words - Web Component's Custom Elements, wrapping technology you like (e.g. Vue, React, Angular) and exposing standard DOM API.

In such solution you will have multiple components and each of them has:

• framework you like (but of course preferably only one)
• standard DOM API that other components can easily consume. You can even manipulate it via plain JavaScipt

As I worked with Vue at that time I wrote Custom Element's adapter for Vue - https://github.com/karol-f/vue-custom-element - so you have superior compatibility (e.g. Vue's $emit send standard DOM event that can be captured via plain JS or e.g. React/Angular) and IE9+ compatibility.

I recommend to look at such solution as you:

• will be future-proof
• won't be tied with any framework you choose today
• your users will see standard HTML elements and can interact with them with framework they like or even with plain JS
• There woun't be manual Vue initialization as browser will tell you and auto-init component if it's on page (you can even lazy load component such way)

and many more.

Such solution is not tied with Vue - you can use any other framework you like. Also Web Component's Custom Elements are standard browser feature and won't be gone anywhere!

Regards!

My take on that is that we have a hundred, or a few hundred, people who will contribute code to Gutenberg, but tens of thousands who will write plugins and themes that interact with it. The success of Gutenberg won't just be the end user experience, but also the dev experience. It's not the only thing, but an important thing that makes WordPress successful is that it is easily extensible.

Quoting the comment above by @dmccan because it's such an important point in support of Vue.

WordPress has democratized more than just publishing. I wonder how many successful tech careers and businesses have launched due to the approachability of WordPress. Mine, for sure.

I'm going to throw my hat in VueJS's favor. The local JavaScript meetup here is co-lead by one of the members of the core team for VueJS and it seemed to be the one that people who attended could on-board with much faster than others. My previous experience was with AngularJS and I found VueJS to be incredibly easier to learn and just start coding even though I was starting from scratch.

I see some folks are talking enterprise and thus Angular, but while WordPress may need some love in that area, I think the decision should be based on, functionality and such aside, ease in on-boarding developers. With the discussions we've seen on meta boxes and whatnot, getting plug-in authors to "Gutenberg-ify" their work instead of just abandoning if/when the classic editor goes away.

Some more points good to mention about Vue.js: (Just personal thoughts, others libs, FWs and options are appreciated and for sure have their own unique features and pros)

• PRO It doesn't necessarily require a transpiler or force how to be used and can directly run on web as jquery can

This would amazingly help plugin developers integrating with Wordpress UI. They can attach a new vue instance to any part of page as a widget. Also big Wordpress project can Progressively adopt with Vue.js without the need to huge breaking changes in code base as vue dosen't assumes about how it is going to be used. I think this is the success key why Laravel/Vue is so popular and working good together :)

• PRO JSX and css-in-js supported too!

It may help migration of current WordPress projects with React/JSX code faster to vue.js with less change requirements. (there is even a babel plugin: babel-plugin-transform-react-to-vue)

• FACT Vue just like Preact and unlike Angular/React is not an open source project owned by a big company like Google or Facebook.

This would be something critical for a HUGE project like Wordpress to escape a potential vendor lock-in. If an opensource project not owned by a company someone should start it (So "Key person dependency" is meaningless to be mentioned as a CON).

I vote for VueJS.
Not because I know anything about it, but because I have no clue how it is prononunced in english language. However, I used Joomla for years and pronounced it wrong all the time.

Joke aside.
Not many here discuss what framework is better in supporting old metaboxes and custom fields. React was very bad at it, as we know now.

Now, just to unsubscribe from this issue.

In order to focus the discussion, I have created a task issue here: https://github.com/WordPress/gutenberg/issues/2741

I'd suggest Vue, just because Laravel. Lots of WordPress folks unhappy with the course it took or still takes, have switched over to using Laravel as their main CMS framework, while keeping WP as the second choice. Preact is just a clone and massive compatiblity layer, kind of what Novell DOS was to MS DOS, PC DOS and vice-versa.

cu, w0lf.

Vue.js all the way!

You should certainly look at Hyperapp.
Pros

1. It is very similar to Elm (Model, View, Update) architecture.
2. It has built-in Redux like Reducers called "actions" (called to update the model and in-turn View).
3. Uses JSX
4. Encourages "functional programming" designs
5. It is 1kb so it's easy to load and easy to understand.

Cons

1. It is still new and so is the eco system. But you can influence it and contribute to it.
2. There may be issues that's not uncovered yet.

The principles of Gutenberg blocks dovetails nicely with those of Web Components. It's low-level, framework agnostic and an emerging standard (with mature and tested polyfills) - the perfect fit for WordPress.

See also: Polymer - Web Components with some sugar.

Vue is a fantastic option, and here are the reasons that I believe so:

I began watching Vue in early 2016. I loved it and wanted to determine if it would ever be "in-demand" or if its growth was anything to write home about. At the time it has 16,000 stars on Github. It was cool and all, but people hadn't really adapted to it in the midst of all the Angular vs React crap.

I wound up losing _all_ of my data and starting over on September 17th, 2016. Exactly one year ago, today. (Here is my current data set.)

Over the past year I have watched Vue's popularity grow (in terms of mentions on the internet and tracking Github stars) at a _record breaking_ rate. Vue has amassed 40,000 stars in 365 days. That is an average of 109 per day. In comparison, the world's beloved _React_ grew from 49,000 to 75,000 in this same timeframe. (71 per day) Vue will surpass React in the next few months, in terms of user ratings.

While everybody was talking about React's growth being the most incredible of all time, they were unaware that Vue was the actual titleholder. They were unaware that Vue was growing because of people genuinely loving it as a tool, rather than because of any famous backing (Facebook).

Vue has been in Github's trending repos list every single day for well over a year now. 99% of the days it is above React. 10% of the days, React doesn't make the cut.

All of this shouts "use Vue because it has had more popularity growth!" But what I mean to convey is that Vue has grown because people genuinely love it because it is great, intuitive, and powerful tool (often incorrectly presented as "great for small apps") for applications of all sizes. But not only a tool. Vue is an ecosystem. It comes with a massive supporting community, as well.

Might I add... the .vue files are genius. So many tools are being built to handle styling in React because there is apparently something wrong with CSS Modules and having your styles in an external file. (Idk...) But Vue doesn't have this issue. Vue has control statements baked into the syntax, and (since I've seen custom element comments above) not only plays well with custom elements... It _is_ a library/framework for logical custom elements.

Preact is great. Honestly, I just started another project with it today. But when I look at Preact I see an off-brand React. It wasn't built to be innovative or to progress the way we create web-based software. It was created to look and act just like a pre-existing tool, but to offer better performance.

That is my two cents. Now I am broke.

I hope your final decision makes you happy and provides a great foundation for the future of your products.

@ahmadawais :

• Time to market is important for both enterprise and open source projects. You can find examples of projects that never shipped because they ended up taking too long and being obsolete before they were shipped. A few projects ended up being abandoned during the work toward a major release.
• Being opposed to Preact means "we did a mistake with React for reasons beyond the licensing". I think with "The learning curve is already huge for intermediate/new devs" you meant that wordpress' developers were already lost with React. That does not surprise me. But it seems difficult to believe that Vue, even if less verbose, will solve the learning curve problems. The old PHP WP engine and any single page app javascript framework are very different. Vue and React are a lot similar with each others.
  I am not sure why you see competition between Wordpress and Laravel. I may be naive here. I know very little about the Drupal 8 story.
  From my point of view, Wordpress is a CMS and it attracts developers because of its large user base of not technical users and the features already built in it. There are a lot of templates and developers can very quickly build a new site that is customizable by a non developer.
  Laravel is a PHP framework that, as far as I know, does not give you a lot of the features of a CMS. A developer will choose it because he needs more freedom.
• I am not sure how having a few successes with Vue + Laravel also means "Vue is good for Wordpress". I think there is very little intrinsic synergy between PHP and any JS framework. I completely agree that is important to find a framework that is good for the community. If most of the current developer community that wordpress' depends on is familiar with Vue and they love it, this has a heavy weight in your final decision.

From an engineering prospective, I think that both Marko JS and Vue are newer frameworks . They learned a lot from React and were able to remove some of the verbosity in it. In that sense Marko seems to remove even more boilerplate code than Vue. In particular Marko keeps cohesive code that is good to keep in the same place and leave in HTML what HTML is good for and in Javascript what Javascript is good for. And it is also 10x faster. So beside the fact that lately Vue has a lot of fans, I do not see many reasons to prefer Vue to Marko.

Sorry but Marko's syntax and setup is horrible in comparison to VueJS. Performance wise I haven't seen any source where MarkoJS is faster in any significant way without adding time to understand how it works.

@bovas85 syntax is subjective but I don't think there is any basis in your claim that Marko's syntax is "horrible in comparison". Really early versions of Marko had a syntax that was closer to Vue's HTML-based syntax and the release that introduced Marko's current syntax was extremely well received by our users.

We put a lot of thought into the Marko syntax to make sure that it is familiar to developers who understand HTML and JS and we wanted it to be as simple and as powerful as possible with minimal boilerplate. I think you will find that with any side-by-side comparison that the Marko template will require less code (which is great for readability and maintainability).

Here is a document that I quickly put together so that you can see an overview of the differences between the Marko syntax and the Vue syntax:

Syntax: Marko vs Vue

I linked to it earlier, but for a more in-depth comparison between Marko and Vue (and React) please see:

Meetup: Building the UI - a comparison of React, Vue, and Marko (from the Marko creator) - Video | Slides

As for performance, we have some benchmarks that you can check out: https://github.com/marko-js/isomorphic-ui-benchmarks

Here's a quick run of the benchmarks with Marko and Vue enabled:

Server-side rendering performance

_Node.js (v8.4.0)_

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

Client-side performance

_Chrome Version 63.0.3218.0 (Official Build) canary (64-bit)_

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

Those are the benchmarks we created for Marko.js so obviously take those results with a grain of salt, but we made every effort to be fair.

Also, just wanted to add a few more comments regarding Marko.js and ease of use:

Marko has always aimed to have the simplest integration with Node.js. After installing the marko package via npm here is all of the code that is required to render a template to an HTTP response stream:

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

I think that is as simple as you are ever going to get.

Marko also works with popular JavaScript module bundlers: http://markojs.com/docs/bundler-integrations-overview/

To render a top-level Marko UI component to the DOM here is all that is required:

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@patrick-steele-idem According to http://www.stefankrause.net/wp/?p=431 benchmarks, markoJs
is as performant as Vue et al.

So, we can conclude that in general client side scripting, Markojs and Vue are equally performant.

Of course, the benchmark, I linked, does not include ssr. So I won't comment on that.

I vote for Vue. jQuery is already a near requirement to use WordPress. People familiar with jQuery should feel familiar with the Vue syntax. It's ideology about the DOM isn't all that extreme as something like Angular. It falls back on the WordPress principal on ease for the user.

As I suggested about two years ago for Calypso, Mithril.js using the HyperScript API would be a good choice to replace React. It has a standard MIT license.

A small investment in new tools for doing at least some of the heavy lifting automatically for converting from React to another vdom library may pay off well in developer hours saved -- as mentioned in that issue as a suggestion for Automattic to do in advance to hedge its bet on React.

Even without considering non-vdom libraries, there are more than 25 vdom libraries (e.g. inferno.js, maquette, etc.) that could be considered -- as in this list I put together in Jan 2016 for a different project considering vdom options.

Here are some technical reasons why Mithril.js or other vdoms emphasizing (or at least supporting) the HyperScript API are the best choices.

Personally, I feel templating approaches to making JavaScript-powered UIs like React’s JSX or Angular’s own templating approach or the templating systems in many other UI systems including Vue are obsolete. Why? Preferences and "best practices" for writing server-side generated HTML-template-based web apps using complex CSS style sheets (like for previous WordPress plugins) are becoming "worst practices" for writing single-page webapps. The technical needs for writing complex modern single-page client-side applications are different than for primarily server-based code because of the increasing complexity on client-side code. In short, the old "best practices" of using templates and complex cascading style sheets just don't scale which leads to difficult to maintain code.

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

Here is an example of a coding playground I wrote that way with several examples in it which use that approach.

So, by writing UIs using HyperScript (plus a vdom library), you can potentially (with some work) replace a backend like Mithril with almost any other vdom or even a non-vdom solution. So, when I have a choice, choosing to use the HyperScript API is a way I mitigate risk from underlying libraries having bugs or licensing problems.

By using Tachyons or similar libraries, I mitigate risk of unmaintainable CSS files as the application grows.

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

Assuming that all the frameworks in the run here do not have any visible differences to the user because of their speed on their browser of choice, we can stop using frontend performance as a metric to evaluate which framework is the best choice.

But if we use server side rendering, we should carefully look at the SSR performances. Calypso seems that is aiming to have SSR. And if successful, one day Calypso will run most of the sites on wordpress.com.

A company pays for the CPU on the servers, not the CPU on the browsers. So from a cost perspective the 10x faster rendering time of Marko likely means that the same traffic that max up 10 servers with MarkoJS, will actually take at least 100 servers running Vue.

If Wordpress can ignore that, I will gladly come to work for the company and get a 10x market salary and use Vue that, by the way, I think is a good React alternative =)

The lighter the framework is — that is, the less functionality it is offering out of the box — the faster it is going to perform. It is pathetically obvious. It is one thing to compare the performance of various algorithms but when the biggest factor is how much other “stuff” is performed, you don’t need to write tests.

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Angular core team here - we're in progress on a lot of interesting work related to CMS/Widget style development, including investing in Custom Elements support (which, for my money, is the smart future bet for building platforms)

Rather than cluttering up the thread further, we'd be happy to chat with y'all offline, if you have any interest. Drop me a line at robwormald at google dot com. Best of luck on this, I don't envy you having to make this call ;-)

I have whipped up a simple poll here which can be used to get insight into what folks want..

currently working on the results page & auth on it. (new to firebase)

PS. took around 1 hour to make this using Vue 🖖

@vinayakkulkarni How about adding Mithril.js to your poll?

@pdfernhout : 👍

Done. I’ve added MithrilJS to the list.

• [x] VueJS
• [x] Angular
• [x] Preact
• [x] Ember
• [x] Marko
• [x] Inferno
• [x] Aurelia
• [x] Mitrhil

Let’s see what people decide upon..
PS. there was a twitter poll by @ahmadawais too.

Hi. I'm a Drupal core maintainer. As @ivanjaros mentioned in an earlier comment, we're also evaluating Preact, Vue, or something else, for some upcoming bits of Drupal's admin UI. We might settle on something different than what you choose, but what you choose will certainly be at least one factor for us to consider in our choice.

I opened these two Drupal issues so far, and more will be coming. Just cross-referencing them here in case those issues/discussions are useful to you.

• components returning multiple root nodes
• slots vs. vnode props

Note that I still strongly like Vue, despite those two issues. Those might be things we're ok with living with, in order to get all the other benefits of Vue.

As the author of Vue, I'll avoid making comments regarding what framework to choose here as I am obviously biased; but as I saw the statement that "Marko is 10x faster than Vue" thrown around a few times, I feel it deserves some clarification. I also don't want to derail the discussion into a technical debate, so I've jotted down some thoughts in this gist for those who are interested.

@michaelbdavidson7 regarding the financial concerns: I have been working on Vue full time for over 1.5 years now and the Patreon support has been really stable. Rather than speculating over Patreon pledge fluctuations, you can check Vue's commit activity to judge for yourself. In addition: having an open financial contribution channel means WP/Automattic can easily ensure Vue's sustainability by becoming a major sponsor (Matt himself is already a personal sponsor!) - that actually aligns with the interests of both projects.

I vote Vuejs

@tungbt94 Why?

Definitely VueJS

The bigger question, why was react chosen before this patent issue. If it was no patent, would you still use react? A lot of points made about NOT choosing preact are the same as to not choosing react.

My vote is with Preact

As I don't have much experience with anything else than React, I will not weight in on what framework to choose.
However, I think the "big community" argument is one that can be of less importance. Why? because when Automattic decide on a framework, that farmwork will get thousands of new users. And if I know the WP community correct, many of them will start contributing to that framework also and the popularity will rise.

Considering where Gutenberg and Calypso are at the moment, I still think that Preact is the best engineering choice.

However, if you still feel strong about burning bridges with any resemblance of React or if you had to start from scratch, I still believe MarkoJs is the best choice. I think the community support may be still a concern.

Assuming that Github stars are somehow correlated with community, Vue is still 10x compared to MarkoJs but looking at the graphs it will change quickly.

Vue is growing linearly:

But MarkoJs seems to be on the inflection point of an exponential growth:

@patrick-steele-idem, the main author of MarkoJs, has always been super responsive on https://gitter.im/marko-js/marko

When people ultimately choose MarkoJs, but really any kind of community, I feel like paraphrasing JFK's quote: "Ask not what the community can do for you — ask what you can do for the community."

Personally I'd like to congratulate @ahmadawais for creating one single issue that has created significant engagement from many JS Devs that use and support the relevant JS Library options.

I suspect this issue has helped inform more JS Devs about WordPress moves towards more JavaScript based development via Gutenberg than any other Gutenberg communication so far.

I use AngularJS but what I don't like is the major update each time, so I'll go with VueJS.

+1 for Marko. Great library that our team uses and has been very happy with. Async rendering, super fast (renders to string in server and to vdom in browser), single or multi-file components, and IMO the best templating syntax out there.

Please take @WebReflection's hyperHTML into account.

I like Angular

I vote Angular

I Choose Angular

just angular

I Choose Angular

angular

I vote Angular

I vote Angular

If you like to vote for a framework, it would be nice to know exact reason and how does it help Gutenberg.

To the peeps coming here to just say "I vote X", please give us some reasons why we should vote X too. "I vote X" tells us nothing apart from that you like X.

I choose angular . Angular have some great change since version2. Now,it is completely, good ，strongly and widely used framework。As it,like ionic,study not quickly,but strongly.

With so many spam “I Vote framework”, github is squawking for me.

I urge fellow devs to kindly vote your choice of framework at https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ instead of just posting ‘I vote …’;

Also, another suggestion is to lock this conversation; most major devs have already had their say on this.

On 18-Sep-2017, at 8:01 PM, Mingyue notifications@github.com wrote:

I choose angular . Angular have some great change since version2. Now,it is completely, good ，strongly and widely used framework。As it,like ionic,study not quickly,but strongly.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898, or mute the thread https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg-ucks5sjn7SgaJpZM4PYie9.

thanks @kidwm for mentioning _hyperHTML_, but I guess it's better to follow their direction:

Don't just share which JS framework you like but also share why

so let me try to do that ...

:zap: hyperHTML:

• PRO: Beginner friendly and familiar to P/React users (instead of JSX you write Template Literals)
• PRO: blazing fast and without VDOM; less memory consumption (emerging markets phones friendly)
• PRO: Requires no tools (requires transpiled template literals only for IE < 11)
• PRO: Fully based on JS / DOM / HTML standards but compatible with TypeScript too
• PRO: fits in less than 5K (min-zipped) without needing extra polyfills or browsers patches
• PRO: 100% code coverage down to IE9 quirks
• PRO: shares same API with its NodeJS counterpart; 100% server side rendering compatible
• PRO: it can adopt existent DOM without trashing SSR layouts/nodes
• PRO: works with Custom Elements better than P/React, it can also be used to define Custom Elements
• PRO: it can do what React, Vue.js, Polymer, Angular, or Marko do, and it wins in terms of size/bandwidth/performance each of them

Now, accordingly to the metrics used so far in this thread, the CONS

• CONS: even if battle-tested, fully test-covered, and with a frozen API, it's a relatively young project (March 2017) so it cannot compete in terms of popularity, adoption, or amount of contributors
• CONS: the community is helping a lot and the project is growing, but major technical contributor so far it's me. I'm 100% committed to this project though, and willing to push it as much as I can, plus I am discussing with few "_bigs_" about using _hyperHTML_ in some of the next big projects of them (I won't speculate further though so feel free to ignore this latter part)

:dart: I truly believe that the future of the Web is to use the platform as much as possible, which is definitively way better than 10 years ago, and thanks to modern ECMAScript specifications way easier to write, read, and maintain. _hyperHTML_ represent the "_current state of the Web art_" in terms of potentials, while every other contender in this list was born in pre full-ES6 era.

I understand community size, contributors, and GitHub stars are important, but I think tests, cross browser code coverage, and amount of bugs, should also be considered, and I'm doing my best to keep the count of _hyperHTML_ and friends close to zero (it's actually zero right now, beside a discussion that is not a bug).

Last, but not least, if nobody gives new solutions a chance and judge just by stars and hype, new solutions will take longer than these should to become more popular.

Of course, I've talked about my latest solution, my considerations might be considered subjective, but specially my latter sentence about giving a chance to new solutions, was very general, not just about my libraries :smiley:

Best Regards

I like angular

must be angular and google.

i love angular

Angular is only real framework!

I choose Angular,not AngularJs.

Only angular is a real framework!

I'm starting to suspect, these comments are made by bots.

@OP: Please lock this thread.

I vote for Angular (NOT AngularJS).

Angular is a platorm, the google team do a lot of great work to make the developing progress easier, including the component, the module, the router, with the dependency injection, you can save a lot of work to arrange all the dependency, with the angular-cli, you can save a lot of work to start a brand new project, you just open the box and your app is well compiled with aot, tree shaking, and many other optimization.

TypeScript is another great tool with angular, it is provided by MicroSoft, aka the entire angular platform is built with ts. You build your app with ts too! It is a great tool to make life easier when the amount of code getting larger and larger, you can do refactoring in the IDE (like vscode) by just one click. Static type checking makes you find the bugs as early as possible. TS also provides a good implementation of OOP, you can arrange and reuse your code in a much better way.

There is also a lot of components built based on angular, like meterial design2, primeng, and I wanna recommend you Jigsaw, which is created by our team. It is adopted by the Big Data Product of ZTE China. It is supporting all the apps of ZTE now.

Anglar is a great choice!!

To all the bots: 🖕

Probably somebody posted on an AngularJs community. I think people can mute the thread if they do not want to receive any more messages.

I think that eventually a similar conversation on this topic will have to happen in a place where there are only WordPress contributors.

I would like to share some of my thoughts on this issue that I have mostly already expressed in the EmberJS slack community group, if you have 10 minutes to read the discussion over there I would recommend it: https://embercommunity.slackarchive.io/wb-marketing/page-2/ts-1505456102000189 There is quite a lot there but I would highly recommend checking it out to get a nuanced understanding of the discussion.

My main points in that discussion are as follows:

• When comparing a 2-4 week spike of implementing something in the Ember framework vs any other Library the other libraries tend to win in the short term but Ember wins out for any longer-term project
• When considering which library or framework to go with it is important to not only consider the technical implementation but also the "soft skills" aspects (community size, commitment to support LTS, community involvement in the core decisions of the project)
• Ember has a track record of providing major improvements to applications built using the ember-cli "under the hood" i.e. without any need to upgrade any of the application code. There have also been cases of minor upgrades to application code (with included code-mod using things like ember-watson) you get a significant performance and productivity boost.

I don't want to go into too much detail in this comment because I could happily write a 10,000 word essay on the above points. I would, however, like to offer my time to anyone who would like to discuss this issue with someone who has an "Ember mindset".

If anyone of the decision-makers would like to have an hour-long call with me to ask more pointed questions about the wider Ember ecosystem I would gladly do so. You can reach out to me on my Twitter (DMs open) I may not be a core team member but I have been building Ember apps since before 1.0 and have gone through all the upgrade processes with various apps 👍

I work for "My eBay" at eBay. We just released our first single page app. We enjoyed every phase of development using MarkoJS. Like me if you love node's streaming programing paradigm then MarkoJS supports streaming and asynchronous rendering. Other facts I liked about MarkoJS:

• its efficient binding of behavior of UI components rendered on the server and in the browser.

• Very efficient event delegation

• Fast serialization of state from the server to the browser

@vinayakkulkarni I think your idea is nice, but the problem is that I can leave more than 1 vote by changing browser (I haven't tried with the same browser).

You should probably use a twitter poll (but there's one already) or implement a login system to make votes unique.

Server-rendering isn't relevant to the conversation here. Node is not going to become a part of the required WordPress stack, so how fast these frameworks render in Node isn't relevant to a decision.

Vue.js! look to this project https://github.com/bstavroulakis/vue-wordpress-pwa

I chose Angular (not AngularJS), it has the biggest community, a stable and complete ecosystem.

Angular is very slow and with v4 it based on typescript, it useless for wordpress development..

I choose Angular by the maturity of the platform

I would vote for Vue because it easier to learn and because my favorite framework Ember Js is too big for the job & Glimmer Js is still too new. :-)

Server-rendering isn't relevant to the conversation here.

in my case I've just mentioned a feature others thought it was relevant

Node is not going to become a part of the required WordPress stack

_hyperHTML_ can pick up any server side rendered content, including PHP. I'm a Zend certified engineer, and I've worked with journalists/publishers using WordPress already, my hint wasn't just out of the blue.

so how fast these frameworks render in Node isn't relevant to a decision.

the fact a framework works on backend too, can pickup server side rendered content, and it would be even compatible with NativeScript maybe is a plus that's irrelevant today, but a future compatible nice to have feature, as an open minded project might consider.

@webreflection I didn't mean that comment to pick on you in particular. It more in response to the comment above me highlighting Marko's "streaming paradigm", but it was intended to cover all of the comments about BE rendering performance.

Vue

@mAAdhaTTah from https://ma.tt/2017/09/on-react-and-wordpress/ :

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

And more important:

Automattic will also use whatever we choose for Gutenberg to rewrite Calypso

Calypso is already using server side rendering. See: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

So my understanding is that SSR performances are relevant.

I love angular too！
AngularJS js real framework！

I vote for Angular

@chriscinelli That's Automattic, not WordPress. WordPress itself doesn't do server rendering with node, so performance under those conditions aren't relevant to the project.

很显然，Angular是最佳选择

I vote for Angular

I vote for Angular

I vote for Vue.js.
It saves most of the time, especially when dealing with views layer.

I must vote for Vue!!!

投一波angular

@trotyl That comment is unacceptable. I've edited your comment to remove it.

oh, please not AngularJS
now is Angular.

@mAAdhaTTah From wikipedia:

WordPress was released on May 27, 2003, by its founders, Matt Mullenweg and Mike Little as a fork of b2/cafelog

Though largely developed by the community surrounding it, WordPress is closely associated with Automattic, the company founded by Matt Mullenweg.

This is Calypso: https://developer.wordpress.com/calypso/ and Calypso uses SSR.

As I wrote in my previous comment, It is pretty clear from the blog post dropping ReactJS support by Matt that they want to keep Gutenberg and Calypso aligned on the same technology. Automattic will serve Calypso pages from their servers with SSR.

I think this is enough to make SSR performance relevant in this decision.

However in a future far away, once Wordpress developers get used to Preact (or Vue or Marko or another framework), a new crazy project may come out and they decide to serve even more parts of Wordpress through node. That will make SSR even more important. So SSR performances may be even more important.

As the conversation has moved on to discuss SSR I think it is prudent to mention that this is very high priority for Ember and has been thought out quite extensively with the advent of Ember-Fastboot

While I do use Fastboot (to great effect) with a few client applications as this is a high-level technology discussion I would recommend reaching out to @tomdale as he was the champion for the Fastboot effort 👍

@chriscinelli WordPress the community project and Automattic the company are still separate entities. If Automattic wants to argue in favor of one or another because of SSR, they can, but it still doesn't change how we, the WordPress community, should consider the framework of choice for WordPress core, which does not, and really cannot, require node to run.

Anyway, I've unsubscribed from this thread. If you'd like to continue this discussion offline, my email is in my profile.

does not, and really cannot, require node to run.

please let's not make SSR capability a discriminating point. Frameworks capable of node SSR can live without any node SSR at all: it's just an extra feature, not a requirement, nor a dependency.

I'd vote for Vue.js

I'm a senior arch who went to MIT and is supposed to be reasonably smart. I've been doing this for many years and I've interviewed a few devs here and there. I know the web is full of smart people, but anyone who thinks that the simplicity of Vue is on par with the complexity of Angular has lost perspective on what constitutes "complex". Component-based Javascript, as Google has conceived it, is completely non-trivial. It's ridiculously complex. Vue is not. Vue is as easy as PHP. I say the obvious, because "Vue is easier to learn" doesn't even come CLOSE to describing how much easier Vue is than Angular. And here's the catch-- I think it's also much much easier than React.

React was walking the line between easy-peasy and google-level, for average people. For small shops, I would say that React is complex enough to challenge small teams. React is more complex than, for instance, PHP/Wordpress. By choosing React, Wordpress/Automattic raised the requirements for developer entry into the Wordpress dev world. I'm sure hundreds of people will cry out, "React is easy" and "The web is getting smarter", but more-complex is still more-complex, at the end of the day.

I humbly think that moving back down to Vue would be closer to WP roots, and less of a technical burden on the WP community as a whole. Web paradigms aside-- sometimes, simple is good.

Angular and Vue are 2 different things

Vue, React, MarkoJS, Inferno, Preact etc are libraries covering just the view layer. All of them including Angular have a way to create the HTML and mutate the DOM in a declarative way. Angular wants to provide a full framework for frontend development and has a lot more things beyond the view layer.

React's syntax is the oldest in this sample. Facebook did a pretty good job to bound a very complex library that does a lot of things (maybe too many) in a very limited protocol surface. You do not need to know any of this complexity inside React to know how to use it and be productive with it. You can infact learn the basic and start using in half day.

Every other library in this list learned from React. They tried to simplify the syntax, improve React's performance, reduce the size of the Javascript code necessary to do the same things and adding some features on top of it.
Preact did a great job to keep an interface very similar to React in only 3Kb.
Inferno and Marko massively optimized the rendering performances.
Marko and Vue simplified the syntax a lot to reduce boilerplate code.
Marko also added an optional Jade/Pug like syntax to keep the code more DRY and the ability to create asynchronous templates keeping everything simple and intuitive for the user.

However all these libraries beside Angular require the engineers to come out with a strategy and mechanisms to fetch data, routing, etc. Redux and its middlewares are one popular way that Gutemberg used to manage the data layer.

In the migration from React, Gutenberg does not need "just another thing to change". Even if Angular strived to keep itself agnostic for the user, using it with Redux and Javascript (vs Typescript) is not a natural choice despite that libraries like https://github.com/angular-redux/ng-redux were developed and support for Javascript is available. Furthermore looking at the votes so far, it seems that the Gutenberg's community is strongly opposed to Google's framework. So most likely Angular will not be an option.

PHP and any of these Javascript framework are completely different beasts

You can have a PHP backend and a single page app frontend but there is no synergy and little similarities.

Any Javascript app is at least one order of complexity above what you can have writing plain PHP code sprinkled with some jQuery. All Modern Javascript apps have to deal with the two big complexity monsters: statefulness and asynchronous flows. They are only mitigated by immutability and async/await in these last years. The developer flow gets slow as the application grow. When you change some code you need to recompile, restart and the app has to go through initialization again. Massive amount of tooling has been built to implement hot reloads and even if awesome, they are still far from being perfect.
No matter what library you choose for the view layer, you will have to deal with the extra complexity.

In PHP you change the code, you save a file and you can immediately reload the page with no build or reloading. Everything works. And more important PHP is completely stateless. Every time that you reload the page you have a blank slate. Even the global variables have a clean state with each request (but it is not a good excuse to use them =P). I haven't written PHP code in a few years but I still miss its simplicity and its developer experience. If you use a modern framework like CakePHP, Symphony or Laravel, you do not miss a lot compared to other languages and frameworks that are more welcomed by sophisticated engineers. The exception is speed. PHP pays its simplicity with runtime performances. Every time you reload a page all the code needs to be executed again. Performances increased a lot with HHVM and PHP7 but in general they are still far from what you can achieve with node.js.

Conclusion

It does not not matter what library you recently used for the frontend. Even if you love it, it does not mean it the best choice for Gutenberg.
The fact that _most of Gutenberg's core contributors_ may like one specific library is important though.

In the end:

A man convinced against his will is of the same opinion still

I think there is a pretty substantial amount of information on this thread on pros and cons of different viable libraries.

Gutenberg's and Wordpress' contributors should be leaved alone may meet in "closed doors", away from the frontend fanboys.
It may be time to clarify your values, goals and constraints you have and pick the framework based on what maximize your outcome.

And good luck again with your decision 😃

I cast my vote for Vue. Beginner-friendly and robust. When I first started using Vue I got that feeling that I had when I first started developing with WordPress. +💯

@colorful-tones only beginner-friendly is quite not good enough! Every project has a life circle, most of the work is in the maintainess progress.

@ChrisCinelli A few clarifications and opinions:

Angular wants to provide a full framework for frontend development and has a lot more things beyond the view layer.

Vue has official libraries for routing, state management, testing, linting and more, plus an official cli tool. All of those are under the vuejs organization, maintained by core members and kept in sync with Vue itself, but the best part is you don't need to learn or use them (hence the 'Progressive Framework' philosophy). Unlike React, this effectively makes it a framework in its official form. Little pun: all of this while still being easier to learn, faster and lighter than Angular. :smile:

Marko also added an optional Jade/Pug like syntax

.vue files can use any preprocessor for the template, the script or the style (for example pug, typescript, coffescript, sass, stylus...). Use what best fits your project!

require the engineers to come out with a strategy and mechanisms to fetch data

This is just an example, but fetching data doesn't need to be over-engineered:

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

From there you can create a very simple Vue plugin to make code even more concise.

Vue itself shouldn't be the right library for this job since there will always be better dedicated libraries (this is also why we don't offer date filters by default for instance, since you would endup using moment or another great library instead anyway). For data fetching, Vue recommends using axios which is a universal, powerful and easy-to-use http library. We are also in the process of writing a cookbook with recommended paths and practices for several business and use cases.

When you change some code you need to recompile, restart and the app has to go through initialization again.

The only real difference is the build step, which is easy to setup nowadays using tools like the official vue-cli or poi. When you save a file, the app is almost instantly ready to be refreshed (build times are very good for large projects too, and from experience developing a large PHP app using a framework like Symfony is more painful). Also, the Hot Module Remplacement feature is a big plus that doesn't exists in the PHP world (to my knowledge) and allows new code to be available for testing in the browser in a near instant time even in large projects (unless you have costly operations like compiling Sass - but you would have the same issue when using PHP). By the way, Vue supports webpack HMR very well.

You will have to deal with the extra complexity.

IMHO, some very popular PHP frameworks seem to be more complex and harder to learn than some frontend libraries/frameworks like Vue. (The opposite is also very true.)

Based on my 2+ years experience building a block-based editor similar to Gutenberg, I think there are several teething concerns to address when choosing the right framework, e.g.

• How would VueJS/Marko/Angular integrate with drag & drop? How would drag & drop in Gutenberg work? When dragging, are you cloning a ghost element or using the existing element? When dropping, where can you insert placeholders to drop a block?

• How would VueJS/Marko/Angular (and its Virtual DOM) work with Content Editables and DOM Range & Selection API? Cross-browser inconsistencies with this range & selection can be very tough to nail here.

• To what extend will copy/cut/paste work in Gutenberg editor? Can I make a text selection between multiple blocks and perform a cut/copy/paste? Do content editables live in each individual blocks or is it all contained in a master contenteditable?

• If there are Gutenberg blocks that contains iframe embeddables, e.g. embedding a youtube player or twitter feed in a blog post, moving this block from one DOM position to another position would cause the iframe to reload itself. Other caveats include inability to get events propagated from the iframe back out to the editor (imagine if you're dragging a block element across the editor and your cursor is now hovering on the cross-site iframe and everything stops working).

All frameworks are great at working with Virtual DOM, but a lot WYSIWYG usage live outside of the Virtual DOM. I think the areas to focus on when assessing the right framework for Gutenberg is how well can the framework deal with DOM event handling, and for bleeding edge requirements that can't be built with framework, how manageable it is to build it outside the framework and plug it back in.

vue

Wordpress является достаточно легким для обучения новых разработчиков, а также имеет большую мощь, если заглянуть чуть глубже, тоже самое можно сказать о Vue
Я буду рад если WP будет использовать этот фреймворк!

My vote is VUE!

In terms of building custom web components, which I think pretty important moving forward, this site provides a score for each listed framework with test params and scores. It's instructive, so would encourage everyone to give it once over:

https://custom-elements-everywhere.com/

My vote for VueJS. Awesome framework, I think Laravel proved it.

WP + Sage 9 (roots.io) + VueJS => perfect stack

There may be a problem with Preact as well.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

Using Preact may make you worse off than using react. Facebook would be allowed to block you from using react or preact even if you didn't initiate the suing. This lawyer seems to think Preact wouldn't be able to hold up it's copyright in court and would be considered infringing on react.

Tell me if I'm wrong. I don't know much about law but wanted to be helpful.

I read this and it's similar to legal advice we got after deciding to
abandon React in our projects. It's not that the risk is huge. Rather we
wanted to minimize risk to downstream clients. This attorney just adds a
concurring opinion. We are using Polymer and Vue instead, both work great
for specific use cases.

On Sep 20, 2017 11:04 PM, "Coding Friend" notifications@github.com wrote:

There may be a problem with Preact as well.

https://blog.cloudboost.io/3-points-to-consider-before-
migrating-away-from-react-because-of-facebooks-bsd-
patent-license-b4a32562d268

Using Preact may make you worse off than using react. Facebook would be
allowed to block you from using react or preact even if you didn't initiate
the suing. This lawyer seems to think Preact wouldn't be able to hold up
it's copyright in court and would be considered infringing on react.

Tell me if I'm wrong. I don't know much about law but wanted to be helpful.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

I swore to myself I would never touch WP again after seeing the horrible code, but if you use VueJS I might reconsider it with a little bit of Valium.

Disclaimer: I am not a lawyer. Following is strictly my opinion.

@codingfriend1 that article has little practical merit.

There are three assumptions made:

1. Facebook has patents which are broad enough to cover preact.
2. If a company using preact, say ABC, sue FB for patent infringement, then FB will use react patents to sue ABC.
3. Facebook's patent have merit.

Let's give a closer look to all the assumptions:

1. Facebook has patents which are broad enough to cover preact.

There is no proof of this till date. Keep in mind that all patents are public. Preact source code is public knowledge.
Moreover, Jason Miller (preact author) has claimed that "none of Preact is patentable — it’s far too obvious."

So I would say this assumption is unlikely to be true. It is possible, but unlikely.

1. If a company using preact, say ABC, sue FB for patent infringement, then FB will use react patents to sue ABC.

This will destroy Facebook's reputation. While I expect FB to fight tooth and nail, but using react's patent that way will label FB as "patent troll".

Meanwhile, FB has enough resources to fight using legal means. So I believe this assumption is unlikely as well.

1. Facebook's patent have merit.

Yes, this is an assumption, not a fact.

As it happens to be, "having a patent" and "having a valid patent" are two different things.
I read this fantastic article where court has ruled patents to be invalid.

There is always a possibility that FB's patent are too broad to have a merit.
Now one would think that, if facebook has a patent, it will have _some_ merit. Yet, logically speaking, if it covers preact,, then it is too broad and hence meritless. So this is assumption is in direct conflict with assumption 1.

Considering that Facebook is using patent to defend itself, Facebook's patent are more likely to be broad and meritless, instead of being enforceable.

Conclusion:

Keep in mind all three assumptions are untested. If all of them turn out to be true, -- and this is technically possible-- then, "yeah, using preact is dangerous."

However practically, chances of all three assumptions being true are too low, especially assumption 1 and 3 together.

So until and unless court rules otherwise, I would say using preact (and other vdom libraries) is quite safe.

Regarding point 1, Facebook has a patent called Efficient event delegation in browser scripts. That's basically jQuery's live() function (later being part of on() in jQuery API)!

However, regardless of the validity of the assumptions, the reason WordPress is moving away from React is not that WordPress has concerns about Facebook. And I'm quoting from the announcement post linked in the issue above (highlight mine):

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

Based on this, it's the perception, confusion, and questions that the patent brings that drove WordPress away. I think the same concerns apply to Preact as well, as explained in my earlier comment.

Regarding point 1, Facebook has a patent called Efficient event delegation in browser scripts. That's basically jQuery's live() function (later being part of on() in jQuery API)!

Does that mean that they invented the event delegation idea at all?! I see some citations there which date back to 1995 year, what does that mean?

@ChrisCinelli regarding what you referred to as what "seems to be the inflection point of an exponential growth" in case of Marko.

I believe this is simply a matter of a scale. When a project has 5k or even 10k Github stars, a single happening like for example a link at the top page of Hackernews can bring 1k stars in a day, which in case of Marko is 20% of the recent number.

At the scale of 65k stars that Vue has it's not that visible. You can even see that because of how star-history script works, at some point it stops showing the fluctuations at all and it's just a straight line till the end.

Such a situation is not unique to Marko itself, it happened f.e. to Inferno or lately to MoonJS which is a microframework inspired by Vue. You could even say that Preact seems to be in a similar point because of how many stars it got lately due to the whole React patents drama.

You can observe what I'm talking about on the following graph from the same source as yours:

Time will tell if these people will actually try the framework in development, use it in production and continue to use it later. I wish Marko well, as every other open source library.

As for Vue, yes it's a stable growth without big fluctuation. With the current speed it should top React before Christmas. At least on Github. :)

What about @aurelia?
Website: aurelia.io
@EisenbergEffect created this.

For me it's a great framework!

1. Simple Conventions (can be customized)
2. Plain HTML
3. Vanilla JS
4. No Framework Intervention!

You can even plugin your choice of library (jQuery, Vue.js, Preact, Ember, HyperHTML, etc...) you want to use and teach Aurelia how to use it!

It's so simple and standards based you won't even need community support, and if you really think community support is important then they got you covered too (with more than 10k stars).

Resources for @aurelia:

1. Introducing Aurelia
2. Aurelia Blog
3. Aurelia Docs

Looks like React is being relicensed under MIT: https://code.facebook.com/posts/300798627056246

Decision should be reversed now, I suppose.

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.

I want to express my HUGE THANKS for Wordpress for taking part in what lead to this change in React lincencing.

I still think Vue would be the better solution. Many of the strengths from Vue still apply, but I want to point out that beginner friendliness and not having to use a build step are, in my opinion, killer features in the wordpress environment.

for mass
for sure
for vueJS

I also chose Angular2.0+ (not AngularJS), which has the biggest community,a strong developer team , a stable and complete ecosystem.

@CrazyBBer Where can I find some data on the biggest community being Angular 2/4? It would help me with a blog post.

Anyways, guys it's over, React is here to stay with WordPress and even as a Vue enthusiast, I find that the best possible way the situation could turn, given the amount of code already written with React.

@ahmadawais @gustojs 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.

Also this statement really bugs me:

we acknowledge that we failed to decisively convince this community.

Effectively saying "We weren't wrong - you developers just didn't understand us".

@ahmadawais : 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.

Plus what @atanas-angelov-dev said.

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:

1. 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._

571 Open issues (!)

It’s 338 now. (I spent a few days cleaning them up.)

During the past few months, the React team was busy preparing a new, largely backwards-compatible React 16 release. It was our largest release ever, so we weren’t as response on the issue tracker, so I’m sorry about that. Turns out, React 16 also solved a bunch of those issues. :-)

I want to point out that most of those 338 issues left are feature requests and discussions. A search for the bug label gives me about 60 issues. And given that React ecosystem is larger than Vue at the moment, it is no surprise that people bump into more edge cases and inconsistencies, and start more discussions. They also expect React to polyfill more browser inconsistencies, so many of the bugs are related to missing coverage of those. Additionally, we keep the documentation in the same repository, so a bunch of those issues are about docs.

I hope this gives you an insight into why we tend to have a higher issue count than Vue.

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.

Unfortunately this is baseless FUD, full stop. I’m not sure what’s your motivation for spreading it, but React has been relicensed as MIT, and that includes any code that React depends on (such as fbjs). There is no sneaky scheme here.

You can see for yourself that fbjs license has also been changed to MIT in https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 five days before your comment. The React 16 release that came out a few days ago doesn’t contain a single non-MIT byte.

The fact that other projects depend on fbjs but have a different license is completely irrelevant, just like it is irrelevant that your application code is probably not MIT but depends on Vue.

P.S. I think Vue is great, and I don’t want to push React on anyone. But I want to make sure that we base this discussion on facts. :-) We are always open to criticism, and I’m sure both Vue and React have things to learn from each other.

All this is exciting talk.

I have to ask - why a framework/library at all? As mentioned earlier, the Web Component standard seems to provide what ReactJS, Vue, and others were built to supply (as the standard didn't exist).

You can use state libraries like Redux just fine with web components. Similar with routing libraries. SSR isn't quite as developed with Web Components, however there are people working there as well. Partly the biggest value of React is the various supporting libraries around it - which are not necessarily lost by using the platform.

What does XXX framework give you over platform Web Components?

Exciting talk indeed...

The fourth licensing for React, so far.

1. Originally Apache 2.0. Should have been fine, right? What was the problem?
2. Then BSD + Patents. Without disclosing what patents do, or do not, exist.
3. Then slight amendments, allegedly to please Google. Without any details as to why.
4. Now MIT, with unspecified refactoring of React, but not for directly related projects, such as React Native, GraphQL, etc... and the shared dependency with the public description "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"

Apparently all that, is nothing to worry about at all.

[ edit removed by Tammie Lister: personal callouts like this are unacceptable ]

@PericlesSouza You can argue that we shouldn't be trusted because the licenses were confusing before. That's valid if it's your argument. But the licenses should not be confusing now.

React is MIT.
Its dependency fbjs is MIT.
The code that React and React Native share (which has been and continues to be in the React repo) is MIT.
React, including all of its dependencies, is MIT.
Create React App is not necessary to use React, but it too is MIT.
Relay and graphql-js are not necessary to use React, but they too are MIT.

We released React 16.0 with the new license. It's easy to verify this.
We also released a new version of React 15.x with the MIT license as 15.6.2.
We are planning to release all future versions of React under the MIT license too.

Add to that, another Facebook employee in this thread admitted that React (MIT for 16? what for <16? 17+? Better watch that package.json carefully) and React Native share code, which required refactoring (then edits her / his comment to remove that statement, after I quoted it).

I am that engineer. (Her.)

You commented https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331737418, then I replied https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331738521.

Here's the original content of our two comments, as recorded in my email client:

Here is the content right at this moment:

After I made my comment, you edited your comment to be much longer, including the additional question:

What parts are being removed to allow React to be published under MIT?

which was not in your original comment. So in response to your edit, I edited my comment to add:

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.

Which you then thought appropriate to call me out on in the following comment. How dare I edit my comment to address a question you added in your edit. I did not remove or edit any claim about React and React Native sharing code.

--

Please stop gaslighting me. It's exhausting.

@youknowriad Would you be so kind as to lock this thread? I can't imagine any more productive discussion happening here.

If anyone else here is legitimately concerned about the license still, feel free to DM me and I'll do my best to clarify.

Which you then thought appropriate to call me out on in the following comment. How dare I edit my comment to address a question you added in your edit. I did not remove or edit any claim about React and React Native sharing code.

Obviously I responded to your edit, is that your issue?

There is no gaslighting needed, simply openness and consistency from Facebook, the React development team, and licensing, and as the four licensing models in Reacts relatively short life time would indicate, and your (current) post, that is unfortunately lacking.

Briefly setting licensing aside: Again, what does React provide today that are gained above and beyond Web Components? Assuming you will still use a selection of supporting libraries in both (i.e. Redux).

With Web Components, WordPress can create many elements than can be used across various front-end frameworks/libraries. This would allow end-users with React, Vue, Angular, or whatever front end they are using to "drop in" WordPress components.

@sophiebits Not sure what version of your post to respond to now, so I will wait, and see what it finally becomes. It's really quite a similar situation to that of React.

@Brian-McBride

You make a good point, and I believe it was raised earlier in the thread - "why not use vanilla javascript", standards based, fully compliant.

Hmm.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

Like I said people, be very careful about your version control if you are using React.

Yes, we accidentally committed three files with the wrong header, from pull requests that were open from before the license change. None were in a released version (nor could they be – one was unit tests, two were part of the website).

Mistakes happen. We fixed it when we found out and I added a script to our CI to verify in the future that no more accidental references are added. You can see it in that commit.

One additional thing that I think Free software projects should consider -- Facebook benefits from the use of React.

But Facebook's values generally do not align with those of the Free software movement -- everything from unethical manipulation of users to attacks on Net Neutrality ("Free Basics"), inability to delete data, inability to block the data collection, censorship, walled garden, echo chambers, and more.

[Facebook] is like when my brother used to make me punch myself and ask, “why are you punching yourself?” Then he’d tell my mum it wasn’t his fault.

As I've watched Facebook over many years, I've increasingly moved closer to the conclusion that I no longer want to support that company in any way, so I personally don't use FB software whenever alternatives exist.

I read a book on React and it looks great from a programming perspective -- but the alternatives are also great, and they don't come with the baggage of supporting Facebook.

I think that Free software projects should always prefer independent, Free software libraries whenever they are available. There are plenty of great alternatives for WordPress, including Vue, web components, Ember, and Mithril. Vue has huge support in the PHP community and does not have any ethical problems attached to it, so it seems like it would fit well. If it's just for the dashboard, it might be worth taking a look at something even more interesting than JavaScript: Elm.

It shouldn't be about what is trendy or cool at the moment, but it should be about what provides the most technology freedom to the next generations -- directly or indirectly.

Just another thought to consider...

Thank you to everyone who voiced their opinions while trying to have a respectful conversation. I'd also like to add a special thank you to @sophiebits, @gaearon, @blake-newman, and everyone else representing projects who kindly spent their time answering questions. Your knowledge is greatly appreciated, and always welcome.

The conversation has since moved on to the JavaScript meetings in the #core-js Slack channel, there's a good summary here. If you are interested in participating on these discussions we invite you to join us there. Alternatively, we have two approaches to interoperability that could use contributions, testing, and feedback: #2463 and #2791.

And with that, this thread has run its course. We are locking the issue, but we encourage you to continue the conversation in the venues mentioned above.

This thread has yielded some good discussion, but some of it has shown unacceptable behaviour and has been edited. It is important to remember that https://wordpress.org/about/etiquette/ applies to any WordPress project and we will not tolerate violations or those that commit them. Thank you, everyone, who has contributed to the conversation in a considerate and respectful way.