Single Page Applications SWOT Analysis

Single Page Applications offer many opportunities to increase performance and availability while reducing hosting costs. Unfortunately, it comes with some compromises and potential threats.

What is a Single Page Application?

An increasingly more popular, but not necessarily new, paradigm for web application development is the single page application (SPA). Sometimes this is also referred to as a “fat client.” It’s called this because of the way application resources are delivered to the consuming device, whether it be a desktop browser, a mobile phone, or television set-top-box device.

In traditional web applications, all processing is done on the server to fetch data, run business rules, render html output, and so on before the content is sent to the browsing device. The device then displays it. Each time an action is taken, the process begins again. Some resources are cached between actions, but often times all new must be downloaded again.

In a single page application paradigm, all the resources are bundled as static, minified, and compressed objects. Resources typically include html, cascading style sheets (css), and Javascript. When the application is first accessed, all the resources are downloaded and the page is never refreshed again. The application only goes back to the server to inform of changes in data, or to collect changes in data.

To clarify, a single page application is not actually an application with only one page. It simply means browsing device only pulls the initial resources once, and then navigates between view states without refreshing the page.

SWOT Analysis

Strengths of Single Page Applications

Because the application isn’t going back to the server between page changes, the transitions are a lot smoother and nearly instantaneous. This makes the application feel more like a desktop app in how responsive it is.

Additionally, because of the way resources are packaged, the total resource download is considerably less.  This reduces bandwidth consumption, both for the end user and the server.

Our biggest reason for selecting this paradigm is that it makes it easier to wrap with Cordova. The Cordova Framework, or commonly referred to as PhoneGap, permits the development of a mobile application in Javascript, HTML, and CSS that can later be deployed on ALL the mobile platforms, including Android, Apple iOS, and Windows. Without it, we would need to write native code for each platform. So this cuts the overall cost of mobile application development by a third in many cases.

Not to mention that the bundling puts all the static resources in the initial download for the device. This permits the end-user to conduct some operations while offline or without having to return to the server.

Weaknesses of Single Page Applications

A single page application handles it’s processing using a heavy amount of JavaScript. For most modern devices, this is not an issue. However, older devices or browsers may struggle to use the latest methodologies. For instance, if your organization is still using Internet Explorer 7, you could possibly not be able to use a single page application.

Another common issue is that when a script fails hard, it can crash or hang the entire application. After this happens, no buttons or links will respond on the page. In a multi-page app, code is more compartmentalized. So an error in one discrete section of the app would not affect other portions.

Lastly, we have to acknowledge that this structure adds complexity to the software framework stack. Any time you do that, you make the system more costly to develop and maintain because it involves more labor. More moving parts also means more things could go wrong.

Opportunities of Single Page Applications

The single page application structure almost completely divorces client-side logic from server-side logic. Because of this, client-side resources can be served from a low-cost, low-latency, high-availability content delivery network (CDN) that leverages distributed caching (served from multiple cities around the world). Amazon’s CloudFront is a prime example of such a service that we frequently employ for our clients. This removes burden from your application server, which permits the same resources to serve more end-users and ultimately reducing hosting costs.

More to the point, this structure moves processing from the centralized server to the distributed client. So each end user picks up their share of the processing, also leaving the server infrastructure to assist more users with fewer resources.

Single Page Apps typically communicate with the server through a JSON based RESTful interface. What this means is that you could exchange either component of the system so long as it still complies with the same interface. Say for example, you write a JSON interface in ASP.Net, but later discover you need to deploy on a Linux server. You could replace the server-side logic with PHP or Node.js without refactoring the entire system.

Threats of Single Page Applications

Such an aforementioned system is not without its risks. With business rule logic now at the end user device, it makes it easier for the system to be tampered with. For instance, a skilled engineer could de-minify your javascript and reverse engineer it to steal your intellectual property. In being able to do so, they can also better study the interface your server exposes and look for opportunities to exploit. There are of course ways to mitigate this, but the threat is still very serious.

How Smart Software Approaches Single Page Apps

We recognize that the SPA stack is not appropriate for every custom developed software application. Most of our web applications are still developed to utilize a traditional, thin-client approach with only moderate amounts of javascript. For small projects, the SPA structure actually adds an unnecessary complexity to the project.

However, we jump at the opportunity to develop fat client applications for those seeking high performance, high availability, highly interactive, highly responsive, distributed cloud solutions. Several of our clients are actively using such systems and are reaping extraordinary benefits.

As of late, our preferred front-end framework has been AngularJS; having made the shift from Prototype and JQuery exclusively. We also leverage Bootstrap frequently, or other Jquery components for rich UI elements.

Want to Learn More?

This is just a sample of what we can do. We have 15 years of experience working in nearly every technology and industry. Whatever you are doing, we've done it and are prepared to tackle your project. Reach out and we will discuss it with you.