Ask HN: Why was React Native recommended to me? Not seeing benefits
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?
60 comments
[ 1.7 ms ] story [ 215 ms ] threadPersonally, 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.
Getting into it pretty much guarantees a certain level of productivity and community support.
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)
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.
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 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.
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.
Alternatively, you could use C++ and Qt for both.
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.
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.
And FWIW Facebook probably employs over a thousand iOS and Android developers. It’s not a “budget” thing for us.
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.
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.
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.
https://react-etc.net/entry/rip-redux-dan-abramov-announces-...
Here's the official blog entry and talk where these features were announced: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
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
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.
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
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.
I would agree with both statements: redux certainly isn't dying, though reflux may be.
- 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 .
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.
>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?
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.
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
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.
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.
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 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?
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...
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.
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:
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.
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.
To me the biggest benefit is that you write your code once though. Especially with a React based kit like Expo.
What languages and for how many years have you programmed?
https://flutter.io/
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.
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
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.
There is a niche where RN chines but that does not mean it is a great solution for any app.
* 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.
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.
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!