This document is not a tutorial. It's intended to provide some context for understanding ReactJS, some helpful information on some its functionality, and how to get started.
This is a 'living doc' that will be continually updated and revised.
The Internet was originally created as a means to electronically share information via static files. This is the first website ever. As you can see, there's not much there. It's a static page, with some links to other pages. No JavaScript or database, just some HTML content. However, as the web became more popular, people began to discover new uses for it. We created ways to incorporate styles and images with CSS. This is a good example.
Eventually we wanted dynamic content, so we created languages that could handle server-side logic on the web and databases that could create, update, and destroy information (think early blogs). Later we wanted executable client-side scripts to provide even more rich user experiences, so we started adding JavaScript and eventually jQuery.
It was the Wild West. Things were new and advancing quickly. No one had the benefit of hindsight. There were no established best practices. There was no separation of concerns. At some point our lack of architecture became really cumbersome. Our websites had reached a level of complexity where they were difficult to maintain and improve. So we adopted the pattern of MVC (Model-View-Controller). We began putting JavaScript and CSS in separate files. Models, Controllers, and Views began to take on distinct responsibilities. This pattern has worked really well for web applications. It allows us as developers to iterate and add complexity while still being able to reason about what's happening and maintain the application. In most cases we ca deliver a consistent quality experience for users and have confidence that things work.
I say all this to point out that while we've forged our architecture for how we build web applications, we're still building on top of a system that was originally designed to deliver static content. In a lot of ways, the pains we feel as developers now are because of the nature of the systems we've created. We're pushing our architecture as far as it can go.
And yet the web continues to evolve.
The applications being built five to ten years ago simply do not meet the standard of what people expect from an experience on a website today. Lightning-fast page loading, high-quality content and user experiences, mobile-friendly, and streaming message and media services are only a few of the demands on web developers today. We continue to add complexity to what we consider "established best practices", and we feel the pain in our development process.
Facebook found themselves entrenched with complexity issues. They were continuing to support more users on various platforms, adding more features, and trying to maintain their ever-growing codebase. And these are most likely struggles you've felt if you've ever worked on an application of scale. They responded by creating React as an internal tool to better handle their front-end complexity. The newly acquired Instagram was also eager to get on board. Eventually they decided to open-source the library.
React was initially met with a lot of snark:
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>Facebook: Rethink established best practices™
— Ben Alman (@cowboy) May 29, 2013
A lot of people thought the way React structured code was a step backward from the established patterns and had poor separation of concerns. However, React argues that the "tried and true" architecture for front-end code creates issues with maintainability and handling complexity.