Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn React.js in a weekend

nodecasts.io

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Learn React.js in a weekend

#41

Post by a13n »

leeoniya wrote: post #38
a13n wrote: post #36

Earlier quoted context omitted.

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…

What about state within a component? How do you encapsulate that state so that other components can't muck with it? What about passing data to that component? What about type checking that data passed in in debug mode? What about a formal API for components to talk to one another? What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

React has answers to all these questions and so much more. Answers that very smart people have spent years coming up with.

Sure you could reinvent the wheel and build all that into your custom component framework, but then you may as well just use React.

Re: Learn React.js in a weekend

#42

Post by a13n »

mangeletti wrote: post #40
a13n wrote: 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!

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!

Re: Learn React.js in a weekend

#43

Post by xufi »

a13n wrote: post #42
mangeletti wrote: post #40

Earlier quoted context omitted.

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!

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

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

Re: Learn React.js in a weekend

#44

Post by leeoniya »

a13n wrote: post #41
leeoniya wrote: post #38

Earlier quoted context omitted.

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

What about state within a component? How do you encapsulate that state so that other components can't muck with it? What about passing data to that component? What about type checking that data passed in in debug mode? What about a formal API for components to talk to one another? What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed? React has answers to all…

I will address these with respect to domvm [1]

> What about state within a component? How do you encapsulate that state so that other components can't muck with it?

Solved.

> What about passing data to that component?

Solved.

> What about type checking that data passed in in debug mode?

Could be solved if i rewrote in TypeScript. But this has never been a problematic issue in 10k+ LOC apps.

> What about a formal API for components to talk to one another?

Yep.

> What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

Obviously, that's what virtual dom is.

In addition to all of this and much more, materialized views are independently refreshable, can be composed between disjoint components. There are async lifecycle hooks, a router, mutation observers, ajax sugar.

All of it is 17k min, requires no special tooling or IDE to write, is isomorphic and is 2-3x faster than React.

I have no doubt that React brings a lot to the table, but I hesitate to treat it as the final word in frontend frameworks for all the above reasons.

[1] https://github.com/leeoniya/domvm

Re: Learn React.js in a weekend

#45

Post by rukuu001 »

a13n wrote: 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…

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

Re: Learn React.js in a weekend

#47

Post by wtf_is_frp »

dopeboy wrote: post #8

Question for people who learn by video rather than text based guides - why do you find it more effective? I have trouble following someone else's pace in a video (or audio for that matter). I also like to be able to copy and paste code into my editor. Navigation to particular sub sections is easier too.

Maybe the problem is that you are assuming others have no trouble. Videos tend to pack more stuff in a shorter amount of time and new concepts require extra effort. I have heard that some "learn better by video rather than text, etc..." but doubt it is true.

Re: Learn React.js in a weekend

#48

Post by skc »

For me the thing I'm finding most annoying is how many errors I get just setting up this stuff, whether it's Angular or React or something else.

I'm on Windows though so I assume a lot of my issues stem from the tutorial authors assuming they are talking to a purely *nix crowd.

Re: Learn React.js in a weekend

#49

Post by drdaeman »

a13n wrote: post #39
drdaeman wrote: post #32

Earlier quoted context omitted.

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…

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

Post reply on HN