11 ms·

These are fantastic technical reasons when considering a SPA vs. a traditional server-side app, but to me the largest consideration, outweighing other technical

These are fantastic technical reasons when considering a SPA vs. a traditional server-side app, but to me the largest consideration, outweighing other technical decisions, is the overall experience the end customer is going to need and expect. Migrating from a desktop-based application to a web version? That desktop version was likely extremely responsive, and full page loads may feel like a step backward. Does the application require constant, fast interaction, such as data analysis, frequent order entry, or highly dynamic UX? That's the domain of the SPA. But if the situation is more of a request/response scenario, then a traditional server-side set up works wonders. The technical difficulties surrounding SPAs vs traditional are for the most part solved. It does require more overall work, but that gap is shrinking. Therefore, IMO the largest deciding factor should be user expectations, and that can go either way.

purerandomness 9y ago
The problem is that most SPAs today are cargo-culting. They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) The ideal solution is a) minimize server roundtrips (<100ms) and b) reload parts of the site via AJAX where it makes sense. No need to shovel 7MB of JavaScript to the user.
- bastawhiz 9y ago
  > They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. This problem existed before SPAs were a thing. Remember ASP.Net pages where the whole page is wrapped in a giant <form> and you couldn't use the back button most of the time? This problem also doesn't exist with properly built SPAs (e.g., by using <a> for links, using the history API correctly, and designing a sensible UX). And certainly, if your app is sending 7MB of JavaScript over the wire and it's not a video game, something is very wrong--SPA or not.
  - reaperducer 9y ago
    I think SPAs get a bad reputation partially because they're trendy. Which means that inexperienced programmers flock to them and make them awful. I recently re-wrote an SPA from a previous dev into a regular set of query/response web pages. The SPA was 2,143K. The new set is 78K. A big part of that savings was because javascript is verboten for this project due to client hardware constraints. Yes, the previous dev was not the best in the world, but IME SPAs are always heavier than their response/query counterparts.
    - RussianCow 9y ago
      > SPAs are always heavier than their response/query counterparts Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.
      - reaperducer 9y ago
        > Heavier by what metric? I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month. Don't forget that plain query/response caches many static assets, too.
        RussianCow 9y ago
        Sure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action. My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.
- deleted 9y ago
  [deleted]
- amsheehan 9y ago
  It sounds like your experience with SPA's is the exception, not the rule. I have never built a product or website using Angular or React that performs as poorly as you describe. - Routing modules in all the major frameworks interact directly with the history APIs, and are fast as f*. - There are only a handful of locations in the US where you can expect sub 100ms server round trips, usually they're around 300ms, but lets call that negligible. The real time spent waiting is usually if you're executing some complex database query over large data sets. This has nothing to do with SPA's vs Monoliths. Even so, it sounds like you just experienced bad code if you're waiting 6 seconds for a modal to open. Also...React with React DOM is only 10kb larger than jquery, and when gzipped it's only 37kb.
  - craig1f 9y ago
    I was going to say the same thing you said. Angular/React routing, if done correctly, don't have those problems at all. If you let the SPA framework do your page-changing for you, open-in-tab and history still works. If you do amateur stuff like, you bind a button to a function, and the function does an document.location.href update, then you're going to have some weirdness. My biggest problem with SPA the last time I did it (a year ago) was optimizing it for search engine crawling.
    - amsheehan 9y ago
      Google's crawler at some point last year started indexing a really large mostly text based AngularJS app I built: https://www.fwdeveryone.com https://www.fwdeveryone.com Even if it didn't, headless chrome makes it really easy to pre-render content for web crawlers.
  - TheRealDunkirk 9y ago
    One of my biggest problems in writing data-heavy web applications is that browsers seem to be really lousy at handling the data. In fact I have 2 applications in this boat. My queries run fast (couple/few hundred ms), but displaying 10's of MB of data, over 10's of thousands of rows of data, has been brutal for a browser. Trying various standard JS table widgets only made the problem worse, but I've discovered ag-grid (a paid JS table widget) which made this tolerable. It takes about 6 seconds to render my big page of data (which is actually on-par with a WinForms version of the system I wrote, using DevExpress). It sounds like you have the opposite problem, and I'm wondering how you display "large data sets" from "complex database queries" in sub-second renders in a browser. Incremental loading (like a news feed) won't really work here, because my users need to be able to sort and filter and rearrange the data as a whole. I guess I could "chunk" the data to be able to see it sooner, but it's still going to hold up the browser until it finishes. I've been looking for a better way for a long time.
