14 ms·

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, be

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big contributors to why I don't really like using Facebook or Twitter anymore. They murder my browser with megabytes worth of slow SPA crap to give me less than a few kilobytes of meaningful data (and/or people screaming at each other). Gmail now takes 10-20 seconds for me to load at this point, on my high end laptop. I just want to switch to HTML mode by default. I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design.

todd3834 8y ago
I don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t. Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience with a hybrid web app for mobile. While this is absolutely true, most people don’t pull it off so I get the critism.
- dhimes 8y ago
  Exactly. In many places slow networks are the problem, and quick spa's give a great user experience comparatively. The biggest lag in Google Docs is when it has to refresh from the server, and then it's like using windows on a 386.
- mycall 8y ago
  I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).
  - fauigerzigerk 8y ago
    I don't think PWA offline storage is anywhere reliable or predictable enough to be advertised as an actual benefit. It's essentially a fancy cache at this point: https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa https://developers.google.com/web/fundamentals/instant-and-o...
Twirrim 8y ago
With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to the "full" gmail experience. Added bonus: It gets out of the damn way so you can just do what you came there to do: write and read email.
- tyingq 8y ago
  There's a single file that's 584KB of javascript from hangouts.google.com in the "full experience" Gmail. Blocking that seems to help, a lot. I imagine there's probably some configuration to turn off hangouts that provides the same benefit.
  - s3graham 8y ago
    It's in Settings.
    - lucasverra 8y ago
      chat off ?
- hyperpape 8y ago
  Great example, because the basic HTML version doesn't support keyboard shortcuts, which makes it a huge step back for me. It's certainly possible to have a server rendered app that uses JS sparingly for interactive behavior, but it blows away a lot of the benefits once you're doing significant DOM-manipulation.
  - aaaaaaaaaaab 8y ago
    If only there was a way to support keyboard shortcuts via plain old HTML... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
beatgammit 8y ago
We had a very static product, and one of our devs decided to make more use of client-side rendering despite essentially being a set of unchanging forms. This quickly got out of hand, so we adopted a hybrid approach. I built out another product, which was much more dynamic and made sense as a SPA. However, having been bitten by the forced SPA, I decided to do as much static rendering as feasible, and I think that has made things a lot easier to develop and less buggy. Honestly, I agree that a SPA is usually a bad idea and prefer to have as much of the app be able static as possible since that simplifies things considerably. For example, slack could open a separate tab for settings (and perhaps chat history) and only have the chat parts as a SPA. It would make it slightly less fancy, but also probably much lighter on resources, faster to load, and easier to develop.
rhizome31 8y ago
Thank you for pointing the real issue with SPAs: they deliver awful user experience. It's quite telling how this fact is missing from the article and from most of the discussion here. We're a bunch of self-referential techies who've lost connection with reality.
- chrisco255 8y ago
  Yep. Millions of SPAs out in the wild and none of them are good. This whole thread is such a joke. It's a bunch of posturing and no data whatsoever from actual SPAs in the wild.
- chalupa-man 8y ago
  I couldn't disagree more. For anyone on a slower connection (I use a satellite connection that's 1 Mbps on a good day) a SPA is almost always a greatly superior user experience. A server-side rendered application is a blank white screen for roughly 50% of the time I'm using it. Even if a SPA takes longer to initially load, it's much nicer to keep the application actually onscreen while it's loading new content. Even if the SPA takes longer to load content it will often feel as if it's faster because you're looking at the application while it loads rather than staring at a blank screen for 5-10 seconds with every click. When people talk about SSR applications being a better user experience I always assume they're operating on first-world 10+ Mbps broadband connections or cellphones in developed cities, because the difference is night and day for those of us on slower. I also disagree with the idea that SPAs are pushed by developers who have lost touch. Clients frequently push for them and ask questions like "Twitter/Instagram/YouTube don't show these blank white pages after every click, why does my site? Can't you make it like YouTube?" Clients want to have them more than developers want to make them.
  - wolco 8y ago
    1 Mbps and each page is 5 seconds? It sounds like huge pages you are viewing
    - chalupa-man 8y ago
