Rethinking Teaching, Learning, & Using React in 2016

I try to avoid Thought Leadering in blog post form, as it’s much harder than the usual “pithy tweet” form. But this question, and its responses, have gotten me thinking:

The short answer is: “building a complete React application is hard.” Building a complete React application requires learning tooling, it requires integrating other libraries, it requires more than just a quick perusal of some React blog posts.

How we got here

Ironically, when React appeared on the scene in 2013, one of its draws was that it didn’t have all the luxuries of a more comprehensive framework. While other JavaScript frameworks of the time required a large level of control and could only be used in apps conforming to a narrow set of standards, React was just a library, a view layer that could fit in anywhere. People dropped it into Backbone applications and started to replace jQuery plugins. Massive web apps dating from the times of MooTools, GWT, and YUI could be incrementally upgraded without changing the underlying data layer.

React didn’t bring its own object model or enforce an unintuitive set of concepts, it simply required a tiny amount of manual tooling configuration to build JSX. The original JSX compiler was quite simple, and could be easily integrated with RequireJS, or Browserify, or that baffling “Webpack” thing that no one except Pete Hunt seemed to actually comprehend. React worked fine as yet another piece incrementally added to a larger application.

Fast-forward three years, and the landscape has drastically changed. Many people still use React as just a part of another larger application, but now applications — and businesses — are being built around a “React stack:” React, a Flux implementation (Redux as of late), react-router, Webpack, and Babel. Ironically, as much as the proliferation of tooling and frameworks has been a common complaint of developers over the past few years, this stack (especially the tooling) is the closest the front-end community has had to a monoculture since we started experimenting with Node-based build tools.

Unfortunately, in the race to build this new stack, we’ve neglected to consider the newbie. It’s not surprising when you consider React was positioned, as most JavaScript frameworks were, as the “alternative to try once you’ve done it the hard way.” The idea at the time was that no new JavaScript user would ever start out looking at React: they’d build some kind of awful painful thing with vanilla JS & jQuery, and then find React as an alternative. The same approach was taken with Webpack (written as an alternative Grunt/Gulp/RequireJS/Browserify), with Flux (written as an alternative to two-way-data binding frameworks including Ember and Angular), and even with Redux (an alternative to Flux).

And for a while, that was fine. But as these libraries and tools became a stack of their own, people wanted to try them out. And, unfortunately, new users were confronted with an ecosystem that hadn’t been designed with them in mind.

Essentially, in our race to fix the problems of the JavaScript ecosystem of 2013, we’ve forgotten to consider coders who don’t have the background in these problems that we do.

The “Just Learn JavaScript” Fallacy

As I mentioned, there have been new articles every day from developers angry and frustrated that they don’t understand the tooling ecosystem, and their instinct is to blame the tools and the authors.

There’s a recurring theme I see in the responses to these posts. Developers who have been writing JavaScript for 2+ years tend to say things towards the effect of:

• Just learn JavaScript, worry about libraries and build tools later!
• Learn tooling and libraries incrementally; add software to your application as you need it.
• You can learn React in a JSFiddle, no need to worry about tooling right now!

To me, these responses seem, frankly, naive. At best, they represent a very different form of learning than what works for me.

As a (single) point of comparison, as soon as I started learning JavaScript, I started looking for the most robust, high-level abstractions I could find, because I knew that there were better ways to do things than what I was doing. And I cared about that because I had no interest in learning JavaScript as an abstract exercise — I wanted to build things, and I needed to learn the tools that would let me do that.

This led to me learning Ember way before it was ready for prime time, but because of that, I learned how to structure and build large-scale applications before I was actually at a company where I had to do so — which turned out to be very useful later on!

I don’t think there’s any reason why a relatively new JavaScript programmer, who understands the basics of the language, should not be able to immediately jump into an application built with React, Redux, Immutable.js, Webpack, and Babel. Right now, doing so must be extraordinarily difficult, but this doesn’t have to be the case.

This Is Not a New Problem

