Live data from Hacker News

Why I'm Not a React Native Developer

arielelkin.github.io

151–160 of 318 posts

Re: Why I'm Not a React Native Developer

#151
I'm the author of http://programmingreactnative.com, maintain the https://github.com/jondot/awesome-react-native list and built some other tools and libraries for React Native, along with a few apps.

Obviously the conclusion that follows is that I think React Native is going to be a revolution for mobile development. Not only will it succeed, it will get copied, and you'll have many variants of the same like-minded platform (open source, developer-oriented, low-barrier language).

Regarding the article, my point of view is that some points in this article are valid, but are trivially obvious:

- Javascript is Javascript, take it or leave it. Flow and Typescript is an evolution that to me looks good. It is one language that was adopted to be user-facing in React Native. According to Apple's Developer terms 3.3.2 and 3.3.3 only interpreted languages that run on JavascriptCore are allowed to be pushed to market.

- You can't know what the future holds. I was part of the Ruby community at the start, then Node, then Go. I was hard core into .NET, and before that Java. I saw platforms and technologies rise and fall, and was surprised over and over. I was much into Silverlight, a technology that Microsoft wanted to take over native development on the Web. Guess what happened to Silverlight? THAT was very nasty. We all know how that feels, but that's nothing to attribute just to React Native.

- Regarding patents: I believe we will have alternatives to React Native long-term, with the same properties but we'll still choose React Native :). However I also believe Facebook doesn't use patents in a bad way that the author hints at, as far as we know and as far as we've seen. I also met with core React Native developers, and they're awesome.

Practical advise: I'd suggest for the author to meet with the React Native core team.

Re: Why I'm Not a React Native Developer

#152
post #145
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."

If you are considering how to build a native app, reasons why you don't like Javascript are relevant.

You can build RN apps in ClojureScript and, voila: You rarely have to touch JS. Edit (it's not without its flaws though): https://youtu.be/6IYm34nDL64

Re: Why I'm Not a React Native Developer

#154
This article can probably be renamed to "why Javascript is bad"..only patents and dependencies issues were related to react native..the rest of the article was about how Javascript sucks..and I think developers are already equipped to take the call if they want to use js on a large project or not..

Re: Why I'm Not a React Native Developer

#156
post #113

Earlier quoted context omitted.

So like a messaging app?

Uh no. Your application can be completely shut down and push notifications will still arrive on the phone for Android, iOS, and Windows Phone. Once the app is open, you load the new bits of the conversation. Stuff in the background would be like video/audio calls, playing music, actively monitoring motion/gps (MapMyRun/Ride/Swim/etc), and a few other things that escape me at the moment.

On android at least, if you need to play music, couldn't you do that in a background service written Java and then have a UI written in RN that connects to that service?

Re: Why I'm Not a React Native Developer

#157
post #29
post #28

Earlier quoted context omitted.

The point of having isConnected in the state is that it will change depending on OS events. Random is just used as an example

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…

It didn't need to happen in componentDidMount with multiple calls to setState. If it's not getting info that it would only know after mounting, it could have happened in the same line that isConnected is initially defined within the constructor!

Re: Why I'm Not a React Native Developer

#158
post #44

I evaluated React Native for a project and decided to go with NativeScript instead for a number of reasons: 1. RN releases a new version every 2 weeks breaking my app every time. NS is a lot more conservative between releases. 2. I don't like mixing presentation and logic, RN encourages doing so, NS does not. 3. TypeScript is a first-class citizen in the NS environment, it is not in RN. 4. Angular 2 > React 5. NS cre…

I have been using RN from 0.19 onwards never broke my app a single time. React encourages thinking in components and component would be tightly coupled. I have many kitkat users on my beta app on playstore. For me reactjs is way simpler. Angualr seems like a jee framework.

Re: Why I'm Not a React Native Developer

#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.state.isConnected ? 'green' : 'red';

Re: Why I'm Not a React Native Developer

#160

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.

OP is not complaining about dynamic type -- the examples appear to show where 'type' doesn't apply at all.

The funniest/alarming example for me though was immutablility. The documentation exhorts the developer to take care not to make assignments to immutable objects. And there's your immutability: just don't change object and it will be immutable.

Post reply on HN