Here is a great quote by Charles F. Kettering:

This brilliant inventor has left software engineers with the single most important piece of advice way before we even started thinking how to write software. Yet, half a century later, we're still figuring out why we end up with spaghetti code or the "spaghetti mental model".

Have you ever been in a situation where you inherit code from a previous developer and spend weeks trying to understand how everything works because no blueprints were made available, and the pseudo-self-explanatory-code became too hard to debug? Better yet, the project keeps growing and so does its complexity. Making breaking changes is dangerous and no one wants to touch that "ugly" legacy code. Rewriting the whole codebase is way too expensive, so the current one is supported by introducing new bug fixes and patches every day. It is a well-known fact that the cost of maintaining software is way higher than the original cost of developing it.

What does it mean to write software for the future, today? I think it boils down to creating a simple mental model that doesn't change, no matter how big your project becomes over time. When the size of your project grows, the complexity always stays the same. This mental model is your blueprint, and once you understand it you will understand how your whole piece of software works.

If you take a look at modern web development, and in particular, the frontend development, you'll notice that we live in exciting times. Internet companies and individual developers are tackling problems of speed and cost of development versus code and user experience quality.

In 2013, Facebook released React—an open source JavaScript library for building user interfaces. You can read more about it at http://facebook.github.io/react/. In early 2015, Tom Occhino from Facebook summarized what makes React so powerful:

Most of you know that a declarative style of programming results in less code. It tells a computer what to do without specifying how, while an imperative style of programming describes how to do it. JavaScript's call to the DOM API is an example of imperative programming. jQuery is another such example.

Facebook used React in production for years, along with Instagram and other companies. It works for small projects too; here is an example of a shopping list built with React: http://fedosejev.github.io/shopping-list-react. I think React is one of the best JavaScript libraries used for building user interfaces that is available for developers today.

My goal is for you to understand the fundamental principles of React. To achieve this, I will introduce you to one React concept at a time, explain it, and show how you can apply it. Step by step we'll build a real-time web application, raise important questions along the way, and discuss solutions that React provides us with.

We will learn about Flux, which implements a unidirectional flow of data. Together with Flux and React, we'll create a predictable and manageable code base that you will be able to expand by adding new features, without scaling its complexity. The mental model of how your web application works will stay the same no matter how many new features you add later on.

As with any new technology, there are things that work very differently from the way that you're used to. React is not an exception. In fact, some of the core concepts of React might look counter-intuitive, thought provoking, or even a step backward. Don't rush to any conclusions. As you would expect, there are very good reasons behind how React works, and these reasons come from experienced Facebook engineers who build and use React in production in business-critical applications. My advice to you is to keep your mind open while learning React, and I believe that, at the end of this book, these new concepts will settle in and make great sense to you.

Please join me in this journey of learning React and following Charles F. Kettering's advice. Let's take care of our future!