Ask HN: Why was React Native recommended to me? Not seeing benefits | Hacker News Reader

Ask HN: Why was React Native recommended to me? Not seeing benefits

48 pointsmkirklions59 comments

Ive programmed in 8+ languages, and up to this point Javascript was unused.

It was recommended to use javascript and react/react native so I only needed to program once.

However, seeing the differences between react and react native, this seems overstated.

What were the other benefits? I thought there was already built components/libraries I could drop in for data management. Maybe its bad googling, but I feel like react-native is like any other app I'm building from scratch.

Looking for any recommendations to get a intermediate programmer going?

View on HN

React Native likley has a productivity benefit for simpler interfaces -- the framework is less complex and it's faster to get started. By contrast, iOS frameworks are very powerful and enable you to do a lot more.

However, a lot of this catches up to you.

1) iOS/Android already have very sophisticated and powerful MVC layers, which is what React brings to the web.

2) React Native is not performant and it's hard to solve these performance problems. I've heard a lot of people say this doesn't matter, but I've noticed this is usually said by those who are doing mobile apps for the first time coming from the desktop/browser world where problems can be hidden easier. On mobile you have no such affordances and performance issues are a bigger big deal. Funny enough, React Native would actually perform better (e.g. with scrolling) if it used a shadow view layer like its web counterpart uses. Check out https://texturegroup.org/ for an example of how this would work.

Android's "MVC" layer is a joke, and not a very funny one. An argument for React Native, at least as a replacement for native Android, is that it lets you circumvent the nightmare that is Google's Android SDK and toolchain. Javascript and React+Redux is, arguably, it's own special little nightmare too, but still better than the alternative, especially if used with TypeScript.

you can build MVP, MVVM, MVI, or whatever other arch on top of the Android framework, you don't need to bring react to do that.

The pitch internally at Facebook for React Native wasn't that UI code could be written once and used everywhere. Instead, their goal was to let engineers move between web, iOS, and Android development without retraining. This lets them have one photos team, for example, that is responsible for the photos portion of the product across all supported platforms.

I remember a catchphrase/motto of "learn once, write anywhere"

So basically “lowest common denominator” is their development strategy? The Facebook app is one of the worst on my iPhone. It lags, it sucks power.. I would expect that if the people that invented React “native” can’t make it similarly as performant as real native, then random developers out in the wild aren’t going to do much better — this an ecosystem of iPhone apps that suck simply because they were designed for the worst possible Android phone.

React Native is a godsend to tiny startups, but for companies that can actually afford to hire teams.. it’s an insult to the user to use React “native” and pretend that the app is any good. I own an iPhone because of the features of an iPhone, but companies like Facebook want to handicap my experience because someone’s low-end Android can’t keep up?

Facebook has always sucked at mobile. First they insisted on phonegap-style bullshit, now React “native.” Do they not have the budget to actually hire real Swift or Java/Android developers? I am not sure why “mobile” is considered a platform — perhaps they should instead develop for actual iOS and Android rather than treating those two different OSes and experiences as identical. Android and iOS users would likely be much happier.

For the record, most of Facebook’s app is not currently built in React Native so please don’t use it to judge RN. I could go into why FB app quality ends up low but don’t think it’s that relevant to this discussion.

And FWIW Facebook probably employs over a thousand iOS and Android developers. It’s not a “budget” thing for us.

> Ive programmed in 8+ languages, and up to this point Javascript was unused.

This tells me you haven't built for the web yet. (unless I'm totally misunderstanding what you're saying) React Native extends web paradigms to mobile, so if the web isn't where your experience lies, you'll likely be more comfortable with a traditional native language like Swift/Java.

That’s interesting, I always thought that React brought a little bit of the desktop experience to the web since you can create components that are fairly self-contained. Of course, as you said, the opposite is also true since you’re using JavaScript.

To me the biggest benefit is that you write your code once though. Especially with a React based kit like Expo.

It sounds like you're new to both React Native and the JavaScript ecosystem. I can imagine this being very frustrating for someone regardless of their general programming chops. I happen to be on a React Native project at work right now. Hopefully I can provide a viewpoint that is helpful and give direct answers to some of your questions.

One thing that would be helpful to understand that's missing from the OP, what are you building?

> However, seeing the differences between react and react native, this seems overstated.

I'm actually not sure which specific differences you're referring to. Perhaps you can clarify?

> It was recommended to use javascript and react/react native so I only needed to program once.

