Live data from Hacker News

Why I'm Not a React Native Developer

arielelkin.github.io

221–230 of 318 posts

Re: Why I'm Not a React Native Developer

#221
post #21

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. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

The anti JavaScript ranting is tedious and redundant, however he points out that virtually no React Native code uses Flow, etc., so it's an unused solution. The point about React having hundreds of dependencies is also well taken.

While I'm at it, I find the graphs towards the end claiming, for example, that using Xamarin (or Appcelerator) is more productive than React Native, or implying Swift is barely shy of perfectly safe to stretch credulity.

Finally, Javascript's "slow" state of development is a feature as well as a weakness, just as Swift's rapid pace of development is both a weakness and a feature. React itself progresses at a breakneck pace.

Re: Why I'm Not a React Native Developer

#222
post #209

Earlier quoted context omitted.

>it makes other technologies no longer relevant in this domain Are you really trying to say that React Native makes Java not relevant for Android and ObjectiveC/Swift not relevant on iOS. Maybe you are correct if you want to build Hello World application, when you will be needing something more optimized sooner or later you'll have to rewrite it in Java/Swift.

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.

Re: Why I'm Not a React Native Developer

#223
post #21

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. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

The anti JavaScript ranting is tedious and redundant, however he points out that virtually no React Native code uses Flow, etc., so it's an unused solution. The point about React having hundreds of dependencies is also well taken. While I'm at it, I find the graphs towards the end claiming, for example, that using Xamarin (or Appcelerator) is more productive than React Native, or implying Swift is barely shy of perfe…

I actually find it ludicrous the author is complaining about JS's development as a language being too slow. Just the other day I presented ES2015/2016 and the upcoming changes scheduled for 2017 to a room full of JavaScript developers and the general feedback was that JS was changing too quickly.

The reason ES2015 was so huge and so delayed was actually that ES5 was pretty much the lowest common denominator everyone was able to agree on after the proposals for ES4 went up in flames. ES5 is necessarily incremental and ES2015's delay was mostly caused by the repercussions of ES4's failure -- ES4 failed because it valued innovation over backwards compatibility.

I mean TC39 has announced that they will make a new release every year, batching whatever proposals are stable at that point. How can anyone call that particularly "slow" with a straight face?

Re: Why I'm Not a React Native Developer

#224
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'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.

Re: Why I'm Not a React Native Developer

#226
post #61

Earlier quoted context omitted.

> 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."

That is a very fair characterization of the article - 70% of the article's content is about why JavaScript is bad.

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 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.

Re: Why I'm Not a React Native Developer

#227

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.…

Before 1900 Frege pointed out that we don't need to say, "The sea is salty is true"; we can just say "The sea is salty". A century later it still hasn't sunk in.

Re: Why I'm Not a React Native Developer

#228
post #61
post #21

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. He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple! Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49): class Root extends Component { rende…

> 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."

The "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.

Re: Why I'm Not a React Native Developer

#229

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?"

I've seen some coding rules/guides that explicitly forbid short form of 'if' statement usage.

Re: Why I'm Not a React Native Developer

#230
post #14

Earlier quoted context omitted.

I feel like this is some sort of signaling, a la 'no true programmer uses javascript, because types!'.

Well then, if no true programmer likes dynamically typed languages, I'd better make some calls... Hey, RMS, Abelson, Sussman, Steele, Guido, Larry, Matz, Richard Gabriel, ESR, DHH, Flatt, and Felleisen, it turns out you're not true programmers! Okay, cool. Needless to say, I claim No True Scottsman.

Lisp, though, does have types.
Post reply on HN