Why ReactJS (or something like it) is the Future of Front-end
A high-level overview of the concepts behind React and why it's not Just Another Framework.
Slides available on Speaker Deck
I’m a “full stack” developer.
For some of my career, I’ve focused more on the “back end”, and for much I’ve focused on the “front end.” But maybe not the front-end you’d expect. I was a Flash developer.
So when I talk about “front end” development, what exactly do I mean? GUI programming.
And one thing I’ve always said is that front end development is much much much harder than backend.
For a long time, I don’t think people took me seriously.
Why did I say that?
Most of these aren’t problems that are intrinsic to GUI programming. They’re problems with the platform. As time goes on, they’ve gotten better, and they’ll continue to get better. They’re not what I want to talk about.
There’s one problem that I think overrides all of these.
State is.
What is state? It’s just the information stored in an application at any one point in time.
On the server, a request comes in and a response goes out.
With normal HTTP, there isn’t any state*. Each time a request comes in, we start anew: analyze the request and building a response.
The whole thing is a glorified function.
In fact, if you do it right, the whole thing should literally be a function (excptions: db, cache, etc.)—in the mathematical sense of the word that we all learned in high school though we may not remember anymore.
For each input, there’s only one possible output. In other words, if I give it the same input, I should get the same output. In math, it’s called a function, but in CS, we call it a “pure” function.
Underlying this of course, the server does have state. At any time, there are a certain number of connections to the server, it’s at a certain point in writing responses, etc. but none of this matters to the developer. We have an abstraction or mental model that that lets us think of it as a pure function.
But that’s not the case in front end development. The user interface has state. If the user clicks on a button and a gallery is shown, we need to store that state somewhere so that, the next time the user clicks, we can determine what action to take depending on their previous clicks.
Even worse, we have to build these stateful pieces and graft them on to the stateless response from our servers.
It’s like building a sculpture by glueing layers onto layers.
You get to other states of your application by mutating—or changing in place—the DOM upon user interaction. [Mention examples, jQuery, etc.]
As your application grows, there are more states. And you need to be able to navigate between them.
In fact, if you're using URLs, you need to be able to navigate from any given state to any other.
And there’s no easy way to enter our app from another state. (It always has to start from our base.)
That makes server-rendering states really hard. Which makes SEO hard, and pages feel slow to load.
For a long time it seemed like this was just a fact of life. This was how it’s done and we were stuck with it.
Then came React.
React’s proposal is simple: What if we thought of the document as the result of a function which took some input and returned a DOM object? When a state change happens, we just feed a new input into the function and show what comes out.
As somebody who’s spent a lot of time writing complicated UIs (in Flash), I don't think it's an exaggeration to say this was a revelation.
This is the reason why React isn't Just Another Framework; why it isn't Backbone v2.
Benefits of functions. [Contrast with templates.]
[Read slide]
The answer is that our function doesn’t spit out a whole new DOM—instead it spits out a description of the DOM. One that can be compared to the actual DOM to generate a diff which, when applied to the real DOM, results in our desired document.
React isn’t exciting because of the Virtual DOM. It’s exciting for the abstraction that enables: functions that accept an input and return a representation of a DOM element.
In reality, these aren’t just regular functions in React, they’re Component classes. But don’t let the C word fool you, these classes are really just functions in disguise.
So what is the input that the component classes accept?
You can think of the input as being in two pieces: “props” and “children.”
Props are any bit of data a component might need—a string, a boolean, whatever—and children are other components that you want it to manage.
Here our component class f takes one prop—title—and two children, which are each components themselves. And since they’re components, they can also have props and children (though I’ve only given them props).
Since each of these are React component classes, they each return a DOM element (representation). That means that—in addition to the “title” prop—f is being passed two DOM elements that it can do whatever it wants with. For example, it might wrap them in a div and return that. Or create a table and put each of the children in a cell.
Or it might wrap the children in a list and create a new heading component using its title prop. In that way, the input of the heading would be derived from the input we’re giving to f. You can imagine f being defined like this, and (with React) that isn’t too far from the truth.
What we’re seeing here is composition: taking three components that are completely independent—they don’t know anything about each other—and combining them into something bigger.
Since we’re dealing with HTML, it might be convenient to think of props and children like this. Now remember, f, g, and h aren’t actually DOM nodes themselves, they just return things that represent DOM nodes. But it’s useful to think of our components like this.
In fact, React actually has a special dialect of JavaScript called JSX that lets you write them like this.
But if each component just transforms its input and passes it down to nested components, where is the state stored?
Well, React has you covered. Each component instance is capable of storing some state that persists between renders. So when a user clicks the next button in your gallery, you can increment a count in the component’s state and it will trigger a re-render.
In other words, that f() function we looked at really has another parameter—a state object.
But you’d be surprised how little you need it. It turns out, most things we consider state can actually be derived. In other words, passing down props and children covers most of our needs. And for those times when it doesn’t, React’s rigorous quarantine of state into one little place on our component makes managing it much easier.
We can seed our state with the URL. URLs are supposed to be serialized representation of our application’s state; we should be able to pass the URL as a prop to our application component, decompose it into a state, transform that state, and forward it along to child components (which transform and forward it to their children). In other words, it’s possible to derive an entire application’s state from the URL.
And since React is written in JavaScript, we can do this on the server. When the request comes in to the server, we can use the requested URL as input to our application component and get out a Virtual DOM instance that represents the document. Then we can convert that Virtual DOM to an HTML string and send it to the browser so that they get our application pre-rendered in the correct state.
That means search engines get the right HTML.
That means users don’t have to wait for JS to bootstrap an app to show something.
The input comes into our application and our application converts that into a (virtual) DOM representation. React's diffing engine takes it from there.
But with most frameworks, that still wouldn’t help us very much. Even though we have the HTML of our app in the right state, we wouldn’t have the means to get to other states, because—with other approaches—that depends on starting from a specific state. They just plain can’t know how to bind the JavaScript to the particular HTML that we sent down.
That’s not the case with React. With React, the same app that we used to generate the HTML on the server can be used to bind functionality in the browser. All we have to do is give it the same input we gave it on the server and it will generate the same DOM—but with all our JS behaviors bound to it. The DOM diffing engine will take it from there.
After that point, any state changes—triggered by clicks, etc—just update the application's state, which is passed down as props to nested components in order to generate a new (virtual) DOM.
And since our application is a function that can “convert” the URL into a (virtual) DOM, we can enter it in any state simply by seeding it with the correct URL.
And that's one of the really exciting things about React and the abstraction it provides.
React sets us up to fall into the pit of success: if you build a functional application, you can jump to any state from any state (or no state) for free—in the browser and on the server.
[Credits]