- mfrye0 9y ago
  I agree with the others. Those are signs of bad software dev, not SPAs in particular. It's relatively easy now to break up the 7MB bundle into chunks and load on demand. So you get the benefit of both the fast, small initial load while other stuff loads in the background. Then I'm not sure what you're referring to on links and waiting for single interactions... With SPAs it's actually easier with the History API to create deeply nested stateful apps via the url / links. The confirmation modal, maybe your backend API sucks? Idk what your talking about with a 6s delay. On top of that, a pure SPA means you have a static website, which means you can host the whole app off something like S3. We save so much money by hosting our stuff statically.
- xmlninja 9y ago
  and with serviceworkers also breaking the refresh button :D
  - arrty88 9y ago
    And intercepting URLs meant for the API server
- intrasight 9y ago
  I see no way that a properly built SPA could perform worse than a properly built server-rendered app form a network bandwidth perspective. JSON is always smaller than HTML.
- heavenlyblue 9y ago
  Let us all give some credit to LastPass, which manages to tick all of the points you're making here. More importantly, at the same time being a simple browser plugin.
- sibeliuss 9y ago
  In much modern software this is no longer an issue.
- emodendroket 9y ago
  > They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) > [...] > No need to shovel 7MB of JavaScript to the user. Well that's exactly the problem. Someone thinks they don't need all the "dead weight" of something like angular that solves every one of these problems and instead they do a half-assed version where it's all broken.
- chrismorgan 9y ago
  > minimize server roundtrips (<100ms) Not possible, because the speed of light is too low. I live in Australia. Servers tend to be in America. That hundred milliseconds has just been blown in latency, along with another hundred or two, depending on where in the US the servers happen to be. Take something like FastMail. Our servers are in the US, our team is mostly in AU. FastMail couldn’t be fast for us and many of our customers without being crafted in the SPA style—and even customers in the US benefit from its latency-compensation techniques, which reduce at least 50ms of delay (plus further page load, so call it 100ms at a minimum, but probably more like 250ms) to zero. Please don’t blame navigation-breaking on the SPA style of app; blame it on developer ignorance and occasionally laziness, with perhaps a side of unfortunate browser APIs (onclick is a poor event for this sort of thing for various reasons). And I assure you, simple JavaScript-enhanced pages manage to have at least as much problem with such links as SPAs do.
bloudermilk 9y ago
Being in the middle of a non-trivial SPA build, I can't agree that the technical difficulties are "solved", especially if you want to build on open source tech. Specifically, my project was prototyped in Firebase and for various reasons needs to be moved off. Now I'm left building a lot of plumbing that just isn't available outside of Firebase. In the end, our result will be less capable than the Firebase equivalent because we don't have time to engineer features like offline support and optimistic updates. There are a lot of tradeoffs to be made in order to avoid "hard problems" that are still very prevalent. I'll be happy to be proven wrong :)
- dahauns 9y ago
  But how is that a problem of SPAs in general? This sounds more like a problem of using Firebase for prototyping.
  - bloudermilk 9y ago
    Firebase is a solution, not the problem. The problems are: * How do you allow users to continue using your SPA without a network connection? * How do you enable snappy and responsive UIs when the network is slow? * How do you synchronize state between client/server? These are just some of the "hard problems" that you'll face building an SPA. Firebase has its own solutions but many other tradeoffs. All I'm saying is that we don't have hardened open source solutions for these problems yet, in the same way that we have Rails/.Net Core MVC/Django for traditional websites.
    - mason55 9y ago
      > How do you allow users to continue using your SPA without a network connection? How do you do this with a traditional web site/app? > How do you enable snappy and responsive UIs when the network is slow? How do you do this with a traditional web site/app? > How do you synchronize state between client/server? At worst you do it just like a traditional web site/app True, these are all problems that you deal with when building a single-page app, but the worst case scenario is that you end up with some of the same problems as traditional web sites. None of these are new problems that are introduced by the fact that you're building an SPA. The new problems that SPAs introduce are things like history/back button breaking and how do you let users bookmark things or share deep links.
