251–260 of 318 posts
Earlier quoted context omitted.
I feel like this is some sort of signaling, a la 'no true programmer uses javascript, because types!'.
We all use it, but 'no true programmer likes javascript.' :)
Earlier quoted context omitted.
I'm not sure that's right. 1/0 is undefined NOT infinity, hence -1/0 is also undefined . So actually line 3 should evaluate as true.
NaN === NaN evaluates to false. That’s what happens here, not anything with Infinity.
A lot of people here seem to criticize the OP's POV on javascript, but my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems. I am a javascript programmer AND an iOS programmer. I work with React to build web apps at work. And lately I have played around with react native, but I felt uneasy jumping ship to use solely react native for the very…
Similarly, Flow/Purescript/Elm have every ability to provide a safe interface to javascript.
Earlier quoted context omitted.
You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.
It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand. I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]). The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeC…
Earlier quoted context omitted.
Do you have any specific example where Java or ObjectiveC/Swift would be of better use?
Anything that requires some kind of processing like, for example facebooks own Instagram.
Earlier quoted context omitted.
I prefer statically-typed languages too, but this is easily solved by using something TypeScript or Flow.
Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. JS has its uses, but it's difficult to debug, doesn't take advantage of all the advances in modern languages design that help prevent whole classes of bugs, and carries a lot of baggage. The only benefit would be universal app development, but even then Xamarin seems like a better choice.
Because targetting javascript has a lot of advantages, being cross platform is a major one of them. You basically get the type-safety of swift, with the ability to target multiple platforms.
The fact that it transpiles to JS is irrelevant, you can provide a safe interface to something unsafe. Take Elm for example, it transpiles to JS and yet guarantees that you will never produce a runtime exception.
Earlier quoted context omitted.
You mean unlike every company that is behind any other project you are relying on that doesn't come with an explicit patent grant? In other words you have no MIT or BSD licensed dependencies, or in fact no open source dependencies that don't either come with an explicit non-revocable patent grant and aren't licensed under Apache 2.0, GPLv3 or MPL 2.0 (all of which by the way still terminate the patent grant if you su…
True, but it give Facebook more legal leverage over you, arguably, and Facebook is more likely to abuse that power than a loose collection of open-source programmers, or a smaller, less wealthy company that doesn't have its tendrils everywhere.
The MIT license, the BSD licenses, and so on, don't contain a patent grant. Only the Apache 2.0, GPLv3 and MPL 2 licenses do.
If you use an open source project which doesn't come with a patent grant, you can be sued for patent infringement over that project.
Facebook's patent grant prohibits Facebook from suing you over patent infringement for using React, except if you sue them over patents first.
So nothing in your stance is specific to Facebook. If you use AngularJS, Google can sue you over any patents used in AngularJS.
Facebook's patent grant acts as a kind of "no first strike" policy they have to obey for React-related patents: they can't sue you over React-related patents unless you sue them first.
Yes, Facebook can still sue you over other patents. Everybody can do this, even if you don't use their software.
Is Facebook's patent grant as permissive as those in the Apache 2.0, MPL 2.0 and GPLv3 licenses? No -- these only allow retaliation if you sue over the projects the licenses cover specifically.
But the patent grant is considerably better than not having a patent grant. If React is covered by patents (nothing in the grant requires Facebook to actually own any relevant patents), it's extremely likely similar libraries are just as likely to be covered by them (without a patent grant from Facebook) and open you up for liability.
Patents are not specific to software. If something React does is covered by a patent and another project also does it, that's still covered by the patent even if the code isn't from React, even if the author wasn't even aware of React doing it and never heard of the patent.
So, yes, if you exclusively use GPLv3/Apache 2.0/MPL 2 licensed projects, you're safe -- except for all the other patents you might be infringing on that aren't owned by the maintainers (and that the maintainers therefore can't give you a patent grant for).
But there is no scenario whatsoever where using React opens you up to more patent woes than using an alternative implementation -- or a comparable project (like AngularJS, Ember, etc) that doesn't come with a patent grant.
If you're concerned about React, be concerned about AngularJS first. Because if you use AngularJS, Google can sue you over patents without having to wait for you to sue them first.
Earlier quoted context omitted.
The context of this entire thread was about mobile ecosystem. The concept of "cross platform" only holds when you're comparing two similar ones
the whole premise (that i m sold on react-native) is that it lets you use code from your react app and run it natively. And the concept of cross-platform is not only for "similar" platforms like mobile, but across disparate platforms, like mobile AND PC. Otherwise, what's the point of cross-platform?
Earlier quoted context omitted.
For example: You make something remotely similar to Instagram and it takes off. FB sues you and takes all your reacts and natives from you. You left with nothing.
Or FB sues you over literally any patent you happen to be infringing. They're a big company, I'm sure their patent war chest has a few zingers for cases like these. Oh, and your scenario only works if you sue FB/Instagram over your patents first. They can't revoke the patent grant willy-nilly except in retaliation.
It's software patents you should be worried about, not open source projects that try to offer you even the tiniest amount of protection from them.