Common misconceptions
There is a common opinion that React is a huge set of technologies and tools, and if you want to use it, you are forced to deal with package managers, transpilers, module bundlers, and an infinite list of different libraries.
This idea is so widespread and shared among people that it has been clearly defined, and has been given the name JavaScript Fatigue.
It is not hard to understand the reasons behind this. In fact, all the repositories and libraries in the React ecosystem are made using the shiny new technologies, the latest version of JavaScript, and the most advanced techniques and paradigms.
Moreover, there is a massive number of React boilerplates on GitHub, each one with tens of dependencies to offer solutions for any problems.
It is very easy to think that all these tools are required to start using React, but this is far from the truth.
Despite this common way of thinking, React is a pretty tiny library, and it can be used inside any page (or even inside a JSFiddle) in the same way everyone used to use jQuery or Backbone: just by including the script on the page before the closing body element.
To be fair, there are two scripts because React is split into two packages: react, which implements the core features of the library, and react-dom, which contains all the browser-related features. The reason behind that is because the core package is used to support different targets, such as React DOM in browsers and React Native on mobile devices.
Running a React application inside a single HTML page does not require any package manager or complex operation. You can just download the distribution bundle and host it yourself (or use unpkg.com), and you are ready to get started with React and its features in a few minutes.
Here are the URLs to be included in the HTML to start using React:
If we include the core React library only, we cannot use JSX because it is not a standard language supported by the browser; but, the whole point is to start with the bare minimum set of features and add more functionalities as soon as they are needed.
For a simple UI, we could just use createElement and, only when we start building something more complex, we can include a transpiler to enable JSX and convert it into JavaScript.
As soon as the app grows a bit more, we may need a router to handle different pages and views, and we can include that as well.
At some point, we may want to load data from some API endpoints, and if the application keeps growing, we will reach the point where we need some external dependencies to abstract complex operations. Only in that very moment, should we introduce a package manager.
Then the time will come to split our application into separate modules and organize our files in the right way. At that point, we should start thinking about using a module bundler.
Following this very simple approach, there's no fatigue.
Starting with a boilerplate that has one hundred dependencies and tens of npm packages of which we know nothing is the best way to get lost.
It is important to note that every programming-related job (and front end engineering in particular) requires continuous learning. It is the nature of the Web to evolve at a very fast pace and change according to the needs of both users and developers. This is the way our environment has worked since the beginning and what makes it very exciting.
As we gain experience working on the Web, we learn that we cannot master everything and we should find the right way to keep ourselves updated to avoid the fatigue. We become able to follow all the new trends without jumping into the new libraries for the sake of it, unless we have time for a side project.
It is astonishing how, in the JavaScript world, as soon as a specification is announced or drafted, someone in the community implements it as a transpiler plugin or a polyfill, letting everyone else play with it while the browser vendors agree and start supporting it.
This is something that makes JavaScript and the browser a completely different environment compared to any other language or platform.
The downside of it is that things change very quickly, but it is just a matter of finding the right balance between betting on new technologies versus staying safe.
In any case, Facebook developers care a lot about the DX (developer experience), and they listen carefully to the community. So, even if it is not true that to use React we are required to learn hundreds of different tools, they realized that people were feeling the fatigue and they released a CLI tool that makes it incredibly easy to scaffold and run a real React application.
The only requirement is to use a node.js/npm environment and install the CLI tool globally:
npm install -g create-react-app
When the executable is installed, we can use it to create our application passing a folder name:
create-react-app hello-world
Finally, we move into the folder of our application with cd hello-world and we just run:
npm start
Magically, our application is running with a single dependency, but with all the features needed to build a complete React application using the most advanced techniques. The following screenshot shows the default page of an application created with create-react-app:
We will use this tool throughout the book to run the examples for each chapter which are also available on GitHub at the following address:
https://github.com/MicheleBertoli/react-design-patterns-and-best-practices
