Why I'm Not a React Native Developer

Post by andrewmcwatters » Wed, Sep 28, 2016, 7:46 PM UTC

strugglefun wrote: post #217

franciscop wrote: post #159

Please what kind of programmer would ever do this? if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } That is just verbose unnecessarily: this.setState({ isConnected: weAreConnected }); And probably not so popular, but this: var color; if (this.state.isConnected) { color = 'green' } else { color = 'red' } Would be simplified often to: var color = this.…

> Please what kind of programmer would ever do this? Someone with an interesting development development history (maybe C?), with little grasp of the idioms of newer coding styles.

Post by SomeCallMeTim » Wed, Sep 28, 2016, 8:09 PM UTC

kowdermeister wrote: post #182

SomeCallMeTim wrote: post #31

Earlier quoted context omitted.

TypeScript is a JavaScript best practice at this point. It's a type safety net on top of dynamic types, so you get the best of both worlds. TypeScript has a flag that prohibits switch fallthrough, for instance, though that's an easy one to set up a linter to catch. One reason I prefer NativeScript to React Native; they are embracing TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but that I fr…

If you are not building large applications then TS is counter productive. Just consider the extra compilation step, the dependencies and obfuscated source code. While it can be tremendous help, calling it a best practice misses the point.

Post by SomeCallMeTim » Wed, Sep 28, 2016, 8:15 PM UTC

wvenable wrote: post #136

kuschku wrote: post #70

Earlier quoted context omitted.

For what purpose is dynamic typing ever useful except "it’s faster to develop"? With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.

Unless you are doing Java, I would even take issue with the argument that dynamic typing is faster to develop. It's taken as obvious fact but I don't think we should just take that as face value. Getting as-you-type feedback, intellisense, and simple documentation (methods, parameters, types) is hugely productive. As well as the ability to break things and know you've caught all the breaks. I would say that a very fa…

Post by caub » Wed, Sep 28, 2016, 8:42 PM UTC

StyloBill wrote: post #250

caub wrote: post #204

var a = 0; var b = -0; console.log(a === b) // true console.log(1/a === 1/b) // false That's perfect math you mean, of course -Infinity != Infinity, what did you expect? I think you should rather think harder, learn math possibly, and your 'safety' problems with arrays are not problems at all, it's the opposite for other people

> I think you should rather think harder, learn math possibly Oh the irony, when stating that 1/0 = infinity. If you'd learn maths yourself, you'd know that 1/0 is undefined.

Post by aurelianito » Wed, Sep 28, 2016, 10:21 PM UTC

tempodox wrote: post #176

qwertyuiop924 wrote: post #60

Earlier quoted context omitted.

Besides, while JS's problems are very real, they're quite exaggerated. It's still a perfectly usable language, even without TS and whatnot. And unlike some languages used for app programming, an error doesn't have the potential to hand you a segfault.

> ...an error doesn't have the potential to hand you a segfault. And that is a good thing why? So you don't realise there was an error and your app runs on in a corrupted state?