The React Curve

Shortly before the Christmas of 2015, Pete Hunt engaged the Javascript community on Twitter, asking where newcomers to React experienced the most difficulty.

After seeing a call from responders for an article summarizing responses, and after reading Eric Clemmons’ post on Javascript Fatigue, I decided to do some analysis of the original tweet’s responses. To get an idea of the content of the replies, I did a word count of all responses using the code here.

• Tools and Tooling: Mentioned 22 times
• Redux and Flux: Mentioned 16 times
• Webpack Alone: Mentioned 12 times
• Babel Alone: Mentioned 5 times

To run the code, and see how the results were gathered, simply type the following into your terminal.

git clone https://github.com/Connorelsea/TwitterAnalysis
cd TwitterAnalysis && npm install && npm build
// Edit twitter_account.js and add your Twitter developer info
npm start

The Responses

Though some responded with critiques of React itself, I and many others found that these are minor, asserting that the real problems lay at the feet of its complicated tooling and infrastructure. Most of the responses and critiques had little to do with React itself, and far more to do with it the overbearing set of tools.

This tweet sums up the feelings of many users’ responses and critiques I have heard in the past. Though, as Hunt responded, where do we draw the line on what may be considered difficult to a newcomer and what may not?

React-Colored Glasesses

A few months ago, I came into the Javascript community as an almost complete beginner. I came from a heavy object-oriented background in Java and held an intermediate knowledge of HTML, CSS, and Javascript. After learning Express, functional patterns, and ES6's crazy syntax (compared to Java), I felt that learning Javascript was going well. I had created a few, albeit simplistic, express applications and I was ready to move forward. After researching where to move next, with the intent to create a simple SPA, I found React and began learning — and shortly after, I realized that the journey I embarked upon was far larger of an undertaking than I had imagined.

The first hiccup in my journey through Javascript was at React.

I entered the Javascript Freenode IRC, asked a simple question, and someone gave a simple response. I was pleased until I realized what I had unearthed. Shortly after their answer, another user voiced dissent, presenting an argument for progressive enhancement, that at the time, went far over my head. More users piped up, throwing their words of wisdom into the conversation.

“Well hey, be sure to use Babel and Webpack to get the best of ES6 and JSX!”

“No, why use Webpack? Browserify is much simpler and conducive to my isomorphic boilerplate!”

“Isomorphic!? Don’t you mean universal!”

“Remember, you’ve got to choose a way to manage data and state. I personally use Flux.”

“Flux!? Anyone who’s anybody is using Redux!”

“Redux is a fad. I’d use Reflux or Vue.js… or maybe even Meteor with…”

I left the IRC — heading to a Google search page with nothing but an expanded vocabulary and a spinning head.

Unfortunately, even though I’m sure advocates clinging to their respective stacks are trying their best to be helpful, throwing progressive enhancement and isomorphic architecture at a newcomer asking, “What is React?” is not the best way to handle beginners.

React, and many of the tools surrounding it, are heavily unopinionated, which results in much of the community rolling their own stacks, patched together with their favorite libraries from NPM. I am not an advocate for making React more opinionated, or having Facebook include more proprietary tooling, but I am an advocate for experts writing tutorials or guides to remove their react-colored glasses. The ambiguity of React, and the freedom that comes with it, is both a blessing and a curse.

Most of my confusion stemmed less from React itself, and more from the paralysis of choice. In addition, structuring applications using React and the tools in its ecosystem was my first experience with this level of professionalism and complication. I was being introduced to completely new application architectures, 4 or more build tools, and libraries from everyone’s favorite stack that “ you just have to use!”

Though I have learned much more about React, Webpack, Babel, and other ecosystem tools since then, I do remember the rough beginning to my journey. I suspect many of the developers, though of course not all, creating tools in the React ecosystem grew up with Javascript, while others like me simply jumped onto the moving train and took off running.

If anyone has more idea on how we as a community can combat this rough beginning to help newcomers in the future, let me know.

Meta-Fatigue

Though meta posts such as these may be cumbersome, it is a valid conversation to be had. The problem lays not in React, but the culture surrounding it. The JavaScript community is fantastic, inspiring, and is creating some really cool stuff. The problem is that too many of these amazing developers are too focused on creating the future to realize that adoption matters, and while experienced developers adopting your library may catch on quickly, beginners may not. In addition, many forget about their humble beginnings, offering newcommers advice that is simply not fit for someone at their level.

Move fast, break things… but write great documentation along the way.