The genius of React
August 30, 2015 in JavaScriptA long time ago, in the age of Web 1.0, web pages were simple. You generated some HTML on the server side, it was delivered to the client, and when the client wanted to navigate or change something on the server, he made another request, a new HTML page was rendered, and the cycle began anew.
This process was beautiful and unencumbered with phrases like “unidirectional data flow” and “pure function” and “application state”, although it was all those things.
Then came the sin of interactivity. Web pages began to change without the server’s notice. And the life of web engineers became hard. First there were event handlers and inline javascript and DOM manipulation, later - jQuery spaghetti code. It’s a nightmare to manage permutations of state of separate page elements without proper abstractions.
Out of this madness were born modern front-end frameworks like Backbone or Angular.js or Ember. They borrowed object-oriented architecture from venerable UI toolkits (because graphical user interfaces existed for 20 years before web apps), and they generally get the job one. There’s one problem, though - the front end becomes a fully fledged application and it requires hard engineering skills to design and maintain.
Here’s where React comes in. (I’m not going to explain what it is - that’s what the docs are for.)
It brings the simplicity of Web 1.0 to modern times. With Virtual DOM it made the full page redraw operation so fast that when anything changes we can just re-render the entire page with new data. This is exactly as traditional websites worked. Don’t get confused by classes in React - all of it is just a sophisticated HTML generator.
This is how I suggest you should view React apps: a “client” part - the React view, and a “server” part (in quotes, because they are two parts of the same front-end codebase). The “server” part can be whatever - object oriented, functional reactive - have fun. There are just two rules:
- The only action the “client” can make is invoke a function in the “server” side. (But not receive a response.) View code does not contain any logic except for rendering.
- The only action (and response) the “server” can make is change the application state and initiate a full client redraw. (Sometimes it will respond to client actions, sometimes - to updates from the backend. This doesn’t matter.)
Backend guys are happy because this what they are used to.
HTML/CSS guys are happy because they can work with almost clean markup, unobstructed by model logic.
Serious OO architect guys can still design the entire front-end app in a clean, organised way and not trip over messy UI interaction.
If you long for simpler times, React is for you.
PS. All of this is not so clear when doing React, but with Om, the Clojurescript interface to React, the React component code looks almost identical to server-side templates. Hooray for homoiconicity!
Liked the post? Treat me to a coffee