[kevinflo]

I love love love love love react as a technology, but this is just awful. I believe any developer not on Facebook's payroll still contributing to React or React native at this point has a moral obligation to stop. I personally feel like such a fool for not taking all this seriously before the ASF gave me a wakeup call. React is a trojan horse into the open source community that Facebook purposely and maliciously steered over time to deepen their war chest. Maybe that's an overblown take, but they had a perfect opportunity here to prove me wrong and they didn't. The defensive cover they present here feels so paper thin.

Even if we paint all of their actions in the most favorable possible light, and even if the clause is a paper tiger as some have claimed, it doesn't matter. This is not how open source should work. We should not have to debate for years if a project's license is radioactive. Especially individual devs like myself who just want to use a great tool. We should be able to just use it, because it's open and that's what open means. This is so much worse than closed. It's closed masquerading as open.

[stephen82]

Well, I planned to learn more about React, but reading now this convinced me to learn Vue.js instead.

It's under MIT license developed by a single person in addition to community's contribution.

This link is rather interesting https://vuejs.org/v2/guide/comparison.html#React

[unkown-unknowns]

Alternatively there's this: https://github.com/developit/preact

Preact is a fast 3kB alternative to React, with the same ES2015 API as that of React.

Preact is MIT licensed and does not have any additional conditions beyond that.

[jfaucett]

Yes, preact looks like a good drop-in replacement. The good thing about the MIT license is you know what you are getting.

I also agree with the OP, even viewing FB in the best light possible, about the best case you can make is that they want to hedge any risks to themselves while profiting from OSS contributions and the OSS marketing. As it stands, there is virtually no case to be made for them wanting to contribute to the OSS community. IMHO if you're a dev and contributing to the facebook oss ecosystem, I would actively encourage you to stop.

[raulk]

As I said in my article [1]:

Patents protect ideas and inventions. In most cases, patent assertion cases are not black or white — win or loose. Infringement evaluation is complex and costly. A lawsuit can cost hundreds of thousands or millions to file and pursue. You might have a 85% confidence that FB violated a patent of yours, but to even pursue it it’s going to cost you a lot of money.

If on top of that, you will need to invest to migrate away onto a different frontend framework first, and make sure that all your customers are using your new product version (what if you’re using React Native? your users may not upgrade the apps at once!), before you can even file the lawsuit, do you think that’s an honest, ethical usage of open source philosophy?

Bottom line: Open Source is not a “quid pro quo” trade. Open Source is about creating communities to build better software together. It should never be used as a marketplace to exchange people's rights.

[1] https://medium.com/consensusx/if-youre-a-startup-you-should-...

[jnbiche]

Thank you. You pretty eloquently summed up my thoughts about this entire situation. I'm sad, because Facebook runs some pretty cool open source projects. But I will no longer contribute to them if this is their attitude. It's about as far from community-oriented as I can imagine.

[chiefalchemist]

FB would be happy to replace the internet with Facebook. I think we've all known this for some time now. It's not their attitude, it's their entire reason for being. It's a form of totalitarianism that we don't have a word for; that's beyond most people's imagination.

It would be fitting for FB to change their motto (?) to "We're not evil either." Lol

[chiefalchemist]

So ultimately patents boil down to the deepest pockets. Not that I'm naive, but that's a pretty shitty way to do such things.

[tgb]

Sorry I've forgotten what the status was on the "are APIs copyrightable" question, i.e. the Oracle v Google fight. I'm kind of confused about what wikipedia says happened - there seem to be two final rulings one in favor of Oracle and one in favor of Google with Oracle appealing the second. Is it that APIs are copyrightable but duplicating them is (sometimes?) covered under fair use? Either way, I'd be a little hesitant to use this.

[ktRolster]

APIs are copyrightable. You can see here: http://www.zerobugsandprogramfaster.net/essays/x-1.html

There is still a question on fair use. Google won the jury trial, but the appellate court is ruling in a few months, and that could change everything.

[gardnr]

The link that you provided is from May of 2016. AFAIK, Google won that case and the appeals and there are no ongoing appeals: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....

Oracle really has a way of being a big swinging legal turd, I do believe they would try anything they could. It just seems like they wouldn't wait a year to get it going.

[joatmon-snoo]

You are correct. (For the unfamiliar, there are separate rulings because in this case, the Court of Appeals for the Federal Circuit ruled that APIs are copyrightable, then remanded back to the district court to re-try the case in light of the new decision about copyrightability, which then found that reimplementation of the API was covered under fair use.)

[auxbuss]

Only in the US. In the EU, in particular, APIs cannot be copyrighted[0].

Namely: "For the avoidance of doubt, it has to be made clear that only the expression of a computer program is protected and that ideas and principles which underlie any element of a program, including those which underlie its interfaces, are not protected by copyright under this Directive."

[0] http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:320...

[joatmon-snoo]

Whoops - sorry, yes, this is a very good point. I'm usually good at checking my own US-centric POV but I totally forgot here.

[solomatov]

IANAL, but the problem with MIT is that it doesn't give you anything in relation to patents. I.e. it doesn't even mention them. In this respect, it's no better than React's BSD without patents. I.e. MIT and BSD are quite similar.

[slavik81]

The MIT license doesn't mention copyright either, except to state who holds the copyright and forbid you from changing that statement.

The actual permission notice says you have the right to use the software without restriction. To me, a layman, it would seem contradictory and unfair if they later claimed that they held previously unmentioned patents that restricted your use of the software.

[comex]

