What do you want to learn?
Skip to main content
React: The Big Picture
by Cory House
Interested in React? This course explores why React is worth considering, tradeoffs to consider, and reasons React may, or may not be the right fit for you.
Start CourseBookmarkAdd to Channel
Table of contents
Hello. My name is Cory House, and welcome to React: The Big Picture. I'm the principal consultant at reactjsconsulting.com. Are you considering React and wondering why it's so popular? Are you curious if React is a good fit for you and your team? Or perhaps you're already using React, but you want to better understand the merits and downsides so that you can better sell React to your coworkers and leadership. If so, this course is for you. In this course, we're going to answer three questions, why should I choose React, what tradeoffs are inherent in React's design, ecosystem, and philosophy, and why shouldn't I choose React? Some of the major topics that we'll cover include the many potential use cases for React, what sets React apart from its competition, key projects to consider in the React ecosystem, approaches to mitigating React's downsides, and the five key decisions that you need to make to get started. By the end of this course, you'll understand React and its ecosystem at a high level and you'll have a clear view of React's strengths, tradeoffs, and weaknesses. I hope you'll join me to learn what makes React special in React: The Big Picture, at Pluralsight.
Hello, and welcome to React: The Big Picture. If you're watching this, I assume that you're new to React and you're looking for a short overview of what it is and why it has become so popular so that you can decide if React is right for your team. I'm Cory House. You can catch me on Twitter @housecor or at my consulting site, reactjsconsulting.com. This course consists of three short modules. In this first module, we'll explore what makes React special and worth choosing over the competition. In the next module, we'll discuss the tradeoffs inherent in React's design so that you can understand what you're getting and what you're giving up by choosing React. And I'll close out the course by considering common concerns that I hear about React and approaches for how to mitigate these concerns. All right, let's get started.
Let's begin with a brief history of React. Facebook created React in 2011 for their own use on facebook.com, one of the highest-trafficked websites in the world. React was then utilized by Instagram a year later in 2012. After already using React internally for 2 years, Facebook open sourced React in 2013. Some initially dismissed it because React ran contrary to popular practices by placing markup and logic together in a single file. But as more people experimented with the library, many embraced the new component-centric philosophy for separating concerns. Each React component is a separate concern. A year later in 2014, React had grown significantly in popularity and was embraced by many notable companies outside of Facebook. This popularity led Facebook to open source React Native too in 2015. React Native is a related library that allows you to create native mobile applications for iOS and Android using React. In April of 2016, React reached another significant milestone by publishing version 15. This was a notable release because the previous version was .14. Moving to 15.0 finally put React's semantic versioning scheme in sync with traditional semantic versioning practices, and it also helped convey that React was now a mature and stable platform with over 5 years of active development and heavy production usage to back it up. Today there are over 30,000 React components in production at Facebook. Facebook is deeply committed to React since it also uses React on Instagram and React Native for mobile development. Today, Facebook employs a full-time React development staff that regularly releases bug fixes, enhancements, blog posts, and documentation. And as you'll see soon, many large, well-respected Fortune 500 companies now utilize React in production.
If you're watching this course, the biggest question on your mind likely is why should I choose React over the long list of alternatives? Well, throughout the course, we'll explore the answer in detail, but in the next few clips, let's explore six key reasons, flexibility, developer experience, corporate commitment, community support, performance, and testability.
Reason 1: Flexibility
Reason 2: Developer Experience
Reason 3: Corporate Investment
Reason number 3 is that many well-respected corporations are deeply invested in React and its ecosystem today. React was created by Facebook, so of course React is heavily used on Facebook, one of the highest-trafficked apps in the world, as well as Facebook's other properties such as Instagram and WhatsApp. Facebook is deeply committed to React. Although React is an open source project, four of the top six committers to the React project are current, full-time Facebook employees. And the Facebook development team maintains an active blog that consistently outlines the details of each release and plans for the future. Because of Facebook's deep existing commitment to React in production, when breaking changes occur in React, Facebook has consistently provided a codemod that automates the change. Now, a codemod is a command line tool that you can point at your code base to automate changes. So with React codemod, you can automatically update older React components to the latest specification. Over the years when breaking changes have occurred, the Facebook team has consistently published a codemod in order to automate updating to the latest version. So for example, when Facebook released React 15.5, the propTypes feature was published as a separate package, and use of the propTypes feature embedded in React began throwing a warning to notify developers of the change. To make updating easy, Facebook released a codemod to automate the changes by updating imports to reference the separate propTypes packages. And it's smart enough to update relevant code below in the body of the components as well. The beauty is we can feel confident about writing React components today because of Facebook's deep investment in the production React code, means they must rely on the codemods that they create to update their own code. See, codemods exist because Facebook needs them. Facebook has over 30,000 components in production. This is a benefit of using React because it helps assure that significant breaking changes in the future are highly unlikely. Doing so would require Facebook to deal with painful breaking changes to tens of thousands of their own components, so this helps assure the long-term stability of the project.
Reason 4: Community
The 4th reason to consider React is it boasts a huge, active community. Since 2013, React's popularity has steadily grown to over 75,000 stars on GitHub today. This makes React one of the most popular repositories on GitHub. Today it has over 1,000 contributors. In fact, out of over 2 million repositories, only 3 repositories have more stars on GitHub than React. At the time of this recording, the React npm package is downloaded over 1.5 million times every single week. Now that's seriously impressive. On StackShare, a site where companies can share the technologies that they're using, nearly 5,000 companies have reported using React. And at the time of this recording, React is the eighth most popular technology on all of StackShare. Facebook developers and a long list of open source React contributors are also involved in Reactiflux, which is an active online community of over 20,000 React developers. There are over 55,000 threads on Stack Overflow that are tagged reactjs, and nearly 20,000 tagged react-native, as well as a long list of related tags for other React-related technologies. Now all this matters because it adds up to a simple fact: if you're trying to do something in React, you can almost certainly find an example of it online. And hey, what developer doesn't love a little copy and paste now and then? It's pretty awesome being able to consistently get answers from other people who have run up against the same challenge that you're trying to solve. And that's because React is embraced by far more than just Facebook. Today, many of the world's most respected companies use React, including Apple, Netflix, Amazon, Airbnb, PayPal, and many more that you see here. Many of these companies regularly open source their React-related work as well. So if you choose React, you're certainly in great company. And you don't need to create your own components, since there's a huge list of free and mature component libraries online. Microsoft open sourced their React component library for making user interfaces that look and feel like Microsoft office. Material-UI offers a set of React components that implement Google's material design guidelines. And React-Bootstrap is a popular library that contains React components that make it easy to work with Bootstrap. Plus, there are literally hundreds of interesting standalone React components out there on GitHub that you might find useful. Check out the awesome React list on GitHub for a long list of additional components. Deep community investment has led to a wide variety of mature, related projects. Do you need routing? Well, check out React Router. Do you want to handle complex data flows using a library? Well, Redux and Mobx are two popular options to consider today. Do you want to set up automated testing? Well, check out Jest, which is also from Facebook. Want an alternative to RESTful API calls where you can declare your API calls on the client? Try out GraphQL, which is a great fit on React apps. Want to quickly set up a server-side rendered site in React with node? Then try Next.js. Of course, this just scratches the surface of the ecosystem. This list could go on and on. So I guess you could say that React is kind of a big deal right now.
Reason 5: Performance
Reason 6: Testability
In this module, we explored the many reasons that React has become so popular. It's exceptionally flexible. You can build web apps, native apps, desktops apps, virtual reality apps, and more. React provides a rapid feedback development experience that allows the developer to work with single components in isolation. You don't need the cognitive overhead and slow feedback loop that often occurs when maintaining separate interconnected files. Facebook has made a deep corporate investment in React including a full-time development staff, excellent documentation, and heavy public usage by Facebook itself on both facebook.com and Instagram. React has remarkable community support. It's one of the most popular projects on GitHub, and it's used by many of the most respected companies in the world. It offers excellent performance by default, and handy performance enhancements for the rare occasions that you need them. Finally, it's easy to test, especially with popular libraries like Jest that are built in to popular boilerplates like create-react-apps. Okay, so this module was admittedly quite the sales pitch. Life can't all be rosy; you're right. So in the next module, let's consider the tradeoffs that are inherent in React.
I enjoy React, but I have to admit, I just gave you a one-sided sales pitch. So in this module, let me step back and be more balanced. Here's 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,
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 fundamentally 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. However, React's library approach also has some clear advantages. At only around 35K gzipped, React is significantly 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 light-weight. This is precisely how Facebook slowly rendered 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 boilerplates 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
Tradeoff 4: Separate vs. Single File
Tradeoff 5: Standard vs. Non-standard
Tradeoff 6: Community vs. Corporate
Why Not React?
If I'm going to share the big picture with you, I owe it to you to be completely up front about the potential issues with choosing React. So in this module, I'll share the common concerns I hear about React. JSX differs from HTML, React requires a build step, there's a potential for version conflicts, and React has evolved over time so you'll find references to old features when searching the web, and since React is a lightweight library, you may feel intimidated by the number of decisions you need to make up front. Oh, and you might have heard that React's license has a patent clause. Well, great news, that's no longer an issue. With the release of React 16, Facebook relicensed React to use the standard MIT open source license, so there's nothing to worry about there anymore. That said, you'll see that some of the other concerns above are valid and others are merely misconceptions or issues that can be easily mitigated.
Concern 1: HTML and JSX Differ
Concern 2: Build Step Required
Concern 3: Version Conflicts
The third concern is potential version conflicts. As I mentioned earlier, React with React DOM weighs only around 35K minified and gzipped. That's a very reasonable size, but there's some downsides to having a runtime at all. See, you can't run two versions of React at the same time on the same page, so this means that you need to keep your React components on the same version for a given page. In contrast, if you build standardized Web Components, you don't have to worry about version conflicts at all since there's no runtime. Standard Web Components just leverage the support that's built right into the browser. However, for reasons I outlined in a previous module, I still prefer working in React over using plain Web Components, and that's partially because the Web Components standard lacks features that I've grown to know and love from React and other frameworks like efficient DOM updates, reactive data binding, and more. So there are other interesting tools to consider like SkateJS, Svelte, and Stencil, which bring those features to Web Components without the need for a framework. These options are interesting because they leverage the Web Components standard, but add extra features. They also embed their runtime within each component so you don't need to worry about version conflicts. And since React is a lean component library, you will often choose to use related libraries with React such as React Router, so you need to run compatible versions. This means that you typically need to run a recent version of React to avoid a version conflict. For example, today if you want to use the newest version of React Router with your React app, you need to run React 15 or newer. In practice though, I've found version conflicts are rarely a problem in React. Since Facebook has been consistent about releasing codemods when breaking releases occur, upgrades to your existing React components can typically be easily automated. Here are three tips to avoid version conflicts. First, agree as a team which version of React you're working with. Second, upgrade React when you're upgrading related libraries. And finally, on the rare instances where there are breaking changes in a future release, decide as a team when to upgrade.
Concern 4: Outdated Resources Online
The 4th concern is old stuff showing up in searches. React has a large, mature community, and it has evolved since it was open sourced in 2013. Search for the term react example on Google, and you get 1.7 million results. There are over 57,000 questions tagged with react on Stack Overflow and around 30,000 questions on related technologies like React Native, React Router, and Redux. And there are thousands of blog posts out there on blogging platforms like Medium about React and related technologies. And hey, having many great resources online is a great thing, right? Absolutely. But there's an obvious risk. Some of this public content is outdated. React has evolved since it was released in 2013, so as you search around the web, you'll see some patterns that are no longer popular today. So what has changed? Well recently, features have been extracted from React Core to keep the library lean and simple. Since React is used for more than just the web now, React DOM was extracted to a separate package, so you'll see many posts using the style on the left, but today, reference the separate React DOM library for web development. And if you're doing development for other platforms, you'll import the renderer that's appropriate for that platform such as React Native. Second, since most people are using ES classes today, react.createClass was extracted to a separate library called create-react-class, so you need to reference this separate library if you want to declare React components using the createClass style. And since only some teams choose to use PropTypes over alternatives like TypeScript and Flow, the PropTypes library was extracted to a separate npm package, too. So you'll need to install the PropTypes library and import it like you see here on the right. Finally, mixins were initially a popular way to share functionally between components in React. However, due to various issues, mixins are no longer part of React Core. Today, alternative patterns like higher ordered components and render props serve this purpose. Now this is an advanced topic, so don't worry if that makes no sense at all. The bottom line is, when you see an old point that mentions mixins, look into these alternative patterns instead. So keep these four changes in mind. You'll see the old-style imports on the left in older blog posts and videos, but as you can see, it's trivial to update the old code to reference the separate packages on the right. And of course, when you're in doubt, check React's documentation. It's excellent, up to date, and actively maintained by Facebook.
Concern 5: Decision Fatigue
Cory is an independent consultant with over 15 years of experience in software development. He is the principal consultant at reactjsconsulting.com and a Microsoft MVP.
Released21 Nov 2017