SPA and the Single Page Myth | John Papa

John Papa

Evangelist on the loose

SPA and the Single Page Myth


SPA is one of the most exciting technology strategies today, but it may be one of the worst terms in modern web development. Just the word “Page” can have many meanings.

SPA Misconceptions

Chances are you have heard the term SPA tossed around at the office. SPA’s are on the rise but there are a lot of misconceptions about what SPA means. SPA stands for Single Page Applications … but are they truly a Single Page App? I’ve found that one of the biggest hurdles for folks understanding SPA is the term itself. The name can often imply that you are building a single page, with a single set of functionality, such as a search screen or a To-Do list app.

Now let’s play out a common scenario where you are a developer and you are making your case for the architecture of your new project to your manager, Bob. You ask for Bob’s permission to build the next mission critical app on a Single Page App strategy. Bob knows the user will see dozens of pages, so Bob might suspect you and the development team that you might be looking for an excuse to use the “latest and greatest” and that it won’t work for multiple pages. “We need more than 1 page” Bob says. We developers tend to gravitate to the shiny new objects. But I don’t think we can blame Bob in this case as the term SPA can easily be misconstrued. You and I both know a SPA is much more than a “single” page, right? Or is it? The answer to that lies in your interpretation of what a “page” is, and that is why I wrote this post :)

Let me be clear: you can build a SPA that supports robust business applications. Angular, Durandal, and Ember are three great SPA presentation frameworks that lead the way in this area. So how do we break down this barrier and get the point across that a SPA can fully support large-scale application development? It all starts with understanding the P in SPA. Ask a few developers what a “Page” is, you likely will get a variety of answers. So again, how can we blame Bob for misunderstanding its meaning?

What’s a Page?

One interpretation of what a page could mean is the “totality of whatever occupies the four walls of the application UI” (a quote from Ward Bell). If that content changes, then we’ve changed to a new “page”. For example, a page switch could be what we do when we switch from Sessions to Speakers in this live demo. That’s a fairly reasonable assumption, but that is not the “page” in a SPA.

The “page” in SPA is the single web page that the server sends to the browser when the application starts. It’s the server rendered HTML that gets everything started. No more, no less. After that initial page load, all of the presentation logic is on the client.

My friend Ward Bell defines the server and client roles perfectly here:

The server plays no part in determining what the application does with a SPA. That’s the client’s job. It’s the client that composes application pages out of HTML templates (HTML fragments) and data, both of which it downloads on-demand asynchronously as it needs them.

The server’s diminished role is an important distinction in a SPA. The server has no UI logic. The server maintains no UI state. The server, however, does provide resources to the client. Those resources start out with the initial HTML for the web page (the shell) and may in response to client HTTP requests for data in the form of HTML fragments, JSON data, or on-demand JavaScript/CSS.

So Why is it Called Single?

The single page is the starting point. It’s the first part of the app that gets the ball rolling. When a SPA starts, the first visible thing we notice is the initial server rendering of the shell. That shell is our single page. In many SPA’s we won’t ask for another complete page rendering again. We already have what we need in that initial page rendering and now we rely on the SPA presentation framework to help us orchestrate the HTML changes for the user within the confines of that single initial page.

This is really important. In a SPA, we make one round trip to the server, up front, and get the initial HTML page.

HTML Fragments are Views

Let’s revisit our conversation with Bob. You’ve explained to him that the Single Page in SPA is truly just a term that means the first page is rendered from the server, then the client takes over. Bob starts warming up when he hears you say that it’s really a rich web app that can run on any platform, on a variety of devices, and in a modern browser. But Bob is smart, he wants to know how this single page will support the 2 dozen screens your app needs. Bob says “Once we get that initial page loaded, we need other pages, don’t we?” This is where you introduce the term Views.

Views are the “other pages”. The Views are HTML fragments that make up what the users commonly call screens or pages. A user might say “Go to the order entry screen” or “Go to the customer search page”. Their terminology is different from developers, and that’s OK as long as we understand how to translate it when we need to. In our developer speak the term “page” is overloaded. In a SPA everything the users sees is a “view”. When a view occupies the entire screen we call that a page to reflect the fact that it visually commands the user’s full attention. Technically, it’s just a another view composed by the client.

We typically have many views in a SPA. Going back to the live demo you’ll see there are several views. We can flip between speakers, sessions, attendees, speaker details and session details. These views, as we call them, are the answer to Bob’s question. Yes we need other pages. SPA supports that well, we just call them views. That’s an important distinction because we can have more than 1 view visible on the screen at one time.