Scarbutt 9y ago
I'm struggling with this (SPA vs no SPA), and think you are stating the obvious: overall experience the end customer is going to need and expect. data analysis, frequent order entry, or highly dynamic UX The hard part is, how do you measure that? obviously some web apps need highly dynamic UX, a spreadsheet, some not, a blog, choosing between these two is easy. But most web apps sit somewhere in the middle, I don't know the answer, but for example, how much will github users benefit from the experience of a SPA?
- ljoshua 9y ago
  GitHub actually straddles the line a little bit. You'll note that when browsing around through folders in a repo on GitHub that you get the faux loading indicator along the top, and then it shows the contents you're navigating to. Same with switching between code and issues, for example. But switch to a different repo and you get a full page refresh. For my company's product, we're much more on the side of a traditional server-side app, because users will send off a batch of information (their customers to open a line of communication with), and then wait for the responses to roll in. But the dashboard page where we show responses is a partial-SPA, similar to GitHub: new responses are loaded asynchronously, and you will soon be able to switch to different views of the data without a reload. It's a good balance for our application. I realize it's not answering your question about how to measure it, but hopefully it provides some anecdotes.
tarsinge 9y ago
> Migrating from a desktop-based application to a web version? That desktop version was likely extremely responsive, and full page loads may feel like a step backward. I'm working in this space of migrating existing desktop apps and what I've seen is that most of the SPA are so heavy that they end up feeling sluggish and that paradoxically server-side apps can feel more responsive and snappy to end-users.
- thirdsun 9y ago
  Particularly if you consider a fast server-side app combined with perceived performance enhancements like Turbolinks. I know it didn't have the most popular start, but these days Turbolinks is rock solid and basically removes page reloads with a single line of JavaScript. It's an effortless improvement.
mattmanser 9y ago
I use Trello, Asana and Toggl, all single page apps (all fairly "trivial" in my book). In all of them, every now and again something will go wrong. Like yesterday, I was trying to replace a project on a task in Toggl and it kept reverting back. In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. Asana's just super slowwwwwwww. Trello has wildly inconsistent UI, some places saves on edit, some you need to click a save button. And given these are all well funded apps with good dev teams, doing extremely simple apps, it shows just how hard it is to get SPA right and I don't really think the difference is shrinking much at all. And I think this professionally too, a previous contractor turned part of the SaaS I'm working on at the moment into a SPA, and frankly, it's a nightmare (doesn't help it's durandal). They're so inflexible and so brittle. That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it.
- RussianCow 9y ago
  > In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. > That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it. Okay, I'll bite: What would have been the alternative in these cases? Having each action submit a form POST to refresh the entire page, like in the 90s? Then you wouldn't have been able to click it multiple times in the first place, because each one would have caused a page refresh. Or are you saying that they could have implemented it in JavaScript without implementing an entire SPA? In which case, the problem sounds like it's with the logic, and has little to do with the fact that it's a SPA, so you would have likely seen the same bug regardless. I totally understand all the frustrations people have with modern web apps, but your frustrations are with sloppy engineering, not with the idea of SPAs. I believe that, in most cases, the superior user experience that SPAs provide far outweighs the extra margin for error that comes with the territory.
  - 9y ago
rehemiau 9y ago
You can have similar, equivalent or even better user experience with server-side rendering and "javascript sprinkles" as in Turbolinks or Unpoly
smoe 9y ago
For me user expectations and whether you actually have the resources to produce a quality SPA are the biggest deciding factor. I don't have a strong opinion on SPAs in the general case, but I find it worrisome that it seems that SPAs are used as the default starting point without considering if the gains actually outweigh the cost. E.g At my last job I build the initial version of the application alone and although I'm pretty confident in my javascript skills I opted for a traditional server-side app too keep complexity and cost of maintenance as low as possible. Javascript was later added on top to make common interaction like sorting a table feel more responsive.
seba_dos1 9y ago
With most SPAs actually, as a user, I get less responsiveness due to overcomplicated UIs and memory leaks and, for instance while browsing in train, bad handling of poor connections. Facebook is a great example. It's almost impossible to have it opened for a long time in a few tabs simultaneously on a PC with 8 GB RAM. I often end up switching to m.facebook.com full page load version, cause it just works and it works fast.

