That's definitely not a fair characterization of this article.
Concerns about roadmap and patent usage show up before any concerns about JS.
Edit: Though I agree, a strangely large amount of the article is dedicated to "Why I just don't like Javascript."
Yes, if you use React you're basically agreeing not to sue Facebook over patents. Except if Facebook was acting in bad faith they'd probably have enough patents you could be found in violation of to ruin you anyway. If your software is non-trivial, it's already violating patents you probably never even heard of.
But the real kicker is that if you're not using React you're probably already using open source software. And in the JS ecosystem that probably means you're using software under MIT, BSD and ISC licenses, which have no patent provisions whatsoever.
Fun fact: AngularJS uses the MIT license and does NOT contain a patent grant whatsoever. If you use AngularJS, Google can sue you over any patents it holds that are relevant to AngularJS -- they don't even have to wait until you sue them first.
Ember? Same thing (MIT license without patent grant).
jQuery? Although it was dual-licensed as MIT/GPL at some point it's now only MIT-licensed and again contains no patent grant.
In other words: unless you have an explicit patent grant, you're at risk of being sued by the owners of whatever patents you happen to be infringing upon. The only difference is that you're entirely reliant upon the goodwill of the patent owners while React explicitly shields you unless you sue Facebook over patents.
http://en.swpat.org/wiki/Patent_clauses_in_software_licences...
React, like most JS projects, is licensed under an MIT/BSD style license (they're too similar to be worth the distinction in this context).
The alternative to having the FB patent grant wouldn't be to have the Apache 2.0 patent grant. It would be having no patent grant, as is the case with AngularJS, Ember and jQuery.
Which is completely beside the most important point: if you don't use React, you might be still affected by React-related patents owned by Facebook and there's no patent grant preventing them from suing you -- and this holds true for all patents owned by everybody else.
The default for JS projects is no patent grant. FB is actually more benign than any of the alternatives by providing a patent grant at all.
Not only is the argument entirely theoretical (If FB doesn't sue you over React patents, they might still sue you over non-React patents or someone else might sue you over React patents FB doesn't hold) but it's also invalid (FB doesn't benefit from offering a patent grant compared to not offering a patent grant -- which would have been the default for open source projects like React).
If you just want to argue that FB could have done more, yes of course they could have. But that's like shouting at someone giving you a free penny why they don't give you a free dollar.
The problem is the startup I work for relies on patents for a big part. And if we use any Facebook stuff, which I actually wanted to do as the main developer (react and react-native), they can use our stuff without caring about our patents! Because we can't sue them!
So basically, with that license Facebook on the one hand protects itself against patent trolls. Good, fine.
On the other hand though they grant themselves the right to use any patent of any company that uses their products, because you can't sue them any more! No? That's how I read it after having read a lot of discussions, none of which talk about that major issue, because for most people in this discussion defending their own patent(s) against Facebook is not an issue, so the discussion is very heavily one-sided towards people who don't have that problem.
If FB has patents that cover parts of React, the same patents also cover similar parts in other projects, including your own.
By using React you prevent FB from using those patents against you within the project in which you use React instead of your own analogous code.
They can enforce their patents against you if you infringe on them in your code. They can't enforce their patents against you if you infringe on them by using React.
This is a protection you only get by using React. And it's the only thing that changes if you sue them over patents.
The only difference is that if you don't use React, depending on the exact patents, they might not be able to determine you are infringing on their patents without looking at your code (whereas if you use React they know which of their patents cover React).
But as I said, this "drawback" really pales in comparison to the very real risk of infringing on patents without even using React in the first place. Facebook might hold the patent for some ubiquitous aspect of your application and they could still sue you over that if they want to at any moment.
That said, if you run a software company and intend to sue Facebook over patents, you better believe that they have an arsenal that can take you off the market for good if they want to.
Besides, why would you want to use open source software created, maintained and sponsored by a company you're planning to sue?
2 minutes in a 5 minute animation short are the credits.
Here's a 2:18 animation with 1:06 credits -- way more than the ratio I gave: https://www.youtube.com/watch?v=8ZRLlyxvr6E
Credits --crew members, voice talent, sponsors, thanks, etc-- can rise almost linearly with the length of an animation, and even more so with increases in its production value.
A 5 minute short can have almost the same team size as a feature animation (which requires > 2 minute credits). The fact that they'll be employed for shorter time doesn't mean they don't get their names on the credits.
I sure am glad to know about the patent considerations in this simple criticism in this JavaScript, as I've decided not to use React because of them.
> Then why don't you drink this glass of 70% orange juice and 30% motor oil, since by your definition it's "simply orange juice".
I think a more proper correlation of your analogy vs OP's argument would be if you held it up and claims "why I won't be putting this motor oil into my car" and OP pointed out "that's because it contains mostly orange juice." Its intended to be an article about the con's of React Native, but is mostly an article about the cons of Javascript. Its a very well written article and (imho) its best parts are the concerns of long-term development of an entirely distinct ecosystem.
It's purely a misconception in the same way that 30% motor oil is pure orange juice -- which is to say, it's not a misconception, by my reading. I wonder what my IP laywer would say about it, will post if I decide to ask.
Unless I am looking at the wrong comment, @pluma's explanation is just that it's not a problem as long as you don't sue Facebook. But this is equivalent to saying that as long as you give up your only recourse in the event FB violates your IP, you'll be fine. To me it seems like a mentality that makes sense primarily if a person doesn't ever expect to do anything worth patenting, or doesn't ever plan on patenting for some other reason. Don't sell yourself short.
> doesn't ever plan on patenting for some other reason
I personally don't believe patents, outside of a few very special circumstances, should be allowed to exist. The idea that Facebook could copy one of my ideas and out-compete me based on their size is, imho, a perfectly reasonable thing for them to do. That being said, the current environment seems to demand that one patent any and everything they can as a pre-emptive defense. Hmm.
As to the roadmap, it's open-source with a vibrant community, if FB steps down, people in the community can fork, step up and continue maintaining... That's the whole reason behind open-source is that you can continue it.
Also, re: your edit.. yeah, far too much... yes JS has oddities, but the null reference issue is present in most OO languages, not to mention a lot of the other issues are well known and/or present in a lot of other languages as well.
Most JS specific oddities can be warned against with linters, and you can use TS/flow if you really want type checking at build.
It's not like he's saying "Javascript sucks," he's outlining specific places where it can cause issues in development compared to the alternative.