Why do we react?

Functional programming and reactive programming have been more of theoretical concepts for frontend developers in the past because they seemed like overkill tools especially for something as simple as web-pages in the era when the frontend was a dumb static representation of the server state.

But now things have changed. Redux creator Dan Abramov rightly compares asynchronicity and mutation with coke and mentos. While being very common names in our day to day lives, if these come together, the mixture can become explosive enough to get out of control very soon.

Today we create multi-platform, high-performance, rapidly evolving interfaces to cater fairly complex applications.

User Interfaces being event-driven in nature have had a problem of not scaling well. Changes/events in one part of a page can have an effect on some other page or part of page. It feels like a fire under control to start with, but when these effects become causes for some other changes in the application, the end of these cascading CAUSE and EFFECT cycles quickly becomes unpredictable. Also, when architected with little decoupling and abstraction between different layers of responsibility, sophisticated design pattern can not make space in building frontend applications. Reasons like these combined quickly give rise to `edge cases` and then `dirty-hacks` on code that cannot be accompanied with automated tests.

ReactJS(and the eco-system around it) is built on the principles of functional reactive programming where the application is always in a predictable state and the entire view is a consistent mapping of that state object. That allows us to make controlled changes to the data to cause a visual change in the application, rather than changing the actual visible page itself (which gets efficiently re-rendered to reflect the state data change). Its not just easy, but also intuitive to add automated tests for these applications, without which a lot of programmers today would call even fresh code legacy. Emerging design patterns like flux (put together by Facebook) make it possible to control the data flow and the side-effects because of its change.

That said, ReactJS in neither a complete frontend solution, nor the only one available today. It fits together as the View (V) with flux and MV* (popular in the near past) paradigms. Its popularity and success have opened doors to its emerging alternates which can even be more performant under certain circumstances (eg: inferno). While react and react-like libraries make the most preferred fits for the V (view) part of modern frontend applications, rest of the pieces like M (model), C (controller), presenter, pipeline, state store, etc are carefully chosen depending upon the requirement of the project.

With the kind of decoupling built into ReactJS, it can be used not only in web applications, but also in mobile/ desktop applications with performance as good as native alternates if not better. This brings a great advantage of being able to efficiently code views for all devices and platforms in a common language(JavaScript) by the same engineers. Facebook and Netflix are good examples of apps that run on Reacts across all platforms of consumption.

reactJS: https://facebook.github.io/react/
reduxJS: http://redux.js.org/
infernoJS: https://infernojs.org/
flux: https://facebook.github.io/flux/

Leave a Reply

Your email address will not be published. Required fields are marked *