A transitional experience from jQuery to Knockout to AngularJS to React to Angular

It has been 12 years since I became a devoted student of JavaScript in the professional arena. Over this period, my learning path kept changing as the philosophy of JavaScript-based web development evolved at a rapid pace. I started my career in jQuery, later I was introduced to KnockoutJS. Then I moved to AngularJS (1.x), followed by React. Now, my upcoming venture expects profound knowledge in Angular(9), which I started learning a couple of months ago. That's why it's essential to keep molding yourself with time to stay relevant. In this article, I'll be trying to articulate my learning experience and to comprehend how the philosophical changes took place in the JavaScript realm.

jQuery Saga

Considering the pre-jQuery era, where the developer had to write a lot of code just to create a DOM node and manipulate the same. jQuery actually brought autumn at that time to those developers. When my career took off, jQuery was shining in the middle of the sky. $(document).ready() was the ultimate bootstrapping function where the modular pattern and factory pattern were the standard way to modularize the code. We had to bind the event(s) for every DOM element with the callback function. We had to make DOM manipulation once we used to get the updated data from the asynchronous Ajax response. Under this circumstance, it was indeed challenging to gain performance unless you started leveraging the JavaScript object orientation to organize your code. It made me keen on this, and eventually enriched my knowledge. I would like to pick three points that actually helped developers at that time to fast-track web development.

1. The DOM node creation, manipulation, and event handling in jQuery.
2. The partial rendition of the page by using Ajax's asynchronous response.
3. Availability of a lot of jQuery plugins that helped to build complex UX.

The primary reason for the jQuery saga was an easy learning curve. When I turned back to that time, it was indeed a cumbersome way (considering the way of writing code in the present era!) to write code but loaded with a lot of fun and curiosity.

Knockout punch

Consider this, you have a dropdown box with multiple options. On clicking a button, you are fetching a new set of options from the rest API so that the list of options in the dropdown box should get changed accordingly. In jQuery, we had to write code (or call the modular function) to update this dropdown DOM to fulfill the requirement. The legend developers became greedy. They started eyeing introducing a templating engine that could use javascript variables to update the DOM in both ways if either of them gets the updated value. That time many such libraries came e.g. Mustache, KnockoutJS, Handlebars, etc. Knockout was a standout performer among others. I was fortunate to get the opportunity to work on the same for a couple of months. According to me, these are the following reasons that allowed KnockoutJS to overpower jQuery.

1. Introducing the template concept to bind the javascript variables into DOM. It was the beginning of two-way binding.
2. MVVM (Model-View-View-Model) pattern to segregate the template rendition from UI logic. It helped to reduce LOC significantly.
3. Extensibility and reusability of the template made sure to get rid of redundant code.

It was the beginning of the end of the jQuery saga. As the templating concept was entirely new to the other developers, the learning curve was a bit steeper than jQuery. To me, it was the drastic change of philosophy to segregate the template from the logic. The DOM manipulation became obsolete. Eventually, the UX started getting more complicated than before as we had to concentrate on writing efficient UI logic only. Indeed, it saved the day of every developer.

Invincible AngularJS

KnockoutJS actually prepared the path for the inevitable arrival of AngularJS. It put the last nail in jQuery's coffin. At that time, getting the opportunity in AngularJS was an awe-struck experience as it was not just a library like others but rather, a full-blown framework with a lot of path-breaking concepts. As I did work in Java, adopting the same framework philosophy in the JavaScript realm, was quite remarkable for me.

My first analytical observation was, AngularJS did force developers to write code abiding by specific patterns. There was limited flexibility to experiment on the implemented design pattern. However, there is a debate on whether such enforcement is good or bad. Anyway, it actually helped developers to write less bootstrapping code and focus more on behavioral UI logic development. However, according to my experience, it earned my respect due to the following reasons.

1. I could divide the monolithic template into many modular, nested directives. The code became reusable and testable as a logical unit.
2. There was clear segregation of the model, view template, and the related behavioral logic. Two-way binding helped to bypass the rewriting code of the rendition logic.
3. I could move the repetitive functions into services. E.g. synthesizing the API response, making API calls, derivating some logic by evaluating some clauses, etc.

Overall the AngularJS was invincible at that time for developing complex SPA.

React'ive Adventure

The two-way binding was the fundamental feature of AngularJS, later the same appeared as a double-edged sword in regards to the application performance. Meanwhile, shadow DOM came into the play to produce a better performance boost. However, it was indeed difficult for AngularJS to fall back to Shadow-DOM as they already accepted Real-DOM as the bone of their rib. So the AngularJS community decided to move on by rewriting the core logic, and they named it Angular. At the same time, another library emerged named React. I was fortunate to get the opportunity to endure a philosophical change again to start thinking in the react-way.

React-way is totally different from AngularJS. It doesn't comprise two-way binding, directive concepts, etc. like AngularJS. As React is a library, it allows experimenting with various patterns like Flux/Redux, adopting the functional programming paradigm, etc. Unlike AngularJS, React encourages the developer to use atomic-level components that could be nested up to N levels. The following are the reasons I enjoyed working in React a lot.

1. Lightweight, fast, simple, flexible, and adaptive. That allowed me to do an experiment with various architectural patterns. You could clearly segregate user actions, logic derivation, synthesizing API responses, utility services, and state management.
2. JSX templating is very simple and I do not need to remember various notations, like other frameworks/libraries, have. Also, there is no need to remember a lot of library functions and architectural concepts.
3. React encourages developers to break down the monolithic component into multiple reusable atomic and high-order components. It improves the modularity, and reusability and also helps in debugging and writing unit test cases.

React is indeed a brilliant library to use if you need to develop something very quickly. For the time being, the long four-plus years of an affair with React is going to an end as my new venture requires Angular to be associated with.

Herculean Angular

This transition was a bit easygoing for me as I worked in AngularJS earlier. The concept and fundamental philosophies are more or less identical. The primary differences are, adopting TypeScript which I already knew, and changing syntactic sugars. As I'm still in the learning phase, I've figured out a few key points that I loved the most so far.

1. Especially strict typing, generics, and annotations in TypeScript have enabled strictness in the automated code review process. Developers are less allowed to introduce anti-patterns unknowingly so the entire application codebase can maintain the same standards.
2. The Tree-shaking mechanism allows for making a slim-trimmed build for production.
3. The optimal utilization of the shadow-DOM and two-way binding made sure robustness and better performance. The initial learning curve is a bit steeper than competitive libraries. Though it ensures maintaining a full-blown architecture of a complex application.

So far, learning is going well. It is indeed a satisfying experience to be part of such rapid transitions in the JavaScript realm. I wish for some more brilliant frameworks/libraries to come in the future to ease the developer's work. Thanks for reading this article, and feel free to share your experiences too. Happy learning!