What is React.js?

React.js is one of the most talked about JavaScript web frameworks in years. Alongside Angular, and more recently Vue, React is a critical tool that has had a big impact on the way we build web applications. But it’s hard to find a better description of React.js than the single sentence on the project’s home page:

A JavaScript library for building user interfaces.

It’s a library. For building user interfaces. This is perfect because, more often than not, this is all we want. The best part about this description is that it highlights React’s simplicity. It’s not a mega framework. It’s not a full-stack solution that’s going to handle everything from the database to real-time updates over web socket connections. We don’t actually want most of these pre-packaged solutions, because in the end, they usually cause more problems than they solve. Facebook sure did listen to what we want.

This is an extract from React and React Native by Adam Boduch. Learn more here.

React.js is just the view. That’s it.

React.js is generally thought of as the view layer in an application. You might have used library like Handlebars, or jQuery in the past. Just as jQuery manipulates UI elements, or Handlebars templates are inserted onto the page, React components change what the user sees. The following diagram illustrates where React fits in our frontend code.

This is literally all there is to React. We want to render this data to the UI, so we pass it to a React component which handles the job of getting the HTML into the page.

You might be wondering what the big deal is. On the surface, React appears to be another rendering technology. But it’s much more than that. It can make application development incredibly simple. That’s why it’s become so popular.

React.js is simple

React doesn’t have many moving parts for us to learn about and understand. The advantage to having a small API to work with is that you can spend more time familiarizing yourself with it, experimenting with it, and so on. The opposite is true of large frameworks, where all your time is devoted to figuring out how everything works. The following diagram gives a rough idea of the APIs that we have to think about when programming with React.

React is divided into two major APIs. First, there’s the React DOM. This is the API that’s used to perform the actual rendering on a web page. Second, there’s the React component API. These are the parts of the page that are actually rendered by React DOM.

Within a React component, we have the following areas to think about:

• Data: This is data that comes from somewhere (the component doesn’t care where), and is rendered by the component.
• Lifecycle: These are methods that we implement that respond to changes in the lifecycle of the component. For example, the component is about to be rendered.
• Events: This is code that we write for responding to user interactions.
• JSX: This is the syntax of React components used to describe UI structures.

Don’t fixate on what these different areas of the React API represent just yet. The takeaway here is that React is simple. Just look at how little there is to figure out! This means that we don’t have to spend a ton of time going through API details here. Instead, once you pick up on the basics, you can spend more time on nuanced React usage patterns.

React has a declarative UI structure

React newcomers have a hard time coming to grips with the idea that components mix markup in with their JavaScript. If you’ve looked at React examples and had the same adverse reaction, don’t worry. Initially, we’re all skeptical of this approach, and I think the reason is that we’ve been conditioned for decades by the separation of concerns principle. Now, whenever we see things mixed together, we automatically assume that this is bad and shouldn’t happen.

The syntax used by React components is called JSX (JavaScript XML). The idea is actually quite simple. A component renders content by returning some JSX. The JSX itself is usually HTML markup, mixed with custom tags for the React components. What’s absolutely groundbreaking here is that we don’t have to perform little micro-operations to change the content of a component.

For example, think about using something like jQuery to build your application. You have a page with some content on it, and you want to add a class to a paragraph when a button is clicked. Performing these steps is easy enough, but the challenge is that there are steps to perform at all. This is called imperative programming, and it’s problematic for UI development. While this example of changing the class of an element in response to an event is simple, real applications tend to involve more than 3 or 4 steps to make something happen.

Read more: 5 reasons to learn React

React components don’t require executing steps in an imperative way to render content. This is why JSX is so central to React components. The XML-style syntax makes it easy to describe what the UI should look like. That is, what are the HTML elements that this component is going to render? This is called declarative programming, and is very well-suited for UI development.

Time and data

Another area that’s difficult for React newcomers to grasp is the idea that JSX is like a static string, representing a chunk of rendered output. Are we just supposed to keep rendering this same view? This is where time and data come into play. React components rely on data being passed into them. This data represents the dynamic aspects of the UI. For example, a UI element that’s rendered based on a Boolean value could change the next time the component is rendered. Here’s an illustration of the idea.

Each time the React component is rendered, it’s like taking a snapshot of the JSX at that exact moment in time. As our application moves forward through time, we have an ordered collection of rendered user interface components. In addition to declaratively describing what a UI should be, re-rendering the same JSX content makes things much easier for developers. The challenge is making sure that React can handle the performance demands of this approach.

Performance matters with React

Using React to build user interfaces means that we can declare the structure of the UI with JSX. This is less error-prone than the imperative approach to assembling the UI piece by piece. However, the declarative approach does present us with one challenge—performance.

For example, having a declarative UI structure is fine for the initial rendering, because there’s nothing on the page yet. So the React renderer can look at the structure declared in JSX, and render it into the browser DOM. This is illustrated below.

On the initial render, React components and their JSX are no different from other template libraries. For instance, Handlebars will render a template to HTML markup as a string, which is then inserted into the browser DOM. Where React is different from libraries like Handlebars is when data changes, and we need to re-render the component. Handlebars will just rebuild the entire HTML string, the same way it did on the initial render. Since this is problematic for performance, we often end up implementing imperative workarounds that manually update tiny bits of the DOM. What we end up with is a tangled mess of declarative templates, and imperative code to handle the dynamic aspects of the UI.

We don’t do this in React. This is what sets React apart from other view libraries. Components are declarative for the initial render, and they stay this way even as they’re re-rendered. It’s what React does under the hood that makes re-rendering declarative UI structures possible.

React has something called the virtual DOM, which is used to keep a representation of the real DOM elements in memory. It does this so that each time we re-render a component, it can compare the new content, to the content that’s already displayed on the page. Based on the difference, the virtual DOM can execute the imperative steps necessary to make the changes. So not only do we get to keep our declarative code when we need to update the UI, React will also make sure that it’s done in a performant way. Here’s what this process looks like:

When you read about React, you’ll often see words like diffing and patching. Diffing means comparing old content with new content to figure out what’s changed. Patching means executing the necessary DOM operations to render the new content

React.js has the right level of abstraction

React.js doesn’t have a great deal of abstraction, but the abstractions the framework does implement are crucial to its success.

In the preceding section, you saw how JSX syntax translates to the low-level operations that we have no interest in maintaining. The more important way to look at how React translates our declarative UI components is the fact that we don’t necessarily care what the render target is. The render target happens to be the browser DOM with React. But this is changing.

We’re only just starting to see this with React Native, but the possibilities are endless. I personally will not be surprised when React Toast becomes a thing, targeting toasters that can singe the rendered output of JSX on to bread. The abstraction level with React is at the right level, and it’s in the right place.

The following diagram gives you an idea of how React can target more than just the browser.

From left to right, we have React Web (just plain React), React Native, React Desktop, and React Toast. As you can see, to target something new, the same pattern applies:

1. Implement components specific to the target
2. Implement a React renderer that can perform the platform-specific operations under the hood
3. Profit

This is obviously an oversimplification of what’s actually implemented for any given React environment. But the details aren’t so important to us. What’s important is that we can use our React knowledge to focus on describing the structure of our user interface on any platform.

Disclaimer: React Toast will probably never be a thing, unfortunately.