Live data from Hacker News

Learn React.js in a weekend

nodecasts.io

31–40 of 49 posts

Re: Learn React.js in a weekend

#31
post #20

Earlier quoted context omitted.

or, you know, just write the app in pure javascript and still reap the benefits of [2-3x faster than React] virtual dom. though i'm a bit biased [1] ;) [1] https://github.com/leeoniya/domvm [2] http://mithril.js.org/

Meh since when is computational performance really a bottleneck? Do you find your site is loading seconds too slowly because JS is executing? I sure don't. On today's machines the much larger bottleneck is how fast and easily you can iterate on product at scale which is a problem that React is a fantastic solution for.

> Meh since when is computational performance really a bottleneck?

Ever used a phone that wasn't > at scale

React is a front-end framework. The only "scale" that exists in its world is the fat DOM you generate and how fast it can mutate it. From that perspective, it sucks at scale (take a look at Preact and Inferno). Your iteration speed depends on good app architecture, not a specific framework. React Native does sound like a good perk, but likely isnt useful enough to make anything you cannot do anyway in HTML5.

Re: Learn React.js in a weekend

#32
post #19

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 pr…

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).

Re: Learn React.js in a weekend

#33
post #20

Earlier quoted context omitted.

or, you know, just write the app in pure javascript and still reap the benefits of [2-3x faster than React] virtual dom. though i'm a bit biased [1] ;) [1] https://github.com/leeoniya/domvm [2] http://mithril.js.org/

Meh since when is computational performance really a bottleneck? Do you find your site is loading seconds too slowly because JS is executing? I sure don't. On today's machines the much larger bottleneck is how fast and easily you can iterate on product at scale which is a problem that React is a fantastic solution for.

On mobile, it matters a lot, especially older/low-end Android phones.

Re: Learn React.js in a weekend

#34
post #20

Earlier quoted context omitted.

Meh since when is computational performance really a bottleneck? Do you find your site is loading seconds too slowly because JS is executing? I sure don't. On today's machines the much larger bottleneck is how fast and easily you can iterate on product at scale which is a problem that React is a fantastic solution for.

> Meh since when is computational performance really a bottleneck? Ever used a phone that wasn't > at scale React is a front-end framework. The only "scale" that exists in its world is the fat DOM you generate and how fast it can mutate it. From that perspective, it sucks at scale (take a look at Preact and Inferno). Your iteration speed depends on good app architecture, not a specific framework. React Native does so…

Scale in terms of number of engineers and app size, not users

Re: Learn React.js in a weekend

#35
post #34

Earlier quoted context omitted.

> Meh since when is computational performance really a bottleneck? Ever used a phone that wasn't > at scale React is a front-end framework. The only "scale" that exists in its world is the fat DOM you generate and how fast it can mutate it. From that perspective, it sucks at scale (take a look at Preact and Inferno). Your iteration speed depends on good app architecture, not a specific framework. React Native does so…

Scale in terms of number of engineers and app size, not users

> number of engineers

can't this be said about any popular framework? "it scales because everyone knows it"

> app size

what specifically makes React scale better with app size than any other properly componentized architecture?

Re: Learn React.js in a weekend

#36
post #34

Earlier quoted context omitted.

Scale in terms of number of engineers and app size, not users

> number of engineers can't this be said about any popular framework? "it scales because everyone knows it" > app size what specifically makes React scale better with app size than any other properly componentized architecture?

It doesn't scale because everyone knows it. It scales because React by nature isolates business logic into components so that for the most part 100 engineers can simultaneously work on the same product and be confident they aren't breaking stuff. (Or realize they are through merge conflicts)

> "properly componentized"

With React, 100 engineers don't have to know how to "properly componentize" things because it's already baked into the framework. You can't really write React code without proper componentization.

Re: Learn React.js in a weekend

#37
post #29

Earlier quoted context omitted.

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).

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

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.

Re: Learn React.js in a weekend

#38
post #36

Earlier quoted context omitted.

> number of engineers can't this be said about any popular framework? "it scales because everyone knows it" > app size what specifically makes React scale better with app size than any other properly componentized architecture?

It doesn't scale because everyone knows it. It scales because React by nature isolates business logic into components so that for the most part 100 engineers can simultaneously work on the same product and be confident they aren't breaking stuff. (Or realize they are through merge conflicts) > "properly componentized" With React, 100 engineers don't have to know how to "properly componentize" things because it's alre…

> React by nature isolates business logic into components

The essence is simply this:

    function MyView(model) {
      return template;
    }
...which can work with any view layer and the same 100 engineers. Especially if the model is an API with business logic around some immutable stream/state. The concept is simple enough to be described in one sentance :)

> don't have to know how to "properly componentize" things

I think you're overstating how difficult this problem is or forgetting that React's API must still be learned from documentation and examples.

Re: Learn React.js in a weekend

#39
post #19

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 pr…

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).

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/)

Re: Learn React.js in a weekend

#40
post #19

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 pr…

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!

Post reply on HN