purerandomness 9y ago

The problem is that most SPAs today are cargo-culting. They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) The ideal solution is a) minimize server roundtrips (<100ms) and b) reload parts of the site via AJAX where it makes sense. No need to shovel 7MB of JavaScript to the user.

bastawhiz 9y ago
> They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) I am not defending SPAs, but the points you've made are not indicative of SPAs, they're indicative of bad software. This problem existed before SPAs were a thing. Remember ASP.Net pages where the whole page is wrapped in a giant <form> and you couldn't use the back button most of the time? This problem also doesn't exist with properly built SPAs (e.g., by using <a> for links, using the history API correctly, and designing a sensible UX). And certainly, if your app is sending 7MB of JavaScript over the wire and it's not a video game, something is very wrong--SPA or not.
- reaperducer 9y ago
  I think SPAs get a bad reputation partially because they're trendy. Which means that inexperienced programmers flock to them and make them awful. I recently re-wrote an SPA from a previous dev into a regular set of query/response web pages. The SPA was 2,143K. The new set is 78K. A big part of that savings was because javascript is verboten for this project due to client hardware constraints. Yes, the previous dev was not the best in the world, but IME SPAs are always heavier than their response/query counterparts.
  - RussianCow 9y ago
    > SPAs are always heavier than their response/query counterparts Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.
    - reaperducer 9y ago
      > Heavier by what metric? I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month. Don't forget that plain query/response caches many static assets, too.
      - RussianCow 9y ago
        Sure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action. My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.
deleted 9y ago
[deleted]
amsheehan 9y ago
It sounds like your experience with SPA's is the exception, not the rule. I have never built a product or website using Angular or React that performs as poorly as you describe. - Routing modules in all the major frameworks interact directly with the history APIs, and are fast as f*. - There are only a handful of locations in the US where you can expect sub 100ms server round trips, usually they're around 300ms, but lets call that negligible. The real time spent waiting is usually if you're executing some complex database query over large data sets. This has nothing to do with SPA's vs Monoliths. Even so, it sounds like you just experienced bad code if you're waiting 6 seconds for a modal to open. Also...React with React DOM is only 10kb larger than jquery, and when gzipped it's only 37kb.
- craig1f 9y ago
  I was going to say the same thing you said. Angular/React routing, if done correctly, don't have those problems at all. If you let the SPA framework do your page-changing for you, open-in-tab and history still works. If you do amateur stuff like, you bind a button to a function, and the function does an document.location.href update, then you're going to have some weirdness. My biggest problem with SPA the last time I did it (a year ago) was optimizing it for search engine crawling.
  - amsheehan 9y ago
    Google's crawler at some point last year started indexing a really large mostly text based AngularJS app I built: https://www.fwdeveryone.com https://www.fwdeveryone.com Even if it didn't, headless chrome makes it really easy to pre-render content for web crawlers.
- TheRealDunkirk 9y ago
  One of my biggest problems in writing data-heavy web applications is that browsers seem to be really lousy at handling the data. In fact I have 2 applications in this boat. My queries run fast (couple/few hundred ms), but displaying 10's of MB of data, over 10's of thousands of rows of data, has been brutal for a browser. Trying various standard JS table widgets only made the problem worse, but I've discovered ag-grid (a paid JS table widget) which made this tolerable. It takes about 6 seconds to render my big page of data (which is actually on-par with a WinForms version of the system I wrote, using DevExpress). It sounds like you have the opposite problem, and I'm wondering how you display "large data sets" from "complex database queries" in sub-second renders in a browser. Incremental loading (like a news feed) won't really work here, because my users need to be able to sort and filter and rearrange the data as a whole. I guess I could "chunk" the data to be able to see it sooner, but it's still going to hold up the browser until it finishes. I've been looking for a better way for a long time.
