My Reaction to React

React is JavaScript.

jQuery, sure, that's probably harmful in the long run, but you have to know JavaScript to use React.

/Structuring/ an app is a different skill that takes lots of consideration, especially in a language as flexible as JavaScript.

All future frameworks should be designed to be easy to learn. This means removing (or at least better isolation of) complexity, but also making a nicer API and writing tutorials as an essential part of the framework. If there's anything really cumbersome to explain in the tutorials, it should be simplified.

So I recommend the author learn minimalistic libraries like Riot instead of React. Those are really lightweight and very easy to grasp. However, even the docs of Riot could still be improved. Despite its simplicity, I could have learned it in half the time if it had a better tutorial.

Essentially, this means applying findings from UI design to framework API design. Here, the user is a developer, but surprisingly many principles still hold: Principle of least surprise, make similar things look similar, make different things clearly different, and so on.

React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it.

You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that gives persistent immutable data-structures. This comes at the cost of having to use its own methods like map and filter, instead of normal JS everywhere.

But that is pretty much it. There are a few more other concerns that'll necessitate the use of redux-thunk, (which at its core is a few lines long), but you don't need to worry about any of this upfront. The thing with React is that unless you make costly architectural decisions upfront, you can always learn as you build, and figure out the right way to structure your project. Once you've built a fairly large project, you'll form your own set of opinions on which way you like to think about front-end code, and that'll inform you on your next project.

There is a learning curve, but with React, you are always thinking about fundamental things like encapsulation and message-passing than trying to learn non-transferable knowledge about a particular framework's quirks and conventions.

Those screenshots of code are kind of a challenge to read.

I don't get the boilerplate around App.main:

    var App = {
        main: (function() {
            window.addEventListener('load', function() {
                // ... initialization ...
            });
        })()
    };

The initialization code is with an event handler function, fine. But then:

- Then registering of that event handler is stuffed into a closure, although it doesn't declare any variables or pollutes the global namespace in any way.

- This closure is then called immediately and its return value is stored into App.main, although it doesn't return anything, so App.main is declared as "undefined".

So there are two layers around that code which serve no purpose at all. Why not simplifying it? All you want is an App namespace and an event handler for window / load:

    var App = {};

    window.addEventListener('load', function() {
        // ... initialization ...
    });

Or, if you want a "real" main function (i.e. an "App.main" that is actually a function):

    var App = {
        main: function() {
            // ... initialization ...
        }
    };
    window.addEventListener('load', App.main)

If you put your tags within , right before , you could simplify this further to:

    var App = {
        main: function() {
            // ... initialization ...
        }
    };
    App.main();