Why Does React Exist

Introduction

You're about to start building a new website, and the first thing you do is run create-react-app my-website

But have you ever stopped to consider why you're even using React in the first place? Is it just the hooks or the fact that you can easily create components and use them in pages?

Why does this tool exist? This article will explain why React exists and how it has become a go-to tool as a fast way to create websites.

A brief history of JavaScript

React is a framework of JavaScript, so let's look at a brief history of JavaScript.

Since 1993 when the first browsers (Netscape Navigator) with graphical user interfaces were invented, websites could only contain static content. No dynamic behavior like modals or lists of products pulled from an API, or dynamic events like today.

Around 1995, there was that need to have some website interactions. And then, the Netscape team hired Brendan to create a scripting language for that purpose. That scripting language ended up being JavaScript!

Over time, JavaScript has become the standard scripting language for websites. Chrome, Firefox, Internet Explorer and so on all have a JavaScript engine used to compile JavaScript code to perform those interactions.

JavaScript works with ECMAScript, which creates the standard by which all browsers should follow when creating JavaScript engines.

What JavaScript does in the context of web development

HTML and CSS are markup and stylesheet documents (respectively) that put elements together and style them to appear beautifully on a web page. But that's all they can do. You cannot trigger any dynamic content. This is where JavaScript comes in.

JavaScript engines in web browsers also connect JavaScript and the web document built with HTML and CSS. Among many other features that the browsers allow JavaScript to do, the browsers also give JavaScript access to the Document Object Model (DOM).

The DOM is a tree object which contains all the elements in the web document. Access to this tree makes it possible for JavaScript to remove, modify, and add elements to the document.

How we used to do it. How it's different now

For example, we have a website with three pages: Home, About, and Contact. Here's an example of how this website would get created without the features of JavaScript:

• index.html for the home page
• about.html for the about page
• contact.html for the contact page
• styles.css for the stylesheets, which would contain style declarations for the app

With a website like this, navigating to mywebsite.com would require the browser to request the path /index.html from the server. Depending on the network speed, or the availability of all the page's necessary resources, a response from the server may be delayed.

If a user clicks on an about link on the homepage, the browser would again have to go through fetching the HTML file and loading the resources to the page. And the same thing goes for the contact page.

There is always a site reload for any new navigation, even when the difference between page 1 and page 2 may be a single character or image.

Single-Page Applications (SPAs) were introduced to solve this and other shortcomings. Websites today are faster, and with SPAs, debugging websites has also been made easier.

The rise of single-page applications

Multi-page Applications (MPA)--the traditional way of building applications—requires a page refresh on every navigation, even when the previous and current page contain minimal differences.

The concept of SPAs involves dynamically composing elements and rendering the page on the client-side (which is the browser) for any page you navigate to. This is contrary to MPAs, which render the page from the server and only serve the resources for that page.

Client-side rendering is accomplished with JavaScript. Most of this is done with the aid of DOM manipulations—modifying, adding, and removing elements on the screen--when a new page is activated.

With SPAs, the website usually only reaches out to the server once to get an index.html file. The file references a JavaScript file that handles the client-side rendering implementation for different pages. So when you navigate to a new page, the page does not reload.

The URL in the address bar is updated, the routing state in the browser is updated, and the JavaScript updates the document where needed. For places like the header and footer, which would usually be the same across all pages, those places are not re-rendered. Only the body content with new changes will be rendered.

Front-end web development is extremely challenging

The advancement of SPAs comes with more advanced challenges to developing for the front-end. Developers would now have to handle events, dynamically loading data, manually manage navigations, and more.

Front-end isn't what it used to be. Imperitavily manipulating the DOM using JavaScript is a ton of work. Abstractions were needed.

Declarative code can more predictable and easier to debug

There are two programming paradigms which are Imperative and Declarative programming.

In imperative programming, you tell the computer the exact steps it needs to take to reach your desired result. Declarative programming involves telling the computer your desired results and letting it handle the steps.

A simple example to illustrate this is a filter operation. Let’s first see an imperative approach:

const arr = [1, 2, 3, 4, 5, 6, 7]
const filtered = []
for(let i = 0; i++; i < arr.length) {
  const item = arr[i]
  if(item % 2 === 0) {
    filtered.push(item)
  }
}

As you can see here, we’re telling the computer, step by step, the method in which we want to get what we want. Let’s look at something declarative:

const arr = [1, 2, 3, 4, 5, 6, 7]
const filtered = arr.filter(item => item % 2 === 0)

Here you are telling the computer what you want, "Give me all the even numbers in this array". Of course, inside the higher-order function (filter), the implementation would be imperative. But from the abstraction, the step-by-step process is hidden.

Declarative code is mostly abstractions that improve the readability of code. Also, they make code predictable. Looking at the imperative approach to filtering above, the function of those lines of code may not be easily predictable. for loops can do many things. But with the filter abstraction, you expect to get a filtered result just by the naming convention.

And when code is easier to read and predict, it's easier to debug when something goes wrong.

With JavaScript, any of these approaches are technically valid. But, as people keep building, abstraction upon abstraction is created to make code more declarative. You have libraries like lodash, jQuery, date formatting libraries, and many more.

The same applies to the frameworks of today. We have a more declarative way of placing elements on web pages without having to use DOM manipulation methods like [appendChild](https://developer.mozilla.org/en-US/docs/Web/API/Node/appendChild)

Declarative Code with Reusable Components

The old way of building websites involved repeating common components (like header and footer) across all pages of the site. These components will usually have the same class names, all connected to one stylesheet to appear the same on every page.

But this method makes it difficult to update these common components. Any additions to the header section on the home page would require a similar update to every .html file using the header.

This method also makes testing a particular component more difficult because instead of testing it in just one place, you have to test it across every page.

Today's Web applications are component-based, in the sense that they are built with the composition of standalone components. This method of building is made easier with the help of frameworks like React.

You have your header, footer, and postcard component built individually and tested accordingly. Then, when creating your home page, you'd import your header and footer components like variables and build up your page using those components.

Now instead of writing the same header implementation in all your pages, you'll have it in only one place and shared among all your pages. Apply a style change to the header, and the change gets reflected throughout the application.

Where React came from, who writes and maintains it

With the arising need for a more flexible, declarative, easy-to-maintain, and easier-to-control way of composing components and user interfaces, Facebook created. The prototype which was called FaxJS was created by Jordan Walker, a software engineer at Facebook.

Many people write React today, from individual developers to frameworks like Gatsby and Next.js. React is used all around the tech ecosystem.

As an open-source library, React has attracted many contributors who have added features, fixed bugs, and helped maintain and manage version updates. Check out the React teams page for more information.

Why it's popular and valuable in the current job market

React is a desirable framework due to being backed by Facebook. Choosing a framework is a long-term investment for businesses, and they desire reliable long-term support for the tools they choose. React is also performant, scalable, flexible, and easy to maintain. It's a no-brainer why it's so appealing to enterprises.

For developers, React is an attractive option for many reasons. It is well documented, easy to get started with, the community behind React is friendly, and many tools have been built for it. You have libraries for hooks, for state management, and many other things!

Conclusion

Many developers initially jump into React because it makes it incredibly easy to get a website started, but as we've learned, it did a lot more than that.

React is a powerful abstraction that allows us to write reusable, declarative components.

Whereas before, we were writing static HTML pages, spending a lot of time manipulating the browser with imperative JavaScript code, or writing the same repetitive components across multiple files.

We also learned what makes React appealing to businesses and why there is a market for React Developers.