4 ms·

Personally, as a customer, the "new" way of doing it is irritating, usually somewhat broken, slow and usually unreliable. I wouldn't be surprised if non-techie

Personally, as a customer, the "new" way of doing it is irritating, usually somewhat broken, slow and usually unreliable. I wouldn't be surprised if non-techies couldn't give a toss if you're using a traditional MPA with a sprinkling of ajax for the bits that really need to be responsive or a total SPA. I'm beginning to suspect the only people who want a SPA are the programmers. Has anyone even got any proof that a SPA is better than a MPA in terms of customer satisfaction? It seems to have all originated from a technical need rather than a customer need. I still prefer doing most thing server-side and then sending snippets of html to update the bits on the page that need updating, occasionally using client-side view templates/JSON, depending on the case.

toddmorey 8y ago
I think it depends on use case, of course. Gmail, Google Slides, or Figma would be poor MPAs I’d say.
scrollaway 8y ago
Good SPAs are fantastic. It's just a lot of people suck when implementing them. The Serverless documentation, an SPA, blew my mind in terms of how fast and clean it is: https://serverless.com/framework/docs/ https://serverless.com/framework/docs/
- sametmax 8y ago
  Just tested it on an edge connection in the German country side: Hacker news: - first load: 6 seconds - next loads: 3.5 seconds Serverless: - first load: 26 seconds - next loads: 7.5 seconds
- JoachimSchipper 8y ago
  Really? Randomly clicking e.g. Providers > Azure, I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time. (Compare e.g. https://docs.python.org/3/library/weakref.html. https://docs.python.org/3/library/weakref.html.) (Single Page Applications arguably have their place. I'm just really confused why you think this is a particularly good example.)
  - scrollaway 8y ago
    On my awful connection, serverless is as fast as HN on new pageloads, and faster than HN when navigating to cached pages. HN is my baseline for how fast a site should be.
    - OJFord 8y ago
      HN is typically how I determine no connection vs. crap connection.
    - OJFord 8y ago
      HN is typically how I determine no connection vs. crap connection. I could `ping` I suppose, but in these circumstances I'm in the browser having just signed in to the crap/not connecting AP.
  - ademarre 8y ago
    > "I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time." You can test the difference yourself by toggling JavaScript in your browser.
- acdha 8y ago
  It takes ~2.5 seconds to load and the first ~1.5 of that won't display anything because it has to process ~600KB of JavaScript and CSS before it can render a few hundred words of text: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f4c3c8dd148eb52d8/ http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... The only reason that's faster as an SPA than static HTML is because they've disabled caching for static resources: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f4c3c8dd148eb52d8/3/performance_optimization/ http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... If the site was optimized it'd perform very similarly either way since there's none of the complex logic or interactions where an SPA really starts to shine and the content is very cache-friendly.
  - scrollaway 8y ago
    Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). You're optimizing against browsing the site. Have you tried browsing the site...?
    - sametmax 8y ago
      When I look for an information I usually google it, then click on the first link, get what I need, and close the site. It's especially true for a documentation website. Even if I browse a little, it will be swift clicks on 3 to 4 pages to get to what I'm looking for. The enormous initial loading time is far from amortized. Bottom line, if your site is just displaying text like a doc, a wiki, etc., making it an SPA is ridiculous. Just use old school techs, and offer a zip for download.
    - acdha 8y ago
      > Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out the runtime overhead. For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly. Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection. 1. http://www.webpagetest.org/result/180628_CF_db268e65de67002e8451445bdeab8cc9/2/details/ http://www.webpagetest.org/result/180628_CF_db268e65de67002e...
- drdaeman 8y ago
  YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff. Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things. Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me. Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.
  - scrollaway 8y ago
    All a symptom of the browser being a document-first platform that's been reused to be app-centric. I agree with you it's a bummer that these things are getting reimplemented on top of a platform that already offers them, but the way the platform offers them hasn't changed much since the 90s and hasn't kept up with what apps need. The core issue being that you have no way of statefully going from one page to the next. State only exists within the page you're on. Hence the rise of SPAs.
danpalmer 8y ago
I think with server side pages, you’re limited in how much you can mess it up, but very limited in how far you can take the experience. With single page apps you have to do a lot more to get back to what server side pages give you, basic browser functionality, and as a result you can end up with worse experiences. However if you’ve got the development resources it can be a far better experience and enable applications that just wouldn’t be usable or even possible on server side rendered pages.
- deleted 8y ago
  [deleted]
- mattmanser 8y ago
  Name me a single thing you can't do in a SPA that you can't do in a MPA with a bit of Ajax? The only thing I can conceivably think of is an offline app, but they're so rediculously niche.
