He compares react.js to angular. Angular basically want to take over your
whole page. Multiple apps on one page, mixed with some jquery, isn’t really
possible. You also have to learn a lot of terminology. It is a full stack
framework. And angular 2.0 won’t have a migration path from angular 1.x...

React.js only does one thing and does it
well: the view. It doesn’t do data fetching, url routing and so.

React.js is quite pythonic. You can start adding little bits at a time to your
code. You cannot really do anything wrong with it.

A core idea is that the html is in one corner. That’s the output. And the
state is in the other corner. They’re strictly seperated, which makes it
easier to reason about.

It is build by facebook. They take page load time seriously. You can even run
react.js partially on the server side (“react native”, inside node.js), taking
down rendering time, especially on mobile. Facebook is pretty deeply invested
in it, so the chances of it disappearing are low. (As opposed to angular:
google is barely using it itself).

When you start using react.js on a page, you’ll have to start thinking about
components. An “unordered list of results”, a “search box”. Those kinds of
components.

Component: basically a piece of html, handled by react. If react renders it,
html comes out. It looks at its state and properties to render it (“it calls
the .render() method”).

State: the current state of the component. The component can change this.

If you can do without state: do it. You’re better off calculating it from
something else. And if it makes sense to store the state on a higher-level
component: do it.

If a component’s state changes, you can assume that the render method gets
called (it does some magic so that it only updates html if there are
changes).

Properties: what you pass a component from the outside. Think parameters,
like a list of products. The component cannot change these.

React.js code is quite simple to reason about as there’s a simple path through
the code. If some method changes the state, react handles the rendering. The
rendering might set up click handlers or other things. If such a click handler
changes the state, react renders everything and so on and so on.

Integration with existing jquery plugins is generally possible, but you’d
rather not do it. React.js tries to store state nicely in a corner and jquery
plugins normally store state on the DOM itself. So watch out a bit. You might
have to build some more custom html than you’d have to do otherwise as you’d
just download one of the existing jquery plugins.

A note about facebook’s flux. “A flux” is just a structure for building large
applications. There are multiple ones. He hopes you don’t have to build such a
large application yet, as the flux you’re choosing might not be the one that
wins out in the end.

If you need a good example of django and react.js, look at django-mediacat.

Question: “How do you integrate with django? Does django still render forms?”
Answer: normally, you’d decouple the front-end and back-end, at least for the
bits you let react.js handle. So perhaps generate some javascript variables in
the django template. And grab the rest via an REST API.

Some clarification to the previous paragraph: you can choose yourself how much
of the page you let react.js handle. He himself is using react.js to handle a
couple of interactive elements on an otherwise-static django-rendered page.

Question: “Are you happy with react.js?”. Answer: “YES!”. It is quite small in
scope. It doesn’t get in your way. Easy to get started with. You can’t do an
awfully lot wrong (he has seen terrible examples with angular: it gives you
much more rope to hang yourself with). You can progressively add interactivity
to your page.

Tip: keep your react.js components small. Only let it handle spitting out
html. Do any calculations you might have to do on the server side, behind your
REST API.