Fredej 8y ago
It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_. The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.
- mehrdadn 8y ago
  If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.
  - simooooo 8y ago
    10 core overclocked 4.6-4.7 i9 CPU. 400Mbit ethernet connection. Gmail still takes 6+ seconds
  - krferriter 8y ago
    Nah, just tested and mail.google.com took 23.3 seconds to load in Chrome and 30.2 seconds in Firefox. I have a 4-core 8-thread i7 and am on a 20Mbps internet line. It's the website, it isn't my computer.
    - mehrdadn 8y ago
      Can you try in Guest Mode (or Incognito but only if you've disabled extensions in it)? I'm guessing you either have (1) battery power or other cause of downclocking, (2) slow extensions, (3) disabled/small cache, (4) an old CPU (old gen i7 maybe?), or (5) a large distance between you and the server. I have a similar machine to yours that's 3+ GHz and it's consistently loading in less than 4 seconds when I'm on AC. (To be clear, I'm not excusing how slow their code is, just trying to help you save some time in the long run.)
    - chalupa-man 8y ago
      Is that from scratch? I'm using an i3 on a 1 Mbps satellite connection, and opening up Gmail now (having opened it earlier today), it was 0.27s until DOMContentLoaded and I could interact with it. It continued asynchronously loading stuff in the background but from my POV it loaded in 1/3 of a second, which in Chrome is faster than the app opens on my iPhone 7. I have disabled the Hangouts/Chat feature in settings which apparently makes a big difference.
dkarl 8y ago
I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. It was nice and would still be nice if browser caching meant a site still worked well over a bad connection. But you can be browsing around a "static" site and hit the back button and be stuck staring at an empty or partly rendered page waiting for your flaky connection to load the page. SPAs handle that situation better even for sites that are theoretically not suited for SPAs. The simple principle of doing your best to display the data you've already fetched is extremely refreshing compared to supposedly "document-oriented" sites, which typically take the opposite approach -- we showed you this page fifteen seconds ago, but we can't show it to you again until we exchange a few megabytes of data with headquarters. And now we can't show you the other page, either. Just be patient. If it's really that important you should have taken a screenshot, mmmkay? (Slow-loading web sites are the main reason my not-so-tech-savvy family members, who are very stubborn and selective about learning anything, are all adept at taking screenshots on their phones. When it comes to information they might need later, they take screenshots, because you can't just leave a page open and trust it to be there when you need it. You might accidentally trigger some navigation and then who knows how long it will take to get back to the information they need, if it's even possible.) Browser caching should theoretically let a document-oriented web site work smoothly over a flaky connection, as long as you stick to the pages you've already viewed, right? But how often does it help even a little bit? Maybe SPAs will eventually be just as broken, but right now it seems damned cool that they make a good-faith effort to show me stuff.
- nicoburns 8y ago
  You could also run server-rendering with a service worker. There's nothing about a service worker that means it only works with SPAs. It basically just gives you control over caching behaviour...
  - callalex 8y ago
    You can also control caching behavior by just setting the headers correctly in the first place. I think the takeaway here is that sometimes SPA frameworks make the behavior “just work” in more cases when the developer doesn’t put any thought into correct cache handling.
