Live data from Hacker News

Why I'm Not a React Native Developer

arielelkin.github.io

91–100 of 318 posts

Re: Why I'm Not a React Native Developer

#91

The legal concerns are legitimate, but frankly, I am unconvinced by the criticisms of JavaScript: There are well-known, well-designed tools like ESLint, and if you like types, Flow and TypeScript, which can mitigate the issues. That's more than you can say about Java (COBOL 2.0, now with a bevy of cargo-cult OO that makes things more overly complex), or Objective-C (All the safety of C, with similar OO problems, and…

Some of us happen to think that no GC is a good thing, in Obj-C's case. Swift eschews it as well.

Manual memory management: It's all fun and games until OOM errors come knocking, or- Segmentation Fault: Core Dumped.

I rest my case. There's a place for manual memory management. It's not in application code.

Re: Why I'm Not a React Native Developer

#92
post #25

Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible. Same with switch fallthrough, same with error handling, same with half his issues with JS. There are some legitimate grievances tucked in there, but the author lost me by pretending that his preferences were universal.

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.

Re: Why I'm Not a React Native Developer

#94
post #80
post #42

Earlier quoted context omitted.

Exactly. Flow even has tagged unions now, and `maybe` types. TypeScript is also a very mature solution to this problem. A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available. In this case, I half agree, because I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must…

"A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available." Right. And JavaScript is not that language, unless you are doing web stuff.

> Right. And JavaScript is not that language, unless you are doing web stuff.

Do I hear an echo in here?

"I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must."

Re: Why I'm Not a React Native Developer

#95
post #29

Earlier quoted context omitted.

Even with state, his code is overly verbose and can be expressed in a much more idiomatic way. var weAreConnected = Math.floor(Math.random() * 10) > 5; if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } } turns into var weAreConnected = Math.floor(Math.random() * 10) > 5; this.setState({ isConnected: weAreConnected }); It's almost like he wrote it in t…

"overly verbose" might be giving too much credit... it's bad code

No. 'Verbose' is correct. It's not bad code. It's a simple control flow.

Re: Why I'm Not a React Native Developer

#96

Earlier quoted context omitted.

Some of us happen to think that no GC is a good thing, in Obj-C's case. Swift eschews it as well.

Manual memory management: It's all fun and games until OOM errors come knocking, or- Segmentation Fault: Core Dumped. I rest my case. There's a place for manual memory management. It's not in application code.

Not necessarily. Swift uses ARC by default, and you'd really have to go out of your way to do any manual memory management.

Re: Why I'm Not a React Native Developer

#97

Reasons why I am a React-Native developer: - It works, really well. - Iteration speed alone has helped us retain at an extremely high DAU/MAU ratio compared to years past. - Both my apps have near 5 star rating across the board, probably the highest rated in the Sports category since we released, and none of our users notice that it is a RN app, which is really surprising b/c RN on Android is not up to par with iOS.…

>React-Native is not for every scenario

What scenario isn't it for?

Re: Why I'm Not a React Native Developer

#98
post #72

Earlier quoted context omitted.

Because it gives Facebook legal leverage over your company.

How, exactly? My company doesn't have any patents; what legal leverage does Facebook have over us? (Trick question, the answer is "zero".)

Maybe if your company's very small, but if your company is large enough, you almost certainly will have patents.

Re: Why I'm Not a React Native Developer

#99
post #96

Earlier quoted context omitted.

Manual memory management: It's all fun and games until OOM errors come knocking, or- Segmentation Fault: Core Dumped. I rest my case. There's a place for manual memory management. It's not in application code.

Not necessarily. Swift uses ARC by default, and you'd really have to go out of your way to do any manual memory management.

Ah. I originally talking about Objective-C, so I assumed that we were talking about manual memory management.

Of course, ARC has its own problems... Hope anybody implementing graphs knows what they're doing, or you'll leak memory like Niagra Falls.

Re: Why I'm Not a React Native Developer

#100

Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible. Same with switch fallthrough, same with error handling, same with half his issues with JS. There are some legitimate grievances tucked in there, but the author lost me by pretending that his preferences were universal.

I have learned, from experience[†], that strongly and statically typed languages, and in general languages with rich type systems almost always result in fewer common bugs, and higher quality code.

I strongly believe statically typed language are objectively superior to dynamically typed ones. Many might say that this is my subjective opinion or just a matter of personal preference, but I absolutely disagree.

[†] (a bit of) my experience explained here: https://news.ycombinator.com/item?id=12594616

Post reply on HN