It's possible to use RN to build an application which runs on both Android and iOS from a single code base. This is possible with a few other environments but none are (IMO) quite as good at affording for a truly native look and feel including dropping down into native code when necessary.

Building a really great app is still a grind on execution and perfecting small details is a chore. The standards of quality in the mobile app world are high which leads to average users having higher standards than they might with desktop or web applications.

> What were the other benefits?

For people who enjoy working in JavaScript, the fact that you can write native applications using mostly JS is a benefit.

Some products benefit from being able to share code between a web product and a RN application is a big boost in productivity. I've personally saved hundreds of hours leveraging this. It's not a 1:1 swap but it's close enough to lower the mental burden compared to creating something from scratch.

> I thought there was already built components/libraries I could drop in for data management.

There are lots of data management libraries for React. Most can be used in a RN app. Maybe the community resources section of the React documentation will be helpful: https://reactjs.org/community/model-management.html

I can provide specific recommendations if you can describe specific needs. Like most ecosystems deciding which tool to use in which situation is a skill which builds up with experience.

Here is too much information, but this is how I spend my evenings now...

Goal is a finance tech app, although I probably just need a pretty front end, and I can do stuff manually in the background (like invest money, wire transfers, etc...).

I do have some database experience, writing to mysql. Was planning on doing that using LAMP, because I have experience already.

Features needed:

>write to database(should be easy with my previous experience)

>Usernames/passwords(I am actually clueless how to start doing this, I have Wordpress if needed)

>Accept payments(but again, I can probably do this through wordpress if its too time consuming).

Other specs, since its finance and people are going to be putting money into it, its gotta look and feel good. I'm willing to invest many months into building this to be perfect. However, progress feels slow since I'm learning the new javascript react-native syntax.

Any tutorials you recommend? Working through the facebook tutorial right now.

last trivia question- I was considering using Reflux, but I saw an article saying reflux is dying. I've heard facebook is especially brutal with changes.

> I was considering using Reflux

Redux is the de facto standard now in that space. It seems to have "won".

See https://stackoverflow.com/questions/36326210/what-is-the-cor... for further discussion.

Nope, sorry those days are over. Redux is on it’s way out, please refer people to this:

https://react-etc.net/entry/rip-redux-dan-abramov-announces-...

This article puts a pretty hard spin on what actually happened: Dan Abramov did not announce a "replacement for Redux", nor is he developing a "Future Fetcher" library. The React team is working on a feature that defers state updates until an asynchronous operation is finished, but we don't know how it'll fit into existing state management solutions.

Here's the official blog entry and talk where these features were announced: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

I'm a Redux maintainer, and that post is utterly and completely wrong in every way.

What Dan Abramov showed at JSConf Iceland was a pair of demo apps that illustrated upcoming improvements in React related to async rendering and data cache handling. Those features have no bearing on whether or not you use Redux, and are certainly not "replacements" for Redux. The linked tweet from Kent C Dodds was a joke tweet in a joke discussion thread, and the author of that site has repeatedly shown that either they don't understand the React world, they are very bad at writing and researching, or that they're just flat-out trolling.

There's certainly been plenty of discussion lately about when it's appropriate to use Redux, and I'd agree that many people are told to use it blindly without understanding what the tradeoffs are. It's also true that the new React context API (available in the upcoming React 16.3 release) means you won't need to pull in Redux _just_ to avoid "prop-drilling" data all the way down the tree.

However, Redux is absolutely not deprecated and not being replaced, and the React team isn't in charge of Redux anyway. Dan Abramov and Andrew Clark, the co-creators, are both now part of the React team, and are no longer active maintainers - Tim Dorr and I are. We _do_ still talk a lot about what the future plans are for Redux, and in fact right now we're working on updating the React-Redux library so that it properly works with the "async rendering" capabilities once those are released (see discussion [0] and an early WIP PR I filed yesterday [1] ).

[0] https://github.com/reactjs/react-redux/issues/890

[1] https://github.com/reactjs/react-redux/pull/898

With that said, in many circles I frequent there seems to be growing consensus that Redux just isn’t that useful, and in many cases ends up being a tar pit of boilerplate code that slows down development. Any project complex enough to require Redux should have enough talent on hand to basically write their own version of Redux for their purposes. Redux is such a small library and not enough people seem to be looking under the hood to realize there’s nothing magical about it.

If this is a growing perception amongst the developer community, it’s only a matter of time before it begins to impact the Redux’s relevancy.

I'll agree with the "nothing magical" statement, but I disagree with most of the rest of that comment.

