In the previous post in this series, we discussed the history of web applications and the use of Client-Side MVC. In this post, we'll go through some of the existing Javascript client side frameworks and how React differs from these projects and why it's so versatile.

Before we dive into the specific web frameworks, let's quickly revisit the issue of client vs server side applications and logic.

Using a traditional web application framework, the web pages are created server side, then sent to the web browser, where they're rendered.

To create the web pages, most web frameworks use some sort of templating engine, which allows the pages to be constructed using composible parts. Most templating engines allow for constructs such as inclusion, looping, and an inheritance model.

Most modern frameworks also use some sort of Object-Relation Mapping (ORM) between the application and the database, and use some sort of mapping between application logic and the web server urls.

In the Client-Side model, we're moving most of this application logic up to the client, where it will live inside the web browser. Then, when needed, the client and server will communicate.

For example, if we were creating a shopping cart application, instead of creating a product page template and sending that to our user, the application would request product information from the server, and the server would return that data, usually in JSON.

Our product API call might look something like GET /products/123 and the server would return something like

{"id": 123,
 "name": "Wizomatic",
 "description": "It slices, it dices!",
 "price" 99.95
 }

which would then get turned into a web page.

This is roughly analgous to how an ORM object would get turned into a web page in a traditional web framework using templates, except with the advantages of rendering and caching outlined in the previous post.

While this series will focus mostly on React, it's worth mentioning that the are other client-side frameworks, some of which are older than React, and deserve some examination, such as Backbone.js, Ember and Angular.

This post will focus on the similarities of these frameworks, rather than their differences. For a more comprehensive view of the differences between these frameworks,t

Once we've established that simple templates aren't enough, we need to consider what to replace it with.

One of the first templates to answer this question was Backbone.js, then Ember and Angular.

These three frameworks are different (their differences are best captured in this article.

These frameworks share several fundamnetal concepts which differ from React. Firstly, they're all full application stack frameworks. Secondly, they all support the idea of data binding, and thirdly, they share a lot in common with the MVC design pattern.

React is largely focused on handling the display and interface parts of the application. That's different from some of these other libraries which cover not only display, but also cover things like object representation and client/server communication. React is agnostic to these concepts, and you're free to store your objects however you like, both on the server and on the client side.

At the same time, if you're coming from one of these existing libraries, you might at first wonder where a lot of the logic around object storage and syncronization will go. I'll cover that in a later post in this series, but the short answer is that the object's representation can be more flexible without the need for complex serialization/deserialization methods inside the application.

This dovetails into the issue of data binding, as data binding between server and client is a feature of other libraries. If you're unfamiliar with data binding in Javascript client libraries, it's the idea that if you have an object in memory on the client side, that the library will handle syncronizing that object's state with the server. React does not do this by default, but it is supported when explicity asked for.

Lastly, React does not impose the MVC design pattern. Since React is largely concerned with the View, how you choose to handle the other apspects of your design are left for the developer to choose. That's not to say that there aren't conventions and librariies which make this choice easier- there are libraries like Reflux (which I'll cover later) and Morearity, which users can choose from and find a design model that works best for them.

In fact, it's even possible to use Angular and then choose React as the view controller. While potentially heavy-weight, this is an option available to the developer.

This post has outlined some of the differences between React and other client side web development frameworks. In the next post, we'll roll up our sleeves and get our hands dirty.