[a13n]

I don't recommend learning Redux the first weekend you learn React. This would be akin to learning about Relativity the first weekend you learn Mechanics. I actually think it's detrimental to suggest beginners learn Redux alongside React because it unnecessarily steepens the learning curve.

Not that Redux is too complicated (it actually has a super simple API). Redux is a (fantastic!) tool you should use once your project is at a large enough scale that you need it. You can go a long way in vanilla React before you feel the pains that Redux (or Relay) solves. The React part of my current codebase is over 25k LoC and I still don't feel the need to throw Redux into the mix.

Take a peep at http://djcordhose.github.io/hh-react-conf-2016/redux-vs-rela...

If you're just starting out then first spend several weeks/months in vanilla React. Unless you need to learn Redux to work on a bigger codebase at a new job or something...

Qualification: I used to work on React Native at Facebook.

[falsestprophet]

What stacks would you recommend for starting a React Native application of low complexity (like single man operation) and low-to-moderate complexity (like a several man seed-funded company)?

[a13n]

If you don't need a server then React Native should basically be your entire stack. :)

Since you do probably need a server, I don't have an incredibly educated answer for you but I use Node + Mongo on AWS because it's cheap, easy, entirely JS, and seems like it'll scale reasonably well (to some point).

[falsestprophet]

I mean does an application being React Native change your opinion on using Redux or Relay?

[a13n]

It's really up to you. It's a tradeoff between spending additional effort on dev ops now (rather than product) versus building the technical debt that will be converting your app over later. If everyone on your team knows Redux then sure, start the app's architecture to scale to a huge team. If it'll significantly slow down product development then have everyone learn + convert later.

I'd err on the side of the latter (vanilla RN, Redux when you need it) to move fast on your product.

[sotojuan]

> I don't recommend learning Redux the first weekend you learn React.

Agree and so do others:

https://mobile.twitter.com/mjackson/status/74507491083006771...

Admittedly this may sound like "argument from authority", but I just mean that it's not an unpopular opinion. I've seen way too many people be too dogmatic about Redux. Core React is underrated.

[mangeletti]

Thanks for the advice.

I've been wanting to learn React for a while, but each time I start, I'm put off by the complexity it adds (compared to e.g., jQuery + vanilla JS). I soon will just jump in and learn to swim.

BTW, do folks use React for server-side apps as well? If so, is that common?

Also, I almost ROFL at the "axes might be logarithmic" in that graph's legend!

[a13n]

Sure thing!

You can definitely render your React code on the server and (distrubutedly + carefully) cache the result to make your initial page load blazingly fast. IMO it's more of an optimization though.

I don't personally use this feature since client-side rendered has been plenty fast enough for me so far.

Learning React is IMO one of the most impactful things I've ever done to be able to effectively build products, couldn't recommend it more!

[xufi]

Thanks for the detailed opinion. I'm just trying to relearn Jquery/Vanila JS myself and want to jump to react and a few other libraries. Seems like I shouldnt be that afraid

[rukuu001]

I'm putting together a React course right now and have specifically avoided Redux (& even server-side React). I don't want to get in the way of the a-ha moment when you see React components working together simply and cleanly

[drdaeman]

What would you recommend to do about the aspects React doesn't cover? (My sole use case is webapps and dynamic webpages)

I mean, React is only when you have an object and want to render an UI component, right? That's quite a small part of what even a simplest CRUD interface has to do (i.e. acquire the object from server and then try to keep it in sync with both server-maintained state and user feedback).

[a13n]

So https://productpains.com is entirely written in React and React Router (no Redux, yet).

I have a few wrapper components that know how to fetch various datas (a product, post, etc). They then pass this data into their children via props. When the user makes a mutation (vote, comment, post, etc) I'll let my server know to make the mutation and then do one of two things:

1. Optimistic: "Fake" the mutation using state until the server response comes back, then reload the data

2. Loading Indication: Give some sort of indication that the mutation is happening (eg. a spinner) and then when the server response comes back, reload the data

We don't currently update data live when there are changes on the server. This could be trivially implemented with polling. Or the more complicated solution would be to use a socket and subscribe to certain datas on the server which would get pushed to the client upon mutation. (see GraphQL Subscriptions! http://graphql.org/blog/subscriptions-in-graphql-and-relay/)

[drdaeman]

I.e. you suggest to use no library, but just ad-hoc DIY XHR/websocket/whatever-else-works to do what React doesn't?

I was asking exactly because I've already tried this and didn't like the process and results. Used the loading indication approach, with models having `pendingUpdate` flags. Basically, I felt that I'm writing ton of unnecessary code that had to be written only because things are too low-level. Like I was re-solving already solved problems.

React does the UI layer, but DIY data model + persistence layers aren't fun. What I'm looking for, is something like Angular's $resource (or its extensions) for React. Something that hides away the unnecessarily gory details (low-level XHR stuff, URL construction, maybe even data validation) behind a programmer-friendly API facade (`Item.save`), plays well with React and those fluxish patterns, yet doesn't enforce any special requirements on the server-side tech (i.e. can be used with existing Django/Rails/PHP backends).