Certainly there's nothing "magical" about Redux. After all, the core `createStore` function can be written in about 25 lines if you leave out error handling, and the entire core lib in about 100 lines [0]. React-Redux does have a ton of optimization work internally, but conceptually it's pretty simple too - components subscribe to the store, call getState(), extract what they need, and re-render [1]. And that's the great thing: Redux is, as its tagline says, "a _predictable_ state container" - there _is no magic_ involved.

What a lot of people don't seem to realize is that the Redux core is a _starting point_. One of my favorite quotes is:

> "Redux is a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware"

We encourage Redux users to use whatever abstractions are appropriate for their own applications, including writing their own. In addition, Redux was designed from the ground up to be extensible [2]. As a result, the Redux ecosystem has exploded. My Redux addons catalog [3] lists somewhere around 2000 Redux-related libraries, utilities, and tools, ranging from action/reducer generation utils to side effects management addons to abstractions for fetching data from REST APIs.

I've seen dozens of "Redux, but.." knockoffs. Most of them wind up throwing away the key design decisions that make Redux special. In particular, the concepts of plain object actions and reducer functions are what truly enable time-travel debugging and easy serialization of state.

My current estimate is that somewhere between 50-60% of React apps currently use Redux. Redux has gained adoption in the Angular, Ember, and Vue communities as well, and inspired dozens of similar libraries, like NgRx, VueX, and more.

Sure, I expect that some of that "market share" will slip over time, especially with the release of the new React context API soon. But, I also feel safe in saying that Redux will be around for a long time.

[0] https://gist.github.com/gaearon/ffd88b0e4f00b22c3159

[1] https://gist.github.com/gaearon/1d19088790e70ac32ea636c025ba...

[2] http://blog.isquaredsoftware.com/2017/09/presentation-might-...

[3] https://github.com/markerikson/redux-ecosystem-links

> last trivia question- I was considering using Reflux, but I saw an article saying reflux is dying. I've heard facebook is especially brutal with changes.

Not dying, just shrinking usage area. The community feels that it got overused. Kinda like you don't buy an Oracle license to make a todo app. So there's some backlash in the blogs. Upcoming versions of React include better/expanded global state management (the context API). Some of what people use Redux for now will be better served by that API.

Redux also doesn't tie in with any specific database or backend. As other vertically integrated solutions take shape, that will also cut into Redux's usage. At facebook, this would be Relay, a GraphQL library. A lot of people are excited about using a query language to talk to the server. It makes versioning and supporting multiple generic apps/features much simpler. Writing specific web service APIs locks you in if you need to support old client versions, etc. You end up with fetchUserInfo(), fetchUserInfo2(), fetchUserInfo3(), etc to avoid breaking clients. Ugh.

With respect to the last point: redux isn’t dying. I’d posit that most articles and blog posts written about front end technology are highly inaccurate marketing pieces designed to get clicks :)

Probably misread that (or they miswrote): reflux != redux.

I would agree with both statements: redux certainly isn't dying, though reflux may be.

Had to verify it was you, "peter" is out of character. :p

I'll point you to:

- My list of suggested resources for learning React: http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

- My list of suggested resources for learning Redux: http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

- My React/Redux links list, which has categorized links to articles, tutorials, best practices, and much more: https://github.com/markerikson/react-redux-links

Also, come by the Reactiflux chat channels on Discord! It's a great place to ask questions and learn. The invite link is at https://reactiflux.com .

Thank you!

> Goal is a finance tech app, although I probably just need a pretty front end…

Sounds like an interesting, ambitious project, I wish you the best :).

For building a finance app, you're completely right to build just a pretty front end. Since you can't trust the client, most everything of substance is going to be done on the backend.

> write to database

You want to send messages to a backend which are validated for sanity and safety then written to a database. What you're after is very likely a simple http client. Documentation is here: https://facebook.github.io/react-native/docs/network.html

> Usernames/passwords

You want an authentication screen that submits to a backend for validation. The backend creates a session which can be managed in a myriad of different ways. Making decisions about exactly how this works is context dependent. You can manage credentialing, tokens, authentication and authorization, someone else can manage it for you, you may oAuth with a platform that you're building on top of etc.

> Accept payments

If people are paying you for a product or service, Stripe. If people are transferring money to you for financial services, planning or management, they will expect to be able to send ACH/wire transfers without a fee associated. I don't have a foot in this world so I don't really know what direction to point.

> its gotta look and feel good

