Should You Use React for Your Next Website?

Gabriel Richards
Founder & CEO

Learn Reasons Why to Use React Here

Before the use of REACT became popular, interactive web pages were handled largely by server-driven applications. A user would make a request and the information would be transferred to a back end, processed, and then returned to the web page.

It was normal for any simple request to cause an entire web page to refresh. The unfortunate side effect of this was a slower and clunkier user experience.

Sometimes something as simple as adding an item to a shopping cart would reload the entire web page.

As users may have been wishing to add multiple items to the cart, this could result in a rather inefficient user experience (UX); the user’s place on the page could be lost, and with each item it would take several seconds before they were brought back to where they were.

Use React

User behavior being what it is, this could cause people to purchase fewer items or to become frustrated with the shopping experience, causing them to abandon shopping carts, and thus, for sales to be lost. What people really wanted, was a faster, smoother experience. Solutions were developed using tools such as jQuery, which could enable a web page to interact with a back end, and through AJAX, make asynchronous calls to the server and update just a portion of a page, producing a better experience.

However, the tool used (jQuery) was essentially just a layer on top of existing technologies. Since asynchronous operation was not really built as the fundamental principle of this tech stack, systems could quickly become bloated and difficult to maintain.

Single Page Applications.

Enter the Single Page Application (SPA). Using REACT, you can resolve components at runtime, which enables components of the web page to be dynamically and asynchronously updated based on any action made by the user or any server response. Instead of requiring a full server response for each request, components of a page can be dynamically updated in the browser as the application state changes, whether through a server status change, or through user action.

SPAs interact with users by dynamically rewriting content in the existing web page, providing a much more seamless UX. Instead of loading the entire page at once, the content of each page element is updated with any changes in its state. In this way, the web application can feel less like a series of web pages and more like a desktop application, while still avoiding the unnecessary overhead of downloading and installing software.

Successive pages will load in the same way; they are in fact all part of the same single page; only the content within the page updates, typically driven by a user action.

With single page application technology, since there are no page refreshes and individual server requests are typically smaller, responses are much faster. When a user clicks on an item on the screen, only the part of the application that the user interacts with changes; static content does not need to reload.

How React Works

How it Works

REACT.js runs in the browser using a runtime. It is constantly running; it does not require triggers to the server to kick off an action. The application “reacts” based on state changes. This can work for multiple users using the same application. All data is being read from the same data source, and when the state of the data changes it creates an automatic update for anyone viewing that data. New page refreshes are never required, only the relevant data within the page is updated.

While both REACT and jQuery make asynchronous calls to the server, jQuery was a supplement, a layer on top of the DOM tree, and updates were incremental. In contrast to jQuery, with REACT the entire system is architected to be dynamic from its foundations. REACT and single pages apps built with other frameworks will connect to any back-end data source.

Examples When React and Single Page Apps Work Best

There are tremendous benefits to this approach, and it can theoretically be used for any website. It is ideal for any page where you need a very fast interactive highly dynamic page. While the number of ways that one can use REACT are pretty much unlimited, there are a few cases where it becomes ideal.


For typical email software, there is a standard list of elements that remain static, with others that change based on user interaction.

You will generally have a list of folders representing mailboxes (e.g. “In”, “Sent”, “Drafts”) and likely a series of other directories with organized mail. In most cases these listings will remain static. However, next to each folder there will typically be a number, providing information about how many “unread” items are in the directory.

In the center of the screen, usually you will see a list of emails with the sender, the subject, and the receipt date/time. There may be some items that have been read, and those that have not (typically bolded on the page). When someone clicks on an unread email, it may show the email text directly below this entry (possibly a short summary of the email). At the moment of the click (the state change), several things change, while much else stays the same; the email becomes marked as read, a bit of text may show and the count of unread emails changes. This happens all at the same moment, while simultaneously updating the state of the data. Everything else on the page remains static. Only these pieces change.

Had this been handled without REACT (or other SPA), the information would have been sent to the server, which would then render an entire new page with the new information mixed with the pre-existing static data. The experience would have a tendency to interrupt the user’s focus and the page would slow down because of the need for constant page loads. With REACT, the experience is interactive and seamless.

Shopping Cart

Another commonly used application which can make great use of REACT is a shopping cart. When someone is shopping on a website, they see a list of different items on a page. They may wish to add one or more items to their cart and continue shopping (much like in the real world). With REACT, items can be quickly added to the cart, update any indicators of items in the cart and the user can continue their shopping experience with no interruptions.

To understand how this might work without REACT, imagine you are in a supermarket. You reach over and grab a jug of orange juice and place it in the cart. Now imagine that you had to leave the aisle, go back to the beginning of the store and walk down the same aisle to get milk. After doing this with one or two items, you might become frustrated and decide to leave the store and go somewhere else. The same is true of the UX provided without SPAs. With REACT, you can simulate real world behavior by creating a seamless experience, but this time from the comfort of one’s couch.

