This is the first article in the series on developing maintainable Web-Applications with React and Redux.

The goal of this series is to give you a fully up to date view on how to create a web application, sticking to the highest standards, and using the latest technologies that are both widely supported and stable.

At the same time, these articles also show that there is life after jQuery. Back in the days, jQuery was a very useful library, aimed at easing developer experience of developers giving a chance to building something complex with JavaScript. Back in the days, working with JavaScript was not easy. You had to write a lot of code to perform simple operations, such as accessing some DOM elements. Now that the JavaScript standard has evolved, and browser support has also become better, jQuery has become redundant on many levels. Even though I am grateful for the developers of jQuery, life goes on. If you have a good reason to use jQuery, use it. In the absence of a good reason, don't use jQuery just because you formed a habit of using it.

We will also build something useful. There are many courses out there that focus on just teaching things, demonstrating them on a dummy example. Other courses try to build a useful product, yet, they get lost in the details. My goal is to keep things simple, and build a product at the same time.

Thinking ahead of the Churn Rate

It is quite hard to keep up with the latest JavaScript standards. Sometimes it feels like they change every day. As of October 2016, I decided on using

Babel for code transpilation,

Webpack for bundling our packages for distribution and managing dependencies,

ESLint for defining and enforcing our coding standards.

React changed a lot too. This tutorial keeps up with the latest changes. Following the big jump in version numbers of React, the number of breaking changes should decrease too.

What is React?

React is a view library. It helps us build user interfaces for the web.

The reason why React became so popular is that it revolutionalized the outlook on how to build user interfaces for the web. Many developers who have transitioned to React claimed that they had a significantly better developer experience than before, and they became a lot more productive, as the React mindset forced them to think in terms of high maintainability.

The reason behind these claims is that React forces you to create components, and handles DOM updates automatically for you.

As web pages can be split up into self-contained components, React builds on the idea of creating your website using reusable building blocks.

Performance concerns have also been abstracted by React. In fact, React has a reputation of being very efficient, due to putting changes into a virtual DOM first. Synchronizing the virtual DOM and the real DOM is based on minimizing manipulations of the real DOM.

Why should we learn React?

In short, React is very popular, very powerful, and has a great ecosystem. React is fully backed by Facebook, and is used on production.

React comes with rich developer experience. React dev tools fit in the browser, making it easy to monitor the internal state of React components.

React forces you to think in terms of components and reusability.

Developers define a big state machine in MVC frameworks in the M part. In React, there are many little state machines in each React component. Logic is encapsulated in components in such a way that a state change forces the corresponding subtree of the DOM to rerender. The React developer has one less problem to worry about, as React forces you to write consistent code, syncing application state with its DOM representation. It is always easier to develop an application relying on a guaranteed, bug-free behavior.

Developers should not worry much about the performance tax of rerendering a DOM subtree when the state of a component changes. The virtual DOM provides an abstraction that takes care of these problems automatically.

The more abstractions are available for the React developer, the less the developer has to worry about the how question, and can focus more on the what. This means we can solve higher level problems with less effort.

When it comes to performance bottlenecks, don't underestimate the cost of event listeners. When BackboneJs became popular, it combated spaghetti code with structure. When ReactJs emerged, it combated the spaghetti listener structure with an efficient way of encapsulating application state, and updating the DOM.

React or Angular?

When deciding on which framework to specialize in, most frontend developers want to know the answer to the ultimate question: React or AngularJs? Even though I don't encourage comparing apples with pears, I find this question understandable on some level.

The reason why this comparison is not exact is that AngularJs is a full framework, while ReactJs is a library.

React is a small library for building user interfaces. Unlike MVC frameworks, React focuses almost entirely on the view layer. It is possible to use React as a part of an MVC framework, and React applications can also be built on their own.

When talking about AngularJs, I always write about Angular 2. Even though there are still a lot of Angular 1 applications out there, and some of them will never be migrated to Angular 2. New projects should always be started using Angular 2.

AngularJs is more than a library for building user interfaces. It is a JavaScript framework to build Single Page Applications. It has a router and it controls the complete user experience.

ReactJs can be extended to write Single Page Applications using some extra packages. The core React is about building views in the form of components or widgets. You can embed it in any MV* framework, including AngularJs. Even though nesting React in a full framework is an option, it comes at a cost of making a part of the framework obsolete.

The most trending use of React is to connect it with a state management library such as Redux. We will also choose this option. A Single Page Application built on top of React and Redux is stable and scaleable enough to build big applications.

Let's see what the latest trends say about the React vs Angular topic:

Angular seems to be ahead, even though React is on a more rapid growth path. The figures clearly show that both solutions are sane choices.

Personally, I have always favoured solutions that I can customize to my own needs over monolithic frameworks. Furthermore, the use cases of React are wider than that of Angular 2. Beyond Single Page Applications, React can be used for developing web interfaces, content management systems, and it can even be used for developing mobile apps with React Native. This is why I chose specializing in React instead of Angular for now.

Let's start learning React

If you are completely new to React, I suggest reviewing the official tutorial on facebook.github.io. It will not only stay up to date after each version change, but it is also a great tutorial on its own. When using JsFiddle or JsBin, there is no need for setting up a boilerplate repository either. You can learn the basics in a matter of minutes, and you can run your first React application in a matter of five minutes.

As we aim at building a complex web application using React, we will set up a repository, where you can use React right away, together with npm, ES2015, a live reload server, and Webpack.

When it comes to ES2015, I suggest refreshing your knowledge, as we will be writing code according to the latest standards. Review my ES6 articles, and sign up for my new E-mail course on ES6 below!

You can read the other articles belonging to this series in chronological order by clicking here.