Flux slowed me down at the start, but React was rather easy. Easier than Ember for example. The API surface is tiny, everything is done with components and the composition of them.
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.
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.
The recent Ember 2.0 roadmap suggests a more React-like workflow with an emphasis on components and HTMLbars driving the bulk of the framework. It still has all the lovely two-way data binding but it's complimented with a more fun workflow for writing the view code. I like Ember Components because they marry the best parts of the upcoming (and exciting, but disappointingly slow-to-market) Web Components with a workflow similar to React.
> I can tell you from experience that this code will ruin your life
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 doesn't tell you 'who changed the header' either. Other than having a central point through which changes are routed: like a function.
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...
Right, and you have to figure out who changed the model in React too. You don't get magic traceability. If you want to know what caused a change, neither helps. If you want to know what changed the DOM, both allow you to do that. Only React makes it implicit (it may choose not to make any change, for example), this approach is explicit.
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.
You get plenty of magic traceability :) Check out redux. You get it in vanilla Flux if you use immutable data. I would also suggest using React for a toy project to learn more about it. The "pure"ity of the render function means you can trace the state of the DOM directly to a Javascript object (declarative), which was the point of the article's example. Your "down the road" code is imperative, as in someone changes the DOM independent of the state of your data.
You're not converting between data structures in your example, you're mutating a stateful system. Moreover, I'd rather leverage a library so that I don't have to manually do everything myself.
I couldn't work out what point you're making in this response, sorry.
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.
React encourages declarative usage. You declare some data and how it will be rendered in JSX templates, and React does its thing. As a consumer of a library I shouldn't have to care about what goes on under the hood, as long as I know the API and its proper usage.
> 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've found it cleaner and easier to track changes to your model data and let the view be a declarative representation of said model. YMMV though.
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.
I agree on the first line. I think there are very simple cases where hardcoding HTML in Javascript might be okay, but it is dubious. We use templating (both an internal simple templating system which is literally 20 lines of code, and in some cases React, when it is warranted). But I don't think you're getting what I was trying to say. Sorry, for the confusion.
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.
Note about the wide variety of flux implementations that scares people:
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.
We are also switching to Redux after trying Alt: Redux solves a couple of fundamental problems with the original Flux architecture (in fact, Redux isn't actually Flux).
I just wished Redux was a bit more opinionated. But it not being so will certainly please many other people.
This is really good to hear! I would really appreciate a single-page / pdf / ebook version of the redux documentation. Tough to read offline in the segmented pages. Maybe I'll get my wish, since it was rendered using "gitbook".
It would be interesting to see a side by side comparison of people coding for the exact same output, and the time difference between them. If React is supposed to make coding faster, then why is the code a black box? Why do I have to debug the React source code to find out what's going on. Too much div soup, too much abstraction. I genuinely would love to see a code-off between developers where they make a simple TODO app, with one in vanilla JS and the other in React. Presuming the React developer has mastered React and won't run into some form of roadblock (which is rare).
Was that because you now structure you code in a better way, or was it because of React's functionality? And what aspect of the functionality was the most productive? The templating system? Did you used to hand-code your HTML in jQuery, or did you use templates in the HTML document?
A bit of both. With React we now have a much nicer code structure, because it forces us to think in components. We have a JS file and an SCSS file for each component. Before we rendered the view on the server side with Python/Jinja2.
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.
>Client-only rendering is why Soundcloud feels so slow and why Stack Overflow (purely server side rendering) feels so fast.
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.
Isn't this the benefit of an isomorphic architecture? Get the initial speed of server-side rendering but then let the feature-filled ajaxy goodness take over.
ReactJS for stupid people: "oh great another JavaScript framework, so tired of all the hype, can't wait for the next one to come out 17 seconds from now", etc etc
You clearly didn't read the article. One of the biggest misconception is that React is a framework. All React does is render views dynamically. It gives you almost nothing else. React is an alternative to manipulating the DOM using jquery, which usually leads to hard-to-debug spaghetti view code.
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.
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.