chrisco255 8y ago
Facebook is not a SPA. It is SSR PHP.
bhauer 8y ago
> I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. But even Slack is subject to the same clunky and slow user experience you're describing because its entire user interface is an SPA. In my opinion, a site for the SPA hall of shame is the Starbucks.com progressive web app [1]. My grievances about it are legion, but to name a few: * It's agonizing slow, both on the client and server. The server is an egregiously-slow GraphQL endpoint. * It hasn't been tested on anything but Chrome, as far as I can tell. It flat out refuses to work in Firefox or Edge, even fresh installations I've put into VMs. These browsers may not be mainstream targets, but odds are you would have no trouble supporting them if you weren't using these unnecessarily complicated client-side frameworks for placing a coffee order. * It routinely messes up state management. I've had it forget my selected store location; fail to add items to the shopping cart; fail to submit orders; fail to apply star points (coupons); get into a weird state where it thinks I have a coupon when the server disagrees; etc. It's constantly introducing new and imaginative ways to fail. * If you use it for months, white-page failure modes are surprisingly common. Every time I use it, I wish that Starbucks had made just a plain responsive web app with simple server-side rendering. It would be fast and probably work better as a way to place orders. [1] https://app.starbucks.com/ https://app.starbucks.com/
- chalupa-man 8y ago
  The Starbucks app in Edge is _miles_ faster than Amazon.com or eBay.com for me on my slow satellite connection. I think this is one often underlooked feature of SPAs. SSR stuff is a blank white screen about 50% of the time for people on slow connections, SPAs have a slower initial load and then from then on are either faster or _feel_ faster because they don't go completely blank for 5+ seconds every time you click something. Even a slowly-loading SPA feels better than any SSR site for that reason, IMO.
  - pjmlp 8y ago
    You can do the same with hybrid approach, using service workers doesn't imply doing an SPA.
enraged_camel 8y ago
>>Agree with the article. I find server views to be substantially easier to work with. When working with static pages that have minimal interactivity, sure. Just render the HTML and send it to the client. Once you get past that though, if you try to stick with SSR you'll end up with incredibly difficult-to-decipher mish-mash of if/then statements, most likely with lots of jQuery or equivalent thrown in. I've debugged such templates and they are universally messy, not just because they are usually written by backend engineers who have a minimal understanding of/appreciation for JavaScript, but also because keeping track of state with such templates is really inefficient and frustrating.
Const-me 8y ago
SPAs are especially bad on mobile. When browser receives HTML, either complete pages or updated fragments of them, it only needs to parse HTML, style/layout, and render. These steps are relatively fast, especially rendering (usually GPU does that). When browser received JSON or XML instead, it needs to do all that as well (parsing is slightly simpler), but also it needs to make visual elements out of the data. Takes a lot of processing and therefore electricity: JavaScript is not particularly fast, the code size is often not insignificant i.e. takes time to download and parse the code, and the runtime is essentially single threaded (for any given page).
int_19h 8y ago
As a user, I miss pre-SPA days. For all the negatives that SPAs were supposed to solve, there was one thing about those apps, and it's that they were predictable. These days, you never know whether you can even open a link in a new tab, or bookmark it, for that matter.

todd3834 8y ago

I don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t. Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience with a hybrid web app for mobile. While this is absolutely true, most people don’t pull it off so I get the critism.

dhimes 8y ago
Exactly. In many places slow networks are the problem, and quick spa's give a great user experience comparatively. The biggest lag in Google Docs is when it has to refresh from the server, and then it's like using windows on a 386.
mycall 8y ago
I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).
- fauigerzigerk 8y ago
  I don't think PWA offline storage is anywhere reliable or predictable enough to be advertised as an actual benefit. It's essentially a fancy cache at this point: https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa https://developers.google.com/web/fundamentals/instant-and-o...

Twirrim 8y ago

With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to the "full" gmail experience. Added bonus: It gets out of the damn way so you can just do what you came there to do: write and read email.

tyingq 8y ago
There's a single file that's 584KB of javascript from hangouts.google.com in the "full experience" Gmail. Blocking that seems to help, a lot. I imagine there's probably some configuration to turn off hangouts that provides the same benefit.
- s3graham 8y ago
  It's in Settings.
  - lucasverra 8y ago
    chat off ?
hyperpape 8y ago
Great example, because the basic HTML version doesn't support keyboard shortcuts, which makes it a huge step back for me. It's certainly possible to have a server rendered app that uses JS sparingly for interactive behavior, but it blows away a lot of the benefits once you're doing significant DOM-manipulation.
- aaaaaaaaaaab 8y ago
  If only there was a way to support keyboard shortcuts via plain old HTML... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

beatgammit 8y ago