This can be done w/ RN but (obviously) RN isn't required. If you're more comfortable with the native language of the two platforms (Java & Objective-C or Swift) it may be a more productive use of your time to go that direction.

Unsolicited start-up advice: Don't go out of your way to learn new technology while building a company. There are plenty of "hard parts". Intentionally adding to the litany of hurdles to overcome is a very bad idea.

> Any tutorials you recommend?

Given your past experience, I recommend you work through a single simple tutorial (the Facebook one will do) then start trying to build your app. No reason to solve someone else's made up problems when building your own thing will naturally present plenty of problems.

> Reflux

If you mean "Reflux", I don't know what that is and I'm pretty deep in that world. Probably unnecessary.

If you mean "Redux", it's a very popular, extremely simple state management library. I recommend you try going without it and pick it up if you think it will help later on. Redux solves a specific set of problems that most small applications don't have.

Thank you for the detail.

>You can manage credentialing, tokens, authentication and authorization, someone else can manage it for you, you may oAuth with a platform that you're building on top of etc.

Is there a Stripe of passwords/credentials?

Or something I can google to understand how to get started?

If you’re on a LAMP stack, I assume you’ll use a PHP framework? If so, they will have libraries available that can handle auth for you. Laravel is the big php framework these days. Lots of libraries and tutorials available.

On the payment side of things, Stripe isn’t the only option available. The pro is that it has the fastest Onboarding workflow and a super slick api. The con is that you pay for it.

If you are margin conscious or your business revolves primarily around payments you can do better.

If that is the case for you, build with stripe through MVP stage but keep in mind you may want to swap out one day while building.

I’ve seen some niche businesses save 1% over stripe. That doesn’t apply to everyone but is frequently overlooked.

Thank you for the rec on Stripe. I know the 3% fee is crazy and I havent taken the time to look for another solution.

My goal is to get mostly wire transfers. But I think you are right about the inevitability of getting something cheaper.

Thanks for the php tip for laravel, Ive heard of it and was part of my original plan. Oh boy, back into php :P

If you are alone in your project and never used JavaScript - don't use React Native. It won't give you any benefits at all. It's that simple.

It may be useful if you know and like JS already or your have a team of web developers and you need them to build mobile app for you or your client. They should be able to do it without much to learn and your will have an app that can be potentially run on Android and iOS.

I'm writing a finance tech app, I pretty much need it to be perfect for obvious reasons. This was one of my goals, bringing people in later to build on my code.

Do you think its worth hiring a software developer 5pm-8pm to work on this with me? I was otherwise going to brute force it myself evenings and weekends.

> I was otherwise going to brute force it myself evenings and weekends.

I think you'll save yourself time in the long run (and learn new skills) by going through HTML, CSS (especially flexbox, particularly important in a React Native app) and Javascript (focusing on ES6) base-level material.

I don't follow. In my opinion, if you're alone on a project, the case for React Native (compared to writing an Android app in Java and an iOS app in ObjC or Swift) is even greater.

The OP didn't ever explicitly say he wanted to create an iOS and an Android app though, and I would agree that if that's not a desire, then React Native is less compelling, especially if OP has never used JS, as you said.

Only if you are a web developer. If you already know other languages, Obj C / Swift for iOS and Java for Android would be easier (even if there is duplicated work).

Alternatively, you could use C++ and Qt for both.

Ok, I guess that's where we disagree. I think that even if I were well versed in native Android or iOS development, I'd be better off writing a new app in React Native (even if I had to learn it all), rather than becoming well-versed in native development of the other, and then writing two apps.

If I was an expert in both Android and iOS, and knew nothing of web development... I still think I'd lean toward learning and using React Native. But only then would it be a close call.

I would just target the platform I already knew first, then port to the other if it turns out to be worth it.

The library commonly paired with React/React Native for data is Redux.

People who use React and React Native to share code between web and native typically report 85-90% of their code can be shared. Some UX code is platform-specific. Most of the application code should be reusable. Much of the UX code, such as for a button or input field, should be reusable. Getting high reusability depends on strong knowledge of both platforms. That's kind of the case with any abstraction though. The better you know the entire system, the better your code sharing.

React is different from many UX libraries because of its functional structure. You describe what you want, say <b>text</b>. Most people use JSX, but it's really just representing that in a tree structure, an object for each node, references to child nodes, etc. You don't code the algorithm/steps to represent that to the platform. In a traditional native UX library, you'd do something more like "Element textEl = new Text("text"); el.isBold = true; container.add(textEl);". Then when you want to change things, you'd find the element and adjust the properties, delete it, etc. In react, the mental model is to just rerun your render code which spits out the new UX. The library handles the diff/update. React Native essentially takes your tree, it's knowledge of the platform's current state, does a diff, and makes those updates for you. Naturally, there are a lot of underlying heuristics which make that diff/update efficient.

