4

Is there a canonical definition of SPA which would exclude the software architecture model described below?

I'm working on an app with a new web-architecture model (new to me, at any rate) which has features that differentiate it from a Single Page Application (SPA) as the term is conventionally understood.

Since the model uses server-side and client-side variables which always automatically mirror each other, I would like, at least provisionally, to give the model a label something like Reflective SPA (or veSPA for short) but I'm concerned that due to its reliance on server-side processes, it may not qualify as an SPA at all and, as such, this name would be misleading and/or nonsensical.

Towards the end of the Wikipedia entry on Single Page Applications there is a statement:

A SPA is fully loaded in the initial page load and then page regions are replaced or updated with new page fragments loaded from the server on demand. To avoid excessive downloading of unused features, a SPA will often progressively download more features as they become required, either small fragments of the page, or complete screen modules.

I'd strongly subscribe to this as a conventional definition of an SPA. This is absolutely what I think of when I read the acronym SPA.


What differentiates veSPA is that instead of:

page regions are replaced or updated with new page fragments loaded from the server on demand

veSPA repeatedly responds to user interactions by updating the queryString, either via:

1. Updating the URL (including the queryString), using:

  • window.history.pushState({}, document.title, 'https://example.com/' + queryString); (Javascript)

2. Reloading the URL (using a new queryString), using:

  • window.location.href = 'https://example.com/?' + queryString; (Javascript)

3. Redirecting the URL Request (using a new queryString) at server level, using:

  • header('Location: https://example.com/'.$Query_String); (PHP)

When the page is actually reloaded, various custom-data attributes in the root HTML element are populated from the queryString, using the super global variable $_GET in PHP.

When the URL queryString is updated, the same custom-data attributes in the root HTML element are populated from the queryString, using new URLSearchParams(window.location.search) in Javascript.

Either way - and this is the most important culmination of everything described above - the app-view is then rendered via CSS from the values in the custom-data attributes in the root HTML element.

Does this repeated use of page-reloads and server-side PHP (described above) mean this model is too differentiated from SPA (as conventionally understood) to have the term SPA meaningfully applied to it (or to use SPA in its name)?

Is there a canonical definition of SPA which would exclude the model described above?