We had a very static product, and one of our devs decided to make more use of client-side rendering despite essentially being a set of unchanging forms. This quickly got out of hand, so we adopted a hybrid approach. I built out another product, which was much more dynamic and made sense as a SPA. However, having been bitten by the forced SPA, I decided to do as much static rendering as feasible, and I think that has made things a lot easier to develop and less buggy. Honestly, I agree that a SPA is usually a bad idea and prefer to have as much of the app be able static as possible since that simplifies things considerably. For example, slack could open a separate tab for settings (and perhaps chat history) and only have the chat parts as a SPA. It would make it slightly less fancy, but also probably much lighter on resources, faster to load, and easier to develop.

rhizome31 8y ago

Thank you for pointing the real issue with SPAs: they deliver awful user experience. It's quite telling how this fact is missing from the article and from most of the discussion here. We're a bunch of self-referential techies who've lost connection with reality.

chrisco255 8y ago
Yep. Millions of SPAs out in the wild and none of them are good. This whole thread is such a joke. It's a bunch of posturing and no data whatsoever from actual SPAs in the wild.
chalupa-man 8y ago
I couldn't disagree more. For anyone on a slower connection (I use a satellite connection that's 1 Mbps on a good day) a SPA is almost always a greatly superior user experience. A server-side rendered application is a blank white screen for roughly 50% of the time I'm using it. Even if a SPA takes longer to initially load, it's much nicer to keep the application actually onscreen while it's loading new content. Even if the SPA takes longer to load content it will often feel as if it's faster because you're looking at the application while it loads rather than staring at a blank screen for 5-10 seconds with every click. When people talk about SSR applications being a better user experience I always assume they're operating on first-world 10+ Mbps broadband connections or cellphones in developed cities, because the difference is night and day for those of us on slower. I also disagree with the idea that SPAs are pushed by developers who have lost touch. Clients frequently push for them and ask questions like "Twitter/Instagram/YouTube don't show these blank white pages after every click, why does my site? Can't you make it like YouTube?" Clients want to have them more than developers want to make them.
- wolco 8y ago
  1 Mbps and each page is 5 seconds? It sounds like huge pages you are viewing
  - chalupa-man 8y ago

Fredej 8y ago

It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_. The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.

mehrdadn 8y ago
If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.
- simooooo 8y ago
  10 core overclocked 4.6-4.7 i9 CPU. 400Mbit ethernet connection. Gmail still takes 6+ seconds
- krferriter 8y ago
  Nah, just tested and mail.google.com took 23.3 seconds to load in Chrome and 30.2 seconds in Firefox. I have a 4-core 8-thread i7 and am on a 20Mbps internet line. It's the website, it isn't my computer.
  - mehrdadn 8y ago
    Can you try in Guest Mode (or Incognito but only if you've disabled extensions in it)? I'm guessing you either have (1) battery power or other cause of downclocking, (2) slow extensions, (3) disabled/small cache, (4) an old CPU (old gen i7 maybe?), or (5) a large distance between you and the server. I have a similar machine to yours that's 3+ GHz and it's consistently loading in less than 4 seconds when I'm on AC. (To be clear, I'm not excusing how slow their code is, just trying to help you save some time in the long run.)
  - chalupa-man 8y ago
    Is that from scratch? I'm using an i3 on a 1 Mbps satellite connection, and opening up Gmail now (having opened it earlier today), it was 0.27s until DOMContentLoaded and I could interact with it. It continued asynchronously loading stuff in the background but from my POV it loaded in 1/3 of a second, which in Chrome is faster than the app opens on my iPhone 7. I have disabled the Hangouts/Chat feature in settings which apparently makes a big difference.

dkarl 8y ago

I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. It was nice and would still be nice if browser caching meant a site still worked well over a bad connection. But you can be browsing around a "static" site and hit the back button and be stuck staring at an empty or partly rendered page waiting for your flaky connection to load the page. SPAs handle that situation better even for sites that are theoretically not suited for SPAs. The simple principle of doing your best to display the data you've already fetched is extremely refreshing compared to supposedly "document-oriented" sites, which typically take the opposite approach -- we showed you this page fifteen seconds ago, but we can't show it to you again until we exchange a few megabytes of data with headquarters. And now we can't show you the other page, either. Just be patient. If it's really that important you should have taken a screenshot, mmmkay? (Slow-loading web sites are the main reason my not-so-tech-savvy family members, who are very stubborn and selective about learning anything, are all adept at taking screenshots on their phones. When it comes to information they might need later, they take screenshots, because you can't just leave a page open and trust it to be there when you need it. You might accidentally trigger some navigation and then who knows how long it will take to get back to the information they need, if it's even possible.) Browser caching should theoretically let a document-oriented web site work smoothly over a flaky connection, as long as you stick to the pages you've already viewed, right? But how often does it help even a little bit? Maybe SPAs will eventually be just as broken, but right now it seems damned cool that they make a good-faith effort to show me stuff.