SPA also supports more than 1 view on the screen at the same time. In the live demo the top navigation and the sidebar are also views. In a dashboard, we can load multiple views, too. So the term views really means an HTML fragment that offers a distinct set of functionality to the application. It often means the view follows the Single Responsibility Principle where the view can operate on its own in a variety of contexts.

What’s the Shell?

I’ve tossed around the term “shell” without properly introducing it, so let me correct that now. The shell is the layout and structure of your app. The visual parts that rarely change. The shell is generally loaded on the initial page load from the server and serves as the placeholder for all of your views. In the live demo, the shell is what contains the sidebar, the top navigation area, and the content area.

Navigation and Menus

Bob now understands the role of views and wants to know how you intend to allow the user to go between the views. Your app will have menus and navigation, so how does a SPA support that? This is where you explain routing.

Most modern SPA presentation frameworks support the concept of routing via a service known as the router. The router’s job is to allow the user to go from View A to View B within the browser by clicking some menu item. if you want to get all technical you can tell Bob about HTML5 push state and the browser’s history and navigation stacks, but it’s probably a more effective route to take (pun intended) to say that the app will have menus, it will support the browsers back and forward buttons, and it will allow a user to go to a specific place (view) in the app given a url (a term known as deep linking) without posting to the server.

When a user clicks on a menu item, the SPA sees that url and translates it to a View that should be displayed. If the view has not been seen before, the application may make an HTTP request to retrieve the HTML template for the view. Then it will compose the view, fill in the template, and display the view in the appropriate location within the shell. If the view has already been viewed once, the browser may have cached it and the router will be smart enough not to make the request. This is one way a SPA can reduce round-tripping to and from a server, and thus improve performance.

What is Data?

Another sticking point with SPA’s is how the term data gets tossed around. A SPA requests data over HTTP from a server. Data is not simply a list of customers. Data can be JSON, HTML, or some other resource that the app requires. A SPA can be built to request these resources asynchronously and on-demand. As my friend Jesse Liberty observed:

… there is a big difference in my mind between saying “what is sent from the server to the client may include JavaScript, CSS or even HTML” on the one hand and “only data is sent from the server”.

He has a great point. When we think of data, and more importantly when Bob thinks of data, he is likely thinking of the customers and orders in the app. And he is right, but data is not limited to the pure data in a SPA. The data can be anything the SPA client needs from the server. So perhaps this data term is overloaded and we should instead clarify this by saying that a SPA will request resources on-demand (or cache them if so desired) and those resources may be JSON data, HTML fragments, JavaScript or CSS. At least then Bob would clearly know we mean so much more than pure data.

So to clear this up let’s stop calling it data and instead refer to it as resources. A SPA makes requests for resources from the server.

Worst Name Ever?

Well, I don’t believe in total absolutes. But while SPA may not be the worst name ever it certainly is not the most clear term to describe them. In fact, I prefer to call them Rich Web Apps but RWA just sounds awful so I’ll stick with SPA :)

PS – Special thanks to Ward Bell and Jesse Liberty for providing their feedback on this post, and for correcting my poor grammar.

