
Learn React.js in a weekend - jon_kuperman
https://nodecasts.io/learn-react-js-weekend/
======
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...](http://djcordhose.github.io/hh-react-conf-2016/redux-vs-relay.png)

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.

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

~~~
_asummers
I get different things from videos than I do text. From a video, I get a "why"
and a "how" most often, whereas from text I get a "what". Obviously text can
represent why and how, but I feel there's something lost going from screencap
to screencap that is perfectly captured in video about the process of getting
from point A to point B. Additionally, most blog posts don't publish the
mistakes (let's try this thing! crap it didn't work, here's why. This is
especially true as a result of a question.) but you can very easily convey
that type of information in video by just showing it not working. The pacing
thing is totally a valid concern and I find myself watching youtube videos at
1.5 or 2x speed to consume the content.

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

------
DavidGuan
Something about react life cycles, in a daily sharing video:
[https://www.youtube.com/watch?v=vEf8c1-WBBs](https://www.youtube.com/watch?v=vEf8c1-WBBs)

------
payne92
Is this all paid content?

~~~
jon_kuperman
Nope! Everything is free except the first link!

------
hit8run
How about: RTFM [https://facebook.github.io/react/docs/getting-
started.html](https://facebook.github.io/react/docs/getting-started.html)

I don't get the react hype anyways. Writing inline HTML in JavaScript seems so
weird to me (JSX).

~~~
firasd
The argument (among others) is that if you're going to be using if/else, for
loops, and all that in a templating language you might as well use a full-
featured language like JavaScript... (youtube timestamp:
[https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=4m13s](https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=4m13s))

~~~
leeoniya
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](https://github.com/leeoniya/domvm)

[2] [http://mithril.js.org/](http://mithril.js.org/)

~~~
a13n
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.

~~~
leeoniya
> Meh since when is computational performance really a bottleneck?

Ever used a phone that wasn't < 6 months old to browse the modern web?

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

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

~~~
leeoniya
> 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?

~~~
a13n
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.

~~~
leeoniya
> 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.

~~~
a13n
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.

~~~
leeoniya
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](https://github.com/leeoniya/domvm)

------
zghst
React is 1 hr at the most to fully learn and get a good grasp...

