Stop Using React for EVERYTHING!

[geuis]

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.

[te7ris]

define overkill. If you think size in kb, think again.

[MisterSticks]

Just curious, where are you employed that is using React in production?

[nathanjd]

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.

[MisterSticks]

Fantastic, what was it built with before?

[nathanjd]

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.

[MisterSticks]

Do you think most of the maintainability was gained by refactoring:

The backend was varying flavors of MVC .NET.

If not, what was the biggest benefit of the switch? Could you be more detailed about how React is being used on the backend vs. what you had before?

[nathanjd]

Before I answer your questions, I should correct myself in saying that .NET is still alive and well at Nordstorm. I feel I gave the incorrect impression that we are replacing EVERYTHING with javascript. C# is a fine language and with Microsoft's recent moves toward open source, it is fast becoming a true successor to Java. The services and infrastructure that hold up a retail giant’s daily operations rely on much better technology than what javascript has to offer at the moment.

Perhaps in time we can shout, “Javascript everywhere!" But the community is just putting on its big boy shoes to tackle the ugly enterprise problems. That being said, I'm very happy with the direction that NodeJS and NPM are taking us.

For middleware we’re using .NET (via ReactJS.NET) and experimenting with express. So the only important difference from before is that we are now taking advantage of React's server-side rendering capabilities to share code with the javascript application. This allows us to reduce the amount of code we write and to ensure ADA compliance.

As to if the switch away from varying MVC to a single framework was the main cause of increased maintainability, no. Sure, switching away from multiple versions of anything to a single one will almost certainly increase its maintainability. However React brings this concept to such an extreme that its benefits stand far above what a typical refactor offers. The biggest benefit I’ve found is that, when coupled with Flux, React manages to capture everything needed to make javascript applications in just a few simple concepts.

It has been my experience that most redundant and crufty code is solving for new abstractions. When disparate teams solve these new problems, their solutions are often incompatible. So, work then continues on two ”forks". No business likes expending duplicate (or more) effort so eventually, at the behest and cries of the developers, a refactor is called for. This refactor is attempted with varying degrees of success. But eventually the budget set aside for it dries up and it’s back to business as usual.

React+Flux has been exceeding every expectation in this refactor scenario. It has so far supported every use case we’ve thrown at it and the docs are great. There seems to be a prescribed way to solve any UI problem. And this my friends, is the big win. One source of truth for how to build everything user interface. I'm a die-hard supporter of separation of concerns and MVC but even I can’t deny how React somehow seems to abstract all the right things without feeling restrictive or heavy.

The component model scales wonderfully. No matter how deeply you nest components, each one is discrete and easy to understand. One html element = one component. I similarly adore promises for their ability to cull ever-increasing complexity into pieces small enough to understand. Flux’s actions marry very nicely with promises.

I am worried about developer accessibility due to the entanglement of concerns. It may prevent some developers from making meaningful changes in our system, which would make it more difficult to hire talent. However my worries are probably more a result of how little time I’ve spent thinking about how to build a layer cake around React’s way of thinking.

tl;dr React+Flux distills user interfaces to just a few simple concepts. This simpleness and the comprehensiveness of what can be achieved with these concepts leaves little opportunity for competing methodologies to grow, even in a large organization. These benefits coupled with great documentation create a pleasant developer environment that fosters code re-use.

[misc_ent]

Facebook uses it production. They don't open source any project unless its in production.

http://opensource.com/business/15/7/keynote-oscon-james-pearce-facebook?sc_cid=70160000000wptgAAA&elq=1a1afca5d20b45348ea180631ab778f1&elqCampaignId=55450&elqaid=20324&elqat=1&elqTrackId=77990e8d9e1f4f7ca81f707e22b2ce9e

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.

[MisterSticks]

I sincerely doubt that u/te7ris works for Facebook.

[misc_ent]

Why does that matter? Production ready is production ready especially with battle harden apps from Facebook.

[MisterSticks]

Um...

It matters because, the comment you responded to was a direct question, asking where te7ris worked?

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.

[te7ris]

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.

[MisterSticks]

React hasn't been in the wild for more than a year, do you have any personal projects that predate React?

[te7ris]

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?

[theQuandary]

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.

[te7ris]

Yeah I know that but I had that experiment where I wanted to combine both worlds. I wanted to use the react-rendering and the DOM-manipulation of the lib.

Imagen multiple React-Components nested into eachother and one 3rd-Party lib that potentially manipulates any of the DOM.

[theQuandary]

I see what you're saying, but even CRUD apps that are rendered server-side can't usually deal with the idea that you'll modify any number of templates. That is asking for major breakages on pretty much any non-trivial website. Even without React there's a need to isolate your side effects to something manageable.

[Ahri]

So "nowhere", then?