tl;dr The BSD + PATENTS.md pattern is not F/OSS. Facebook is trying to goad you into entering a mutually assured destruction patent stalemate, but you don’t have nukes. They do. Stop using React, there are other better alternatives.
Before you get into my thoughts, maybe you’ll want to look at some other debate from other strangers on the internet: Discussion of Facebook’s explanation on HN Discussion on Apache Foundation banning use of React on Reddit
We’re departing from our regularly scheduled programming, but in light of the recent news of Facebook has refused to remove the patent implications from react, Facebook posted an explanation of why they chose the BSD + PATENTS.md approach to their licensing, I thought it was important to get my opinion on this out there as a developer, into the sea of internet opinions from other strangers you don’t know. The Apache Foundation has banned use of React in it’s projects.
As you should with any stranger’s blog post on the internet, take this one with a grain of salt. Here’s why
I’ve never been a huge supporter of React, I think the tech is cool, solid, and though they weren’t the first to use virtual dom, they were probably the first to bring it to the mainstream. I do think they were the first to build/popularize a project that does what React Native does, and for that I’m grateful.
I’m not a lawyer. I don’t believe you have to be to understand the implications of their additions, and here’s why: the uncontested truth of the PATENTS.md file addition is that if you sue Facebook for patent infringement, you lose to the right to use React. This means if you patent an idea (patents are broken in the first place, but I won’t get into that here), and Facebook sees fit to copy it, and you sue them, you must rewrite your frontend, and stop using React.
According to Facebook/people who still want to use React, this is supposed to create a Mutually Assued Destruction kind of atmosphere and prevent spurrious litigation. In theory it would do that, but there are problems, and because of those problems, I’m never using React again or contributing to any project (I don’t contribute much at present so that’s not a real loss for anyone) that uses it.
I’ll start with my own technical findings when using/watching beginners use React, then go into the legal issues I see with their explanation.
The technical case
1. React suffers from lots of accidental complexity
The IDEA behind react is simple (and react is not the first place it’s come up), but Facebook has taken that simple idea and needlessly exposed many of those complexities to you. There are cleaner, simpler ways to do it.
Also, if anyone has any examples of a react codebase that aren’t using JSX, let me know. JSX isn’t bad in and of itself, if you’re ready to take on that complexity, but it’s presented disingenuously in the react documentation as an option when it’s just about a requirement. Quite a while ago, React removed the in-browser JSX compiler they offered from React. While it’s true that this functionality is provided by Babel (which is what they suggest you use), that is a beginner-hostile move.
2. React is hard to set up and use
3. React goes against many of the norms of HTML/CSS/JS frontend development without offering proper fully-baked alternatives
Sometimes the way it’s been done up until now is not the right way forward. But tell me this, what’s the right way to style React components? If you’ve ever tried to navigate that minefield this point will make sense. If you haven’t, sorry this might ring a little hollow for you.
The legal case
The BSD + PATENTS.md approach that Facebook has created is supposed to create a MAD stalemate that prevents spurrious lawsuits but this doesn’t hold up when you consider using two facts:
1. Facebook is known for replicating ideas of competitors and using their massive scale to crush your product
If you are looking for cases/proof, Google it, the web is littered with startups that claim that Facebook stole their idea. I don’t particularly believe that ideas can be “stolen”, but if they can, Facebook does it a bunch. If you were too lazy to google it, here’s the WSJ writing about it. BTW, I searched reddit to try and find where their discussion of this was, and all I put in was “facebook explanation”, and got some pretty alarming results.
2. If your company has less money in the bank than Facebook, you could never sue Facebook for patent abuse.
Yahoo tried once, and look how it turned out. You better believe that’s not how Yahoo wanted it to end. They just couldn’t beat Facebook, because Facebook bought up 750 (!!) patents to defend itself.
MAD only works if EVERYONE has nukes. Regular F/OSS devs with no affiliated corporation have super soakers. Small to mid-size corporations have aks, large corporations have maybe an army, navy and an airforce. Mega corporations like Google and Facebook have all that, and nukes.
React is obviously a pretty good piece of tech. If I’m telling you not to use it, and you’re entertaining the idea, I would be remiss in not at least suggesting some other solutions.
Component-based UI libraries
In my experience, the best part of React has less to do with the specific technology of React itself, and more to do with the popularization of small tools that do one thing well (AKA, some small bit of the UNIX philosophy). In this case, React does managing UI views/components well. There are other libraries that can do that for you, with less complexity, albeit less developer man-hours invested:
Vue.JS - I’ve used it extensively, and it’s pretty awesome. The guide is well written.
Preact - If you’re looking for something very very similar to react’s API, check this out. It’s MIT licensed, and that’s that.
Knockout.JS - You don’t even have to use components with Knockout. Use it however you like – it’s a great fit for server-side rendered app environments where you don’t have time to try and figure out how you’re supposed to integrate your backend with react/whatever else. Just drop some reactive stuff on the server side-rendered page, add a script tag with
ko.applyBindings() at the end, and you’re off to the races. Also has EXCELLENT documentation.
Mithril.JS - I haven’t used Mithril.JS extensively, but my thinking on it is just look at how small it is. I’ve read through the documentation numerous times, and it’s just too small, simple and straightforward to hide a complexity timebomb. It’s as simple as that. I’m planning a rewrite of my surprisingly popular (considering I haven’t touched it in years) CASGO project, and I’m going to use Mithril to do it.
Close-to-native Mobile development