On “Keeping Up with Javascript”
Last week, I presented some thoughts on “Keeping Up with Javascript” at the React.js SF Bay Area Meetup. You can see my slides below.
Here are some of the questions I received from those present at the Meetup that deserved a little more exposition.
On “When to Move Fast”
During our transition from Backbone to React, we made the (seemingly) bold decision that instead of devoting an insurmountable amount of resources to completely rewriting our numerous applications in React, we would approach development in two ways:
1. All new applications are written in React.
Greenfield projects (those that lack the constraints imposed by prior work) get the flexibility of using React to its fullest, without worrying about previously established conventions.
2. Provide escape hatches in legacy code.
In our brownfield projects (existing, legacy code), we provided wrapper Views that could handle rendering React components. This meant that instead of propagating the usage of Backbone, we can slowly chip away at existing Backbone applications and use React how we expect to.
The combination of these two approaches made it simple to incrementally introduce React rather than deal with a wholesale replacement of existing, well-written (and well-tested) Backbone code.
As for how “upset” people were, a lot of it was due to that previously mentioned flexibility — because we were moving so fast and introducing a library we hadn’t used as much as Backbone, there was a stark difference in the conventions we had to follow:
Writing tests was (and is) painful without the proper test harness.
Each team had taken it upon themselves to create one that worked for themselves. We ended up building our own test harness to deal with very common use cases like rendering to the DOM and providing `context`.
Shimming React components into Backbone Views isn’t exactly ideal.
This caused more than a few issues because of the loss of `React#context` as well as made things like the React DevTools extension not work as expected.
That all being said, as soon as we did our due diligence to establish the same conventions and developer ergonomics as our Backbone code had, concerns around our transition to React largely dissipated — developers who have used React extensively have found it to be an efficient and delightful improvement over our homegrown Backbone stack.
On “Our Transition from Backbone to React”
I’m actually part of an open source project that’s written in Backbone years ago, and we’re thinking of migrating to React as well. It’ll definitely help a lot if we have a better idea of what we’re dealing with before we actually execute it. — via email
The topic of our transition from Backbone to React is obviously much more involved than what’s above, and deserves to be discussion topic of its own. How it started (a twenty-page document) and how it has ended (a four-page retrospective) are just a few of the things we’d like to share around the technical and non-technical parts of that particular transition. Of course, we’ll synthesize all that in a much more digestible manner, but if learning more about how we’ve moved from Backbone to React is interesting to you, please reach out!
On “The One Way™”
…are there more docs anywhere on “The One Way” and your process? … [I’m] curious if there are more like minds about UI infrastructure as you called it? — via Meetup.com
One way that we’ve approached reining in the ever-changing Javascript ecosystem has been to establish a clear set of constraints in the tools we use, dubbed the One Way™. The thing about it is, its less a process and more a clearly established set of constraints that help set the expectations of our developers. Not only can we have less debates about what tool resolves a trivial need, but we can also make sweeping improvements across the codebase without concerns of some parts of the site being out-of-date.
Some of the things we’ve declared as part of the One Way™:
All presentation code should be using React.
This one should be fairly obvious, I hope!
Components should declare their own data requirements.
We accomplish this via our own data declaration language and will soon be using GraphQL to do this.
All code should be universal.
This means that code can and should be capable of running on both the client-side and the server-side. Whether or not we actually end up running it in both places is besides the point.
All applications use the same workflows.
Developers using the same tooling, lint rules, and deploy processes makes moving between applications (and teams) a trivial task.
Of course, there are a great many other things that are part of this, but in the course of their day-to-day work at Coursera, a developer should spend their time working on the problem they’re trained to solve, not thinking about the tools they use to do so.
Much appreciation to the React.js SF Bay Area Meetup for giving me the chance to share some of my thoughts, to Bryan and Lewis for listening to the talk too many times, and to Leith for helping shape the ideas we see here today.