mfrye0 9y ago
I agree with the others. Those are signs of bad software dev, not SPAs in particular. It's relatively easy now to break up the 7MB bundle into chunks and load on demand. So you get the benefit of both the fast, small initial load while other stuff loads in the background. Then I'm not sure what you're referring to on links and waiting for single interactions... With SPAs it's actually easier with the History API to create deeply nested stateful apps via the url / links. The confirmation modal, maybe your backend API sucks? Idk what your talking about with a 6s delay. On top of that, a pure SPA means you have a static website, which means you can host the whole app off something like S3. We save so much money by hosting our stuff statically.
xmlninja 9y ago
and with serviceworkers also breaking the refresh button :D
- arrty88 9y ago
  And intercepting URLs meant for the API server
intrasight 9y ago
I see no way that a properly built SPA could perform worse than a properly built server-rendered app form a network bandwidth perspective. JSON is always smaller than HTML.
heavenlyblue 9y ago
Let us all give some credit to LastPass, which manages to tick all of the points you're making here. More importantly, at the same time being a simple browser plugin.
sibeliuss 9y ago
In much modern software this is no longer an issue.
emodendroket 9y ago
> They break middle mouse button (or Ctrl-Click or whatever your favourite "open link in new tab" shortcut is on your Apple computer), at the same time break browser history, and at the same time make you wait for any single interaction you're doing (show spinning wheel for 6 seconds before opening a confirmation modal) > [...] > No need to shovel 7MB of JavaScript to the user. Well that's exactly the problem. Someone thinks they don't need all the "dead weight" of something like angular that solves every one of these problems and instead they do a half-assed version where it's all broken.
chrismorgan 9y ago
> minimize server roundtrips (<100ms) Not possible, because the speed of light is too low. I live in Australia. Servers tend to be in America. That hundred milliseconds has just been blown in latency, along with another hundred or two, depending on where in the US the servers happen to be. Take something like FastMail. Our servers are in the US, our team is mostly in AU. FastMail couldn’t be fast for us and many of our customers without being crafted in the SPA style—and even customers in the US benefit from its latency-compensation techniques, which reduce at least 50ms of delay (plus further page load, so call it 100ms at a minimum, but probably more like 250ms) to zero. Please don’t blame navigation-breaking on the SPA style of app; blame it on developer ignorance and occasionally laziness, with perhaps a side of unfortunate browser APIs (onclick is a poor event for this sort of thing for various reasons). And I assure you, simple JavaScript-enhanced pages manage to have at least as much problem with such links as SPAs do.

bloudermilk 9y ago

Being in the middle of a non-trivial SPA build, I can't agree that the technical difficulties are "solved", especially if you want to build on open source tech. Specifically, my project was prototyped in Firebase and for various reasons needs to be moved off. Now I'm left building a lot of plumbing that just isn't available outside of Firebase. In the end, our result will be less capable than the Firebase equivalent because we don't have time to engineer features like offline support and optimistic updates. There are a lot of tradeoffs to be made in order to avoid "hard problems" that are still very prevalent. I'll be happy to be proven wrong :)

dahauns 9y ago
But how is that a problem of SPAs in general? This sounds more like a problem of using Firebase for prototyping.
- bloudermilk 9y ago
  Firebase is a solution, not the problem. The problems are: * How do you allow users to continue using your SPA without a network connection? * How do you enable snappy and responsive UIs when the network is slow? * How do you synchronize state between client/server? These are just some of the "hard problems" that you'll face building an SPA. Firebase has its own solutions but many other tradeoffs. All I'm saying is that we don't have hardened open source solutions for these problems yet, in the same way that we have Rails/.Net Core MVC/Django for traditional websites.
  - mason55 9y ago
    > How do you allow users to continue using your SPA without a network connection? How do you do this with a traditional web site/app? > How do you enable snappy and responsive UIs when the network is slow? How do you do this with a traditional web site/app? > How do you synchronize state between client/server? At worst you do it just like a traditional web site/app True, these are all problems that you deal with when building a single-page app, but the worst case scenario is that you end up with some of the same problems as traditional web sites. None of these are new problems that are introduced by the fact that you're building an SPA. The new problems that SPAs introduce are things like history/back button breaking and how do you let users bookmark things or share deep links.

Scarbutt 9y ago

I'm struggling with this (SPA vs no SPA), and think you are stating the obvious: overall experience the end customer is going to need and expect. data analysis, frequent order entry, or highly dynamic UX The hard part is, how do you measure that? obviously some web apps need highly dynamic UX, a spreadsheet, some not, a blog, choosing between these two is easy. But most web apps sit somewhere in the middle, I don't know the answer, but for example, how much will github users benefit from the experience of a SPA?