tags: angular durandal ember SPA
  • Tim Falkins

    “I prefer to call them Rich Web Apps but RWA just sounds awful so I’ll stick with SPA.”

    Yes, and “Hot Towel” certainly goes better with that.

    • Robbie Pallas

      Great article John! Thanks. I’m not so sure RWA would be a good name even if the acronym didn’t sound awful. I think it’s too general to actually let the user know what it is. It leaves me wondering exactly what ‘Rich’ means. Most modern apps/sites are rich compared to apps/sites that came before them. I thought the same about the name RIA (Rich Internet Applications) Services. As for a better name than SPA – i’m really not sure :)

  • Sampath Lokuge

    Thanks John. It’s a really awesome
    article about the fundamentals of SPA. And your live demo is also nice :)

  • Pingback: SPA and the Single Page Myth | Webdev |

  • Jason Rainwater

    A lot of these concepts exist in modern day desktop client development practices. If you think of the browser as the desktop application you will find yourself in a very similar world

  • Aaron Fischer

    We tend to use the term “page” rather than “view” for our less technical team members. It is afterall visually the same to them. The url changes and the screen has different content. But SPA worst name ever, it’s a javascript client application, it shouldn’t be confused with static html content.

  • Pingback: SPA and the Single Page Myth | WebApi and SPA i...()

  • Sk.Tajbir

    Thanks for sharing such an awesome article..

  • John Smith

    Ward’s descriptions of how these pieces work together help – along with the discrete and concise details of the what and why. I never get too hung up on names, it is what it is; we’ve used the term SPA to move this concept along for the last year or so and it works well whether.
    So, maybe we can just refer to it as a Shell Presentation Architecure to move the shell approach along. A little clearer and nobody gets hung up on the name, whatever it is, or will become in the future.
    Great write-up!

  • Nilesh

    Thanks for this wonderful article that explains the fundamentals of SPA. It definitely clears the misunderstanding.

  • Rusty

    John, when is your next SPA course coming out?

    • johnpapa7

      Year end, I hope :)

      • Rusty

        Will it covert SPA authentication? What is the best way to do authentication with SPA?

        • robertob

          Good point.

          The visual studio 2013 release has an owing katana based spa project template included. I’ve yet to fiddler it but apparently it introduces use of oauth code grant flow token acquisition and securing resource requests by attaching token to authorization header, i.e. the same game plan we use in native phone and tablet client apps.

          This is a change from the wsfed token acquisition and session token cookies (stc) secured resource requests that browser clients have used previously.

          Understanding this new vs13 owin katana based spa project templates oauth secured story for browser clients will be helpful.

  • Allen Conway

    Great way to articulate SPAs John and how it doesn’t necessarily mean a single ‘page’, but rather a combination of views + 1 trip to the server. Nice job sir.

    • johnpapa7

      Thanks Allen :)

  • Taiseer Joudeh

    Straight to the point! Simple explanation for SPAs.

  • Pingback: Decaying Code | Community Update (2013/12/10) on ASP.NET, OWIN, Single Page Application and Entity Framework()

  • Tolga Yaramis

    Great article again..

  • Praveen Addepally

    @johnpapa7:disqus – Hello John, I have a question regarding picking up a SPA framework for a web app we are going to start building soon. We have looked at both the Angular and the Durandal frameworks. Having been used Javascript, JQuery, Knockout from a while we are really biased towards the Durandal framework. Also we do see that there is a good amount of learning curve for the Angular framework. Now the only thing that concerns is the life of Durandal framework. Is Durandal framework going to die soon since it does not have a good financial backing ? Also what do you suggest us on going forward with ?

    Your reply is greatly appreciated. Thanks!

    • Jordi Montserrat

      Hi Praveen, which path did you follow? I’m facing exactly the same dilema….

      • Praveen Addepally

        We took the route of AngularJS and it’s pretty good and we are loving it!!!

      • Simon Lawrence

        I would say that AngularJs and Durandal are in the same boat. They are both going to be replaced by newer versions (Angular 2.0 for Angular and Aurelia for Durandal). Upgrading either of them to the newer version will be quite an overhead… but why bother? – they work now and will continue to work in the future.

  • robertob

    What if the existing spa acronym was kept the same but instead of it referring to “single page application” it instead referred to “single pull application”. This might remove confusion over page being a server response vs a client side view.

  • Carlos Redondo

    Hi John,

    I’m trying to figure out best development pattern to use for a migration project we are going to initiate next months, it’s a conversion of an old fashion POS Windows Forms application (touchscreen with big ugly buttons) to a modern touchscreen application, faster, easy to deploy, and capable to run on desktop and mobile devices (that’s more or less the high high level request I received)… and I found SPA approach very interesting. My development team has gained MVC skills during last year (2013), we converted an web forms to ASP.Net MVC using Bootstrap, jQuery, knockout, responsive design, etc, and I found MVC SPA as a very intersting approach for our new POS. In current windows form POS solution we used the event notification pattern to maintain all user controls updated/sync with state/data, so for example, when an item is added to shopping cart, then the Totals User Control is “listining” the changed shopping cart event to refresh its Totals, is there any known development pattern we could used in SPA MVC approach to notify and maintain individuals visual elements sync with current status/data? I saw your online demo SPA with session and speakers, let’say I will like to filter sessions by speaker, but speakers gallery control don’t know anything about session list control and viceversa, but Speakers has a “selected” event it’s somehow (that’s the question) wired to Session List. I just want to ask to the expert looking for recommendations you know… check this course, read this… I don’t want to end up with an spaguetti code, just because I didn’t ask at right time.

    I’ll start next week sharing Pluralsigth videos with our dev team, first one will be SPA JumpStart, I know we’ll have fun!

    Thanks John for all your help, and wish you best for 2014!


  • Pingback: Tutorial for Building SPA using AngularJS | Bit of Technology()

  • James Barrow

    It would be great to see a post on SEO and analytics and how that ties into a SPA. I found out after building a SPA that it’s not so simple when you then need to include SEO. Analytics is okay, e.g. Google Analytics is just plain JS and you can also fake the “page” views, but the SEO Googlebot crawling is quite different and is possibly easier to do with multiple actual pages with nice URLs, instead of hashbangs.

  • Alexandre Hedreville

    Hi John.. I would need to add a Pub / Sub library to my SPA

    Which ones should I check?

    Which one best fit on your HotTowel SPA?

    Thanks in advance

  • TR

    Well, WAI uses RIA in the ARIA specification.


    But every time you request a new view, it will come from server , right ?


    It means that server method will return only a page(shell) and rest of all views (html) are asked by client framework but fetched from server every time…am i got it right ?

  • Theodore Lewis Bissell

    Excellent article John!! I believe that your description of SPA as a development paradigm is the best I have read. For me, it brings my understanding of SPA full circle. As you point out; the only ‘weak link’ of developing an SPA project lies in the common understanding of the terminology involved for developers and ‘business’ management folks alike.
    My own perception of SPA is that it is a fairly strict application of ‘client-server’ principles (you :( frown)). Your descriptions of ‘views’, ‘navigation’, ‘shell’, and ‘data’ are spot on! They, in no way, disturb the principles of ‘Single Responsibility Principles’, or other ‘SOLID’ principles so valued in internet development these days. I myself use the term ‘client-server’ as a description of this architecture. That term is certainly obsolete for those who have been educated in a ‘3-tier’ architecture world; but it may be the best analogous term to use. Development has always been a task of having the computer ‘DO’ something we can ‘VIEW'; and doing this with ‘DATA’ . This principle has been reflected in every evolution of languages, patterns, frameworks, and technologies since its original conceptualization. HTML and HTTP are firmly embedded in it. REST and other asynchronous communications rely upon it. Although the idea of running ‘client’ and ‘server’ in the same context (same physical machine, device, whatever…) is heralded as ‘new'; it is not to me as a developer who understands and knows the history of ‘programming’–and how to code with the ‘latest and greatest’.
    Perhaps we could call ‘SPA’ , ‘NewestClientServerArchitecture’ or ‘NCSA’, and describe it as the ‘newest, cleanest, brightest’ idea for architecture…or maybe that is too long an acronym and sounds too ‘governmental’…LOL The only problem then would be that the MVC/MVVM folks and ‘Bob’ would ask where the ‘business logic’ resides. In fact, this may be the only legitimate weakness of SPA frameworks as they now are implemented. That is, the clarity of the ‘separation of concerns” principle in specific implementation.
    This is not to say this weakness resides in SPA alone. It actually has become the norm in development tools, methodologies, and development paradigms in general. Part of this problem is that we as developers have a tendency to over-complicate. We tend to look at a problem and once we have found an answer; we like to elaborate on it. In doing this, we are constantly inventing new terminology to describe our elaborations in hopes of ‘catching the next big wave’. In fact, the only real value of any coding is keeping the code as ‘pedal to the metal’ as possible.
    That is why I find YOUR articles and contributions so delightful. I follow you because you keep things simple, and elaborate only when necessary. Jesse Liberty, Rick Strahl, the ‘three Scotts’ (Hanselman, Guthrie, and Mitchell) along with you; are the people I find this trait in.
    Thanks for sharing!

  • Muhammad Raheel

    Hi John,

    Your article is useful to understand SPA basic ingredient like: Route, View, Shell etc.. I’m analyzing requirements to develop over SPA framework but still not sure which framework should I stick with. Not sure to develop with Ember.js OR AngularJS.

    • John

      THere is no perfect choice, but my current preference is Angular

  • TheCatIsFat

    Hi Johnny, Byer here – very well done article – I hope you are well – Thanks!

  • tgoyer

    Maybe just call it a Starting Page App? :)

  • MattFromGA

    I think a large web app could be build as a collection of SPAs. Within angular, each SPA is a collection of controllers that together make up a set of “business processes” being exposed for the user to work with. Sometimes the user may want to transition to another real page that exposes a different set of “business processes”. Some frameworks like jquery mobile can make the entire site work with just one main page load, but I think it can be very helpful to be able to truly navigate to another page during major page changes so that memory can be reclaimed and unintended interactions between unrelated scripts is lessened.

  • Tarun

    Hi John,

    I just started working on an application after reading your article but feel litter bit stuck. I have a question, lets say I have two different design screens such as Admin and end-user, how would you create two layout pages(master) where header and footer are different.

    Please answer me if there is any solution.


%d bloggers like this: