ReactJS for Stupid People (2014)
blog.andrewray.me
blog.andrewray.me
Flux on the other hand was hard to grasp, since all of the different implementations and the naming problems. Actions in MVC are just methods of the controller classes, but in Flux they are objects, which kinda threw me off track right in the beginning.
Also, I came from ExtJS and Ember and was accustomed to two-way data binding and the whole Flux thing felt backwards, because interacting with the Models in Ember-Data didn't take any effort. After they were bound I just needed to type my data and they get updated automatically. I just had to look about gathering them at the end and send their updates to the server.
I was always confused with 'Flux' and was never able to understand it. Redux is very nice.
But I didn't choose it. Another dev at the current project did.
It took me a few weeks to fully understand what Redux is about. I didn't know about "one store for all", the difference between actions and action creators and how immutability was mandatory.
I just jumped in and started my first component with a (rather bad) tutorial I found with google and copied a Redux store and actions from a co-worker.
The Redux docs weren't good till 1.0
After I asked Dan something I realized I got it all wrong. But now I think it's a really nice way to do front-ends.
$.post('/login', credentials, function(user) {
$('header.name').text(user.name);
});
The alternative isn't React. It's
$.post('/login', credentials, function( user ) {
setUserName(user.name);
});
// Somewhere else...
function setUserName(name) {
$('header.name').text(name);
}
React gives you incremental HTML rendering via a virtual DOM. Which saves you having to do that manually (though in many cases you don't need to do it at all). A lot of this article reads like framework-fetishism.
On Flux, I like his comments there. I'm thinking of reinventing the command pattern in Javascript and calling it SuperFlux...
This approach punts the ball into part of the field you can see, understand and control. React punts the ball into someone else's stadium.
Framework-fetishism is being enamoured by things a framework does that you could do yourself in a couple of lines of code. Unfortunately Javascript programmers seem to be very vulnerable to it. There are good reasons to use React, but they aren't what the article wants to praise.
So how do I tell from React where my model was changed, in what bit of my code, that I couldn't tell just as easily in my own function?
React is only declarative in as much as it provides an imperative function to convert between data structures. You can do this yourself, and should.
I was referring to the claim that React is declarative. Not my code.
Things aren't declarative magically. A declarative system is one where you declare a data structure, and you feed it to a separate bit of imperative code that operates on that declaration. In react's code, the 'declaration' is a set of HTML templates and the 'operation' is to create a corresponding DOM.
> you're mutating a stateful system
Both approaches do. React mutates state too.
> Moreover, I'd rather leverage a library
Good for you.
For some things React is a big time saving. But for many things it is a waste of bandwidth, a waste of development time and a waste of programmer education. Just like any library that isn't required. Using libraries is not free.
If you want the kinds of benefits the post highlights, you can get them much cheaper with a few lines of code. If you want to import a full library to save a few lines of code, that's your prerogative, of course.
React shines when you need a templating system and you can benefit from the performance of a virtual DOM. If you want a basic virtual DOM, then you can do it very easily yourself (a few lines of code in the simplest case), but as things get more complex, it becomes a better tradeoff in favour of React. If you want a comprehensive system, React becomes a very useful tool, one I rely on myself. But it is important to understand what you need and why. If you don't need a virtual DOM, then using React seems pretty foolish, to me.
Javascript is full of frameworks, and full of programmers who use them without knowing what they're for.
> Both approaches do. React mutates state too.
Right, but I don't have to concern myself with the stateful system (the DOM). I can delegate that responsibility to React.
As to your other points, I agree that people should put more thought into their selection of tools.
I'd much rather punt the ball into a stadium with some properties/parameters than run the logistics of a game myself (security, ticket sales, refereeing, etc). It's saved me gobs of time as a developer. Again YMMV.
On the second point, it depends on how hard you think the logistics are. Often the logistics consist of a couple of sweaters for a goal, and a ball. Knowing when you need a 100,000 person stadium, and when a back yard will do is the trick. Which gets lost in framework-hype. And when a post lauds a stadium because 'it has grass, guys!' then it sounds like they're buying into the hype rather than the reality. If the OP had said 'it has a kick-ass virtual DOM - never write DOM synchronization code again!' then that's a different matter. But it didn't. See what I'm saying? I'm definitely not being anti-React or anti-Framework.
> React gives you a template language and some function hooks to essentially render HTML.
This is actually wrong, despite the official page saying the same. It's the biggest misconception in the React community. render() function outputs a data structure which describes HTML and ALSO user event handlers on that HTML. Any UI program does both: handle input user events and generate graphics output. A View is only the latter part, hence React cannot be only the View.
Refer to original MVC paper http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
> A view is a (visual) representation of its model.
> … a view should never know about user input, such as mouse operations and keystrokes.
1: it's not that big a deal if you choose the "wrong" one. Flux implementations are small and based on many similar concepts. Even if you choose one that ends up being unmaintained, your flux choice will still stay a solid choice. We are using 3 different flux implementations in our apps, and have no plans to migrate any of them.
2: It's starting to look like redux has "won". Flummox, which was previously a leading contender for the title, now recommends redux. Redux has a very simple core, is an excellent merger of the best concepts of flux, elm and others, has great documentation, and an extensive ecosystem of plugins.
I just wished Redux was a bit more opinionated. But it not being so will certainly please many other people.
We use React since four months, and we develop faster compared to before, when we used only jQuery.
(Genuine questions, not making a point).
I think there are many reasons for the productivity boost. Thinking in components, more readable code, great debugging possibilities, understandable data flow, to name a few.
And, last but not least, it is lots of fun :-).
Soundcloud might be "slower" than StackOverflow because it continuously streams music while you're navigating the page. A car is also slower than a drag racer, because it fits multiple people, luggage, and conforms to several safety standards. But maybe we should all be driving drag racers instead.
I've been doing React for a few months now. I definitely like it better than Ember/Handlebars, Angular or vanilla jQuery for managing views. It's much easier to reason out what your view looks like and how it can change.