As a web developer, you are familiar with the way most websites are built today. There is usually a web server (in languages such as Java, Ruby, or PHP) that processes user requests and responds with markup (HTML).

This means that on every request, the web server interprets the user action through the URL and renders the entire page.

In an attempt to improve the user experience, more and more functionality started to get pushed from the server side to the client side, and JavaScript was no longer simply adding behavior to the page but was rendering it entirely. The biggest advantage was that a user action was no longer triggering a whole page refresh; the JavaScript code could deal with the entire browser document and mutate it accordingly.

Although this did improve the user experience, it started to add a lot of complexity to the application code, which led to increased maintenance costs and the worst—bugs in the form of inconsistencies between different parts of the screen.

In an attempt to bring sanity to this scenario, a number of libraries and frameworks were built, but they all failed in the sense that they didn't tackle the root cause of the entire problem—mutability.

Server-side rendering was easy because there was no mutation to deal with. Given a new application state, the server would simply render everything again. What if we could get benefits from this approach in our client-side JavaScript code?

That is exactly what React proposes to do. You declaratively write the interface code in the form of components and tell React to render. On any change of the application state, you can simply tell React to re-render again; it will then calculate the mutations required to move the DOM to the required state and apply them for you.

During this chapter, we are going to understand how React works by refactoring the code we've built so far into an SPA.

<script src="lib/react-with-addons.js"></script>
<script src="lib/jquery.js"></script>