The uses of REACT can be applied in any situation where content needs to be updated regularly, but where other pieces of the page should not change. This can apply to everything from photo galleries, file sharing sites, social media sites, educational sites, and more. The website itself becomes interactive much like a desktop application.

Where REACT is not as helpful

There are some circumstances where using REACT might seem to be overkill. For instance, any new data-heavy loads should not be loaded as part of the same single page app.

If the entire page or site that must be loaded is brand new, it makes sense to treat it separately. In this case, it makes more sense to use server-side rendering as the content should likely be loaded freshly. For instance, if one were to switch from a static “home page” to a “product list” page, the content on these are entirely different. One could theoretically use two different SPAs, however it may not be necessary.

Another case where REACT might not be necessary, is for many backend business systems, where dynamic refreshing of content is not as necessary. This is especially the case if there is already a system that does what you need; it could become too expensive to redesign what has already been created.


REACT vs. Angular vs. Vue.js

It is important to note that there is more than one type of single page application framework. There are many, but for the purposes of this article we’ll examine the three most popular ones: REACT, Angular, and Vue.js. Angular, initially created by Google, has been on the scene for some time. It was the first widely adopted SPA. Vue is the newcomer on the scene and is popular because it is very lightweight and relatively easy to learn.

Angular, being there first, suffers from its own learning curve. It is built entirely in JavaScript and is encapsulated; it serves as a layer on the existing DOM (Document Object Model). Unfortunately, as a result it tends to be slower; it is an add on to existing frameworks. It was an improvement over jQuery in terms of power, but not in ease of use; it is quite complicated to learn, and some argue that it is somewhat clunky.

REACT has the advantage over Angular in that it uses its own “virtual DOM.” One can think of this as like using active memory on a computer or caching to speed up processes; a smaller version of the DOM gets created and is therefore far more agile and runs considerably faster than Angular which needs to traverse the entire DOM to process anything. REACT embeds HTML directly into the script, so that code is generated on the fly; it takes dynamic updates and applies them as full archived patterns for the entire project. The Virtual DOM reads data and renders output very quickly.

It is worth mentioning Vue.js, as it is growing in popularity largely due to its ease of use, and that it is packaged with the popular Laravel PHP framework. It is fast and easy to learn; however, it lacks institutional support for the most part. Generally, it is considered to be a better choice for smaller projects. Vue’s ease of entry comes with the drawback that as it attracts many beginners, it can allow people to develop some bad coding habits, and possibly create problems which may be harder to debug later down the line.

Let’s look at some of the numbers surrounding each of these frameworks:


Commits: 12,718
Contributors: 1348
Used by: 2.9m
Watch: 6.7k
Star: 142k packages: 109,562


Commits: 16,582
Contributors: 1073
Used by: (not provided)
Watch: 3.2k
Star: 56.2k packages: 37,167


Commits: 3076
Contributors: 285
Used by: 1.2m
Watch: 6k
Star: 155k packages: 30,839

We can see that while there has been more activity on Angular than REACT, this is largely a function of its age. The popularity of REACT, as is demonstrated by the “watch” and “star” numbers is considerably higher at this point. You can see that Vue is lagging behind the other two in terms of popularity.

Sites using REACT

To get a general idea of the popularity of REACT, it’s worth nothing that many major websites use it. It was created by Facebook, so it makes sense that Facebook makes heavy use of REACT, to combine with its PHP back end. Instagram, also owned by Facebook, uses REACT for its entire site.

The framework itself is open, so many other major sites have used it. Here’s a brief listing of some of the most popular sites using REACT:

yahoo mail
Khan Academy
NY Times

The Future of REACT

Given the current state of SPAs, REACT appears to be one of the stronger frameworks and will likely last for quite some time. In comparison, Angular, which was built in the Google infrastructure is somewhat limited, and forces one to stay in its own ecosystem. Its relatively high learning curve and slowness of response may be factors in its declining popularity. 

REACT uses a more open architecture and doesn’t confine one to one way of doing things. It is more flexible, and more people are involved, so as a result it has a larger faster growing ecosystem, and is often considered to be easier to learn than Angular

Vue’s popularity is certainly growing and worth paying attention to, however for the most part it lacks institutional support, whereas REACT has been adopted by many major players (as mentioned above). Vue.js will likely remain a popular framework, however unless it becomes adopted by some major organizations, it will unlikely be able to compete with REACT.

Finally, one might suggest that REACT has a better “brand” than the other two – the name describes what it does; it makes web pages “react-ive.”

- Gabriel RichardsFounder & CEO | 

Filed under: <SoftwareWeb Development>

Ready to make your new React website?

Contact Us