ljoshua 9y ago
GitHub actually straddles the line a little bit. You'll note that when browsing around through folders in a repo on GitHub that you get the faux loading indicator along the top, and then it shows the contents you're navigating to. Same with switching between code and issues, for example. But switch to a different repo and you get a full page refresh. For my company's product, we're much more on the side of a traditional server-side app, because users will send off a batch of information (their customers to open a line of communication with), and then wait for the responses to roll in. But the dashboard page where we show responses is a partial-SPA, similar to GitHub: new responses are loaded asynchronously, and you will soon be able to switch to different views of the data without a reload. It's a good balance for our application. I realize it's not answering your question about how to measure it, but hopefully it provides some anecdotes.

tarsinge 9y ago

> Migrating from a desktop-based application to a web version? That desktop version was likely extremely responsive, and full page loads may feel like a step backward. I'm working in this space of migrating existing desktop apps and what I've seen is that most of the SPA are so heavy that they end up feeling sluggish and that paradoxically server-side apps can feel more responsive and snappy to end-users.

thirdsun 9y ago
Particularly if you consider a fast server-side app combined with perceived performance enhancements like Turbolinks. I know it didn't have the most popular start, but these days Turbolinks is rock solid and basically removes page reloads with a single line of JavaScript. It's an effortless improvement.

mattmanser 9y ago

I use Trello, Asana and Toggl, all single page apps (all fairly "trivial" in my book). In all of them, every now and again something will go wrong. Like yesterday, I was trying to replace a project on a task in Toggl and it kept reverting back. In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. Asana's just super slowwwwwwww. Trello has wildly inconsistent UI, some places saves on edit, some you need to click a save button. And given these are all well funded apps with good dev teams, doing extremely simple apps, it shows just how hard it is to get SPA right and I don't really think the difference is shrinking much at all. And I think this professionally too, a previous contractor turned part of the SaaS I'm working on at the moment into a SPA, and frankly, it's a nightmare (doesn't help it's durandal). They're so inflexible and so brittle. That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it.

RussianCow 9y ago
> In Toggle if you click start stop too quickly, to create a bunch of tasks to add, it doesn't register it. > That's SPAs for you, there's always something a bit wrong with them, they're extremely hard to get right, unlike traditional web apps. I often find myself rolling my eyes at YetAnotherPointlessSPA because there will always be something you have to fight with in it. Okay, I'll bite: What would have been the alternative in these cases? Having each action submit a form POST to refresh the entire page, like in the 90s? Then you wouldn't have been able to click it multiple times in the first place, because each one would have caused a page refresh. Or are you saying that they could have implemented it in JavaScript without implementing an entire SPA? In which case, the problem sounds like it's with the logic, and has little to do with the fact that it's a SPA, so you would have likely seen the same bug regardless. I totally understand all the frustrations people have with modern web apps, but your frustrations are with sloppy engineering, not with the idea of SPAs. I believe that, in most cases, the superior user experience that SPAs provide far outweighs the extra margin for error that comes with the territory.
- 9y ago

rehemiau 9y ago

You can have similar, equivalent or even better user experience with server-side rendering and "javascript sprinkles" as in Turbolinks or Unpoly

smoe 9y ago

For me user expectations and whether you actually have the resources to produce a quality SPA are the biggest deciding factor. I don't have a strong opinion on SPAs in the general case, but I find it worrisome that it seems that SPAs are used as the default starting point without considering if the gains actually outweigh the cost. E.g At my last job I build the initial version of the application alone and although I'm pretty confident in my javascript skills I opted for a traditional server-side app too keep complexity and cost of maintenance as low as possible. Javascript was later added on top to make common interaction like sorting a table feel more responsive.

seba_dos1 9y ago

With most SPAs actually, as a user, I get less responsiveness due to overcomplicated UIs and memory leaks and, for instance while browsing in train, bad handling of poor connections. Facebook is a great example. It's almost impossible to have it opened for a long time in a few tabs simultaneously on a PC with 8 GB RAM. I often end up switching to m.facebook.com full page load version, cause it just works and it works fast.