Gackenheimer - Introduction to React

IN, US

It gives me great pleasure indeed to see the stubbornness of an incorrigible nonconformist warmly acclaimed.

Albert Einstein

React is a JavaScript framework. React was originally created by engineers at Facebook to solve the challenges involved when developing complex user interfaces with datasets that change over time. This is not a trivial undertaking and must not only be maintainable, but also scalable to work at the scale of Facebook. React was actually born in Facebooks ads organization, where they had been utilizing a traditional client-side Model-View-Controller approach. Applications such as these normally consist of two-way data binding along with rendering template. React changed the way that these applications were created by making some daring advances in web development. When React was released in 2013, the web development community was both interested and seemingly disgusted by what React was doing.

As you will discover throughout this book, React challenges conventions that have become the de-facto standards for JavaScript framework best practices. React does this by introducing many new paradigms and shifting the status quo of what it takes to create scalable and maintainable JavaScript applications and user interfaces. Along with the shift in front-end development mentality, React comes with a rich set of features that make composing a single-page application or user interface approachable for developers of many skill levelsfrom those who have just been introduced to JavaScript, to seasoned veterans of the web. You will see these featuressuch as the virtual DOM, JSX, and Flux conceptsas you read this book and discover how they can be used to create complex user interfaces.

You will also see, in brief, how Facebook is continually challenging the development world with React Native. React Native is a new open source library for creating native user interfaces utilizing the same principles as Reacts JavaScript library. By creating a Native UI library, React has pushed its value proposition of learn once, write anywhere. This paradigm shift applies to being able to utilize the core concepts of React in order to make maintainable interfaces. By now it is possible you are thinking that there is nothing React cant do when it comes to development. This is not the case, and in order to further understand what React is, you need an understanding of what React is not , which you learn later in this chapter. First, you will understand the underlying problems that caused React to be created and how React solves those problems.

As already noted, React is a different concept when it comes to web development in general. It is a shift from generally accepted workflows and best practices. Why is it that Facebook shirked these trends in favor of creating an entirely new vision of the web development process? Was it just extremely cavalier to challenge accepted best practices, or was there a generalized business case for creating React?

If you look at the reasoning behind React, youll see that it was a created to fill a specific need for a specific set of technological challenges faced by Facebook. These challenges were and are not unique to Facebook, but what Facebook did was tackle the challenges directly with an approach to solve the problem by itself. You could think of this as an analogue of the Unix philosophy summarized by Eric Raymond in his book, The Art of Unix Programming . In the book, Raymond writes about the Rule of Modularity, which reads,

This is precisely the approach that React takes in solving the troubles of complex user interfaces. Facebook, when developing React, did not create a full Model-View-Controller architecture to supplant existing frameworks. There was not a need to reinvent that particular wheel and add complexity to the problem of creating large-scale user interfaces. React was created to solve a singular problem.

React was built to deal with displaying data in a user interface. You might think that displaying data in a user interface is a problem thats already been solved, and you would be correct in thinking that way. The difference is that React was created to serve large-scale user interfacesFacebook and Instagram scale interfaceswith data that changes over time. This sort of interface can be created and solved with tools that exist outside of React. In fact, Facebook must have solved these issues before it created React. But Facebook did create React because it had valid reasoning and found that React can be used to solve specific problems encountered when building complex user interfaces.

React does not set out to solve every problem that you will encounter in user interface design and front-end development. React solves a specific set of problems, and in general, a single problem. As stated by Facebook and Instagram, React builds large-scale user interfaces with data that changes over time.

Large-scale user interfaces with data that changes over time could probably be something that many web developers can relate to in their own work or hobby coding experiences. In the modern web development world, you often offload much of the responsibility of the user interface to the browser and HTML, CSS, and JavaScript. These types of applications are commonly referred to as single page applications, where the common request/response to the server is limited to showcase the power of the browser. This is natural; why would you not do this, since most browsers are capable of doing complex layout and interaction?

The problem arises when your weekend project code is no longer maintainable. You have to bolt on extra pieces of code to get the data to bind properly. Sometimes you have to restructure an application because a secondary business requirement has inadvertently broken the way the interface renders a few interactions after the user starts a task. All of this leads to user interfaces that are fragile, highly interconnected, and not easily maintainable. These are all problems that React attempts to solve.

Take for example the client-side Model-View-Controller architecture with two-way data binding in templates you saw mentioned earlier. This application must contain views that listen to models, and then the views independently update their presentation based on either user interaction or the model changing. In a basic application this is not a noticeable bottleneck for performance, or more importantly, for developer productivity. The scale of this application will inevitably grow as new models and views are added to the application. These are all connected through a delicate and intricate mess of code that can direct the relations of each of the views and their models. This quickly becomes more and more complicated. Items that live deep in the rendering chain or in a far away model are now affecting the output of other items. In many cases an update that happens may not even be fully knowable by the developer because maintaining a tracking mechanism becomes increasingly difficult. This makes developing and testing your code harder, which means that it becomes harder to develop a method or new feature and release it. The code is now less predictable and development time has skyrocketed. This is exactly the problem that React sets out to solve.