6 ms·
> This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. That's definitely not a fai
by Pfhreak 10y ago
> This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint.
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."
- pauljaworski 10y agoThat is a very fair characterization of the article - 70% of the article's content is about why JavaScript is bad.
- andrepd 10y agoWell, it is :)
- xpaqui 10y agoIt is but not due to `Type errors`, `Lack of function signature`, `Immutability`, `You can’t trust arrays`, `Unsafe initialisation`, `Optional curly braces after an if`.
- coldtea 10y ago70% of the content is not necessarily "the most important part of the content". 2 minutes in a 5 minute animation short are the credits.
- EdwardDiego 10y ago2 minutes isn't 70% of 5 minutes. It's only 40%. Yeah, nitpicking, I know.
- coldtea 10y agoGetting the exact percentage is not necessarily the most important part of an analogy.
- ulisesrmzroche 10y agoYou know theres no 5 minute animation shorts with 2 minute credits in existence.
- coldtea 10y agoIf you ever go to a short film festival, animation or not, you'd be surprised. Here's a 2:18 animation with 1:06 credits -- way more than the ratio I gave: https://www.youtube.com/watch?v=8ZRLlyxvr6E 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.
- threepipeproblm 10y agoThen 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 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.
- cloverich 10y agoYou should read @pluma's explanation of the patent grant. I think its purely a misconception that's unfortunately been regularly repeated. > 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.
- threepipeproblm 10y agoNot sure I follow your orange juice / motor oil rebuttal but I'm going to focus on the more substantive portion of this interchange... 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.
- cloverich 10y agoI definitely glossed over the patent issue a bit and appreciate the comment. > 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.
- hiou 10y agoThis is definitely a specialist feeling the discomfort of not yet becoming a polyglot. Had a CTO like that once.
- nkozyra 10y agoThe author seems to express a deep enough understanding of Javascript to not warrant this dismissive critique. 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.
- deleted 10y ago[deleted]
- paulftw 10y agoAuthor seems to express a deep understanding of JS quirks and outlines specific places (often rare corner cases) that'd trip a JS beginner.
- tracker1 10y agoTrue, but he also dismisses build chain or cross-compile solutions in favor of a solution that requires a build chain and compile.
- pekk 10y agoIf you are considering how to build a native app, reasons why you don't like Javascript are relevant.
- vikeri 10y agoYou can build RN apps in ClojureScript and, voila: You rarely have to touch JS. Edit (it's not without its flaws though): https://youtu.be/6IYm34nDL64 https://youtu.be/6IYm34nDL64
- crimsonalucard 10y agoDid you read the article? Compiling to JS is an issue that is addressed.
- deleted 10y ago[deleted]
- iron_ball 10y agoOnly barely; he includes it as the middle of a chain of hacks that highlight, not remedy, the deficiencies of Javascript.
- tracker1 10y agoI will not eat green eggs and ham!
- vikeri 10y agoYes, but I was addressing the issue of writing JavaScript, not using its ecosystem. And the lack of a high quality standard library is elegantly solved in ClojureScript by using the Google Closure library.
- vikeri 10y agoYes, but I was addressing the issue of writing JavaScript, not using its ecosystem. And the lack of a high quality standard library is elegantly solved in ClojureScript by using the Google Closure library.
- pluma 10y agoThe "concerns about patent usage" is a tired trope as well. 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.
- michel-slm 10y agoThe patent retaliation is more broad than the provision in the Apache license though, which basically only revoke the patent grants for a specific work if you sue over patent infringement in the same work. http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0 http://en.swpat.org/wiki/Patent_clauses_in_software_licences...
- pluma 10y agoYes, I actually wrote a paragraph on Apache/GPL/MPL patent grants which I deleted before submitting because it's really not relevant to the argument. 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.
- tracker1 10y agoWRT the Patent concern, you'd be hard pressed to find ANY open-source tool from a large company that doesn't have similar provisions, including Swift's Apache license itself... 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.