7
  • 2
    Nothing you describe here sounds new or unusual with an SPA. SPA doesn't just mean an entire website, nor even entire page. Indeed SPAs can't replace a lot of server-rendered content (For all kinds of reasons, including SEO) - many SPAs are just components within a site or page. to work with and compliment the rest of that site, which means they're often coupled to that site in all kinds of ways. (Common scenarios include users entering and submitting data in a form which needs more sophisticated validation and feedback, such as user registration, login, profile edit, payments, etc) – Ben Cottrell Apr 17 at 10:50
  • Just like with all things, people tend to define things differently. Is something that looks and feels like an SPA (but under the hood isn't technically) an SPA? An end user will call it that because they can't tell the difference, but a backend developer would not (as they have "no knowledge" of the frontend that consumes their endpoint, and their endpoint doesn't behave like one of an SPA would). – Flater Apr 19 at 10:03
  • @Flater - Yes, you're right, "people tend to define things differently". But where things have strict definitions, people who define those things differently are simply wrong. You could tell me that HTML5 which uses <center> is still "a kind of HTML5", or a website with a .webmanifest but no Service Worker is still "a kind of PWA" but neither of these statements would be true. – Rounin Apr 19 at 10:23
  • @Rounin: Just because some line exist (such as the incompatibility of <center> in HTML5) doesn't mean that everyone therefore agrees to draw it in the same place. So like your <center example, we can assert that some line exists on SPAs (it's in the name, i.e. it must be an application accessible through a single webpage), but whether that focuses on user experience, technical implementation, or general architectural approach is up for debate and not universally answerable. Real life consistently teaches developers that semantics are much more vague than logic would want it to be. – Flater Apr 19 at 11:44
  • @Flater - If you're saying that SPAs do not have a strict definition, that precisely answers my question asking whether they do or not. I'm not asking: "What is the strict definition?" I'm asking: "Is there a strict definition (and if so, what is it)?" Hence my reference to "fuzzy edges" in the question title. I'm not adopting a position that nothing is relative. In fact, I think the vast majority of things are relative. That notwithstanding, some things are not relative. – Rounin Apr 19 at 12:48
9

There is no canonical definition of a single page application, since there is no governing body that defined it. Instead, it is a name that got applied to web applications that exhibit a number of characteristics about how client and server interact.

  • Reduced or eliminated page reloads: this is the quintessential difference between traditional web apps and SPAs. The user does not navigate away from the page, or does so infrequently, when they perform an action.

  • Rendering logic is pushed to the client: HTML is rendered on the server in traditional web apps. This logic is written in JavaScript and is executed on the client in SPAs.

  • Service-oriented or micro services architecture on the server: with clients responsible for rendering logic, server logic is reduced, and the data exchange format is most often changed to JSON. Web API end points are exposed as data services.

  • More complex client side architecture: with more logic on the client, JavaScript code tends to adhere to one of the MVC or MVVM style architectures in order to promote testability and organization.

Your application does not need all of these attributes. In fact, it may have more than exist in this list. The definition of a single page application is not exact, so don't get to hung up on it. If you use a client side framework like ReactJS or AngularJS, then you could be creating an SPA — if it has the characteristics above. Then again, you can have an SPA without using one of those frameworks if your application has the characteristics above.

The definition is in the behavior and architectural style — how client and server interact — rather than the specific code you write or the frameworks you use.

Since the model includes both server-side processes and client-side processes, ... I'm concerned that due to its reliance on server-side processes, it may not qualify as an SPA at all...

It is common for both server and client to have models. Client side models tend to have more data than logic. Server side models tend to have more business logic. What you describe does not eliminate "SPA" as a description of your application.

Does this use of page-reloads and PHP (described above) mean this model is too differentiated from SPA (as conventionally understood) to have the term SPA meaningfully applied to it (or to use SPA in its name)?

The answer is "it depends." If every user interaction, or a majority of interactions cause a page reload then your application is not an SPA. Page reloads are common in SPAs when the user navigates from one major "application module" to another. Here again we have some fuzziness. What constitutes an application module largely depends on the application and business functions it encapsulates.

2
  • Thank you, @GregBurghardt - your last paragraph, especially, brilliantly answers my concerns: "If every user interaction, or a majority of interactions cause a page reload then your application is not an SPA. Page reloads are common in SPAs when the user navigates from one major "application module" to another." I have fully audited the app and it has only three page reloads. Two of these can be refactored as window.history.pushState statements. [1/2] – Rounin Apr 17 at 13:52
  • 1
    This means the app will have a single user interaction which leads to a full page reload and, otherwise, many dozens of user interactions which result only in pushState. Given all this, I think I can be tentatively confident to refer to the app's architecture model as SPA, while recognising it may be an uncommon example. [2/2] – Rounin Apr 17 at 13:52
1

There is no canonical definition of SPA, but the common understanding is that in a SPA, a full HTML page is only loaded once, while a regular web site have multiple full page loads.

Since your architecture reloads the whole page (and not just updates/replaces parts of the DOM via code) it is not a SPA as it is normally understood. An important characteristic of SPA's is that you have persistent state on the client side. But this state gets wiped with a page reload, so this changes the programming model fundamentally.

While nobody owns the term SPA, you will just confuse people if you call your architecture a SPA.

13
  • Thank you, @JacquesB - this responds to precisely the concerns I was worried about. I have fully audited the app and it has only three page reloads. Two of these can be refactored as window.history.pushState statements. This means the app will have a single user interaction which leads to a full page reload and, otherwise, many dozens of user interactions which result only in pushState. So I'm more content now than I was earlier to refer to the app's architecture model as SPA, while recognising it may be an uncommon example. – Rounin Apr 17 at 13:46
  • 1
    @Rounin: But why is it important for you to call it a SPA? – JacquesB Apr 17 at 13:52
  • 1
    @Rounin a consequence. Others might include impacts on SEO and link sharing, possible privacy issues (see e.g. stackoverflow.com/q/323200/3001761), ... – jonrsharpe Apr 17 at 16:29
  • 2
    @Rounin: depending on what information you are storing in the query string, you could be sharing sensitive user information in the form of a link. Don't forget browser history here, either. It sounds like the query string is a string representation of the current state of the application. That could be a security issue. Be careful what kind of info you store. – Greg Burghardt Apr 17 at 17:30
  • 1
    @Rounin: I've never heard of veSPA. If you have to qualify "SPA" with another buzzword, you will likely confused people. I would call it an SPA and explain it is a non standard implementation, or just not call it an SPA. Maybe SPA-like? – Greg Burghardt Apr 17 at 17:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.