In this series of posts, I'm going to present modern web development using React. As I do, I'll touch on the fundamentals of web development over time, the benefits of client side web frameworks, the React framework, then other tools in the React ecosystem.
Before thinking about React, let's first about how we would go about writing a web application without it. The most obvious way we can write a web application is that we can generate each page as a document on the server and that document from the server to the client. This is what we've done since the very beginning with Perl/CGI, and what we've been doing with frameworks like Ruby on Rails, and Django, and J2EE, etc.
In this traditional web framework model, the server keeps the application state. When a user performs an action, the web browser notifies the server and the server sends back a new document to display.
This traditional model of application development is well understood, but when we want our web applications to feel "responsive", it begins to fall down.
With the advent of AJAX, the server could now send portions of data back and forth to the client. This meant that, for example, a post on a web forum could be sent and the user could submit it without leaving the page.
This technique for interacting between server and client grew increasingly sophisticated and over time, we've seen things change into the current era of web application development where the bulk of the visible parts of the application run on the client. These are often called "Client-Side MVC" web development.
Client-Side MVC has a number of advantages.
From a user perspective, a site that resides on the client is going to be faster and more responsive. Because the majority of the user interface code is running purely on the user's computer, the site "feels" more responsive. That's because instead of needing to request a page, wait for the server to generate the new page, send that new page and then display it, the web application can stay running while new data is either submitted to or fetched from the server.
In addition, because the user interface is separated from the data, the amount of data transferred between server and client can be reduced. Even if there's a large initial transfer of code (ie the application itself), each subsequent transaction between server and client can include just the data that's changed, rather than every visual element on the page. This means that even when data needs to be exchanged between client and server, there's less data to be transferred and the application feels more responsive.
Furthermore, keeping the data separate from the display means that the application can take advantage of caching and other techniques to reduce the need for client/server communication.
Lastly, using this technique can lead to more "interesting" user interfaces and functionality like auto-completion and rich graphical and textual interfaces.
From a technical perspective, the server code can be written more in a more straightforward manner. Instead of needing to process templates and generate pages, the server can support a simple API that is shared between it and the client.
Since all programming libraries are essentially APIs, programmers are already familiar with using APIs. Because the scope of a particular API is limited, these web APIs are easier to develop and debug. They can also provide a clean separation in development between frontend UI development and backend server development.
After developing sites with a client-side MVC framework, it's hard to think of going back.
In the next post, I'll discuss the various Client-Side MVC frameworks.