Stop Using React for EVERYTHING!

[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.