batteryhorse 8y ago
As a programmer, I absolutely hate SPA's. I've never used a good SPA, they're always slow, and behave strangely. I much prefer the traditional way. It's the same with Electron apps. I think it's just web developers who like SPA's
- collyw 8y ago
  Agreed, logic usually ends up scattered between the front end and the back end. You need to start using JavaScript (I much prefer Python). The Angular app I ma maintaining just now would be so much simpler if it was server side rendered, instead we have an ajax call to load contents of every dropdown....

toddmorey 8y ago

I think it depends on use case, of course. Gmail, Google Slides, or Figma would be poor MPAs I’d say.

scrollaway 8y ago

Good SPAs are fantastic. It's just a lot of people suck when implementing them. The Serverless documentation, an SPA, blew my mind in terms of how fast and clean it is: https://serverless.com/framework/docs/ https://serverless.com/framework/docs/

sametmax 8y ago
Just tested it on an edge connection in the German country side: Hacker news: - first load: 6 seconds - next loads: 3.5 seconds Serverless: - first load: 26 seconds - next loads: 7.5 seconds
JoachimSchipper 8y ago
Really? Randomly clicking e.g. Providers > Azure, I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time. (Compare e.g. https://docs.python.org/3/library/weakref.html. https://docs.python.org/3/library/weakref.html.) (Single Page Applications arguably have their place. I'm just really confused why you think this is a particularly good example.)
- scrollaway 8y ago
  On my awful connection, serverless is as fast as HN on new pageloads, and faster than HN when navigating to cached pages. HN is my baseline for how fast a site should be.
  - OJFord 8y ago
    HN is typically how I determine no connection vs. crap connection.
  - OJFord 8y ago
    HN is typically how I determine no connection vs. crap connection. I could `ping` I suppose, but in these circumstances I'm in the browser having just signed in to the crap/not connecting AP.
- ademarre 8y ago
  > "I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time." You can test the difference yourself by toggling JavaScript in your browser.
acdha 8y ago
It takes ~2.5 seconds to load and the first ~1.5 of that won't display anything because it has to process ~600KB of JavaScript and CSS before it can render a few hundred words of text: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f4c3c8dd148eb52d8/ http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... The only reason that's faster as an SPA than static HTML is because they've disabled caching for static resources: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f4c3c8dd148eb52d8/3/performance_optimization/ http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... If the site was optimized it'd perform very similarly either way since there's none of the complex logic or interactions where an SPA really starts to shine and the content is very cache-friendly.
- scrollaway 8y ago
  Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). You're optimizing against browsing the site. Have you tried browsing the site...?
  - sametmax 8y ago
    When I look for an information I usually google it, then click on the first link, get what I need, and close the site. It's especially true for a documentation website. Even if I browse a little, it will be swift clicks on 3 to 4 pages to get to what I'm looking for. The enormous initial loading time is far from amortized. Bottom line, if your site is just displaying text like a doc, a wiki, etc., making it an SPA is ridiculous. Just use old school techs, and offer a zip for download.
  - acdha 8y ago
    > Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out the runtime overhead. For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly. Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection. 1. http://www.webpagetest.org/result/180628_CF_db268e65de67002e8451445bdeab8cc9/2/details/ http://www.webpagetest.org/result/180628_CF_db268e65de67002e...
drdaeman 8y ago
YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff. Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things. Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me. Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.
- scrollaway 8y ago
  All a symptom of the browser being a document-first platform that's been reused to be app-centric. I agree with you it's a bummer that these things are getting reimplemented on top of a platform that already offers them, but the way the platform offers them hasn't changed much since the 90s and hasn't kept up with what apps need. The core issue being that you have no way of statefully going from one page to the next. State only exists within the page you're on. Hence the rise of SPAs.

danpalmer 8y ago

I think with server side pages, you’re limited in how much you can mess it up, but very limited in how far you can take the experience. With single page apps you have to do a lot more to get back to what server side pages give you, basic browser functionality, and as a result you can end up with worse experiences. However if you’ve got the development resources it can be a far better experience and enable applications that just wouldn’t be usable or even possible on server side rendered pages.

deleted 8y ago
[deleted]
mattmanser 8y ago
Name me a single thing you can't do in a SPA that you can't do in a MPA with a bit of Ajax? The only thing I can conceivably think of is an offline app, but they're so rediculously niche.

batteryhorse 8y ago

As a programmer, I absolutely hate SPA's. I've never used a good SPA, they're always slow, and behave strangely. I much prefer the traditional way. It's the same with Electron apps. I think it's just web developers who like SPA's

collyw 8y ago
Agreed, logic usually ends up scattered between the front end and the back end. You need to start using JavaScript (I much prefer Python). The Angular app I ma maintaining just now would be so much simpler if it was server side rendered, instead we have an ajax call to load contents of every dropdown....