Justin and the Technically Team
May 18, 2020, 2:13 p.m.
React is a philosophy and framework for building interactive web (and native) applications that are built on reusable components.
Web apps are increasingly using client side rendering instead of server side (scary words! we’ll explain them)
Web developers use React to build dynamic web applications like Twitter
React’s philosophy emphasizes reusable components so you don’t rewrite code
The must-know basics and pieces of the React ecosystem: props, JSX, state, and React Native vs. React JS
Unless you live under a rock (which, given San Francisco rents, is becoming a legitimate housing option), you’ve probably heard about React. It’s at the center of a lot of hot topics right now, like “are frontend engineers really engineers” (hint: yes, yes they are) and my personal favorite, “what’s the most complicated way I could possibly build this one page website.” So what is React, and why should you care?
To get the most out of this post, you’ll want to understand how a web app works and what dynamic content looks like.
Hopefully you’ve been reading some Technically in your free time, and you’re familiar with the client-server model. It’s how the whole web works: companies host their websites and apps on fancy, powerful servers in [the cloud](https://posts.technically.dev/archive/whats-cloud/), and you download files from those servers to look at in your browser. When these files are dynamic, their content changes based on who’s logged in, what’s going on, what screen you’re on, and stuff like that. This section is about how that actually happens.
When an app or website needs to send you dynamic content, there are (surprise!) two places they can create that content: on the server side, or on the client side. The server side means they populate and configure the page before they send it to you; the client side means they send you the basic HTML, and the dynamic logic happens in your browser.
In practice, the difference is in where the backend logic happens: all on the server, or mostly in the browser calling [APIs](https://posts.technically.dev/archive/whats-an-api/) on the server.
The benefit of doing things client side – you don’t need to reload the same HTML and other boilerplate stuff every time you load a page; all that needs to change is the dynamic parts of whatever you’re loading.
(Nowadays, things aren’t completely black and white: a new class of applications is combining server side and client side rendering into hybrid models that take advantage of the benefits of both.)
React is a library for building these kinds of interactive apps. A few engineers at Facebook built it almost 10 years ago – it was present in the 2011 News Feed – and it slowly got more popular over time. A framework is just a bunch of code that helps you write other code, so let’s explore exactly what React is about and what it helps you do.
The core philosophy of React is all about components. If you take a look at popular web apps that you use – Twitter, Google Drive, or even Wikipedia – there’s a lot of repetition going on. Each tweet that you see in the web app looks pretty much the same; it’s a box of a certain width and color with some text in it and a border. All Google Drive files look pretty similar when you load your homepage, too. In React, these are components, and they’re built to repeat, a lot.
Instead of writing the same HTML for every single file icon in your Google Drive, the Google engineering team might build a React Component called a file. That file has a basic HTML structure (box, border, shadow, etc.), but the rest is dynamic: it will show the green icon if it’s a spreadsheet, and the blue icon if it’s a doc. The name of the file, as well as the time it was last updated, is also dynamic (it changes from component to component).
In your typical web app, you might have anywhere from a few to several hundred components. The important thing to understand here is that this focus on components is a fundamental pattern shift – people did not always build their sites this way. Part of React’s popularity is tied to the paradigm shift, not just how useful it is as a framework.
One last important thing to note: developers also build server side rendered apps that use React. One of the most popular frameworks for React is Next.js, which helps devs build apps like that.
Let’s run through a few key parts of the React ecosystem so you can get a better sense of what developers are doing. If some of these don’t click the first time, that’s totally OK; it’s more important to get the broader ideas at play.
Each component is a combination of things that don’t change (sometimes color, size, etc.) and things that do change (text, images, etc.). When you write React components, you pass the things that do change – the dynamic elements – to the component through props. The word might be short for properties. I don’t know.
Sometimes your React components need to remember things. If you’re building a little timer, you add and display a second every second; so you need to remember what second we’re at. React has special built in functionality for storing data like that, and there’s even an entire framework for managing React state.
“Just take it from our component library.”
We have a bunch of components that we’ve built and use across the app: instead of creating something from scratch, use one of those components.
“You could turn it into a component if you want, but I’m not sure how reusable it’s going to be.”
It’s only worth making a bunch of HTML into a component if you’re going to reuse it across the site; if it’s a one off thing, don’t bother.
“We moved our mobile app over to React Native because our developers were more familiar with it.”
We were building our iOS app in Swift, but ended up moving it over to React native because our developers already knew React.js.
Client side rendering
Server side rendering