I mentioned before that I was an early Ember user. At the time, Ember was going through some similar teething pains. Many developers were building applications with Ember by using a Rails integration that used Rails’s asset pipeline. Those of us who had no interest in Rails were kinda left to fend for ourselves in a mishmash of Grunt scripts and other terribly inefficient build processes. And, worst of all, we had to build these projects from scratch, as there was nothing gluing any of these tools together.

Of course, if you wanted to learn Ember, you theoretically could get started with a CDN <script> embed of Ember and an in-browser Handlebars compiler. But this obviously wasn’t going to lead to building anything usable, and certainly not anything production-ready, and so I dove into the messy ecosystem that was browser build tools, circa 2013.

Like any brash upstart programmer, I decided that I should immediately try to solve not only my own problem’s, but everyone’s, so I worked with a few other like-minded coders on a project called ember-app-kit. It was messy, slow, and boilerplate-heavy, but it was a start. That project evolved into the awesome Ember CLI project, which rolled generation, building, and running of apps into one CLI tool, abstracting over a vast array of tooling.

Having watched the evolution of build tools in Ember, I can tell you, the problems that the current “React stack” are almost identical. The desire for Ember CLI came out of the incredible difficulty in getting users up and running with Ember. Sure, you could point them at a JSFiddle, or even use some development-only tooling that runs in a browser and just let them write everything into a single <script> tag, and this might get them far enough to learn “Ember,” but it certainly won’t get them far enough to learn how to make “Ember apps.”

With Ember CLI, they could say just say: npm install -g ember-cli && ember new my-app && cd my-app && ember server. And done. Obviously, there are many more complexities a user would encounter on the way to building a proper app, but this is all you need to run this app.

Seriously, check out the Getting Started and Tutorial sections of the Ember documentation — that should be our target.

Where We Go From Here

We have so many awesome tools at our disposal now. Three years ago when I was helping to piece together Ember boilerplate, we could only imagine robust, reliable, partial rebuilds for JavaScript applications, and now Webpack does that with about ten lines of configuration. I remember working on ES6 module transpilers and worrying that this was never going to break into the mainstream, and now everyone is building ES6 modules through Babel. I remember arguing with people that NPM would never be a platform for frontend dependencies, and now, I install everything from React to Bootstrap CSS files with it.

The only limitation now is combining and teaching these tools together. As a community, we should work towards building a canonical “way to get started with React.” It’s not that we just need a “React CLI,” it’s that we need a designated happy path to follow to build an application. This will involve software — codifying “best practices” into frameworks and tooling — but also better tutorials and documentation.

When we codify a stack into a framework, we provide a “black box” for new developers that works in their favor. We can smooth over implementation details and common roadblocks and provide an easier developer experience. We can make building applications easier for new developers without throwing a ton of mystifying NPM packages at them.

And we should remember: It is possible to teach many things at once. Michael Hartl’s Rails Tutorial is testament to this. It’s one of the best programming books I’ve ever read, and is a beautifully pragmatic guide that teaches everything from minitest to Heroku to Bundler to Git. While the official Rails guides aren’t nearly so comprehensive, they still manage to cover more ground than any single library’s reference documentation, or any scattered blogpost, ever could. I hope the community can invest (both in time and funding) as much in documentation as it has in code.

In 2016, let’s build cohesive frameworks, not boilerplate. Let’s build applications using best practices by default, rather than stumbling over trial-and-error configuration. And let’s make sure new React developers have the resources they need to avoid the same mistakes we made.

As a postscript, here are a few recent efforts in React stack documentation and tooling for beginners:

• Tero Parviainen’s Full-Stack Redux Tutorial is an impressively comprehensive look at building server-side and client-side Redux apps from scratch.
• Juho Vepsäläinen’s book SurviveJS covers Webpack, Babel, ESLint, and other JavaScript tools while teaching React & Flux.
• GlueStick is a command-line tool abstracting the boilerplate of universal React applications.
• Jonny Buchanan’s nwb tool simplifies the configuration and use of Babel, Webpack, & Karma, and also includes generators for scaffolding React applications
• I’m working on a framework/command-line tool called Earthling, inspired by the same concerns that led to this blog post. It’s in a very experimental/spike-y phase right now, but it’s made me optimistic about future possibilities in this space.

(thanks Allie, Paul-Jean, and Scott for beta’ing this post!)