No, they aren't. React is complete overkill for lots of the uses people have been using it for.
Going back the last 5 years, we've had Backbone, Ember, Knockout, Cappucino, Marionette, Angular 1, Angular 2, React, Virtual Dom, and even more frameworks I'm not recalling right now. It has been a constant progression of one js framework to the next, all trying to solve the same problems in a variety of ways.
Meanwhile, actual work has been done just building sites based on the best practices of the last 20 years with tons of practical advancements being made with low level protocols and new browser capabilities.
Yes, I have used most of these frameworks. For a vary narrow set of application types, they are suitable. But they are not useful for the majority.
At Nordstrom we are rebuilding the entire site with React (yes, even on the servers). Only ~0.5% of users are seeing it in production at the moment, but more is coming soon! So far it has been faster than any previous overhaul attempt and is looking to be very maintainable. It really is a pleasure to work with.
Mostly jQuery and mustache composed as AMD modules pulled in with require.js. The backend was varying flavors of MVC .NET. It got the job done and required little on-boarding time but was very difficult to maintain.
React + flux in comparison provides a very prescriptive way to modularize code that promotes re-use across the company. We've begun publishing our common components to a private NPM registry to get some SemVer goodness.
The only pain point so far has been jest, but it's easy enough to use a different unit testing framework. I'm very partial to mocha with chai assertions.
The projects they're open sourcing are not just hackfest ideas or work that interns contribute, these are tools Facebook uses in production. Facebook open sources only what it uses in production—this way, people know that their offerings are supported and valuable.
Your comment is just as out of context as the one u/nathanjd made. The difference is I'd actually like to hear his experience in this matter. You are just parroting press releases.
the projects I work on for my employer (3 days a week) dont use react (they have their own stack). The rest of my time I spend on developing a pretty big react project which is not yet in production. Had 2 small React projects (SPAs for interal stuff) before that.
I first picked up react dec 14' and had tried various things with it. The most frustrating was trying to combine libs that havily change the DOM with the react-render-cycle. Why are you asking?
That's still a rather easy solution compared to quite a number of frameworks.
When your component mounts into the DOM, you then wire in whatever DOM-manipulating library you're using to the local DOM element(s). To prevent React from interfering, you use shouldComponentUpdate to trap and handle any data updates and return false (so no re-render). In the componentWillUnmount stage, you unwire whatever you're using.
Two and a half out of three of those are things you'd need to be doing anyway. The only major change is returning false to prevent re-rendering.
7
u/te7ris Aug 27 '15
give me one good reason NOT to use react for everything.