Why ReactJs
Fore-warning: This article reflects my personal, subjective opinions
I do not like react.. yeah I saids it. Not hate, dislike. While I cannot ignore that I love the concepts which react is built upon, I dislike react itself as a complete product from these concepts.
Let me quickly summarise why I dislike react, incase tl;dr:
- Mixing of concerns
- Low level
- Complicated, especially after adding redux
- It’s not like Angular 1.x or Aurelia or Svelte :’(
So let’s go
- Mixing of concerns
This is what bombed PHP’s reputation initially. Anyone could learn PHP in a day, which was not a bad thing, and then mix this PHP code directly with html- Egads!. Ease of learning was not the issue here. The issue cropped up when a noob would quickly hack something, making an unholy, hellish, procedural code soup… The horror! Debugging, impossible. Code organization was a fabled dream of the sages — The apps produced were totally un-maintenable, and only the original developer could comprehend what is happening where.
The architectural design of JSX sounds similar to the PHP example given above. Again, love the concept of JSX (extending javascript to html), but it’s implementation feels archaic. Imagine if an inexperienced developer, one who has not touched enough frameworks and software engineering concepts writes React-JSX-Redux mashup code.
2. Low level
One-way data binding and immutability as a concept, yes! But as is with everything, these concepts don’t come without a heavy price to pay
Yes, the cost of safe code can be heavy. The cost of these functional concepts is normally complexity, and react’s code-base can grow in complexity, this is because react is low-level coding, maybe too low level.
And the more lower-level the code is, the more complex the code becomes.
\(O_O)/
3. Complicated, especially after adding state management
As noted earlier, the closer the code is to the metal, the more complicated it becomes. And then add Redux (or any other tool) to the mix for state management. Learning Redux should not be confused with learning react. This is a totally different beast with it’s own concepts that are a challenge to grok.
The code becomes complex even after getting the concepts. Yes thunk am pointing at you! No thunk you!
4. It’s not built like Angular 1.x or Aurelia or Svelte :’(
These are frameworks I fell in love with. Hook line and sinker. It was love at first site, I was swept off my feet. I was in the clouds ⛅️ .
Angular 1.x — Adding semantic javascript code to html, extending html functionality. Futuristic concepts, easy to pick up, easier to implement, and beautiful javascript if properly written (and more organized than similar sized Jquery projects), super light-weight and could inject angular code anywhere in your app; no full code re-writes needed. How cool was that! No other framework came close. But 2-way binding could bind you in debugging Purgatory. Oh well..
Angular 2+ is well… it’s complicated
Aurelia — What I considered the future of frameworks, until very recently. It keeps standards with the code is beautiful to write and behold. And it uses straight javascript and javascript standards compliance, no clout. But since the development path they are taking is to implement Typescript, I dunno. If the angular 2+ team had continued with Rob Eisenberg’s (Creator of aurelia js, Durandal, former contributor in the Angular 2+ project) and maybe listened and adopted some of his ideas, I believe they would have made something simpler.
Svelte — Whilst I’m not one to follow fads, this new kid on the block has me hooked. Svelte (an actual English word which means slender and elegant) has come out guns blazing. It’s a fresh take on frameworks and questions the how and why modern frameworks are designed the way they are. Rich Harris, it’s creator, takes friendly jabs at react’s architecture (why you don’t need the virtual DOM for example) and goes a step further to establish a solution to the issue. I’ll keep watching carefully from the sidelines as this framework matures, for maybe a year or so.
Ideally a framework should help the developer do his work. It should be simple to learn and adopt, with clearly documented and straightforward APIs which assist a developer do his work; which is to write business logic code, not become a Framework Research Specialist.
React’s concepts which lean towards Functional Programming have started us in the right direction, but it’s architecture has taken us backwards with scope mixing and single large monolithic files structure (if poorly written).
I chose to do a major project in React because of metrics.
You cannot fight numbers; both the community and number of widgets implemented are huge. Also having a backing from a big organisation helps with assuring it’s continuity. And finally React Native, affectionately acronymed RN in the community, brings mobile-native development for React practitioners — I code android, now I have the power to code everything!
