Technology
Web application, website or web app
We clarify the difference between a web page and an application.
React is a JavaScript framework that was created in 2011 by Facebook developer Jordan Walke. It was used for the first time in Facebook's News Feed the same year. In 2012 Instagram jumped on board and implemented React in its solution. It grew within the Facebook group and in May 2013 Facebook decided to release the framework as open source - free for everyone to use.
Today you'll find React.js at companies like Apple, PayPal, Netflix and of course Facebook. It is one of the three major JavaScript frameworks right now alongside Angular and Vue. At Limetta React is our first choice among JavaScript frameworks and below we explain why.
Structuring code into components is by no means unique to React, but the way it's implemented in React has proven to work very well in both large and small projects.
As a development principle, componentization is generally a very good way to:
In a typical React application you have a component hierarchy (components that in turn use other components) and data that flows through this hierarchy. High up in the hierarchy you often have large components that contain a lot of data handling and business logic and far down you often find small simple components whose main purpose is to render something on the screen, e.g. a checkbox or an icon. So it's not only the componentization but also the hierarchical structure it contributes that helps us structure large and complex solutions.
All web solutions will need to work with the DOM — the Document Object Model. Loosely speaking, you can say that the Document Object Model is a hierarchical data model for a page displayed in a web browser. So when you change something on the screen you are poking at the data object model. And when you change the data object model the browser has to redraw the page or parts of the page — and that takes time. When we say time we are admittedly talking about milliseconds, but considering that modern web pages contain a lot of interactivity and a lot of data that changes frequently, those milliseconds risk adding up to seconds. Then it becomes noticeable to the user as a sluggish user experience.
In React this has been solved by coming up with something called the virtual DOM. A virtual DOM is basically a copy of the real Document Object Model, except it isn’t rendered to the page as soon as something changes. That means, on the one hand, that you can make several changes in one go without the page needing to be re-rendered for each individual change, and on the other hand, that you can precompute the consequences of those changes and ensure you only re-render what absolutely needs to be re-rendered.
This is the secret behind why React is so fast.
In a React application data can only flow in one direction: from top to bottom. This architecture even has a name: Flux.
Think of the routes that data can take through the application as pipes and the water in the pipes as the data. A typical React application would then have a thick pipe at the top. It would then branch into narrower pipes which in turn would branch into even narrower pipes, and so on. At each branching point there would be a funnel you can pour water into (add data) and a valve (hidra data). So if you pour data into the pipe at the top it can flow out into all the other pipes provided the valves are open. But if you pour water into a funnel far down in our pipe construction the water can only flow down into the underlying pipes. Just as water would never think of flowing upwards in the pipes, data in a React application cannot move from the bottom up.
This principle allows you in a React application to isolate data-driven events to only the parts of the application that should be affected by those events. It gives the developer both an overview and control over how data flows in the application. It is also part of the technical architecture that makes React so fast — you make sure that as few parts as possible of the application are affected when a change occurs. Fewer things needing to be redrawn means faster re-rendering of the page.
Success breeds success, as they say, and this applies to open source to a very high degree. You want to use a framework that is used by many others simply because it tends to bring many benefits in the form of:
All of this is in place in React because it is such a large JavaScript framework.
React may be one of the world's largest JavaScript frameworks, but like all other frameworks it doesn't cover every user scenario one hundred percent. You often need to bring in other code libraries to handle tasks that React doesn't fully manage.
React is designed to build JavaScript applications with a focus on fast user interfaces. That also means that other functionality that might be needed has been toned down or omitted. One such example is data handling. It's perfectly possible to build simple data handling on a small scale with just React, but for slightly larger applications you need to bring in code libraries specifically developed for that. Two of the most popular libraries are Redux and MobX. They both provide React with powerful data management tools but with slightly different approaches.
You might think it's a disadvantage that React alone doesn't cover everything, but we think it's more of an advantage. JavaScript frameworks that try to cover every possible scenario become very large and heavy to work with. Partly it's about the amount of code that needs to be downloaded by visitors' browsers, partly it's about the process of developing in them. The fact that React doesn't cover all conceivable functionality gives us the option to complement React with different types of technology based on the project rather than always having to use the same technology.
Our clients often ask which framework is "the one to use". It's a highly relevant question since no client wants to invest time and money in something that risks becoming a technical dead end. But it's seldom so extreme that there is only a single framework that matters. In this article we've mentioned the big three: React, Angular and Vue. All three meet the requirements you should set for a modern JavaScript framework. With that out of the way, you can instead focus on which framework is best suited for the task at hand, how much experience the development team has with the framework, and whether there are compatibility requirements that make it easier or harder to get the chosen framework to work together with other parts of the application.
Making this decision is something we help our clients with. If you're completely uninterested in the technical aspect of the solution and only want it to be fast, good-looking and work, we choose the framework based on the specific project in order to meet those functional requirements. We often end up with React, but not always.
There is also comfort in knowing that everything — regardless of framework — is basically plain JavaScript at its core. What the framework adds is therefore not an entirely new programming language but merely a toolbox that speeds up development and improves the quality of the solution.