I Switched to ReactJS from Angular

It’s undoubted that the web application world is moving forward.  For a while, one would interact with a web app by submitting a form to the server for processing and having to wait for new pages to load.  I’m sure many websites still do this.  It works, it’s easy, and there isn’t anything necessarily wrong with it.  However, lots of data meant lots of time to load and there was the superfluous need to reload headers, footers, etc.  One could also run into server issues, such as too many POST variables being used, or the processing exceeding the maximum execution time.

Once Javascript and AJAX (asynchronous json and xml) came along, one could get web applications to work without having to submit an entire page’s worth of data to the server and waiting for the results to spit out.  The web browser could, in real time ask the server to get some information using all the request types available with a page load (GET, POST, etc).  The benefit was clearly less load on the server at one time (upon form submission) and an improvement in user experience.

AJAX, as brilliant as it is, kind of goes against a lot of how people understand programming.  Ever since I started coding as a teenager, I’ve always learned that code gets read from the top to the bottom.  That means if I assign a variable a value in line 10 of the code, I expect it to return that value when I ask for it on line 11.

However, with AJAX that is not the case.  If I ask to assign a variable in line 10 via a function with an AJAX request within, it will not have that value on line 11.  Since it’s asynchronous, it works outside of the normal flow of code.  The AJAX request would not have had time to get the server response and return the correct value before being asked to deliver it on line 11.  The benefit of this is speed (the remaining scripts can load without having to wait for a server request to complete).

As old as it is, I don’t believe AJAX became as popular as it is today until the last decade or so.  I believe this is because it was hard to use and unapproachable for many programmers.  Using vanilla Javascript, making an AJAX request was a huge pain regarding many lines of code.  If you had behavior that required those AJAX responses, it was complicated to simply keep track of what functions were firing and when.  God help you if you had a POST or PUT request and needed to send data along with headers and so forth.

jQuery helped things a bit, as AJAX requests became easier and you could use promise and when statements to make sure code dependent on those AJAX requests runs after the server responds.  However, that was still complicated as it led to many promises, many parameters, and stuff like keeping track of nested functions.  I personally believe that jQuery and Javascript were not ready for the problems that asynchronous requests presented.  Thus, I found their solutions to these problems confusing, as it tried to add the element of time to an architecture that wasn’t designed for it….

I’ll be honest, sometimes I would just use use setTimeout to call functions dependent on AJAX responses with the hope that the AJAX request would have completed by the end of the timeout period.  After looking at other commercially-distributed code made by other professional developers, I know I’m not the only one who did this.  I’d do it rarely if I just couldn’t be bothered with passing a new parameter to a delicate function I didn’t want to mess with.  It’s much faster than working with jQuery promises and worked (most of the time).  However, I did not want to continue doing this, as it was a gamble.

In late 2017, after seeing my projects at work use more and more APIs and tiring of making jQuery work,  I started to hear of front-end frameworks that realized the issues that came out of the woodwork  as the world moved towards using APIs and the increasing need to have a better way to keep track of changing variable values.

These frameworks fascinated me because they used an MVC (model-view-controller) approach.  They would take care of updating my variables when their values changed asynchronously.  I started with AngularJS.  I’m not sure why.  It was developed by Google, so that was a good selling point.  I also really liked how easy it was to attach a method to an event, instead of the old way where we had to find an element in the DOM and attach an event handler.

However, I believe I was expecting too much.  Even if the Angular digest system updated your variable, it doesn’t mean that calculations using that variable got updated.  You would have to call a digest method explicitly to re-do calculations.  In all honesty, I don’t understand how digest worked, but I know that it was slow if called too often.

I also knew that there was a lot more to AngularJS and that the way I was using it was probably wrong.  I believe AngularJS pressured you to use its ecosystem and the learning curve was too much for me.  I hated having to do my own routing.  Perhaps I was spoiled by how easy routing is in WordPress and Laravel.  So, I don’t blame AngularJS for me abandoning it – I simply found it too intimidating.

In the beginning of 2019, I decided to switch to ReactJS.  I simply found their language more approachable for my apparently primitive brain.  For instance, the fact that ReactJS calls their components components is something I find refreshing.  Angular calls their components directives, which is annoying.  Angular also had weird rules regarding naming (something about hyphenated html attributes having to be converted to lower camel case), sending parameters separated by pipes, and other general weirdness.

ReactJS seems to give more control back to the developer, is more intuitive, and seems to want developers to keep going with it.  For instance, ReactJS error messages are extremely helpful, with helpful tips to do things the correct way.  I get to explicitly update variable values using their state properties instead of crossing my fingers with Angular’s system.  I also find that it integrates easier with other back-end frameworks, such as Laravel.  I find its system of handling API requests much more intuitive.  Finally, it works great with NodeJS.  One never realizes how annoying reloading a page is until you don’t have to do it anymore.

So, working in a ReactJS environment is extremely smooth and something I’m looking forward to learning for years to come.  I eventually want to learn React Native to easily convert web apps into mobile ones.  The biggest selling point I think is that Facebook actually uses ReactJS prominently, whereas Google does not use Angular in any significant public-facing way.  That in itself says a lot.  I think the future looks promising for ReactJS and am eager to adopt it as it makes me feel I’m part of a pioneering front of web development.