September 15, 2013
If there is just one phrase in the web development community that I wish could just go away, it would be “Single Page Apps”. My big problem with the term can be misleading and uninformative. It gives no insights into the technology behind the application. Like HTML5, the term “single page app” is more of a marketing term than a technical term.
Let’s take a pretty common scenario of having an application that requires logging in. Let’s say that our login page is actually a separate page, but the rest of the app fits the single page model. Does this mean we no longer qualify as a single page app? What do we call our app then?
Even if we only have one server rendered page, most SPAs have client side navigation using either push state or hashes. Really, we have multiple pages, but the routing is done on the client rather than the server. In this instance, describing something as single page is very misleading.
When we are building traditional server side MVC applications, we typically describe them using the framework they are built on top of. When someone talks about their rails app or Django app, we have a solid understanding of what they are talking about. Why don’t we just do this on the client side? When someone talks about an Ember app or an Angular app we’ll have a general understanding of how it was built.
In the end we’re just building web applications, so let’s just leave it at that.
Written by Greg Babiars who builds things for the web. You can follow me on Twitter.