Why React – techboi – Medium

Further UI state transitions must be accomplished with references to UI elements and piece-wise mutations.

Instead of trying to patch over the problems of UI state transitions, React describes the UI at any given point in time .

There is little ceremony involved in creating a component, and it is easy to compose components and to create higher-order ones.

Put differently, you do not have to manually take care of UI state transitions anymore which considerably reduces error-proneness.

There is no separate templating language to describe the UI and its view tree.

React is a popular library for creating user interfaces (UIs). Since its public release in mid 2013 it continues to gain traction and… @techboi_: Here’s why we use React for building UIs. #techboi #blog #reactjs #frontend #development

Why React

React is a popular library for creating user interfaces (UIs). Since its public release in mid 2013 it continues to gain traction and foster innovation without any sign of slowing down yet. React’s uptake in the mobile sphere via React Native is but one example. In this article, we explore React’s unique suitability for creating UIs by providing a list of specific reasons.

The UI is described at any given point in time

Traditional approaches to writing UI code allow the describing of the initial state of the UI. Further UI state transitions, however, must be accomplished with references to UI elements and piece-wise mutations. This is very error-prone as edge cases are easily missed, thereby introducing inconsistency and bugs. The following screenshot is an example from Medium:

Understanding this error potential, many frameworks employ (two-way) data-binding to solve inconsistency problems and to increase convenience. From personal experience, traditional data-binding becomes unwieldy for more complicated cases and does not help if parts of the UI tree need to be replaced (in a dynamic manner).

Instead of trying to patch over the problems of UI state transitions, React describes the UI at any given point in time. You, as a programmer, describe the state of the UI as the single source of truth and the UI itself is derived from that. Put differently, you do not have to manually take care of UI state transitions anymore which considerably reduces error-proneness. The UI code becomes declarative and there is no—or at least much less—chance of local state and variables becoming out of sync with the UI. Using references to UI elements is an extremely special case and not the norm. See the following links that make a similar point:

Many modern frameworks have adopted this approach due to its superiority for the majority of use cases. In order to benefit from this even more, the framework must provide a usable way of accomplishing (inter-component) change propagation. This is a topic for another article.

There is no separate templating language to describe the UI and its view tree. React rather uses a domain specific API with some syntax sugar on top (JSX). The point here is that React reuses JavaScript for the UI description and therefore gets all its powerful programming language features and abstractions for free. Reusing the host programming language for view notation leads to less workarounds, less duplication, more reuse, and less context switches between different technologies. See the following for more examples:

This point is very much related to React’s host language reuse. In other frameworks, a component’s view tree description resides in its own file, separate from the rest of the component. This is separation for the sake of separation, motivated by dubious concerns. React counters this by embracing cohesion inside components. The advantages include less cognitive overhead, less context switches, and easier navigation.

There is little ceremony involved in creating a component, and it is easy to compose components and to create higher-order ones. You are more likely to create reusable (higher-order) components than feeling the need to copy and paste code. It is my claim that this leads to better and more plentiful third-party libraries as well.

React is not a comprehensive framework. Instead, React describes itself as a View library and does not really concern itself with how the rest of the application is structured. React is conceptually simple. This leads to a shallower learning curve and more flexibility when it comes to the application structure. On the other hand, the resulting agony of choice can also be seen as a disadvantage.

The backing of a project by a large organization is not a guarantee for widespread success—there are many counter examples that illustrate this point. Famous ones include Google’s Wave, Buzz or GWT. However, React is used heavily inside Facebook and it seems that a fair amount of resources are invested into React by Facebook. Not only that, but the arguably huge community and tooling around React makes a healthy impression. This leads to trust in the future of React.

React is based on valuable principles which makes it more than a fashionable trend. It is not so much any single feature anymore that sets React apart—it is the overall philosophy and the resulting mindset, community, and ecosystem.

I’m co-founder & CTO of techboi . We are a software company based in Berlin, Germany. We value efficiency, technology, design and blog about it. You can follow us on Medium , Twitter , Facebook , Instagram , Snapchat and Github .