I know that the title of this post may be a bit of link bait, sorry about that. But having been in this business quite a while now, I am noticing a trend. A trend that worries me.

The Single Page Application (or SPA) moniker is one I’ve always disliked (as you’d know if you follow me on Twitter). But it’s not the technology I have a problem with, it’s the moniker and the implications of the moniker.

The Technology Behind the Moniker

I started doing web development in the ‘90s on ASP (no, not ASP.NET). This was a treasure trove of open database connections, imported headers, and clunky HTML. I never thought we’d get to where the web was a mature platform to develop upon. In the past few years, technologies like Knockout, AngularJS, BackboneJS and the like have all contributed to a richer client-side experience. No longer were we dependent on post-backs or page requests to get the job done. Things are good. They are really good.

What these technologies have in common is an application model on the client. They go about it in different ways, but the real revolution is the ability to build up an application with features like dependency injection, data binding, view management, and separation of concerns. It means we can build real software in a web page instead of just using JavaScript for simple event handling and DOM manipulation.

At the same time the back-end has become simultaneously less and more important. Back-end code has changed significantly. No longer are we spending as much time building markup or dealing with partial pages. Instead, we’re now building APIs for our applications to call. These APIs are useful for a variety of scenarios: web development, mobile development, and integration. Our back-ends are more about business logic and data than ever before. As I said…things are really good.

Enter “Single Page Applications”

During this heyday of web development, someone decided that this new paradigm needed a name. Lots of monikers were tried, but the one that unfortunately stuck was “Single Page Applications” or SPA. My issue here is that the goal is to build your entire site in a single page.

This starts with the wonderful client-side routing that many see on the web currently. Because we can now route to different views in the browser, it feels like we’re just doing desktop development again. This is certainly true for people coming new to web development with things like AngularJS or BackboneJS.

Please don’t misconstrue what I am saying. These technologies are amazing and have changed the web in great ways. The problem is when you mix them with the Single Page Application moniker. I am seeing too many projects that think that their entire website should be a single SPA. This returns us back to monolithic apps. Even in a perfect world, this amount of JavaScript in a single page is problematic.

This approach mirrors something that web developers used to hate: Flash and Silverlight. This was an issue back then. If you build one huge project for the web, you’re probably breaking the web. I am sure you’ve all been on a Flash-based site that had their address page deeply nested and no link to it. Sure, SPAs don’t usually do this, but if you’re code is complex, the resolution of a client-side URL is going to involve a lot of code.

Adding to this monolithic behavior is the rich ecosystem of client-side technologies that seem to encourage larger code-bases in a single page request. I keep seeing projects that seem to try and mimic client-side development. We’re getting notoriously close to mimicking Visual Basic 3 apps in the browser. Might as well bring back ActiveX apps…ok, not really.

What Can We Do?

The horse is out of the barn for the SPA moniker and the technology behind it is great. What we need to do as developers and a community is to make sure people know that building rich client applications in the browser doesn’t mean making the entire site a single page.

What I talk to students and clients about is building islands of functionality. When the workflow of the user matches multiple views, make a rich client page (e.g. SPA). But when they break out of that workflow, it’s ok to create another page. In fact, many web sites are likely to be a handful of SPAs.

Let’s take an example. If I were building a pizza restaurant website. The home page would probably be a SPA so that the process of ordering a pizza online would be as smooth as possible. We don’t want page requests slowing down the process or losing the customer. But the contact page, directions page, about page and even the dining-in menu would probably be all separate pages. If you’re thinking it would be cool to make this all part of a single, but SPA…you’re part of the problem

Am I wrong?