What is React? Is it a framework, and why should you care?

If you’ve spent any time around developers, chances are that you’ve heard the name “React” tossed around more than once, perhaps sometimes along with “Angular”, or, more rarely, “Vue”. So what’s React? Is it a plane? Is it a spaceship? Is it a library? Or is it a framework? And is it even important? Let’s find out.

React — framework or library?

React developers describe it as “a javascript library for building user interfaces”, as you can see in the big banner on its homepage. But most people call it a framework, and thus make it part of the holy trinity of front-end javascript frameworks, with Angular and Vue. So what’s the deal? Well, the discussion is mostly academic, with one side arguing that a framework is “something that you plug your code into”, and a library is “something you plug into your code”, and the other side arguing that react does, essentially, the same thing as the other two, but — to be honest — for the average person the naming convention is pretty irrelevant, so we might call it either. What IS relevant though, is that React does one thing and it does it pretty darn well: it allows you to rapidly build amazing, responsive and fast user interfaces. It’s extremely popular (if you look at some charts and comparisons you might see some trend there), open-source and backed by a large corporation. So where did it come from and what makes it the number 1 javascript framework (or library)?

A brief history of React

React was created in 2011 by Jordan Walke at Facebook. By then, the platform had grown so large, that the existing solutions were not enough, so they built their own front-end framework (or library) to meet their increasing needs. In 2013, React was open sourced, and since then it has grown exponentially, with new features being added all the time and an amazing community of developers growing around it.

Why is React popular?

React is pretty mature and time-tested, and it has been used by a lot of household names (Netflix, AirBnB, Instagram, to name a few. Also, Facebook). It is more light-weight and performant than Angular, which is Google’s solution to building front-end applications. React also doesn’t impose any specific ways you have to do things, and you can select from a vast array of additional libraries to do anything you please. There is no single “React way”. Thus, you can build your own React stack to suit your particular needs. 

React is declarative and component-based

When you consider an app, what you see are single elements, such as buttons, dropdowns, cards and info boxes, combined into larger elements, such as menus and forms. They display certain information and react (see what I did there?) to your input, making changes to what is displayed. React works exactly like this, allowing you to think naturally of the interface you are developing. The basic unit of structure in React is a component - a building block of your app. This can be anything — a message popup, a button, an icon, a passage of text, or a container to hold all of those inside and pass some data to each one. You simply provide React with information on how all the components should look depending on specific parameters (also known as the application “state”) and it takes care of the rest, making appropriate changes to the view according to the changes in state. This is called “declarative programming”, and you can already see that it feels natural and logical to work this way — it speeds up and makes it easier to develop even the most complex front-end applications. React is also very performant in making changes to the views, because it virtualizes the content of the entire app and first makes changes to this virtual “view”, and then figures out the best and fastest way to display the changes on the screen. This results in very smooth and performant apps, providing excellent user experience.

SPA, SSR, CSR, oh my

You probably heard some of those terms tossed around at some point, but what do they mean? 

SPA stands for Single Page Application, and the term is kinda-sorta related to CSR, or Client-Side Rendering, which is opposed to SSR, which stands for Server Side Rendering. Help! 

What is server-side rendering?

In traditional web applications, when you enter the URL in the browser, a request is made to the server, which then decides what needs to be shown, cooks up the necessary html page and sends it back to you. When you browse the page and want to do something, such as perform a search or filter data, another request is sent to the server, which then performs necessary actions, finds your information and cooks up another html page for you. So initial page rendering time might be pretty fast, but then you get a reload every time you try to do something. This is called server side rendering, because — you guessed it — all pages are first rendered on the server, and only then sent to you.

What is client-side rendering?

On the other hand, in the CSR approach, the server gets the entire package and sends it to you in one fell swoop. The first render may be slower, because your browser is downloading all that stuff, but then our hero JavaScript wakes up and takes over and starts to work its magic — handling all rendering logic from the cozy inside of your browser. This means instantaneous transitions, smooth animations, non-existent load times, and never, ever, ever seeing any page reloads (and hence the term Single Page Application, as technically everything happens inside a single html page). For all intents and purposes, it feels like a native app. The downside? That initial load can be pretty painful, and it’s not perfect for SEO. 

There is also the hybrid approach when the initial render is made on the server, and the functionality is gradually transferred to the client as the browser loads all necessary components.

Why am I telling you all this? Because React can be used for all of those. On its own, it’s perfectly suited for making client-side single-page applications, but it can also be rendered on the server or used for the hybrid approach with tools such as Gatsby and Next.js. 

What about React Native?

And now the best part of React: it really is “just” about rendering views, and not specifically on the web. The web is of course its most prominent target, but it can be also used to make mobile apps, with the help of React Native. And these are not hybrid apps, i.e. browser windows disguising as applications, they are really native apps, so they perform way better and they can take advantage of all the features of the given device.

And here you go

So let’s sum up: React is a fast, performant, developer-friendly, and unopinionated framework-library-thing. It can be used for all kinds of applications, whether rendered server-side, or client-side, it can also be used to make native mobile apps, and since it’s platform-agnostic, in the future it may well be possible to make native React tumble dryer apps. It is under constant active development and it has the backing of a large corporation, so it’s here to stay. It has been used to develop many successful and well-established digital products, as well as countless smaller applications made by everyone and their brother. There is a great community of developers around it, making countless libraries and plugins of all shapes and forms, as well as learning materials. 

Corporations love it, startups love it, freelance developers love it, even my cat loves it, judging from the way it’s purring while I’m working on my React apps. I’m sure you’ll fall in love with it too, when you see what it can do.

Are you interested in launching a project with React? Contact us: hello@start-up.house