SPA (Angular, React...) [still] not a solution to all problems

3 years ago I warned about blindly adopting the Single-Page-Application as default model for web applications. I was expecting my recommendation to expire soon, however, 3 years later, I must reiterate my recommendation. More and more organizations are adopting SPA as the default web technology and while there are very good reasons to choose such an approach, there are also good reason for choosing a simpler solution. ROI analysis, which is often lacking, must be carefully done as writing SPA (React, Angular etc) applications is significantly more expensive. I've lead a team that pioneered SPA development back in 2012, well before AngularJS was born, and have been working with these technologies ever since. While things have improved greatly, I am afraid the cost is still significantly higher for SPA solutions - it is more difficult to write, more time consuming to write, more error prone, there are fewer good developers, many competing frameworks with too many fundamental changes, and for other reasons I've written about last time. The development cost is dwarfed by the cost of maintenance of such applications, which often results in a rewrite, as I have predicted in 2018:

Consultants will be more than happy to write all the JavaScript code you can handle, especially knowing that they will be back in 3-5 years to do it all over again.

Why is SPA more expensive?

Engineers, often do not make great managers. So often great managers are not technical. As a non-technical manager, it is critical, and perfectly feasible for you to understand this problem from high level. Let me break down the "web application" down to the basics, to illustrate the problem we are dealing with.

Web applications, a brief history.

At it's core, a Web Application is an application that is accessed over internet(1) via a "browser" (Chrome, Internet Explorer etc). The application is written in HTML, CSS and JavaScript, which is what the browser understands and displays. Browser accesses the application, which resides on some server owned by the company which owns the application, via some URL like www.myApp.com. The browser's main purpose is to display the User Interface (UI) of the application, allowing you to, for example, fill out payment information form on Amazon.com. The browser then sends the payment information back to the Amazon server, the server charges your credit card, and returns new UI to the browser informing you of the result of your transaction.

::The "Submit" button era

Browsers started out as dumb terminals - displaying a UI and sending data back and forth from the server. The back-end server did 99% of the work. The reason why old websites had a "Submit" button at the end of a form you filled out, was because this is actually what was happening - your browser "submitted" (or sent) the data to the back-end server. That is all it did.

Internet became immensely more user friendly when someone finally decided to rename "Submit" button to "Pay". Very innovative.

Of course, this "dumb terminal" mentality, meant that using a browser lead to poor user experience. For example, in the old days, if you clicked the "PAY" button multiple times on Amazon, you'd end up with many orders of the same item. Messages like "Please click the button only once" helped to minimize this occurrence but would hardly be considered good user experience.

::The automation era

JavaScript changed all this. Introduced by Netscape, written in 10 days, it was a programming language that ran directly in the browser, and allowed you to do something wild as disabling the "PAY" button once it was clicked the first time. Finally, people were able to order just one book! Amazon was pissed. JavaScript was a revolution, which eventually made Angular and React possible, eventually.

::The war years

JavaScript was an instant revolution that led the revolt of the proletariat against the tyranny of Microsoft! Microsoft held a strangle hold on your computer, by the virtual of owning the Windows operating system, on which you relied. The revolutionaries claimed that a browser, powered by mighty JavaScript can replace Windows on your computer. Microsoft went to war against Netscape. By producing the best browser at the time - Internet Explorer 3 - Microsoft killed Netscape and won the war. Like Isildur, Microsoft could have destroyed the browser when they had a chance but didn't. Worse, they made it even more powerful. They did not appreciate the innovations they have introduced!

::Lying in wait

The browser, with its Microsoft's innovations like asynchronous calls to the server, waited until it was picked up by a upcoming search engine Google which decided to build an email client that did not suck. The innovations that Microsoft abandoned, allowed them to launch gMail, an email system that seemed to load new email by it self - without having to click the refresh or submit buttons! It was amazing. With this, a "single page application architecture" was born!

::Web 2.0 era

The popularization of this technique, and the dawn of Chrome - the first browser that ran JavaScript efficiently - lead to a revolution often labeled "Web 2.0". Websites became more dynamic and interactive. Support chat systems became possible, neat UI that changes based on your input and behind-the-scenes calls to the sever became the norm. Autofill of text boxes was a hit.

::HTML5 era

