Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Not a React Native Developer

arielelkin.github.io

Post reply on HN
Print view View original

111–120 of 318 posts

Re: Why I'm Not a React Native Developer

#111

Post by ziziyO »

macspoofing wrote: post #97
weixiyen wrote: post #75

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?

Anything where you need to stay alive in the background and periodically do something.

Re: Why I'm Not a React Native Developer

#112

Post by DenisM »

pzh wrote: post #92
steego wrote: post #25

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.

Speaking of Xamarin.

RN supports iOS, Windows, and Android. Plus RN is somewhat close to React, so some code could be reused between the two. Plus you get out-of-band code updates!

Xamarin supports iOS, Windows, and Android. But there is no web story. Or is there?

Re: Why I'm Not a React Native Developer

#115

Post by skewart »

STRML wrote: 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…

> it's a quirky language

From the blog post:

> JavaScript’s deficiencies seem to impress everyone except JavaScript developers, for whom the aspects of JavaScript that I outlined above are not awful warts, they’re “quirks” or “gotchas” that you, not your language, have to be on the lookout for.

I think his point is that calling JS "quirky" makes it sound benign, or even cute. However, JS's quirks are actually serious shortcomings compared to other languages.

For native iOS and Android developers React Native has a huge intrinsic appeal, for all the reasons he outlined at the start of the post. It's really tempting. Plus, the enthusiasm and scale of the JS community can sometimes ovrshadow concerns non-JS devs have about the language.

To me the post seems helpful. From my experience React Native will certainly not be all puppies and roses for people coming from Java, Swift or Obj-C.

Re: Why I'm Not a React Native Developer

#116

Post by eyelidlessness »

overgard wrote: post #109
evgen wrote: post #84

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.

Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with…

> you can write assertions on a type in a dynamic language

You can, but you can't get any guarantee that said assertion will never fail.

Re: Why I'm Not a React Native Developer

#117

Post by Bahamut »

overgard wrote: post #109
evgen wrote: post #84

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.

Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with…

Writing assertions has a runtime cost that isn't present when using something like TypeScript.

Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.

Re: Why I'm Not a React Native Developer

#118

Post by dwaltrip »

_xhok wrote: post #88

As someone who loves React, the hardest thing about it for me is debugging. I'll get some error about how renderComponent doesn't accept null values or whatever, and when even the outermost error is so cryptic, the stack trace is even less helpful. Is there a conventional solution to this I'm not aware of?

When the stack trace is inscrutable, I find binary search debugging to be helpful. Comment out half of the functionality, see if the error is still there. Narrow the search to the half that is causing the problem, rinse, and repeat until the offending line of code is found.

However, if the error occurs inconsistently, this approach can be much harder to use.

Re: Why I'm Not a React Native Developer

#119

Post by darkmarmot »

_xhok wrote: post #88

As someone who loves React, the hardest thing about it for me is debugging. I'll get some error about how renderComponent doesn't accept null values or whatever, and when even the outermost error is so cryptic, the stack trace is even less helpful. Is there a conventional solution to this I'm not aware of?

As someone who uses a different component-based js framework, can you not just put a breakpoint in the chrome dev tools on the renderComponent method for that component?

Re: Why I'm Not a React Native Developer

#120

Post by hiou »

Pfhreak wrote: post #61
STRML wrote: 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."

This is definitely a specialist feeling the discomfort of not yet becoming a polyglot. Had a CTO like that once.
Post reply on HN