Write Your Own React.js!
Meditation is incredibly difficult for me. First, I sit down. Second, I do some stuff with my arms and legs that I’m sure looks “zen.” Third, I’ll start deep-breathing, or what I think is deep-breathing because who has formal training in deep-breathing?
Within two seconds my phone has buzzed, a bird has chirped, water is dripping from the faucet, and my leg has fallen asleep because I’ve been sitting on it. If I can make it through the onslaught of noise and distraction (which I often can’t) to the end of a session any pro-meditator would laugh at—I feel no different.
If it’s hard for you to find enlightenment through meditation, like myself, it may be easier for you to find enlightenment in rewriting the front-end web framework React! I can’t promise enlightenment in relation to the universe, but instead enlightenment relative to the JavaScript web community that we call home.
In the past I’ve written my own “React” (twice). This essay will reflect on some of my experiences and advocate that you write your own React as well. You’ve probably never heard of my artisanal micro-frameworks, and I’m fine with that. I learned a lot building them and now I get to share that knowledge with you.
There are a lot of “React”s
The core principle of React is actually very simple and surprisingly beautiful. Most conference talks about React mention this principle, so you may have already heard it.
The principle states that a user interface should be composed of components which are pure function that take in some data and return a view. That’s it!
In a more technical style, this principle is denoted in arrow-function style as (data) => view .
React, of course, does a bunch on top of that core principle adding lifecycle hooks, state, and an event system. Yet these extra goodies are really just implementation details which allow engineers to conveniently use this pure functional principle. These implementation details are fairly easy to change when you write your own React, as many already have.
One of the more popular React alternatives (at least in my Twitter feed) is Preact which shares a very similar API to React. Inferno is another popular React-ish implementation.
If you want to venture further away from the React API you will see Cycle.js, Choo, Mithril.js, and more…
Even React Fiber, the React core team’s experimental rewrite of React internals is just another set of implementation details on top of the core abstraction!
There are a lot of “React”s…and you should write another
There are a lot of people who love and use React, but obviously the implementation details on top of the core abstraction have not yet settled since we have so many alternatives.
The ecosystem is still experimenting. Still trying to decide on just the right tradeoffs (including the React team itself with React Fiber).
You should join in on the experimentation! Why? I’d like to propose three reasons:
- React is bad—kinda
- It is easy and fun to write your own React
- React enlightenment
1. React is bad—kinda
I’ll admit, that headline is a little sensationalist. I don’t actually believe that React is bad, and I don’t know anyone who would argue that as a whole React is bad. However, there are some tradeoffs that React makes which may be bad for your specific use case.
For instance, the minified JavaScripts for React version 15.3.2 is 149 kB. Whereas the JavaScripts for Preact version 6.4.0 is 9 kB, and that’s including everything required for UMD. That puts React at 16 times larger than Preact! Depending on your use case filesize matters, and React made that tradeoff for features over filesize.
Another tradeoff React made is that its server rendering API is synchronous. The fact that React has a server rendering API to begin with puts it way ahead of other frontend frameworks, however the API’s synchronous nature means server side-rendering with React can be slow. A streaming server rendering API would be much better for the performance of universal React apps, but it would not be possible given the current design of React.
Most applications really don’t need to be server-side rendered (SSR). However, there are some applications which could benefit greatly from SSR. If you are in the camp where SSR is a requirement, you might consider writing your own React.
One final tradeoff is React’s component interface can easily be stateful and imperative. While the React component interface is capable of some really amazing functionality, if you are down with the functional programming crowd the imperative nature of the React component API may turn you off. Whereas something like the functional component interface composed of observables with Cycle.js may be more interesting to you.
From beginner to expert, we’ve all had at least one gripe with React (method binding in component classes anyone?). When we write our own implementation, we can fix our own problems. Who knows, maybe there are many other people with the same problem and you will have advanced the industry two years?
2. It is fun and easy to write your own React
You are interviewing for a job where the team uses React, and they want to know if you are a React expert—they want to know if you are the real deal. Imagine, your answer to the question “Do you know React?” could be: “Yeah, I rewrote React in my spare time.” That’s some major street cred’, but the best part is it isn’t actually to get to the point where that can truthfully be your response (just don’t tell the interviewer that).
The hardest part about writing your own React is the Virtual DOM implementation. Lucky for you, a lot of smart people have already spent a lot of time writing low level Virtual DOM libraries. virtual-dom is a classic one which Elm used to use, and Cycle.js uses snabbdom.
If you are interested in writing your own Virtual DOM (VDOM) implementation, you also have some great talks to draw implementation inspiration from. Including Lin Clark’s “A cartoon guide to performance in React” or Paul O’ Shannessy’s “Building React From Scratch”.
If you want to transform the JSX language extension there is the classic Babel plugin used by React developers everywhere: babel-plugin-transform-react-jsx, and I have created a more general Babel transformer called babel-plugin-transform-jsx.
After you have your VDOM implementation and optional JSX transformer, all that’s left is defining the interface. Defining the interface, the API, is the most fun part of all. There are an infinite number of possibilities now that you have complete control of the abstractions! You can design the perfect component API for you or your team’s preferences.
Designing your own API is a very rewarding process. In the past getting to the point where you could design an API for a frontend framework would take months of work and you would need to be a master programmer (think Angular 2). Today, you can use a dependency for all the hard stuff and get creative with the rest.
3. React enlightenment
The third benefit of going through the fun and easy process of writing your own React is enlightenment, or some other fundamental realization which makes you a better programmer.
The reason you’ve never heard of my React implementation is because eventually I was just overwhelmed with appreciation for the Facebook engineers who work on React.
React makes some tradeoffs that not everyone can agree on, but those tradeoffs were made in such a way as to encompass as many people and applications as possible.
The argument for choosing React is not that it is objectively the best front-end framework (although there are some who would make that argument). Rather the argument for choosing React is to simply show your interlocutor the ecosystem it has spawned. React did this really cool thing in its early days where it rocketed from being a small niche library to powering one of the largest ecosystems in the web community thanks to its roots at Facebook. This ecosystem status makes choosing React a social choice. You buy in not only to the tech, but also to the people. By writing your own React you run the risk of “forking” the ecosystem. As engineers it is easy to convince ourselves that the best technical implementation should always win, but do the benefits of a few small technical differences really outweigh the cost of fragmenting the beautiful ecosystem created by React?
At the end of your journey hopefully your version of React will be way more successful than mine, and perhaps you will arrive at a different conclusion then I have. Once you’re done, let us know what you learned so the societal accumulation of knowledge may continue.
I’ll try meditation again someday. It’s inevitable that someone will convince me (again) that meditation will solve all my problems. Until then, however, at the price of a couple of weekends you and I can write our own React to discover some of React’s tradeoffs, gain some serious street cred’, acquire new knowledge, and have fun at the same time.
That sounds like a good deal.