HTML 5 was the buzz word that promised a wonderful web application experience, and a death to desktop (or even mobile) application. Everything would be accessed through the browser. This had credible potential benefits to organizations and they knew it. You could not find an "HTML5 developer" anywhere on the globe. I explain some of those benefits here. It was a gold rush. Angular, React did not exist, and everyone scrambled to create their own Angular-like frameworks. I did as well, and was invited to speak about it at conferences such as the GDC in 2014.

::AngularJs era

Soon, frameworks like Google's AngularJS, or Facebook's ReactJS sprang up to fill the need. I was there watching it all happened. "I was there Gandalf, 11 years ago, watching it all unfold". We tried to rewrite our application in AngularJS but it just did not perform well enough. I understand these technologies intimately which is what lead me to offer my word of caution back in 2018, something I want to reiterate today.

Besides the fact that all the SPA frameworks, run on a "browser" which not long ago was nothing but a dumb terminal, besides the fact that all these apps are written in language created in incredible haste, SPA systems are simply more complicated due to their architecture.

In a conventional web application, all of the source code, all of the processing occurs on the Server, which is secured and easier to write. In a SPA, not only is there code on the server, there is also code running in the browser, which is not secure. Just look at the building blocks in the image below, to see the difference in the two approaches.

Because the code on browser is not trusted, can be easily stolen and tempered with, all business rules you include there, must be replicated on the server. This problem alone lead to crazy tech like Blazor which promises one code back for both back and end front end. SPA requires a set of efficient APIs which are not easy to get right and are often over or under architected. Debugging the front end code - which suddenly runs on a thousand different devices - is not easy. While in the traditional architecture, all code is secured on the back and thus never visible to outside of the organization, front end code is available to all - you need to ensure you only reveal code you do not mind being public knowledge. Client side state, something much improved over the years, is still not in your control (user can delete or change it all) which results in more scenarios you need to handle. Client side code or HTML leaks, prevalent in AngularJS applications have to be carefully watched. Power of the browser (especially on mobile devices) has to be taken into consideration - a browser can display HTLM efficiently, but running complicated JavaScript and dynamically changing HTML is not always a good experience.

Single Page Application Architecture is significantly more complicated, and very few people know how to implement it correctly.

Reasons to build SPA apps

There is only one good reasons to build a SPA - the need to create the best possible user experience.

Best possible User Interface / User Experience

There is no doubt that the stateful experience of SPA has the protentional to create the best User Experience. If that is really critical for you, if that is your competitive edge (as it often is in the entertainment industry, which I was part of for a decade) then SPA is a good choice. However, for many of my corporate clients, that is often not the case. You can often get close to the same experience with old-school stateless experience for a fraction of cost.

Mobile app?

Often the need to deliver a mobile front end is consider a good reason for SPA. Since it is believed that API layer is needed for a mobile application, it makes sense to build the web application on the same API. This hold true IF you need a "native mobile app". You only need a "native mobile app" when "best possible user experience" is your goal. Only a native app can give you a perfect apple phone UI feel, for example. However, if this is not the case, then creating a hybrid mobile app (a native app that acts as a browser and displays HTML) is a very good option. If I managed to pull it off in 2012, you can pull it off today!

More efficient network use?

SPA has the potential to optimize network communication as calls to the back-end server are now only for data, not for entire user interface (HTML+CSS+Javascript) on every single page refresh. This is true but rarely results in any change. With gzip of HTTP payload and network (even mobile network) improvements no noticeable difference will be achieved.

Keep developers happy?

OK, fine, there is one more possible reason to do SPA - if developers just do not want to do the old and boring and will leave if you do. Will leave it at that.

Reasons not to build SPA apps

Pretty much everything else...

For pretty much any internal application ( accessible only internally by your employees ), SPA is likely not the right option.

When speed and cost is paramount, implement a traditional web architecture.

If you are still unconvinced, fearing the a traditional architecture will yield bad preformance, check out stackoverflow.com. It is not based SPA architecture(2)

Most important recommendation - do an ROI analysis carefully.

For the record - I love SPA

SPA architecture is one of the greatest revolutions in application development of recent years. I love the tech and amazing experiences can be achieved with this approach. But I love using the right tool for the right problem more.

(1) or over any other network

(2) stackoverflow uses many a-synch calls and dynamic HTML, which is a good combination of both approaches, but it is not fundamentally SPA.