It might imply a patent license, it might not. I don't think it's ever been tested in court. But at best you're getting a license to the Preact author's patents, if there are any, which there probably aren't. You're definitely not getting a license to Facebook's patents - but because Preact is a clone of React (in outward design, at least), any Facebook patent that applies to React has a decent chance of also applying to Preact. So I'm not sure it helps that much...

[slavik81]

Apologies. I didn't notice this was about preact specifically. I agree that switching to preact is unlikely to help with any patent issues. I don't think any free licenses indemnify you from third-party patent claims.

[barneycarroll]

It's debatable how far that provides indemnity from Facebook. It's explicitly derived from their API, so whereas you can conceivably write a project to make use of React and then seamlessly switch to Preact if Facebook become threatening, surely Preact itself is liable — and your software by extension — for using the API?

[confounded]

It does appear that in the US, APIs are considered subject to copyright, thanks to Oracle:

https://www.techdirt.com/articles/20160511/17515734410/stake...

[dcposch]

Check out Preact. It's an API compatible, lightweight React alternative that is actual free software.

As a bonus, it's a lot smaller, just 3kb minified

https://preactjs.com/

[tribby]

you've made a great choice. forget about patents: vue is a joy to use. can't say the same about react, personally.

also check out nuxt.js, a small abstraction layer on top of vue that has some opinions about file structure and also makes SSR a breeze https://nuxtjs.org/

[kdamken]

Finishing up a project at work with Vue right now, and I gotta say it's really excellent to work with. Way more intuitive than some other frameworks out there.

[shams93]

To me it has the advantage that jQuery had, the product if a single developer with a huge community behind him but no large company imposing their agenda on the framework.

[tmat]

React isn't even a framework.

[bdcravens]

When most people talk about React, they aren't talking the single library, but rather, the ecosystem of libraries that enable you to build applications. Most "frameworks" are just a collection of libraries too - the difference is in branding, and most frameworks are really just a pre-built package.json/Gemfile/etc.

I'd venture to say that very few if any of the sites Facebook lists at https://github.com/facebook/react/wiki/sites-using-react are using "React the view library" by itself.

[amelius]

But does it also provide an alternative to React Native?

[thebigspacefuck]

You can use Vue with Nativescript but at this point it's still early days

https://www.nativescript.org/blog/a-new-vue-for-nativescript

https://github.com/rigor789/nativescript-vue

[tribby]

yes, weex[1], which is becoming some sort of apache project. it was formerly (?) an alibaba project, not actually sure on the specifics RE: changing of hands.

1. https://weex.apache.org/

[lqdc13]

I hope they are very good, but it is not a good first impression if your UX framework web page looks like this on mobile:

https://kek.gg/i/C92Fk.png

https://kek.gg/i/89GHzx.png

[tribby]