Traditionally, coding a cross-platform app for both web and native platforms is quite a bit more intensive than a simple language port. It's a ground-up re-write.

Should also be pointed out that React Native is only useful for the traditional event-driven style of apps, eg Facebook. You wouldn't use it for games.

I find the structure very interesting. Thanks for explaining it, in your own words.

I like the concept, but I'm struggling ton managing data outside the component. I've read this is by intention.

Thinking I'll just call everything from my server, save user data into the server directly and constantly recall from mysql. Goal would be to eliminate variables. Although this is a pipe dream, I'll still have to keep users logged in, and securely since this is a finance app.

Redux solves this problem?

Redux is appropriate for that, yes. You'll need to write the code to communicate with the server. So whatever fetch/update APIs you write there. Then interpret the response, and push the data into Redux.

Your server is your main single-source of truth. But on the client, redux is that source of truth that your UX and application code reference.

Lin Clark is amazing at explaining concepts in the React and Mozilla worlds. Here's her intro to Redux concepts: https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...

Thank you, validated what I thought I needed.

Wondering how I should hide all the goodies, pick an encrypt library and move everything over GET?

I wanted to avoid doing back end work in the mysql/php? I could never get the debugger to work.

Also, if you want to focus on how components in React get their data, that's pretty simple. They just subscribe to it.

If you wanted to render a list of accounts, you could have a couple levels.

At the top, you have an account lists component. It gets a list of accountIds from a global data store (in redux). Then it outputs something like this:

  <List>
    <Account id="1" />
    <Account id="2" />
  </List

The Account components then pull info from Redux about whatever they need to render whatever account they're responsible for.

Each component registers a listener/callback with Redux when its first instantiated. So if the balance of an account changes, it's listening for that change. The change triggers your callback, that triggers a fresh render(). Then the next render() pass pulls the updated account balance with its next pass, etc.

redux is going to solve my problems, very excited to get this tip.

