I enjoy React, but I have to admit, I gave you a one‑sided sales pitch. So in this article, let me step back and be more balanced. Here is the plan. Let’s consider six key tradeoffs that you accept when you choose React. These are the key tradeoffs that the React development team made when designing React. In the next few clips, let’s consider the impact of these key tradeoffs so that you can better understand if React makes sense for your team.
This Articles Contents
Tradeoff 1: Framework vs. Library
The first tradeoff is framework versus library. Competitors like Angular and Ember are frameworks. React, in contrast, is generally considered a library since it’s lean and focused on components. Now a framework isn’t better than a library. It’s a tradeoff. Here’s a few advantages to choosing the framework approach.
A framework contains more opinions, so you can avoid spending time trying to choose between many options. This reduces decision fatigue, and there’s often less setup overhead. Frameworks can help enforce consistency since most frameworks are more opinionated. But, React’s Library approach also has some clear advantages. At only around 35K Gzipped, React is smaller than most frameworks.
This means that it’s small enough that you can sprinkle it on existing applications so that you can slowly migrate an existing app to React, even a server‑side rendered app. Imagine you have an existing app built in .NET, Java, Ruby, PHP, Python, whatever. Since React is small and flexible, you can replace a single component on the page with a React component.
So you can use your React components anywhere because they’re lightweight. This is precisely how Facebook slowly migrated from a server‑side rendered PHP application to React. And React doesn’t force many decisions on you. It allows you to only pull in the features that you need to keep your app lean and fast. You’re free to pick the precise technologies that you need for your project, and you’re free to select the best technology for your use case as well.
Decision fatigue is also largely a solved problem with React because opinionated boiler plates, like create‑react‑app, effectively turn React into an optional framework. Now since React is a focused component library, more comprehensive frameworks like Angular come bundled with more features, including testing, a library for HTTP calls, routing, and internationalization all built in. In contrast with React, you select the pieces that apply to your use case and you add them in.
Since React is very popular, there’s almost certainly a mature library that does what you need. Here’s just a few of the most popular options for each use case. And the nice thing with React is your users don’t have to waste time downloading and parsing features that they don’t use. You can pull in only what you need from this list.
Tradeoff 2: Concise vs. Explicit
The second trade‑off to consider is concise versus explicit. React trades conciseness for predictability and explicitness. You spend a little more time explicitly wiring things up together, but that helps them not fall apart. And it also helps people better understand what the code is doing.
It requires a little more code. With React, you declare an explicit change handler, and you reference it on your input. This extra work has some benefits. You have more control because you can declare precisely what should happen on every event. This means you can transform and validate input before updating state and perform performance optimizations as desired.
Your code is more explicit since you clearly state what you want to happen when an event occurs. And this makes it easy to understand and debug when an error happens. Although React helped repopularize doing one‑way binding, other popular libraries like Angular have shifted gears and embrace it as well today for these reasons. Now, if your team strongly prefers two‑way binding, you can use libraries that add it to React, but for the reasons I just mentioned, few do so, and I don’t recommend it. Also, don’t worry.
You don’t need to declare a separate change handler for each input. There are simple patterns for centralizing your change handlers in React, as I show in my other React courses. So in the real world, the amount of code that you write in React isn’t substantially larger because of one‑way binding because you typically have a single change handler for an entire form. In summary, here’s the trade‑off. React requires more typing to implement than traditional two‑way binding approaches, but with the benefit of easier maintenance, greater clarity, reliability, and performance.
Tradeoff 4: Separate vs. Single File
In React, each component contains both logic and markup in the same file, so on the surface, this feels like it violates the principle of separation of concerns. However, in React, you think about separation of concerns differently. Traditional separation of concerns often fixates on placing each technology in a separate file. So in web development, this means placing HTML, CSS, and JS in separate files.
If you change one file, it often requires corresponding changes to other files. Oh, and you’re not forced to handle styling in the same file. With React, you’re free to handle CSS in a traditional separate CSS file, if you prefer. Think of component composition like Russian dolls. Russian dolls are interesting because each doll can hold a smaller doll inside. React’s component model works the same way.
Simple, reusable components can be composed together to build rich, complex user interfaces. With React, you can think of the page as a set of nested components. Consider an author page on pluralsight.com. We could build this page in React by creating simple components like a star rating, an author photo, a navigation link, and so on.
Then we could compose those simple components together to make the course summary, the author summary, or the sidebar navigation. Finally, we could compose those larger components together to create even larger components like author courses.
When you see all this displayed at the same time, you can see how the small components in orange are used as part of the larger components in blue, and the larger components in blue, like the course summary, are composed together to create large portions of the app in green, like the author courses. As you can see, React’s component approach lends itself well to building complex Uis by breaking your page down into small, autonomous pieces that you can reason about and test in isolation.
Tradeoff 5: Standard vs. Non-standard
The fifth tradeoff is standard versus non‑standard. React is just one of many non‑standard component libraries, but the web component standard has actually been around for years without much usage yet. So why aren’t many people building apps with standardized web components yet? Well, first, let’s review what the web component standard is.
The web component standard exists of four core technologies, templates which contained markup, custom elements, which allow you to expand HTML with your own custom elements, the shadow DOM, which encapsulates styling to avoid your styles leaking outside of your component, and imports, which bundle everything together into a single line that you can import onto the page.
I published HTML5 Web Component Fundamentals in 2015, and I remain hopeful about standardized HTML components. But unfortunately, the standard has yet to be embraced much by the development community. Today, most developers continue to use libraries like Angular, Vue, and React instead. So the big question is, why hasn’t the web component standard taken off yet?
Well, likely the biggest reason that people aren’t using plain web components is browser support remains spotty. The template tag isn’t supported in any versions of Internet Explorer, HTML imports are only supported in Chrome, Opera, and Android, custom elements are only supported in Chrome, Opera, and some of the newest Android browsers, and it’s pretty much the same sad story with the shadow DOM.
Web components allow you to expand HTML by declaring custom elements. React components accomplished that same thing. The shadow DOM lets you encapsulate your styles within your web component. Various technologies, like CSS modules, CSS in JS, and even React’s built‑in inline styles, assure that your styles are encapsulated automatically. Finally, web components offer HTML imports for bundling the component together into a single import.
Finally, since web components utilize standards built into a web browser, you can’t use them elsewhere like on native mobile. React in contrast works on mobile and virtual reality too, as well as a number of other interesting platforms. In summary, the web component standard may take off at some point, but currently the majority of developers continue to reach for the tools on the right because they’re innovating more quickly, offer a strong user experience, and run reliably cross‑browser today.
Tradeoff 6: Community vs. Corporate
Facebook provides React a full‑time development staff that carefully plans releases, writes documentation and blog posts, and provides ongoing support for issues on GitHub and often even on social media. Even though React has a full‑time staff, there are over 1,000 contributors to React, so the community is vibrant and engaged. Facebook is currently wildly successful. At the time of this recording, it’s the fifth most valuable company in the world, with a market capitalization of $445 billion.
Even if Facebook were no longer involved in React, the project would certainly live on without full‑time Facebook involvement for the foreseeable future. Plus, many competitors lack the benefit of a full‑time corporate development staff that React boasts today. So while React’s corporate tie is a potential concern, it’s also a significant benefit for support and ongoing development for the foreseeable future. Finally, as I mentioned earlier, Facebook is deeply invested in React with over 50,000 components in production. So as long as Facebook is around, they’re likely to continue providing significant ongoing React support. And that’s it. Those are the trade‑offs to consider with React. Let’s close out this module with short summary.
In contrast, each React component is a single autonomous file that you can work with and test in isolation. The web component standard has been around for years, yet it continues to lack broad adoption. Non‑standard approaches, like React and Angular, remain more popular because they offer the same power, more rapid innovation, and a superior developer experience.
And React is corporate‑backed, which means its design is influenced by Facebook’s needs. But Facebook continues to accept input from the community and has evolved React into a highly flexible and well‑supported system. Of course, with tradeoffs, there’s no right answer. But at least now you understand what you’re getting and what you’re giving up with each of these tradeoffs. In the next module, I’ll be even more critical. Let’s explore the common concerns that I hear about with React so that you can decide if the downsides that other people talk about matter to you.