ChakraUI’s homepage states that it's a simple, modular, and accessible component library to let you build React apps with speed. After delivering a few projects where we used C...
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?
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.
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! Okay, calm down. Here’s the gist:
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.
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.
Let’s go 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: firstname.lastname@example.org