Before choosing it for your tech stack, learn more about React: its components, Virtual DOM, flexibility, ease of development. Find out how it's different from other frontend frameworks, discover possible limitations and ways to deal with them.
Virtual DOM improves performance, and JSX allows programmers to build the UI using syntax that closely resembles HTML. Components allow developers to handle even the largest scale projects with ease.
React is supported by many big companies, so it will remain a stable solution for years to come.
The community of React is vast and active, making it easy to find experienced developers, seek for help, and find ready-made solutions.
The default for React is a SPA (Single Page Application)﹣if we want to build server-side rendered applications, we need to use other tools like Next.js or Gatsby. React gives us freedom in terms of the backend.
Most common high-level problems with React relate to folder structure and the heterogeneity of the environment. Inexperienced developers may find choosing a suitable library problematic and structure the code inefficiently.
The library for creating User Interfaces with reusable components. No imposed technological or architectural solutions. Flexibility and reliability. That’s React in a nutshell.
<blockquote><p>It’s […] a powerful tool that may well change the way you approach front-end development. […] Instead of the usual approach to writing user interfaces, React treats each UI element as a contained state machine.</p><p>– Bonnie Eisenman, former software engineer at Codeacademy.com, now tech lead at Twitter</p></blockquote>
If you consider React for your tech stack, there are a few things you should know. Let’s dive into specifics: React features, flexibility, learning curve, possible tech stack solutions. Also included: senior engineer’s advice on folder structure which you won’t find in tutorials.
Frameworks limit the flexibility in terms of tooling, technology stack, code patterns. React doesn’t limit it in any way. It has a simple task: make building User Interfaces easy and powerful. And it fulfills its purpose perfectly.
<blockquote><p>Having worked with JS frameworks for several years, we all know that frameworks are often bloated and force you to include things you don’t need. That may be ok in the server-side world, but a significant disadvantage with web apps.</p><p>– Rich Manalang, former Architect and Team Lead at Atlassian, about rebuilding HipChat with React</p></blockquote>
The default for React are SPAs (Single Page Applications). When building a complex application, you’ll most likely need to use React with other libraries and tools. There are no dependencies, so you and your team choose the whole tech stack.
Thanks to components and modularity React is perfect for large-scale apps. However, while creating a React app, it’s recommended to have a large scale in mind from the beginning, while designing architecture and structuring folders.
<span class="colorbox1" fs-test-element="box1">Tip: We explain how to structure folders later, with examples.</span>
In the case of React, the library is in charge of performing all of the steps needed to achieve the result. Sometimes it can be challenging since the team has to know how to define the results but in the end the declarative code is easier to read and manage in the long run.
Traditionally, a website uses HTML pages fetched from a server to update the view. For websites that involve high user interaction, it can seriously spoil the performance, since the entire DOM needs to reload every time a user clicks a feature calling for a page refresh.
Single Page Apps written in React don’t need to fetch external HTML pages from a server. JSX allows developers to create a Virtual DOM﹣a copy of a real DOM React uses to see what parts need to change when an event happens. Virtual DOM determines what changes need to be made and updates the particular section intelligently. It takes less computing power and loading time. As a consequence, it improves performance a lot.
To write React apps developers create components that correspond to various interface elements. Each component represents a small, reusable piece of HTML, has its own logic and controls. It can maintain an internal state. Components make unit testing easier.
To define the structure of an application, components are organized logically into a tree-like structure, where higher-level components encapsulate lower-level ones. Components can be nested within other components which allows for crafting complex applications with simple building blocks.
<blockquote><p>Although it is possible to achieve modularity with a classical inheritance pattern, frequent changes in superclass interfaces to support new features affects existing subclasses and increases code fragility. React’s compositional pattern is ideal for overall maintenance and scalability of our front-end codebase as it isolates much of the A/B test code.</p><p>Jordanna Kwok, Engineering Leader at Netflix</p></blockquote>
React uses one-way data binding: it only binds the value of the model to the view, not the other way around. The information flows only in one direction. Developers modify the component’s state, and updates are propagated to components that are nested inside of them. The data can be transferred only from a component to the view, not the other way around.
<span class="colorbox1" fs-test-element="box1">Important: Components don’t modify the data they received.</span>
Two-way data binding, used in frameworks like Angular, means that when there are data changes in the model (the model gets updated), so does the UI, and when UI elements get updated, that change is propagated back to the model. Sometimes it can cause side-effects.
<blockquote><p>The “one way data flow” appealed to all developers in the team as a neat way to think about a UI application interactions. This also felt like a good solution to make debugging and understand data flows much easier and predictable.</p><p>– Subramanyan Murali, former Engineering Manager, Yahoo Mail</p></blockquote>
React offers a lot of flexibility in terms of architecture patterns, additional tooling, third-party libraries.
On the one hand, this flexibility is a huge advantage for frontend experts. Unopinionated library allows a team to adjust every single aspect to the product’s requirements. React gives them a lot of options, is easy and pleasant to work with.
On the other, it’s easy to make a mess in architecture when inexperienced developers start to code in React. Also, in the case of big teams, you need to keep the finger on the pulse in terms of unification: using the same tools and patterns.
<span class="colorbox1" fs-test-element="box1">Key take-away: React’s flexibility makes work easier for experienced frontend developers and may create and obstacle for others (look after the unification in terms of tools and patterns).</span>
React.js is supported by the biggest players. As everybody knows, Facebook stays behind it, but many big companies like Airbnb, Slack, Lyft, are engaged in creating the ecosystem around React.
It makes React a stable solution. We can be sure that the library will be supported for years. Even if React itself would completely stop expanding in a few years, it will be supported for the next 20. That makes it a stable solution for apps that plan to expand and be in the market for a long time.
The React community on GitHub is also strong. On the one hand, that’s an indicator of talent availability. On the other, a big community means more support when your developers will need help. Also, the React community is very active and creates useful tools and solutions that are publicly available.
However, you need to be careful during the recruitment process, because a big community may also mean that it will be harder to pick the best ones from the crowd.
The state of all components depends on one root object tree. This makes your app easier to look at as a whole and debug. Developers can easily separate the Model logic from the View, doing it in a scalable way, as well as write the state locally or on a server. Redux also gives you a few great debugging tools.
React and Redux create a perfect tech stack for real-time applications.
Next.js is used to write server-side rendering to React apps. Server-side rendering allows developers to transfer navigation to the client-side and upload only parts of the website, not the whole.
Next.js launches on Node.js and comes with many useful default solutions that provide excellent performance. The team behind it provided many optimizations.
Next.js is perfect for e-commerce: Google understands it, clients get the content quickly and can navigate easily.
React goes well with any tech stack we choose, meaning you can use any backend.
Node.js seems to be the best choice when you want to use one team to create the frontend and the backend of your web application.
Since Angular is highly opinionated, frontend experts may struggle with following its rules. React and Vue are both flexible, hard to deal with for those who only start with frontend development. Vue is fairly new and it builds its position on the market but the position of React and the community around the library is bigger.
Angular is the most mature framework out of these three. It offers a whole platform with a complete package of tools. Some consider it an advantage, some not since it cuts off the flexibility. The learning curve is steep for frontend experts and concepts seem complex. It is highly opinionated, so will be a better choice for fragmented teams and backend developers. Angular is supported by Google, but they also focus on other technologies.
React is liked by the community, offers a lot of support from the contributors, and useful, publicly available solutions. It’s easy to integrate with other frameworks. It doesn’t offer as much as Angular, but it does its part perfectly. It’s supported by the largest players which makes it reliable for long-term projects. There are many talents in the market. React is a perfect choice for large-scale apps since it offers modularity, however, developers need to know how to handle it.
Vue doesn’t have backing from a big company and is the youngest here. Developers like it since it’s very flexible. However, it can become too flexible for some teams and hard to use for non-experienced ones. It has the lowest learning curve for frontend experts and high for backend ones. Vue has the smallest community and lacks some plugins, but it’s growing steadily, being the most lightweight and offering excellent performance.
React is perfect for a large scale but developers need to take care of the architecture and folder structure from the very beginning.
Unfortunately, tutorials don’t mention that.
For the last 2-3 years, the community has been speaking more loudly about these problems. We’ve also seen it in projects we have worked upon. Being boring or not, this topic is crucial, especially for large-scale apps.
Instead of following the folder structure from tutorials, we recommend looking at it from the abstraction and composition point of view, use feature folders, refactor often, and build an architecture based on bounded context (the central pattern in Domain-Driven Design).
<blockquote><p>DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.</p><p>– Martin Fowler</p></blockquote>
Then, the golden rule in structuring folders is to keep things close to the place you use them.
How could it look like in a React app? Check this example:
Why should you care? The structure from tutorials simply doesn’t scale. Folders like “services” or “repositories” grow endlessly and team members need to build mental images to connect code from various folders. Keeping it together solves the problem.
The structure presented above allows for high scalability and makes development more efficient. It’s easier to make changes and test the app, and new developers have an easier start. If you have scalability in mind, take care of folder structure from the very beginning, and do it the right way.
React offers many solutions that solve the same problems. All of them are popular and there is no best one chosen by the community.
It can be both: advantage and the opposite.
On one side, it gives us the possibility to choose the best solution for our specific case, and the choice is always broad. On the other, we need to choose consciously and take care of every developer maintaining a consistent, relevant environment. When each developer uses different tools, things can go off the beaten track: the code becomes inefficient and it creates bugs.
Many companies choose React because of the freedom and flexibility it offers, along with the stability, supportive community, and a large talent pool. The whole ecosystem provides many useful tools and gives us the freedom to pick the technology stack for our application. In the meantime, React is awesome in doing its job﹣taking care of the UI of our application.
Frontend developers will most likely find React easier to learn and code with, compared to Angular. Compared to Vue, it’s more stable, with a larger community and talent pool.
React seems to be perfect for large-scale apps, but with architecture design and folder structure in mind from the very beginning.
If you need to explore React further, the next chapter of this handbook goes deeper into React scalability, maintenance, performance, and security﹣crucial aspects when assessing the business viability of the technology.
Become a better tech leader.
Join 200+ CTOs, founders and engineering managers and get weekly bite-sized leadership lessons that take <60 seconds to read.
No previous chapters
No next chapters