My Reaction to React

Great idea. Spend 10 minutes writing your framework that gets you 80% of the way. Can't wait for the next decade worth of follow-ups that attempt to patch up the remaining 20%.

Frameworks don't exist just because someone wanted to write a framework. They exist because they solve problems. And they solve problems you likely forgot to think about so you don't have to. Like not losing cursor positions when re-rendering, or not breaking the DOM when trying to re-use input elements or manipulate tables.

React is actually great in this regard: it doesn't try to solve everything, it just focusses on one problem (two if you include React-DOM/Native) and solves it well. Redux is another great example (the entire API can be implemented in less than 100 lines).

The reason libraries and frameworks like React and Backbone and Angular and Ember exist is that direct DOM manipulation doesn't scale. It's on a lower level of abstraction than the application you're trying to build. And the advantage of React (and similar libraries like Mercury) is that it just lets you build components (i.e. partial DOM trees) -- it's trivial to swap the component library out in the future without having to touch any of the application logic around it.

I am no a JavaScript expert - I started playing with frontend (jQuery doesn't count) only recently. The only problem I have with your approach is that the model might mutate. For small projects it is ok - but for larger ones overriding state from many places generates pesky race conditions that are source of all evil. I am not advocating for react as well - to me it is just a view layer. Combining it with redux, flux or any other library concept makes everything complex. And add javascript build tools on the top of that (good javascript sucks). As a mostly "backend" developer (python, erlang, elixir) I really started to like ELM (http://elm-lang.org/docs#complete-guide) which solves all the problems as a language.

1. Language forces you to model-view-controller style

2. Language makes the model immutable

3. Language forces you to use correct types which saves a lot of trouble.

On the other hand, I a new to frontend - so I might be wrong.

I won't make an argument for Angular or Flux/Redux because those are very opiniated frameworks that might be overkill or simply not at all how you want to go about your app's architecture.

But React is about the view. You can't possibly be convinced that manually traversing the dom is just as easy and expressive as using JSX. Even in the simplest of interactive (as in you need Javascript) components or pages.

React's concept and syntax is super easy to understand and perfect for modularizing the components of your app. The real problem IMHO is the tool chain. That's what drives developers unfamiliar with the ecosystem away. And of course the fact that it seems to change all the time. The first time I looked at React they rolled their own transpiler. Now Babel is the recommended way to go.

According to the tutorial page you should either use browserify or webpack. You don't have to - but without them stuff gets messy pretty quick. Of course if you pick one of these up you also have to learn how to use them and you will want plugin A, B and C to get to your simple Hello, World React App in the first place.

So yeah. That's why it's so easy to step away from that thinking why don't I just simply roll my own framework.

For most problems, the following is how you define a component:

    function Comp(state) {
        return React.createElement(
          'div', // tag name
          {}, // props/attributes
          'Hello ', state.name // children
        );
    }

And this is how you use it:

    ReactDOM.render(
      React.createElement(Comp, {name: 'World'}),
      document.getElementById('stage')
    );

So in those situations the entire surface of the React API consists of two functions: React.createElement and ReactDOM.render. And if you use JSX, you won't even directly use React.createElement in your code.

React is conceptually trivial. The API has been getting tighter with each release. React is in active development but so are all of its competitors[1][2]. React is production ready -- Facebook is even dogfooding the pre-releases in production.

[1]: in fact, when a library/frameworks stops being actively developed people start assuming it's dead. Counter-example: Redux is no longer actively being developed because it is officially complete and the implementation is so straightforward and resilient it can't really be improved right now.

[2]: the reason it's bogus to compare it to Angular2 "because that's not finished yet either" is that Angular2 is being built to spec whereas React is being developed under use. Angular2 will be "finished" when the full spec is implemented. React will be "finished" when real-world use shows no further need to change -- by that definition none of the alternatives (including Angular2 post-"final") is "finished" either.