I don't really understand the reason behind Single Page Applications. I'm currently working on a code base so bloated with crap that I feel overwhelmed and I can't help myself think stuff like: "it's such an overkill, we don't need all these dependencies". Is it because it's too expensive to send HTML from the server? What kind of problems SPAs are trying to solve? Does people actually bother about a full page reload? At this point I think we are just following the bandwagon and we forget what problems we are really trying to solve.
Soundcloud was built as a SPA so you can keep your music playing as you navigate.
I wish MyFitnessPal was a SPA in places so I could click checkboxes and paginate the food catalogue at the same time when adding food to my diary.
Nearly everywhere else, IMO, no. SPAs are absolutely harder to build and people start with them by default because everyone wants to be Facebook, which your average CRUD site is not. You can pull in those fancy javascript features as you need them, and hell, even embed React in the one part of your site that truly needs it. Which is what React begs people to do on their website, but apparently people read that and say to themselves "That message is probably for the plebeians building a Todo list app or something. I'M building Todo++ Enhanced, so I'll probably need 40 layers of abstraction and about a gig of dependences to implement a form."
While there can be UX benefits to using SPAs, something I have not often seen expressed, but which I believe is that the main advantages of SPAs are for business rather than technical reasons.
1. Clear separation of concerns for front-end and back-end teams. With SPAs, the work is clearly divided into front-end and back-end parts, with the back-end team working on the server side code and the front-end team working on the static assets (HTML, JS, CSS). Both sides only communicate through a clearly defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work independently of each other, and means that if there are bugs or problems, there is less confusion on which team is causing them and thus which team needs to fix them. Compare that with server side rendering using an MVC framework such as Rails. The migration and model code "obviously" belongs to the back-end team, and the static assets (JS, CSS) and views/templates belong to the front-end team, but what about the controllers and routing? Both teams are going to need to work on those parts of the codebase, and that's going to increase the need for inter-team communication and confusion on which team owns what. For example, I interviewed at a company where the front-end team was US based and the back-end team was outsourced to India, and they were moving to a SPA so the teams could work more independently. Previously they had used JSP, which meant the front-end team had to write HTML and then send it to the back-end team and then they had to coordinate how the back-end team was going to re-write the HTML as a JSP template.
2. Cheaper mobile and desktop apps. While it seems HN is very negative about non-native apps, it's not hard to see the business case of quickly and cheaply converting your website into a mobile or desktop app using something like Electron, Cordova or a web view. Even if you do plan to make a native app, the SPA and native app can reuse the same APIs, reducing the amount of work for your back-end and QA teams.
3. Flexibility in changing back-ends. While less common than the other two cases, if you decide to change your back-end code (such as Twitter moving from Ruby to Scala) if your app is an SPA you only need to recreate the APIs and don't have to rewrite all your templating code (this is less of a problem if you use a more "neutral" cross-platform template language like Handlebars). For me personally, I'm moving all my personal projects to Elixir/Phoenix from PHP, Rails or Java, and because I used server side rendering I had to convert all my templating code to EEX.
I'm not trying to be a jerk, but the answer to this, like most things in software development is, "It depends how you use them". They're wonderful if thought out, designed, and used properly, and a bloody nightmare if not...
I've seen one major use for it. We had a "site" running on a tv (think Netflix tv app).
It had to be run on one page for technical limitations of the hardware's browser. It also had to do all the login, persistent connections at the same time.
A lot of it was videos. Meaning we had to check whether users were still watching, which profiles they were logged in to, and had to optimize the API calls. Which is difficult on multiple pages.
There were plenty of overlays - we had videos on the background, navigation on the foreground. Sometimes we'd have to play another app nested within the app. And the only way of closing that app was through a command sent to the parent.
SPAs are particularly useful in scenarios where you need to combine the characteristics of desktop apps (responsiveness, event-driven UI, complex interactions) with those of web apps (links, drawing upon data various sources, declarative UI, ease of software distribution and installation).
SPAs are usually associated with frameworks such as Angular and the MVVM pattern.
While multi-page applications or frameworks like jQuery can provide similar benefits, with features such as component architectures, pub/sub mechanisms and dependency injection that come with SPA frameworks those usually allow you do so in a more deliberate, comprehensible manner.
Because desktop apps lack several features of web applications:
- links and open interfaces to other applications. Try exchanging data between two arbitrary desktop apps, for instance. Often copying & pasting or manually re-entering data is your only option in these cases. Yes, that's mostly because vendors treat desktop apps as walled gardens and yes, there are walled gardens on the web, too. The web however was designed with open standards and data exchange in mind. This shows quite clearly in the underlying protocols of the web, which is why when exchanging data between desktop apps, nowadays often HTTP is used, too. ARexx on AmigaOS (and to a limited extent AppleScript on macOS) was the only somewhat widely used technology that allowed desktop apps to communicate with each other in a manner similar to UNIX command-line applications. About the only more widely used way of calling one desktop (or mobile) app from another today ironically are customs URL schemes, which of course are quintessentially a web technology, too.
- ease of software distribution and installation. This one's particularly relevant in enterprise environments. Rolling out a new version of a bespoke in-house app to the entire staff and each and every desktop machine in the company with all the individual installation issues that might occur on each local machine is a huge undertaking. Besides, you'd probably still need some sort of server application to synchronise to, which in case of a web application already comes with the package.
Browsers on the other hand today are ubiquitous and other than old IE or firewall issues deploying a new version of a web app to users in enterprise contexts by and large works like a charm.
- being able to declaratively define UIs. Desktop UI used to be programmed in an imperative manner whereas HTML and CSS work declaratively, which allows for faster development and immediate feedback to changes. A declarative style can make the structure of a UI easier to grasp as well. Another huge advantage of HTML - or rather browser engines - is that for the most part it abstracts over device-specific peculiarities. Again, browser engines being ubiquitous is an enormous benefit because you can expect a (largely) uniform and predictable runtime environment on each potential target device. Pretty much what JRE promised but never quite delivered (on the desktop, that is).
The framework / tooling bloat is causing a bubble to form; it needs to be simplified, now. It can be done cleanly, but SPA often is not. You are correct in your assessment, even though the cargo-cultists will say otherwise. It doesn't need to be thrown out, it needs improved standards, focusing on simplicity, http >= 2, and domain-specific concerns, such as state management, routing, etc. The innovation in the space is mostly over, time to give it an injection of standard and boring. And, for the love of God, can we really not do better than the virtual-DOM for updates? In-memory copies? Really?
Also if you're careful with design then the JSON API that the SPA uses can be re-used for iOS / Android apps and third party integrations as you scale.
I’m about to finish my first web application—created to show off as a portfolio piece—and it ended up being an SPA. Granted, it’s not very complex, but I’m thinking about adding additional functionality to it, and if I do I’m pretty sure I’ll stick with the SPA architecture. I like the responsiveness and sense of intimacy, but more than that, I like having all of the functionality easily accessible to the user at all times. The one thing I find most annoying about using web applications is the sense of uncertainty that lurks behind every click of a link/button. I find myself wondering:
- Am I going to be taken to a new page with a different interface?
- Will I have to open multiple tabs and/or navigate back and forth?
- Is this going to take several seconds to load?
It’s not the end of the world, but I find it annoying.
Given the down votes and critical replies I’ve received, it would appear that my understanding of the trade-offs between single page applications and traditional web applications is sorely lacking. I will do some research on the issue; if anyone has any particular resources they’d like to recommend, I’ll check them out.
I wish MyFitnessPal was a SPA in places so I could click checkboxes and paginate the food catalogue at the same time when adding food to my diary.
Nearly everywhere else, IMO, no. SPAs are absolutely harder to build and people start with them by default because everyone wants to be Facebook, which your average CRUD site is not. You can pull in those fancy javascript features as you need them, and hell, even embed React in the one part of your site that truly needs it. Which is what React begs people to do on their website, but apparently people read that and say to themselves "That message is probably for the plebeians building a Todo list app or something. I'M building Todo++ Enhanced, so I'll probably need 40 layers of abstraction and about a gig of dependences to implement a form."
1. Clear separation of concerns for front-end and back-end teams. With SPAs, the work is clearly divided into front-end and back-end parts, with the back-end team working on the server side code and the front-end team working on the static assets (HTML, JS, CSS). Both sides only communicate through a clearly defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work independently of each other, and means that if there are bugs or problems, there is less confusion on which team is causing them and thus which team needs to fix them. Compare that with server side rendering using an MVC framework such as Rails. The migration and model code "obviously" belongs to the back-end team, and the static assets (JS, CSS) and views/templates belong to the front-end team, but what about the controllers and routing? Both teams are going to need to work on those parts of the codebase, and that's going to increase the need for inter-team communication and confusion on which team owns what. For example, I interviewed at a company where the front-end team was US based and the back-end team was outsourced to India, and they were moving to a SPA so the teams could work more independently. Previously they had used JSP, which meant the front-end team had to write HTML and then send it to the back-end team and then they had to coordinate how the back-end team was going to re-write the HTML as a JSP template.
2. Cheaper mobile and desktop apps. While it seems HN is very negative about non-native apps, it's not hard to see the business case of quickly and cheaply converting your website into a mobile or desktop app using something like Electron, Cordova or a web view. Even if you do plan to make a native app, the SPA and native app can reuse the same APIs, reducing the amount of work for your back-end and QA teams.
3. Flexibility in changing back-ends. While less common than the other two cases, if you decide to change your back-end code (such as Twitter moving from Ruby to Scala) if your app is an SPA you only need to recreate the APIs and don't have to rewrite all your templating code (this is less of a problem if you use a more "neutral" cross-platform template language like Handlebars). For me personally, I'm moving all my personal projects to Elixir/Phoenix from PHP, Rails or Java, and because I used server side rendering I had to convert all my templating code to EEX.
It had to be run on one page for technical limitations of the hardware's browser. It also had to do all the login, persistent connections at the same time.
A lot of it was videos. Meaning we had to check whether users were still watching, which profiles they were logged in to, and had to optimize the API calls. Which is difficult on multiple pages.
There were plenty of overlays - we had videos on the background, navigation on the foreground. Sometimes we'd have to play another app nested within the app. And the only way of closing that app was through a command sent to the parent.
SPAs are usually associated with frameworks such as Angular and the MVVM pattern.
While multi-page applications or frameworks like jQuery can provide similar benefits, with features such as component architectures, pub/sub mechanisms and dependency injection that come with SPA frameworks those usually allow you do so in a more deliberate, comprehensible manner.
- links and open interfaces to other applications. Try exchanging data between two arbitrary desktop apps, for instance. Often copying & pasting or manually re-entering data is your only option in these cases. Yes, that's mostly because vendors treat desktop apps as walled gardens and yes, there are walled gardens on the web, too. The web however was designed with open standards and data exchange in mind. This shows quite clearly in the underlying protocols of the web, which is why when exchanging data between desktop apps, nowadays often HTTP is used, too. ARexx on AmigaOS (and to a limited extent AppleScript on macOS) was the only somewhat widely used technology that allowed desktop apps to communicate with each other in a manner similar to UNIX command-line applications. About the only more widely used way of calling one desktop (or mobile) app from another today ironically are customs URL schemes, which of course are quintessentially a web technology, too.
- ease of software distribution and installation. This one's particularly relevant in enterprise environments. Rolling out a new version of a bespoke in-house app to the entire staff and each and every desktop machine in the company with all the individual installation issues that might occur on each local machine is a huge undertaking. Besides, you'd probably still need some sort of server application to synchronise to, which in case of a web application already comes with the package. Browsers on the other hand today are ubiquitous and other than old IE or firewall issues deploying a new version of a web app to users in enterprise contexts by and large works like a charm.
- being able to declaratively define UIs. Desktop UI used to be programmed in an imperative manner whereas HTML and CSS work declaratively, which allows for faster development and immediate feedback to changes. A declarative style can make the structure of a UI easier to grasp as well. Another huge advantage of HTML - or rather browser engines - is that for the most part it abstracts over device-specific peculiarities. Again, browser engines being ubiquitous is an enormous benefit because you can expect a (largely) uniform and predictable runtime environment on each potential target device. Pretty much what JRE promised but never quite delivered (on the desktop, that is).
E.g wego.com built with polymer
- Am I going to be taken to a new page with a different interface?
- Will I have to open multiple tabs and/or navigate back and forth?
- Is this going to take several seconds to load?
It’s not the end of the world, but I find it annoying.