The BIG problem with Angular, React, and Vue....

Issues with Single Page Applications

Angular/React/Vue, these are the 3 frameworks that we hear everywhere! Why so?

Because all everyone talks about is the advantages of these Single-Page Applications. However, in this article, I will shed light on the other side of the coin that no one ever tells you about.

Single-page applications have revolutionized the web industry. Now, considering the popularity of Single-Page applications, you’d not be unreasonable to think that I’m out of my mind to second guess the whole industry, including all the web developers who are constantly learning, Angular/React/Vue and pushing out websites each day by the hour. However, I’ve got my reasons!

Disadvantages

#1 Bundle Splitting

You might already know that there exists a strategy called Lazy Loading or Modularization (Check out this article, if you want to know more about it) which helps to optimize the user interaction/response time/loading time of your website. However, there's still one big problem that many developers usually overlook, that is, even if your application is fully lazy-loaded/modularized, you still have to download the index.html or what some frameworks refer to as the main.js file, which is often the heaviest file or the heaviest module in your entire application. Therefore, even if the user just wants to access the About Us page, lazy loading/modularization might not be the most efficient strategy in the world as you are now anyways loading a whole lot of other not-so-required information as well.

#2 Cons of Implementing Lazy Loading in the Background

This disadvantage is somewhat related to the last one, but it has a whole different set of problems. Let's consider that your website is not data-centric or perhaps authentication is not as essential, so, you have a user session open for at least a week or two. Now, because you lazy-loaded the different pages of your website in the background(when the user was not active anymore), the user sees all the pages(the dashboard, homepage, etc.) available immediately when they return after a week or two. Well, the truth is that the user now sees your old code. As it is quite possible that your website was updated since the user last used it. Although the user returned to the website two weeks later, they’re now seeing seven days(or perhaps more) old UI(code).

Moreover, the problem doesn't end there. This problem becomes even more serious often when a breaking change has been made in the backend, for instance, a route/API call has been changed. Now, this can make it really frustrating for the user in certain scenarios, let’s say they’re filling out a form, but now when they hit enter the site crashes as your code is now trying to access a route that no longer exists. Now, had we not used a Single-Page Framework here the user would never see stale content.

Well, I know there exists a workaround for this problem. So, I tackle this problem by checking the version of my app every 15 minutes to see if the version I have downloaded in the browser has been updated. Speaking from personal experience, I still have to face some downside of this approach. Whenever the version of our website changes, I have to inform the user that the website will be updated in 30 seconds and have to ask them to save whatever they’re doing or retry again after 30 seconds. Well, a few user complaints have made me realize that this is not really the best user experience. It’s hard to explain to the users why all their changes made in the past 5 minutes while filling out a form will be lost in the next 30 seconds and their efforts will go in vain. On the contrary, if you don’t warn the user about the update and just refresh the website anyways, well, what can I say, that’s even worse!

#3 Server-Side Rendering

Now, if you’re familiar with the concept of server-side rendering, you might be thinking that all the above-mentioned problems are worthless. We can use server-side rendering and upload the first page from the server which improves the search engine optimization as well as the load time. Everything’s perfect, right?

Now, first of all, I should highlight the fact that according to a report published in March 2020, more than 50% of single-page web applications don't take advantage of server-side rendering. Secondly, even the ones that do use server-side rendering are not free of problems.

The first page that you have initially rendered from your server is actually dead for a long time, and this is where the concept of the Time-to-Interactive(TTI) Metric comes into effect. In simple words, even though your home page is loaded with the signup button as now everything worked super fast because of server-side rendering. However, now, if the user clicks on the signup button, nothing will happen, if your Angular/React/Vue framework has not still finished downloading in the browser. Well, now you can hope that your SPA framework will download the initial bundle before the user clicks on that signup button, but being a developer in 2021, you don't really want to be dependent on luck, especially if there’s a problem with your code.

Conclusion

Now, you mustn't view this article as an Anti-React/Anti-Angular diatribe. I have nothing against them rather I really think that these frameworks have a place for themselves. In fact, I think these frameworks are great, my job, my earnings, and in a sense, my life depends on these frameworks. What I am trying to impress upon you is that we should not just blindly follow whatever’s trending. It is important that we understand the pros and cons of each framework and carefully decide which framework would better suit our needs.

There are various other libraries such as Alpine JS, JQuery, WordPress, or languages such as PHP, Perl which could be a great starting point if your website is just a blog or just an informative website.

If your user is going to visit only one/two pages of your blog, it would be overkill to use a cool SPA framework in that case.

Look at Wikipedia as an example, it is made with PHP. I'm sure you don't think Wikipedia is slow.

Craigslist is made with Perl. Do you find something wrong with it?

You might want to ask yourselves some of these questions before deciding what kind of framework would work best for you, 1) What is your use case? 2) What features do you need on your website? 3) Are you expecting a lot of events to be triggered on your website? 4) Do you have to fetch a lot of data from the backend to display on the User Interface?

I understand that it might be very difficult to go against this norm of using single-page applications, perhaps you just feel this pressure on yourself to learn these frameworks. When I look around, I see 99% of the Front-End Jobs or even Full Stack Jobs require you to know at least one of the most popular SPA frameworks. Furthermore, it’s getting very difficult for some companies to find quality PHP/Ruby developers.

Now, you gotta do what you gotta do, but all I am saying is, when creating a website, choose wisely because these cool frameworks can become a nightmare really quickly if not used properly.

Btw, do you think if Wikipedia was made in 2021, it would be a SPA? That’s a wrap. Thanks a lot for your time. See you next time, until then, keep learning!