Modern Web App Development

Why React?

Good question!!! Well, the best answer is, why not? As for anything, there are pros and cons and the straight forward answer is not obvious. As some say, coding is poetry and, in programming more than in any other domain, there is no unique way to do the same thing. Although the "single-source-of-truth" is something that software architects and programmers are always searching for, the way of achieving it depends only on imagination and creativity. However, it is always good to rely on a solid base, in this case (web dev) it is about our old friend, Javascript (with all good and bad) and the frameworks that makes (or not) your life easier.

I do not intend to compare the most popular frameworks, there are tons of articles written by brilliant programmers, much more experienced than I am, that deals with this comparison. I only want to briefly summarise what led me to React.js (you can also read React Native, is pretty much the same). Having a previous (I would say also good) experience with Javascript, I was facing (as many of my kind) the dilemma (better to say "trilemma"): Vue, React, Angular (all of them .js). In short: Vue - much too reactive for my taste; React - kind of the middle way; Angular - a bit too much template based (kind of rigid stuff). So, my choice was React and let's jump to it!

React.js vs. old-school

First, this is about what I don't like the most at React, the mix of UI and business logic. At least this is what I thought ... and this is what I saw that others do. But then I figured out that this a false problem, people do so because is the easiest way and not because is the only way. I am old-school, for me the UI is only a semi-dumb layer that shall deal with styles, layouts, graphical templates and so on and on which the meaningful content is hooked. The only "intelligence" of this layer shall be how to arrange the elements on the screen, how to be as responsive as possible and, in general, how to offer a great look to your app, thus contributing to increased UX. The whole processing of the content is the job for another independent layer, of course the key being to keep the reactiveness of React and this is only depending on your software architecture skills and imagination, React does not forbid it (true! does not encourage it also).

Second, it was about functional components vs. class components ... again, I am old-school and, for me, OOP rules. I did not understand why the React team promotes so high the functional components (of course, with strong support of React hooks), for me, the most logical and natural approach in creating complex apps (web, mobile, doesn't matter) is the OOP approach. Then I figured out that this is also a matter of taste, so I remained faithful to the class components regardless of the fact that, somehow, I do not follow some trends.

Third, it was about the famous "single-source-of-truth". Passing props from top to bottom level components or lifting the state is great in React but can become a nightmare when the app complexity grows, the "single-source-of-truth" can easily become the "single-source-of-bugs" (still ok since, at least, you know where to look for mistakes!). Not to mention the cases when you need to pass props between components from the same level but being placed in different contexts of the app (horizontal). Is frustrating, you see them "shoulder-by-shoulder" but not being able to pass data between them and the only way to do it is trough lifting the state up the first common ancestor and then passing props top-down. React REDUX gave me the solution and I am using it now, considering that the functional nature of it and the amount of boilerplate code is a reasonable compromise. Of course, REDUX is functional (not OOP) and comes with some boilerplate code ... but it is also up to you to reduce the boilerplate as much as possible and to integrate the code as much as possible in the OOP approach. Or to leave it as is, no problem!!! Nobody says that a combination between functional and OOP approaches is wrong ... after all, using high order components in React is mostly functional programming and HOCs are really powerful.

Last but not least it was about the nature of Javascript. You know!!! ... not multi-threading but async :)). Yeah, this is the modern Javascript and, to make things even more interesting, the life-cycle of React components makes it even more interesting. When combining with Redux, you can encounter weird situations. So is good to understand this nature and use at the most its benefits (which are much more important than the problems that it generates). And to use some persistent storage (local or session) that will allow you to avoid entering into problems. Sure, you may say that this is a kind of security issue and a lot of browsers does not allow by default the usage of local storage. You may be right ... however, this is another compromise, everything comes with a price and complex apps may need anyway to use such persistent local/session storage. Moreover, if you think on PWA then the discussion on using local storage is kind of useless.

Once I figured out that each of my "philosophical" problems has a satisfactory solution, React.js became much more friendly (not in terms of writing the code because this was obvious from the start). Now I have a multi-layer app architecture that made peace between the power of React, the nature of modern Javascript and my old-school principles. However, this is only a matter of imagination and (maybe) bit of experience.