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?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Rounin
  • 275
  • 1
  • 10
  • 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 '21 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 '21 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 `
    ` 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 '21 at 10:23
  • @Rounin: Just because _some_ line exist (such as the incompatibility of `
    ` in HTML5) doesn't mean that everyone therefore agrees to draw it in the same place. So like your `
     – Flater Apr 19 '21 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 '21 at 12:48
  • @ThomasOwens - you are an accomplished professional, so with the greatest of respect - genuinely - please stop wasting your time arguing that whether something is a matter of opinion or not is, itself, a matter of opinion. Tabs vs Spaces is a matter of opinion. It is certainly not a matter of opinion whether Tabs vs Spaces is a matter of opinion or not. – Rounin Apr 21 '21 at 10:04
  • @Rounin Please do not keep editing meta content into the body of the question. The question should only contain information relevant to getting the information that you need and not commentary about the scope or topicality of the question. I'd also point out that I did not close this question - the community is handling it. The only action I've taken is to ensure the quality of the contents of the body of the question. – Thomas Owens Apr 21 '21 at 11:47

2 Answers2

10

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.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • 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 '21 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 '21 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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 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 '21 at 13:46
  • 1
    @Rounin: But why is it important for you to call it a SPA? – JacquesB Apr 17 '21 at 13:52
  • If it doesn't make sense to refer to the architectural model as **SPA**, then it would be silly to call it **veSPA**. – Rounin Apr 17 '21 at 13:55
  • @Rounin: IMHO it doesn't matter if you have one or three or many page reloads, the difference is between zero and non-zero full page loads (after the initial load), since this fundamentally changes how you manage state on the client side. – JacquesB Apr 17 '21 at 15:04
  • In the case of **veSPA**, `state` is neither managed on the client-side nor on the server-side - it's managed in the `queryString`. Both the server-side scripts and the client-side scripts read the `queryString` to update their understanding of the `state`. For the benefit of **CSS** the `queryString` is also translated into a series of _custom-data_ attributes in the root HTML element. That means that, on the client-side, **CSS** is fully aware of the `state` just as **Javascript** is. The consequence is: if you reload the app when you're looking at any app-view you won't see anything change. – Rounin Apr 17 '21 at 16:08
  • 1
    @Rounin _a_ consequence. Others might include impacts on SEO and link sharing, possible privacy issues (see e.g. https://stackoverflow.com/q/323200/3001761), ... – jonrsharpe Apr 17 '21 at 16:29
  • @jonrsharpe - Fortunately, because of its different approach to web architecture, **veSPA** doesn't have the same scale of SEO problems that a conventional **SPA** would have. Even so, I still wouldn't use **veSPA** for an editorial-first website which needs SEO. My intention is to use it to build User Interfaces for single-file web-based tools which execute PHP-based Filesystem CRUD operations. Link sharing is definitely not a problem: as mentioned above, the `state` is managed in the `queryString`. If you share the URL, you are literally telling the new user-agent what the `state` should be. – Rounin Apr 17 '21 at 16:38
  • @Rounin that's _why_ link sharing is an problem; I intend to send someone else to the right page and end up leaking my whole session. There are so many ways to store state that have better trade-offs. – jonrsharpe Apr 17 '21 at 16:43
  • @jonrsharpe - In this instance what do you mean by _"whole session"_ ? – Rounin Apr 17 '21 at 16:55
  • 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 '21 at 17:30
  • Right, fair point, both @GregBurghardt and jonrsharpe. So, for clarification; my intention is to use **veSPA** to build User Interfaces for single-file web-based tools which execute PHP-based Filesystem CRUD operations. You'll need an authorisation level to access such tools, but that will be handled elsewhere (i.e. away from the tools). If you haven't passed through the authorisation gateway, you won't be able to access the tools. Neither browser history nor user information will be stored in the query string. – Rounin Apr 17 '21 at 17:35
  • 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 '21 at 17:43
  • Yes, you're right, @GregBurghardt. What we're talking about is simply a sub-variety of **SPA**, the `views` of which are primarily (if not, _wholly_) activated / configured by **CSS**, rather than by **JS**. (Which additionally means there's no _isomorphism_ or _SPA-style SSR_ or _Client-Side Hydration_ etc.) So we _could_ call it an "SPA with CSS-powered Views". But I chose **veSPA** this morning because it's a little snappier. – Rounin Apr 17 '21 at 18:19