nicoburns 8y ago
You could also run server-rendering with a service worker. There's nothing about a service worker that means it only works with SPAs. It basically just gives you control over caching behaviour...
- callalex 8y ago
  You can also control caching behavior by just setting the headers correctly in the first place. I think the takeaway here is that sometimes SPA frameworks make the behavior “just work” in more cases when the developer doesn’t put any thought into correct cache handling.

chrisco255 8y ago

Facebook is not a SPA. It is SSR PHP.

bhauer 8y ago

> I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. But even Slack is subject to the same clunky and slow user experience you're describing because its entire user interface is an SPA. In my opinion, a site for the SPA hall of shame is the Starbucks.com progressive web app [1]. My grievances about it are legion, but to name a few: * It's agonizing slow, both on the client and server. The server is an egregiously-slow GraphQL endpoint. * It hasn't been tested on anything but Chrome, as far as I can tell. It flat out refuses to work in Firefox or Edge, even fresh installations I've put into VMs. These browsers may not be mainstream targets, but odds are you would have no trouble supporting them if you weren't using these unnecessarily complicated client-side frameworks for placing a coffee order. * It routinely messes up state management. I've had it forget my selected store location; fail to add items to the shopping cart; fail to submit orders; fail to apply star points (coupons); get into a weird state where it thinks I have a coupon when the server disagrees; etc. It's constantly introducing new and imaginative ways to fail. * If you use it for months, white-page failure modes are surprisingly common. Every time I use it, I wish that Starbucks had made just a plain responsive web app with simple server-side rendering. It would be fast and probably work better as a way to place orders. [1] https://app.starbucks.com/ https://app.starbucks.com/

chalupa-man 8y ago
The Starbucks app in Edge is _miles_ faster than Amazon.com or eBay.com for me on my slow satellite connection. I think this is one often underlooked feature of SPAs. SSR stuff is a blank white screen about 50% of the time for people on slow connections, SPAs have a slower initial load and then from then on are either faster or _feel_ faster because they don't go completely blank for 5+ seconds every time you click something. Even a slowly-loading SPA feels better than any SSR site for that reason, IMO.
- pjmlp 8y ago
  You can do the same with hybrid approach, using service workers doesn't imply doing an SPA.

enraged_camel 8y ago

>>Agree with the article. I find server views to be substantially easier to work with. When working with static pages that have minimal interactivity, sure. Just render the HTML and send it to the client. Once you get past that though, if you try to stick with SSR you'll end up with incredibly difficult-to-decipher mish-mash of if/then statements, most likely with lots of jQuery or equivalent thrown in. I've debugged such templates and they are universally messy, not just because they are usually written by backend engineers who have a minimal understanding of/appreciation for JavaScript, but also because keeping track of state with such templates is really inefficient and frustrating.

Const-me 8y ago

SPAs are especially bad on mobile. When browser receives HTML, either complete pages or updated fragments of them, it only needs to parse HTML, style/layout, and render. These steps are relatively fast, especially rendering (usually GPU does that). When browser received JSON or XML instead, it needs to do all that as well (parsing is slightly simpler), but also it needs to make visual elements out of the data. Takes a lot of processing and therefore electricity: JavaScript is not particularly fast, the code size is often not insignificant i.e. takes time to download and parse the code, and the runtime is essentially single threaded (for any given page).

int_19h 8y ago

As a user, I miss pre-SPA days. For all the negatives that SPAs were supposed to solve, there was one thing about those apps, and it's that they were predictable. These days, you never know whether you can even open a link in a new tab, or bookmark it, for that matter.