I can’t speak to why React Native was recommended to you specifically, but here are some reasons I think speak for React Native and which I’ve also heard from other people (for example those who I’ve interviewed on my site http://madewithreactnative.com)

* Web devs can hit the ground running, more or less without having to learn a new language.

* One code base for both Android and iOS without having to write any native code (Theoretically. For some things, you still can’t get around native code), which leads to

* Shorter development times for apps for both platforms.

* For apps, which are basically just presentation layers for data fetched from server, performance is fine.

* Huge community with a lot of packages and libraries, especially because you can also use many node packages without any problems.

It depends on the product you are building and the team.

E.g for us it was super useful (team of 3) as we just hired a designer ux/ui guy that knew some flexbox stuff and javascript and now he is adopting into react-native quick enough and he is able to change bits in the actual app without us having the need to do it for him.

What am trying to saying is that if we were doing native development for example, there would be no way that the designer knowing a bit of javascript could go in and do it himself in swift/c or java, he'd need us to do it for him.

Maybe try Flutter? It's still beta but has a good team behind it:

https://flutter.io/

React Native is amazing if you primarily work with the traditional web stack of JS/HTML/CSS, especially if you're already familiar with React you're able to jump into React with almost no retraining so you have immediate productivity and power to create on iOS/Android.

If, on the other hand, you do not have much experience on a modern web stack like React/Redux/Node then using React Native may actually feel counterproductive. You would still be getting the benefit of writing once for iOS/Android (or mostly once), reusable components across the app, a vibrant React Native open source components library, a great hot-reload dev experience, the benefits of React's design among other benefits but it all comes down to what you feel productive with and/or how much time does it make sense for you to invest in learning a new language/framework (or two) just to build mobile apps.

If you're looking for a good resource to learn React Native lookup the udemy courses by Stephen Grider, he does a great job of diving deep quickly yet explaining important concepts thoroughly.

Good luck!

One question I would definitely ask is: why native? Would your app be just as well-received if it was a PWA? Do you actually need any specific native functionality? If not, then there are some definite benefits of trying the PWA route, especially if you're good with JavaScript in the browser. We built our app (https://usebx.com) as a PWA and have never regretted it. No frameworks, no gimmicks. Plain old vanilla JavaScript, and it's the same code base running on Safari, chrome, desktop, tablet, mobile, whatever.

I didn’t do React Native programming in a real product and only played with it but like many others, I used Javascript in different runtimes against different APIs. The most famous ones are of course DOM and NodeJS.

The biggest advantage of React Native is that you can carry the same mental model you learned about JS from one API to another: - Representing data and the available data types - Doing async operations - The pros and cons of the single threaded execution - Error handling - Testing / Mocking

I bet I forgot a few others but all these change from one language/ecosystem to another sometimes very significantly, and takes years to master. Objective C/Swift and Java/Kotlin are so different than JS.

So, JS is not my favorite language but for any nontrivial new product, I check if I can use JS with some runtime for the target platform(s) I am dealing with. In that regard, the React Native decision is about checking what APIs are available that will be needed in your project.

As far as I see, React Native is a perfect match for CRUD apps that help users to interact with some data and business logic by using native UI/UX elements.

It does not seem to have much to provide though when you want to do some cool stuff with the camera, 3D APIs, and other device capabilities. Same is true for any new capability that mobile devices may provide in the future.

When you need all these advanced capabilities, one option is to go with a hybrid model, implementing some parts with native languages of a given platform. However, I have big reservations against that.

If I need to use these other languages in a nontrivial way, I would rather go full native and master each language/ecosystem as an individual or team. It will take sometime (for me it took 2-3 months, while learning/working in 3 ecosystems in parallel), but eventually the productivity/ease of development is pretty much the same.

In short, if you are already a good JS developer, do some research on APIs and capabilities that React Native provide, and if you are say ~80% sure that they are enough for your products needs, go for React Native.

That is my 2 cents.

Edit: Typos and rephrasing

I think react native is a good recommendation for a react dev who wants to do cross platform development on mobile.

If you're not a web dev it's not a great fit. You'll have to deal with learning web, learning mobile, and as well as all learning all of react-native's leaky abstractions.

Sounds like a nightmare. I'd go with either native(Java/swift) dev or if you have c#/wpf experience then maybe xamarin.

Your question does not mention the use case ? If react-native was recommended, it was for a something specific ?

We use react-native for a cross platform mobile app (iOS and Android). The alternative would be to write two separate code bases in two two different languages for two separate OSes. RN was a no brainer and we are still very happy with it.

React is newer than jQuery so there aren't yet as many mature libraries out there. Still, it's component-ized approach, especially with Redux, can help keep complex applications easier to manage and reason about.

Disagree - there's a huge thriving ecosystem of React components and libraries available, and many of them are mature.

Since React isn't the only component based framework, I think there are easier ways to manage and reason about a front end. In fact React works well in certain cases, sure. It's just that any philosophies or paradigms that it introduced are in almost every framework now as an addition, see: NgRedux or Infernal.js.

Personally, React wasn't an easy shift coming from an angular background; I just felt the state flow was cumbersome compared to 2 way data-binding; although some people swear by it and say it's the only way. I think the real take away is that there's plenty of options to choose from.

It's not far off to imagine that React may not be the flavor of the year at some point.

I’m curious what about the state flow you find cumbersome? Are you talking about using just pure React with prop passing everywhere or something like Redux that lets you subscribe components to specific state changes?

I haven't thought about comparing React to jQuery, but I think that's good point. React is probably an equally important and ubiquitous stepping stone of a library for JS. Love it or hate it, its a new standard.

Getting into it pretty much guarantees a certain level of productivity and community support.

React isn't "new". It was deployed on FB in 2011, and open sourced in 2013. (2006 for jQuery). 4-5 years is plenty of time to develop a rich ecosystem of libraries ... just recall jQuery circa 2010-2011.

I certainly wouldn't want to build a mobile app these days with jQuery, since that would generally mean more of a pure Cordova app. (I do think that Ionic however would be a great option depending on the use case)

Cordova or Ionic is perfect for those that don’t care about the user experience.

Or those who have considered the options, advantages and drawbacks, and decided Cordova/Ionic is the best tool for the particular job.

You don't really mention your usecase and that is crucial.

There is a niche where RN chines but that does not mean it is a great solution for any app.

> Ive programmed in 8+ languages, and up to this point Javascript was unused.

What languages and for how many years have you programmed?

Depending on your background, and what you're trying to do, something like Xamarin might make you happier.

If you're not a JS person at all, getting thrown into the full-bore insanity of modern web development typically embraced by those who tout React and React Native as the silver bullet, you're gonna have a bad time.

Reply on news.ycombinator.com