I looked into this because I remembered weex having a different alibaba site[1]. it looks like weex became an ASF incubator project ~6 mos ago. around the same time, evan you (vue creator) mentioned on twitter (or maybe a github comment, I don't remember) that there is massive development going into weex right now. I would guess it'll be a few more months before we see a solid website with solid docs from ASF.

1. https://web.archive.org/web/20161224161323/http://alibaba.gi...

[bpicolo]

And also says "Get Invovled"

[pyramation]

looks like weex uses `flow-bin` which is a BSD+PATENTS repo:

https://github.com/apache/incubator-weex/blob/master/package...

not sure, but I think that means users of weex are subject to BSD+PATENTS also

[reademandweep]

nativescript-vue

[heroic]

Try out weex

[jondubois]

Or there is Google's Polymer framework. In my opinion, Polymer is better than React and Vue. I could never bring myself to use React because of its liense terms.

[kenning]

Using polymer as a JS frontend framework wasted about a year of work at my friend's company. They eventually switched to react for one project and an in-house react replacement for the other.

[nawitus]

I've used Polymer in three production applications and they were successes.

[boubiyeah]

google is pretty bad at frontend frameworks from my experience :D Polymer is an experiment that should have stayed in that state.

[gramstrong]

I'd argue that google is pretty strong when it comes to frameworks, and that most of their criticism comes from people who aren't looking for a framework, but rather a library (like React).

And Polymer isn't even really either of those things, it's a polyfill for a native browser feature.

[ergo14]

Polymer is not a polyfill for web components - it is higher level library - something like "jquery for web components" - WC polyfill is separate project, in separate repo - you will need it with X-Tags, Svelte, SkateJS too.

[boubiyeah]

No, a polyfill has to closely mirror an API. Polymer is inspired by web components but went its own way for several features.

[Zenbit_UX]

I'm guessing you're hating on Angular? Why? I'm a huge fan of 1.x & polymer, but I'm curious to know why you think it is not worth using.

[stemuk]

True, what I really love about polymer is https://webcomponents.org, basically a collection of webcomponents that can be used either individually or in combination without much setup.

This creates great looking results pretty fast and also enables you to easily give back to the community by open-sourcing your own components. Last time I checked already 1100 components were listed, of which the vast majority seemed really well build.

[nawitus]

That's not correct, the Web Component catalog is completely separate from Polymer. Polymer is a library to make it easier to implement web components. You can use Polymer without using any of the community's components.

[Zenbit_UX]

What did he say that wasn't correct? He said he loves polymer because it gets him access to community made web components.. Made in Polymer...

[nawitus]

He implied that https://webcomponents.org/ is part of Polymer, but it is not.

[etimberg]

The downside of polymer is that it doesn't really play nicely with modern toolchains.

[jondubois]

Yeah because with Polymer you don't even need a toolchain.

I hate toolchains and their clunky 10+ seconds compile step.

[rictic]

Expect good news on this front at the Polymer Summit on Tuesday.

[thecrazyone]

Why not Angular?

It's conspicuously missing from these discussions

[c0ndu17]

From someone who works with Angular everyday, on a multitude of projects... Angular feels far too heavy in comparison to React. While Angular can do the job, there's just too much bloat.

[Zenbit_UX]

Super powerful but it's no longer the shinny new penny of front end frameworks. Devs like shinny stuff.

[shams93]

Yeah my current gig is steering clear of react because of the patent issue but we are embracing Vue and vuex.

[thecrazyone]

why is angular not even being considered? Has it suddenly become radio active that no one wants to touch it even?

[chrisco255]

Angular 2+ missed the mark on a few things. Most critically, they missed the mark on Components. Compared to Vue, React, Preact, Marko, etc...Angular 2 components are extremely verbose. And this a big problem, because Components are the building blocks for any UI.

Angular has other issues like the AOT compilation file sizes and the fact that certain standard language features are not supported with it. But even having to know the ins and odds of AOT vs JIT...these aren't even things you have to worry about in any of the ones I mentioned above.

I really wish the Angular team had learned the best lessons from React...but they didn't. It's definitely better than Angular 1...but it's not as good as these other alternatives.

[candu]

FWIW, I've been using Vue for the last couple of projects and have been extremely satisfied.

[whatl3y]

I made the same decision about 1-2 months ago for the same reason, and after scaffolding my project from the CLI, creating some components, and adding additional pieces I needed (vue-router, vuex, dev server proxying to my backend, etc.), Vue has been an absolute pleasure to work with.

[coetry]

I haven't had to change to really play around with it, but cycle.js (https://cycle.js.org/) is another option alongside Vue and Preact

[zackbrown]

I remember sitting in the front row at ngEurope (Angular conf) back in 2014, when Misko announced that Angular 2 would be a (breaking) API rewrite vs Angular 1. At that time, Angular was perhaps at its global maximum of community mind share—bigger than React!—and its popularity began to sink afterwards in large part due to that PR snafu.

I wonder if this is React's "Angular 2." What's worse, the misstep this time is due to ham-fisted corporate mal- stewardship, not just miscommunicated technical good intentions. Vue is similarly positioned to be the "next thing" in the way React was three years ago. My how this space churns.

[rogihee]

I'm still working heavily with AngularJS (1) and in combination with components (1.5+), TypeScript and a MVVM approach it is very clean and productive. Even for all its flaws, it still very easy to start with in 10mins, include 1 lib in 1 line and "Hello World" is up and running.

Compare that to the space ship Angular 2. They really made an outstanding effort to create a huge barrier of entry for anyone not having a degree in DevOps. I'm an old fart, I don't need your stinking CLI, Grunt, Gulp, NPM etc stuff.

Compare that to Vue.js really shines in this regard with the same level of entry as AngularJS. For me that is part of what I thinks makes it a succes.

When choosing a new framework I tend to not look for the future, but look in the past. I chose what was mainstream 2-3 years ago, which means right now still AngularJS for me. This means I'm a leecher on StackOverflow, but so be it. I have my own company and clients pay me for working applications, which means I have to choose my tools as efficient and effective as possible. By choosing last years model, it is less sexy but will get me from A to B with the same speed plus added reliability. At the same time I'm keeping a close look to Vue.js and if still going in the same direction next year as it is now, I will definitely switch to it.

[Bahamut]

Coming from the Angular community & still connected quite a bit to it despite currently working primarily with React, I don’t think having an incremental change would have helped Angular compared to React due to the complexity of Angular.js’s API & its flaws. I actually stand by quite strongly behind the decision to rewrite in Angular 2, but Angular 2 took a long time to come into being - it was rewritten 3+ times in getting to its current state & 3-4 years in the making. I think Google devoted the proper resources too late into it in its quest to make the most performant & flexible framework. I believe this gap is what largely hurt Angular, and while the PR snafu was visible, I think the current situation would have been arrived at regardless.

[esistgut]

I agree with you and I think Google is still underestimating the amount of required resources because the framework is still not really "done", a couple examples: universal (SSR) just hit a stable release on angular-cli so it needs time to be widespread and supported in the ecosystem. The are core components like the i18n waiting for a major refactor because they lack basic features: https://github.com/angular/angular/issues/11405

[IanKelling]

> if a project's license is radioactive

It's not a copyright license. It's a patent grant/license which is completely independent. This matters for several reasons, including when just saying "license", this usually means a copyright license.

If this patent grant get's revoked, you are back to simply using the BSD license with no patent grant. I've read so many people say "you'd have to stop using react if you sued facebook", uh, no, you'd have a bsd license with no patent grant like you probably do with tons of other free software your company uses. Clearly, people should be complaining about that if they are complaining about this, but the misunderstanding and misinformation is really strong. If you believe software patents are universally bad, like many people including me, then it is clearly better using the MIT/BSD license alone, which gives you zero patent rights, you are simply infringing and waiting to be sued. I have no problem with it. https://www.gnu.org/philosophy/software-patents.en.html.

[mygo]

I think you're missing the plot. Currently, there is a big philosophical debate on whether OSS licenses like the BSD include an implicit patent grant. When Facebook explicitly includes a revocable patent grant, your argument of the BSD license "with no patent grant" is self-fulfilling. But if the PATENTS file had never existed, then what you have is "a BSD license with a potentially implicit patent grant", which has never been tried in court so could set a precedence, but is waaaay better for the consumer than a "BSD license with no patent grant because that patent grant has been explicitly granted and now revoked".

[chrisco255]

To me it's sort of a toss up between these two scenarios. Implicit grant that has never been tried in court vs explicit grant that only gets revoked if I initiate a patent war?

[mygo]

In both scenarios you have a patent grant before going to court over Patents. The difference is that, in one scenario, you no longer have a patent grant once you go to court. In the other scenario (where PATENTS file never exists), you may still have the patent grant after court.

[IanKelling]

I see. Thanks for the information.

[kevinflo]

I've seen it pointed out before though that it would fall back to just the BSD license and others countered saying that was definitely not the case. It seems to be yet another fundamental thing about this that isn't clear or agreed upon at all. Still, your point is important and I hope people read it and consider it.

Also by "license" I meant the "BSD + Patents license" as the Facebook writeup put it.

[delinka]

"...definitely not the case." Citation needed, reasons required, etc. The patent license says nothing about terminating the BSD license. Neither refers to nor affects the other. Without a good legal argument, one must assume that the BSD license applies whether Facebook is being sued over a patent or not.

[allover]

> I've seen it pointed out before though that it would fall back to just the BSD license and others countered saying that was definitely not the case

Those others were wrong. Facebook have made this very clear in their FAQ [1]:

> Does termination of the additional patent grant in the Facebook BSD+Patents license cause the copyright license to also terminate?

> No.

[1] https://code.facebook.com/pages/850928938376556

[DougBTX]

That answer only addresses the "copyright license", others argue that plain BSD is a "license to use".

If BSD is a "license to use", then it is implicitly a copyright license _and_ a patent licence.

Assuming the above, the argument goes that the implicit patent license in plain BSD is overridden by the explicit patent license in BSD+Patents, and that the explicit one is much more restrictive than the (unwritten) implicit one.

The FAQ doesn't address that.

[abiox]

From what I understand, React isn't under patent, so what patents would be 'implicitly licensed'?

[IanKelling]

> better using

I meant to write "better than using." Also, I was not aware of the implied patent license argument.

[thesagan]

I'm also going to hop on this train and move away from react. Personally and professionally, I don't like the direction the big players are taking the internet. (The closed, proprietary model.)

I suppose there's not much I can do about it except to move my efforts elsewhere, even if it affects my earnings.

[tannhaeuser]

> I don't like the direction the big players are taking the internet

It's more like developers in large parts stopped caring for standards and looked after products and "big players" and "the next big thing" instead aka the consumerization of IT. Happened to SQL, browsers, middleware, network protocols, app servers, containers, programming and markup languages, and more.

Nowadays, big things come onto the scene and into developer's minds via obscene venture capital budgets.

[ZenoArrow]

In the case of SQL, I'd say the fragmentation happened because the standards weren't keeping pace with the types of improvements developers were looking for. Even the different RDBMS couldn't keep pace with all the trends, they've each focused on building up different strengths. We'll probably see a return to standards once the rate of innovation slows down.

[ranit]

> It's more like developers in large parts stopped caring for standards and looked after products and "big players"

This is not a recent phenomenon. For example, developers using (mostly) Microsoft tools on Windows have been doing it for decades already.

[thesagan]

An even better point than mine! Yes, developers (us) have enabled this situation, as well.

Drives home the point of why I need to move on and be careful where I put effort.

[drieddust]

Agreed and there is no reason to still stick with react when alternatives like vuejs and angular are available.

Its not that great anyways when compared to angular 2/4. There are too many concepts to be mastered and it soon become overwhelming. I tried learning react but dropped it after spending a week when I still could not understand routing. Sense of cohesiveness between different concepts is missing. I believe some learning junkies may get the kick out of it but that's not me. My time is better spent elsewhere.

Angular on the other hand introduces everything one single tutorials[1] to make one productive. Deep dive later can be done later on when required.

[1] https://angular.io/tutorial

Edit: minor typo

[chrisco255]

React Router v4 is dead simple: https://medium.com/@pshrmn/a-simple-react-router-v4-tutorial...

It's just React components up and down.

Most of the concepts that you must learn with React have to do with understanding JavaScript. If you know JS, you know 80% of what you need to know.

[geocar]

It's also less capable and completely incompatible with router 3.

[chrisco255]

I hadn't heard that it was less capable. But you can always keep using v3 if that's what you know. He seemed to indicate that it took him a week to figure out routing in React. I have never had that much trouble.

[geocar]

> He seemed to indicate that it took him a week to figure out routing in React. I have never had that much trouble.

When you haven't had "that much trouble", it sounds like you're calling them stupid or a liar, and it sounds like you didn't consider the possibility that you're working on a very different problem or have a different definition of "figure out routing".

I store all of my user state in the URL. This way users can copy URLs to each other containing their state, I can press reload to debug things, Other people can embed portions of my application into iframes, and other good benefits.

However I don't want to sprinkle url changes and parsers all over my code, so I'd like to hook into the router system and glue it into the property system. I've probably been through a few versions of this idea with react and certainly spent at least a week in total trying to get it working well with all the different browsers and widgets, only to have react-router 4 come out and break it.

I then probably spent at least a day or two looking for similar-shaped hooks and couldn't find them. Maybe I should have spent more, maybe I should've been smarter.

However I note that the author of React-router took four very different approaches towards figuring out routing and produced incompatible APIs, which is a strong sign that they weren't able to figure out how routing should work either.

[chrisco255]

No, it's simply that OP did not clarify with any specific problem he had with React Router.

If React Router is not suiting your needs, there are many other options out there. That's the beauty of the ecosystem:

https://github.com/FormidableLabs/redux-little-router https://github.com/react-community/react-navigation

I'm glad that even React Router was willing to iterate on its implementation.

It takes a couple of hours to do a bit of research and searching to find the solution that fits your needs best.

[thecrazyone]

Is there are reason you're not considering angular?

I feel like I'm missing something big with everyone not even talking about angular. Maybe I feel this because Angular was big and then soon it wasn't. Probably that's the disconnect

[tmat]

Same here, This all seems like a "My JS Lib is better than your JS Lib" fight. So let me say this, React is by far and away the best JS view library out there. I don't need MVC in my fucking view(Hey Ember), and I don't need a entire framework for my view(Hey Angular)..

ReactJS 4tw.

[EduardoBautista]

React Native is what I believe to be the big thing in the React community. I haven't hear of anything similar in the Angular or Vue ecosystems.

[sheetjs]

https://weex.apache.org/ is the closest thing for the Vue ecosystem

[Mayzie]

As an alternative, albeit in a different language, is Google's Flutter[1]. If Google can correctly capitalise on this moment in the React.js ecosystem, they could really come to dominate in cross platform mobile app development.

[1] https://flutter.io/

[nutbutter]

NativeScript is really good

[thebigspacefuck]

I've been using NativeScript with Angular and I like it

[WalterSear]

React doesn't do routing. It's a view library.

And for me, the opposite was true vis-a-vis Angular and React, though got as far as making contributions to the Angular 2 tools before I decided to jumping ship.

[drieddust]

> React doesn't do routing. It's a view library.

and that's the problem. React itself solves a tiny subset and delegates the other responsibilities to different tools which may not align with each other. Most of the is spent is wiring making different choices and wiring them together.

On a side note what made you move away from Angular 2 to React?

[arvinsim]

> and that's the problem. React itself solves a tiny subset and delegates the other responsibilities to different tools which may not align with each other. Most of the is spent is wiring making different choices and wiring them together.

So modularity is a problem now?

[thecrazyone]

well there is modularity and then there's keeping frequently used things together. I think react push modularity at the cost of productivity (opinion).

It's like breaking a kitchen knife into two: the blade and the handle, in the name of modularity.

Concretely, this is what I mean: Routing, and a bunch of other things are used together, it would've been better if react had kept the view library separate but also maintained an official router among other things

[chrisco255]

Routing isn't always necessary, if you're building server rendered pages and a non-SPA web app. Facebook isn't a SPA, so that's why they never built and subsequently released a router. They generally only open source and release things they use in production.

[wreath]

What's the problem with solving exactly one problem (and doing it fairly well). I'd rather have the possibility of choosing which routing library or state management and swap things as I see fit, than being locked in with whatever the framework chooses.

[mzzter]

That's the problem, it isn't intuitive at first as to how one should add routing when using React. I learned React-Router, but the API has changed a lot between versions in the past.

[WalterSear]

You can't blame a tool for the shortcomings of another tool, though :)

Fwiw, I concur that React Router is/was a bitch (it's been a while) - I suffered through it too. A client-side hash-based router is ~10 lines of javascript, and is what I'll write unless there's an actual need for anything more.

[tmat]

Angular is nothing like React. It's garbage in comparison.

[drieddust]

In what sense?

[thecrazyone]

I'm not getting the angular hate. Would you want to explain why?

[c0ndu17]

Just my opinion from working with them everyday. Angular is more of a monolithic beast attempting do everything, and mostly it can. React is more of a microorganism with one goal, which it excels at. For me, Angular feels heavy, especially since the introduction of NgModules. I guess the million breaking changes that occurred from AngularJs to Angular2 might have left a bit of a sour taste in mouth, regarding the framework. How can they introduce NgModules in like beta 10? Angular isn't a bad framework, but the question goes down to would you rather have one framework that try to do everything, or many frameworks that each try do their one thing. There are pros and cons to both. On an even more opinionated note, I really enjoy the syntax, and feel of React(jsx)... which something I don't get with Angular components. I'm not even gonna start on redux, but it's pretty fun when you get the hang of it. As with a lot of things in programming but each to their own.

[qaq]

Angular does not come with a patent grant at all. Vue most likely is infringing on FB patents anyway. So what is the win exactly?

[bpicolo]

> Vue most likely is infringing on FB patents anyway

There are zero known patents related to react.

[qaq]

So what patents FB grant is related to?

[vonmoltke]

In that case, the patent clause in the React license has zero effect.

[bpicolo]

Mmm, well it widens the range of people using software declaring their patent grant, which applies to all their other patents as well.

[drieddust]

Angular 2 is MIT licensed. Why you need a patent grant anyways?

[qaq]

because copyright and patents are orthogonal concepts. FB gives you patent grant with restrictions Google does not give you a patent grant at all.

[pdfernhout]

The patent grant is (presumably) implied by the act of licensing under MIT in the absence of other specific restrictions (such as Facebook's PATENTS file as an explicit patent grant with one-sided limitations).

See for example: http://oss-watch.ac.uk/resources/fossandpatents "Some free and open source software licences also explicitly grant the patent rights necessary for the purposes of using, adapting and distributing the code, for example the Apache License v2, the GNU General Public License v3 and the Eclipse Public License. In some jurisdictions, including the UK, it is highly probable that even those free and open source software licences that do not explicitly grant patent rights do in fact provide them implicitly. After all, giving permission to perform a specific act strongly implies permission to perform the steps needed to do so. Thus the permission to redistribute the software granted by all free and open source licences - it can be argued - implies the granting of the right to make use of any of the licensor’s patents which would be infringed by the distribution of the code."

[tzs]

The big question about an implied patent license would be whether or not it is revocable.

In the specific cases of the BSD and MIT copyright licenses note that the licenses do not say that they are irrevocable. A license granted for no consideration is generally revocable unless it specifically says that it is not.

There are substitutes for consideration. It is an open question as far as I know whether or not those apply in the case of free software and make licenses like MIT and BSD irrevocable.

If you use BSD or MIT licensed patented software that does not come with an explicit patent grant, you'll have to deal with these arguments if the patent owner decides to go to court:

1. There is no implied patent license,

2. If there is an implied patent license it is revocable and they revoked yours,

3. The copyright license is revocable, they revoked yours, and that implicitly revokes the implied patent license (even if it is irrevocable normally).

It's so much safer to try to stick to licenses that say they are irrevocable and include an explicit patent grant.

[qaq]

Nice if you are in UK, but a very small % of tech companies is in UK.

[rtpg]

vue and angular don't offer the same typing guarantees as React.

Though I use Angular in my day-to-day, I would really love to be in React land for that reason alone. I've had too many interface bugs due to simple template typos

[drieddust]

How come? Angular is Typescipt first so typing guarantees are builin.

[erokar]

Not in templates.

[swellsy]

You need to use the Angular Language Service extension for vs code, it works perfectly giving you full type completion and error checking in templates https://github.com/angular/vscode-ng-language-service

[drieddust]

Thanks for sharing this.

[Strom]

> I believe any developer not on Facebook's payroll still contributing to React or React native at this point has a moral obligation to stop.

I've contributed to React before and will continue to do so. I haven't seen a single reason why not to. Just because React doesn't use your favorite license? Well this may shock you but I also use and help develop closed source software. In my view there is nothing morally wrong here. What's more, it's not even clear which morals you think I would be failing by continuing to contribute to React.

[jlrubin]

> closed source

That's not really the problem here. The problem is that by using React, even in a closed source context, you are potentially setting yourself up to not successfully make an IP claim against facebook, even for unrelated technologies.

[Strom]

Not being able to sue with patents is not something I give much value to. Software patents aren't even valid where I live and operate. They concern me only as far as USA has the will to have a global jurisdiction. However if Facebook wants to sue me for something ridiculous and has the USA government's global help, then Apache 2.0 license isn't going to save me, they will find something else.

[imtringued]

Yeah and that is exactly the problem with the license.

You give up your right to sue facebook with ALL your patents while facebook only gives up the right to sue you with their REACT patent. We don't even know if there is such a thing as a "react patent".

[vonmoltke]

You absolutely do not "give up your right to sue facebook with ALL your patents". People keep saying this, but it isn't there.

If you live in a jurisdiction where the concept of software patents are void, as the GP indicates, the patent clause in the license is meaningless because there cannot be any patents on React in that jurisdiction.

[rmc]

Is it limited to software patents? e.g. if BMW uses React in a project, and FB has a patent which covers React, then I think FB can use all of BMW's patents without paying, and BMW either has a choice of changing away from React, or not suing FB. Could be helpful if FB wants to do something with cars.

[thecrazyone]

IANAL wait is this true?

The way I understood this conversation was that BMW (continuing your example) cannot sue facebook if facebook infringes them on an of their car patents but it's not a right or a grant or even a license of any sort.

[arnarbi]

I don't understand that last sentence, could you rephrase please?

[Vinnl]

Then again, Facebook isn't making IP claims against you for using React either.

[jnbiche]

> Just because React doesn't use your favorite license?

No, that's not the problem for many(most?) of us. The problem is that Facebook has decided to throw out innovative extra conditions to an old and established license. Innovation is typically not a good thing with open source licenses. It just throws a lot of uncertainty and confusion onto the situation, and for what gain? In fact, no one has any clue how this patent grant will work in practice.

If we believe the minimalist interpretation that some people are proposing here, Facebook has gained virtually nothing here. And that fact in itself makes people suspicious, because why would they dig in for almost no gain?

[chrisco255]

Because Facebook has been sued, even by big players like Yahoo. If Yahoo sues them for patent infringement, they want to be able to say, yo...what about all that free code we gave you?

[shafyy]

Completely agree. Everyone here is acting as suing Facebook (and suing successfully) is something that will happen to all of them with great probability.

Why do you even care? It's a great framework and if you don't want to use it under the license then don't. But why ranting about they should change the license?

I can understand why FB is licensing the way they do. I also would be pissed off if I would get sued for some nonsense all the time and would take an opportunity to potentially reduce that.

[devdoomari]

+1 on this.

I'm going for Preact (https://github.com/developit/preact) for React alternative.

[khuey]

If React really is covered by patents Facebook has then Preact is likely infringing on them since it does the same things in similar ways. And Preact doesn't come with a patent grant from Facebook at all.

[reconbot]

We learned from Java and Google that you can't patent and API. It's not forked from React it's an alternative.

[Lazare]

The risk behind Preact isn't the API. Remember, this is a discussion about patents, so what matters is fundamental concepts and algorithms.

The most likely thing for Facebook to patent is the concept of a virtual DOM that's diffed to apply updates to the real DOM. IF they have such a patent (and apparently they don't), then any library that has a vdom implementation infringes, including Preact.

Of course, if they DON'T have such a patent (which seems to be the case), then Preact is safe, but so is React. :)

[true_religion]

They would have to sue on the basis that Preact and by extension all React-compatible APIs are in violation of their patent.

This would cause mass alienation in the community for little gain, and force many previously neutral parties to align against them for attacking a completely separate project.

And for little damage as well....

If we rewrote our sites to use React coming from Backbone, JQuery and Angular... it won't be too much of a hardship to rewrite our sites to no longer use React in the future. Heck considering the 5-year churn of JS frameworks, I'm already penciling in the rise of a new framework in 2022.

[ballenf]

They would simply sue a particular company for employing infringing technology. They wouldn't have to nor want to make any broader claim than necessary to achieve their goals in the case at hand.

It would likely be a company suing FB for infringing a patent who happens to also use Preact in a site. FB presumably wouldn't have access to the site source code (pre-suit), but would be looking at the compiled, minified public site. I don't know how Preact and React look when compiled compared to each other, but given their similar structures it might be hard to tell them apart. FB would identify the offending bits of code or code structure. They wouldn't need to even use the word "Preact" (or "React") in the suit.

If the underlying suit was a patent troll suing FB, FB's use of React patent clause might actually be celebrated in a enemy-of-my-enemy kind of way by the broader developer community.

It would require FB to finally disclose the patent numbers applicable to React. I've spent a few hours attempted to review FB's patents to find anything related to React technology, but it's a needle in a haystack challenge and I failed. There are tens of thousands of patents and impossible to know what keywords to search for. (If someone else has done this work, would be great!)

[vonmoltke]

> They would have to sue on the basis that Preact and by extension all React-compatible APIs are in violation of their patent.

Why? Why is the API relevant at all?

[chx]

I believe you are mistaken, the problem with the license, if I recall the discussion correctly was that if your company used React then they can't go on a patent lawsuit with Facebook even if the patents have zilch to do with React.

[chrisco255]

Great explanation of implications of React patent clause: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...

[jannotti]

That may be what was said in a discussion, but it is incorrect. If your company sues Facebook for a patent, then you lose the extra patent grant, which means you would have only the original BSD license. Which is what ASF seems to want the software license under anyway.

The patent grant from FB grants you strictly more rights than BSD alone (though admittedly, you could lose those extra rights).

[Lazare]

> if I recall the discussion correctly was that if your company used React then they can't go on a patent lawsuit with Facebook even if the patents have zilch to do with React.

Not at all.

[imtringued]

React is still unsafe because facebook can infringe on your patents and if you sue you will lose your rights to use react.

[Lazare]

That's simply false. It cannot happen. How many times does this need to be explained?

It's been discussed a ton, the plain language of the license makes that clear, Facebook even covered this in their official React license FAQ (https://code.facebook.com/pages/850928938376556).

Please stop spreading FUD.

[jopsen]

Even if you reject the notion of software patents..

I don't want a non-standard license... It's just more complexity we don't need.

Make it LGPLv3 or something if you want a patent clause, don't invent your own.

[jbwyme]

I'm pretty sure that the concept (or implementation) of virtual dom wasn't invented as a part of React. IANAL but I don't think they could patent it. Ignoring specific optimizations, a virtual dom algorithm is fairly simple.

[Lazare]

Correct, there is known prior art relating to vdoms, so any such patent would be fairly easy to defeat, IF it exists...and patents are public, and people have looked, and no such patent seems to exist.

The patent issue is really not a big deal with React; the real concern is philosophical.

[jnbiche]

Patents are public, and Facebook does not have a vdom patent. It's puzzling that this is even a question.

[dminor]

The Google/Java case was about copyrights, not patents, and Google actually lost on that issue.

They won on a fair use claim. And that win is still subject to an ongoing appeal.

[riffraff]

> We learned from Java and Google that you can't patent and API

did we? I think the jury is still out on this, i.e. we had one verdict for google, one for oracle, one for google again, and now there's another appeal.

[threatofrain]

API is a matter of copyright, patents can cover the methods and techniques underneath the API, and so in a way is more general, and it's possible that Facebook patents concern Vue as well.

[kccqzy]

The case was about whether or not you can copyright an API.

[WalterSear]

Could anyone with experience porting from one to the other let us know how it went?

[gedy]

For many codebases, Preact can be use simple as:

    npm i -S preact preact-compat

then add this to webpack config:

    {
      "resolve": {
        "alias": {
          "react": "preact-compat",
          "react-dom": "preact-compat"
        }
      }
    }

https://preactjs.com/guide/switching-to-preact

[bpicolo]

The tricky part is probably testing. I don't think e.g. jest (or maybe it was enzyme?) supports alternative implementations quite yet, though they were working on it...that was true months ago though.

If you're starting from scratch pretty easy though, sure. But that assumption is all too widespread in the JS ecosystem these days : (

[gedy]

We saw no problems with Mocha & Enzyme, can't comment on Jest.

[WalterSear]

woot.

brb :)

[patrickaljord]

Here's a list of companies using React:

- Microsoft - Uber - Yahoo Mail - Dropbox - Airbnb - Netflix - NY Times

If they're ok with the license, you probably shouldn't worry too much. Basically, if you don't own any patents or if your company is smaller than any of the above, you should be ok.

[throwaway13337]

You don't know that they weren't granted separate licensing deals.

I assume they were.

This license is likely to protect facebook against patent litigation that a startup might claim facebook is in violation of.

It's not too hard to imagine a scenario where the next snapchat-like-startup is using react native. Facebook is then in a super leveraged position against them legally.

Snap stories are now facebook stories, instagram stories, and whatsapp stories. It's not such a big leap that it'll happen again.

[evgen]

A more likely explanation is that these large orgs employ real lawyers who looked at the licence and grant and who then approved the use of react because they are professional lawyers who actually understand the legalities involved, unlike 99% of the commenters in this thread.

[TimTheTinker]

I suspect the real reason is that these large companies already have large patent war chests, so any suit from FB could incite countersuits from them. They have a measure of impunity and thus their exposure to risk is much less than that of smaller companies and startups.

[Spivak]

What's not to understand? If Facebook infringes on one of your software patents your choices are to rewrite your existing React code and sue them for damages or ignore it.

Once your 'professional lawyer' agrees that the license is enforceable it's up to you to decide whether giving Facebook an effective grant of all your patents it worth it.

[abiox]

> rewrite your existing React code

my understanding is that this isn't the case - react isn't itself covered by patent, and the bsd license remains in effect.

[jannotti]

No, if such a startup sued FB, then would end up being a legal user of React under the BSD license, which does not terminate.

[mundanevoice]

This is a very dangerous follower mentality. You and I are not in the league of these big companies. If FB sues them they have deep enough pockets to fight back. But we, we would just vanish into thin air.

[patrickaljord]

If you develop a patent worth a billion dollar that Facebook wants to steal, you will probably be ok too.

[thecrazyone]

"worth billion dollars" is not the same as "have billion dollars". FB is both worth and have multiple billion dollars. Does this make sense to you?

[andrewaylett]

All these companies are big enough to potentially have a separate patent agreement with Facebook. I don't have any insider knowledge about them (or anyone else, for that matter) to say whether they do, but you should entertain the possibility rather than assuming their risks are greater than yours.

[eropple]

The person in question was talking out of school, and so I have to be very vague (and you can take this for what it's worth because of it, you don't have to believe me), but at least one of those companies listed in the prior post has no such agreement with Facebook.

[Zenbit_UX]

Source for Microsoft? I once read an article saying that Google, Apple & Microsoft forbade all their developers from even using React due to its licence and this was years ago.

[thebigspacefuck]

Come on, everybody's doing it...

Anyway, it's not up to me, it's up to the legal team and they are saying "No".

[hajile]

https://github.com/facebook/react/blob/0.11-stable/LICENSE

Turns out that forking a somewhat recent version of React that uses Apache is possible while still retaining any relevant patents (esp pending vdom patents) and API compatibility.

[lobster_johnson]

0.11 is three years old, though. Not really recent.

[hajile]

Most of the APIs are the same which is what really counts. Other frameworks like Inferno already have way better performance using methods not tied to Facebook. But adding those to an actual React fork keeps the patent grant in a way that switching to a greenfield codebase might not.

[kevinflo]

https://github.com/kevinflo/react-open at least to play around with for my own purposes. I forget what the state of things even was back in .11

[hajile]

You should probably steer clear of trademark infringement too. I was thinking something like free-dom myself.

[akamaozu]

That's probably the most American-sounding package name I've ever heard

[thecrazyone]

Wow! that's an amazing library name? Would you mind if I ..er.. borrow it? (JK) :D

[kevinflo]

Good point. Just switched it to rdom-open (first thing that popped in my head lol)

[WalterSear]

How about eact?

[djsumdog]

I agree. I also wonder, does the Patents section apply in New Zealand? They banned software patents at a central government level.

Maybe we need groups who can push to lobby for legislation to remove software patents in more countries?

[rothbardrand]

I think a good principle is to never assume malicious intent, but never tolerate an abusive position either.

So, Facebook, lets assume, isn't being malicious and genuinely feels this is the right approach to deal with what they consider to be "meritless" lawsuits... but at the same time, if this response-- genuine as it may be-- gives them abusive power, don't abide it.

Similar principle for politicians-- never support Obama/Trump having a power you wouldn't want Trump/Obama wielding.

For any aspect of power, assume the most abusive historical figure has it-- should they have it? IF not then don't grant it to even people you like.

[thecrazyone]

That would just lead to under-utilization (if that's the right phrase for it) of power.

At most situations you might be assigning improbable risks to things. If you have a reason to believe someone is not going to abuse power, then giving them said power should be okay in real life

Edit: May I add that you're swinging from one extreme to the other. Things need not be black/white. It's a fallacy all on its own

[logicallee]

>but this is just awful.

Everyone in this whole thread is saying the same thing. For anyone not up to speed, I found the following explanation of the issue (analysis of the license) very good and short:

https://www.elcaminolegal.com/single-post/2016/10/04/Faceboo...

This lets you know why we have 300+ comments saying the same thing.

[prewett]

> any developer contributing ... has a moral obligation to stop

Oh, come off it!

If you went to some company and got a patent license, and then proceeded to sue that company for patent infringement on an unrelated patent, they would terminate your license. (That's what cross licensing prevents.) So FB is granting React users a patent license free. Why wouldn't they revoke the license if you were suing them? There's no difference from the normal state of affairs except the patent license is free. Now, if you are worried about FB infringing on your patents, it's wisest not to use React, but that's no different than licensing a patent from someone else.

[stephenhuey]

I'm with you. Check out Aurelia which is under the MIT license:

http://aurelia.io/

I'm surprised at how many companies are willing to embrace frameworks that they believe come from Facebook and Google but are not truly backed by those companies. Aurelia has commercial backing and community contributors and a decent license.

[freewizard]

Any suggestion on an open source & high quality alternatives for a large existing code base depending on React?

[gedy]

Preact with preact-compat is (almost) a drop-in replacement for existing React code: https://preactjs.com/guide/switching-to-preact

[madeofpalk]

> We should be able to just use it, because it's open and that's what open means.

You can. What's stopping you?

[christophilus]

We need to start promoting a single great alternative. My vote is Preact.