React Enlightenment

One of the benefits of React is how is scales, so small examples like this make it seem like it's a lot of complexity. But scale it out to lots of components all interacting with each other and then the benefits of a pure render function, declarative UI, make sense. I highly suggest going through this example to help see the benefits of React: http://reactfordesigners.com/labs/reactjs-introduction-for-p....

This appears to just be a contrived example implementing a familiar component to give you an idea of how React works. Of course, in practice, you just use a select when you want a select.

For a static website with a few pages, you wouldn't need to. But for more complex apps, that's where the pay off is. A brief example: In one of our apps, we needed various select menu behaviors. Sometimes it would accept normal attributes (strings for values). Sometimes arbitrary objects having a toString method. Sometimes it needed to load data. Sometimes it needed to load data given only a model name, and know how to page it. In react, I was able to do this with a single base select component, with a few wrappers (decorators) to add in the various behaviors. All encapsulated, and abstracted behind a relatively simple interface. With honestly not that much more code than the example in this tutorial. And it all felt natural -- like I was just writing javascript. Thats the good side to React.

I think it's a scary example. It's trying to show you the effort involved without convincing you to the benefits of the effort.

The example isn't real-world scenario. TBH, I'd say it's anything but enlightening.

What React does, is keeping the DOM tree in sync with the data (components' states and properties). If you don't have the state - it might be the case that you don't really need React, something like Handlebars.js or jQuery templates (if there's even a need for templating at all) would do just fine.

I mean, there's no real practical difference[1] between something like

    // A stateless React component, so no need for React.Component boilerplate
    const MySelect = (props) =>
        <select name={props.name}>
            { props.values.map((v, i) => <option value={i+1}>{v}</option>) }
        </select>;

    // For this example to be short, no trees here. Only one component.
    // (although internally <select> and <option>s are - but we don't care yet)
    // And, actually, in my opinion React only starts to make sense
    // when there's a big enough hierarchy of components (stateful or not).
    ReactDOM.render(<MySelect name="x" values={["foo", "bar"]} />, targetEl);

And something like

    const MySelectT = Handlebars.compile(`
        <select name={{name}}>
            {{#values}}<option value="{{@index}}">{{.}}</option>{{/values}}
        </select>`);

    // Same as ReactDOM.render for one-component case. For nested, use {{include}}
    // However, note now here's an important difference - unless the templating
    // library is more powerful, the state is monolithic (and has to be defined
    // implicitly, in full) with this approach.
    $(targetEl).html(MySelectT({name: "x", values: ["foo", "bar"]}));

[1]: But there's no difference only when you keep it at this level.

But if your UI is dynamic enough and you start to care about the state (e.g. you don't want to lose user input to template re-rendering, when user switches the tabs back and forth) - React provides a way to handle this by one-way binding between your data structure and DOM tree it handles. All it does, though, is only handling of that DOM tree and handling/propagating state updates (esp. if you combine it with Redux) - all the rest is yours to code.

If you're rendering your webpage with Javascript, because your <select>s are dynamically generated, then you're going to write a lot of code anyway to render the HTML, keep it in sync with the underlying model, bind the user events to trigger actions, etc.

It's a lot of code compared to a static website, but not a lot of code compared to doing it in some other framework, and, for many cases, it is much, much more maintainable.

THAT SAID, I agree that it's a horrible example to have on the first page.

"Here, let me show you pages and pages of scary code that won't make any sense until you've read the entire book, in an attempt to give a brief overview of this framework."

I think there could be a much gentler introduction, preferably using JSX.

That's a bit like looking at the source code for Linux's TCP stack and saying "All that work just to make a TCP connection? I'm definitely not using Linux".

If all you want is a select in React, you can just do `<select><option value="A">A</option><option value="B"></option></select>`. The tutorial is showing how to roll your own select-like control using divs. I doubt that it is much easier to do that using any other JS framework.

Depends on your use case. For a simple website with maybe a form or two, React is overkill. When you're dealing with hundreds of pages with dynamically rendered elements, it helps to keep things consistent and DRY. React helps achieve this through the use of components. For example, let's say I want to allow any button on my page to send a tracking event to Google Analytics on click if a certain attribute on the element is set. With React, I can add this feature for every button by modifying the `Button` component I built. This ends up being a lot easier than having to manually bind the tracking callback event to every `<button>` element that is rendered at some point (and also guarantees that event delegation takes place within the component rather than some other module in your application).

The component pattern is certainly not unique to React but it is a good design pattern that the framework encourages through JSX, component lifetime cycles, etc. While I can't speak for everyone, React has certainly made my life and the life of developers I work with easier since integrating it.

This comparison may help: https://facebook.github.io/react/docs/webcomponents.html

Basically, Web Components exist to solve a different problem than React.

I found this one of the more detailed articles about the differences and why one might favor react http://jlongster.com/Removing-User-Interface-Complexity,-or-...

FYI, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem.

One of the closest items to the "React Enlightenment" book might be "Redux Without Profanity", a free e-book posted at https://tonyhb.gitbooks.io/redux-without-profanity/content/ . (Which, oddly enough, I'm suddenly noticing is _not_ already in my list.) The slides at http://slides.com/jenyaterpil/redux-from-twitter-hype-to-pro... are also a great intro and overview of how Redux works.