React makes me sad
A story of technology adoption
The other day I was taking a glance at my news aggregators and came across a rather interestingly-named post “React makes you sad?”
I never expected anything coming out of lobste.rs to hit so close to home. I’m really not sure how I feel about this. It wasn’t until this inconspicuous little work of comedy that I went from light-hearted pandering over the struggles of using React to actually considering how it has effected me as a developer and the community at whole.
Yet Another Shallow Developer
Just a little over a year ago I started working on this shitty little Angular app because why not? I was hired to write an Angular app, and there wasn’t really anything pushing me to do anything about it. I just didn’t care. I noticed the emerging discussion around React on IRC, and got a taste of the early community. I had spent some time with React in the past — only toying around of course.
At the time I considered React to be very progressive and the new community to be far more “modern” in their taste of tools and architecture. Everyone just went ahead and used browserify and setup a build system to handle compiling JSX and used npm and so on. With my Angular app, I was still adding HTML script tags to my index.html and handling routing with a hash in the URL.
It only took two weeks into the Angular project before I decided I needed to use some npm modules. I took the time to setup browserify and organized my package.json so that the installation and build process made sense and felt like every other “modern” stack out there. After I setup gulp, and was incredibly surprised with how easy it was to get going.
Conformism
Then another weekend came and I spent some time on another toy React project. This time I grabbed an off-the-shelf flux framework and just started messing around with things. Afterwards, I was incredibly intrigued by how well it seemed to work. There were multiple layers where I could resolve the ambiguities in the different states of the UI; I could distinguish between what information belonged in my stores and what state stayed in my components; I could abstract away all these silly things about how something was presented when I implemented all the code behind handling API interactions. I realized it wasn’t really that I could — but rather that React/Flux encouraged me to distinguish between the different layers in the application due to the rigid boundaries between them.
In Angular, if you were to write a service class that held some shared state and exposed some methods for interacting, everything would be tied to that service class. Your controllers would depend on it; they’d reference the service’s instance directly when calling methods on it; your route resolvers would asynchronously instantiate it with it’s initial data, etc.
With React/Flux, there were (although only by convention) many layers where certain logic would belong, and it was hard to break those boundaries. You might have some state in a store, but the store is only known to your top-level component that listens to it. Instead of having something in your component that reaches out and interacts with a store directly, it has to dispatch actions. Those actions create a very hard boundary between your stores and your components; You have to encapsulate the relevant information in that action’s payload. Your component is responsible for abstracting away all the DOM events and view logic and providing it’s end of the bargain when dispatching an action.
There are some other, more-concrete aspects to React/Flux that I found pretty interesting as well. All in all it meant that I decided that React/Flux was the way of the future. That shitty Angular project I was working on?
I rewrote it in a React/Flux stack over the course of a few hours.
It was from that day forward that I really shifted onto the scene
guns-blazing using ES6 compilers with experimental build features, meticulously maintaining a complicated build architecture, building TodoMVC with anything that said “flux” that arrived on the front page of Hacker News. I got hip to isomorphic rendering and even wrote those speculated “integration” tests where I fired action after action into the machine and wrote assertions on the state of each store.
Hipsters and their fads
I got the opportunity to start a new professional React project and this time I wanted to see what I could build myself with everything I’d learned. I built a suite of libraries to handle everything from dependency resolution to routing and it even handled isomorphic rendering seamlessly. They’re on GitHub if you want to check them out (although with horrible documentation).
As I started actually talking about this and even giving a few presentations, I found this to be a very common pattern that other teams have fallen into as well. Everyone and their dog in this community of JavaScript Hipsters™ wrote their own framework and plugged together their sleuth of compile steps and debugging systems, and it stopped being about React or Flux.
It even stopped being about ES6.
Over the history of the JavaScript ecosystem there have always been fads and there’s always been an emphasis on what is hot and new over what is proven and old. The community moves fast. Many would say that this whole React/Flux movement is just another one of those fads that’s going to be left behind when another technology hops in front and says “Look at how much better I am!”
I’d say not only is this movement just a fad, but it’s a campaign. React is only popular because Facebook made it popular. They did a decent job marketing in a way that made enough developers comfortable adopting it. Developers have this innate desire to absolve themselves from all the problems with their current tools. The grass is always greener. It’s easy to convince us that something new is probably better.
This movement stopped being about React and Flux, because along with the waves of adoptions of React/Flux, those developers also adopted new build systems, new language features, new routing libraries, new ways to interact with their API server, etc. It gave everyone the opportunity to say goodbye to the ways of old and hello to their greener grass in almost every area of their stack.
Utopia
Ha! I lied. No Utopia here, although a lot of people seem to think so. I’m starting to think it’s a form of Stockholm syndrome. Of course, as with any new technology (or any technology in general), people started to have problems. Core packages would introduce breaking changes every month. There would be oh-god-so-many bugs in all these experimental tools that people didn’t think about before using. I personally spent a hell of a lot of time working in a problem space that was practically already solved.
People seem to be happy waiting 8 seconds for their bundle to recompile, or spending hours every week trying to fix their incredibly complicated build system in order to keep that compile time low enough, or diving into source map bugs that are making browser debugging impossible, or having to throw away so much infrastructure when their routing library decides that being easy to use is a bad thing.
There are certainly some things that are pretty awesome about React, and there have been many new libraries that try to compete with it. None of them are really catching on but I don’t really know if it matters. Hopefully many of us have learned our lessons about adopting new stuff. But maybe it’s just because our tooling really sucks. Maybe all the Ember people were right.
When I first started to use React and Flux to build an application, I wasn’t using any ES6 features or a complicated build system or a big boilerplate project or any libraries to make data sharing easier. Everything was relatively simple, and of course there was boilerplate involved with just about every part of the code, but in the end that project has survived a lot longer than any of my other ventures into React.
My theory is that many of us obsess with automation and synthetically reaching our Utopia of programming standards. Arrow functions, destructuring, JSX all appeal to our side that’s sick of having to handle function binding or namespace prefixes or external templates and once we get our syntactic sugar fix we simply can’t get enough. It’s a matter of discipline or convenience but we treat it as a matter of standardization and compliance.
Of course, in Utopia, all of this would be standardized and suddenly we don’t need tools like Babel or Webpack. This is what we tell ourselves to justify the pain, but we fail to actually weigh the costs and realize that this Utopia is only a carrot on a stick that is driving the JavaScript ecosystem’s revolution.
