Should You Use React for Your Next Website?
Learn Reasons Why to Use React Here
Without javascript technologies like ReactJS, your web app will waste a lot of time reloading page elements unnecessarily for each user request. Why not change only the part of the page that is relevant to the user’s request?
Basic web applications reload entire web pages on each click. The unfortunate side effect of this is a slower and less efficient user experience.
For instance, in many websites, an action as simple as adding an item to a shopping cart might cause the entire page to refresh. Why should that be? Generally the user wants to continue browsing, so ideally the item would be added to the cart and the user’s flow would not be interrupted.
As we all know from our own experience, the faster and more responsive a site… the more intuitive it is… the more we love it and use it. In e-commerce, anything that slows down the customer will lead to purchasing fewer items or worst case, to become frustrated with the shopping experience and abandon altogether.
Over the year from the late 2000’s through the 2010, javascript solutions developed on top of HTML and in conjunction with server side languages like PHP to optimize some of these workflows. jQuery, which can enable a web page to interact with a back end asynchronously, was among the first good solutions to delivering dynamic web experiences that don’t require full page reloads for every reqest.
jQuery however, has its limitations, and systems that make heavy use of it can quickly become unwieldy to maintain. jQuery just wasn’t built from the ground up to be a software development framework that delivers a fast and dynamic user experience end to end.
Single Page Applications.
Enter the Single Page Application (SPA) in the mid 2010’s. React JS is an example of a single page application framework. React is more sophisticated than jQuery in how it allows React developers to update components of a web page dynamically and asynchronously based on actions made by the user or data changes delivered by a server. React implements a notion of “state”. Object have “states” and when their states change… that can trigger automatic changes to the UI.
This pattern leads to more elegant software development and faster, more seamless ways to improve user interfaces and user experiences. This is because the amount of data transferring through the network, and the processing performed on the servers can be much smaller with each request.
Taking our cart example again, with a traditional app, the request is made to the server, the cart item is added to a database, and the server responds with the entire HTML page again, reloading the header, the footer, and the body of the page you were just looking at… all a complete waste!
With React, clicking Add to Cart might ONLY send the ID of the item to the server with your session ID, update the database, and respond with ONLY the count of items in your start. React would receive that count, update the state of the cart object, and that would trigger an update to the counter you see next to your cart icon!
So much less data transfer, so much less processing… so a very fast and focused round trip to the server. We shared a short piece that highlights the React process for global state management using a similar shopping cart example.
Even when you request the next “page” of content browsing a list of products… no need to update the header or reload and recalculate the cart… because none of the state of that data has changed! The only thing that needs to change is the list of products you’re looking at
With single page application technology, you get one primarily load of HTML, CSS and JS the first time you visit a site, and ensuring requests are then smaller and focused on delivering ONLY what you newly asked for, and thus responses are typically much faster.
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:
REACT
Commits: 12,718 Contributors: 1348 Used by: 2.9m Watch: 6.7k Star: 142k npmjs.com packages: 109,562
Angular
Commits: 16,582 Contributors: 1073 Used by: (not provided) Watch: 3.2k Star: 56.2k npmjs.com packages: 37,167
Vue.js
Commits: 3076 Contributors: 285 Used by: 1.2m Watch: 6k Star: 155k npmjs.com 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:
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.”