Hacker News Reader

Comment by kyledrake | Hacker News Reader

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.

View on HN

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.

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.

It's in Settings.

chat off ?

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.

If only there was a way to support keyboard shortcuts via plain old HTML...

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Aren't those inconsistent across platforms? Also you must use the "super" key/combo, and there's only one. Not to mention the internationalization concerns.

Good luck implementing 10% of the keyboard shortcuts gmail uses: https://support.google.com/mail/answer/6594?co=GENIE.Platfor...

The accesskey feature is usually discouraged because it can break screen readers and other accessibility tools.

Instead of trying to quickly click the link, it's easier to just turn JS off and refresh GMail. You'll be prompted to either turn JS on or switch to Basic HTML. (You can make it the default after that, as described.)

I did this a while back, and the only real issue I've had with it is that there doesn't seem to be an equivalent to the "Check mail now" action for imported email accounts. (The 'refresh' link annoyingly does not trigger this action.)

There's also a hidden 'mobile webapp' version: https://mail.google.com/mail/mu/mp/167/?mui=ca#tl/Inbox

I got a popup saying the offline app is going away with a link to "setup" the new gmail app for offline use. Unfortunately the new gmail app for offline use does not support Firefox.

>Offline unavailable.

>The browser you are using is missing some features required to enable offline. To enable offline, you must use Chrome with version 61 or higher.

There is a direct link to access basic HTML version of GMail : http://mail.google.com/mail/h/

Ahh nice, thanks!

That is a blast from the past. I love it.

hm. So.

The SPA gmail platform has an _infuriatingly long_ loading screen, but once loaded the click-> to reading email _is_ quicker.

I suspect there is allot that can (and should) be done to optimize the SPA version.

But man, the html version is speedy.

I barely use email, but I'm going to put the html-only version into my rotation and see which one I gravitate toward.

Thanks for the tip! I realized this existed but didn't clue in to the fact that it could be set default. I've done so now, and already feel the absurd javascript weight lifting...

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.

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...

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.

> 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/

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.

You can do the same with hybrid approach, using service workers doesn't imply doing an SPA.

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.

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.

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.

I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).

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-o...

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.

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.

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.

1 Mbps and each page is 5 seconds? It sounds like huge pages you are viewing

Well satellite has bad latency on top of that. Not especially large pages, I'd say. eBay, IMDb, Wikipedia.

1 Mbps * 5 = 5 Mb = 625 KB

That's not huge at all, you can barely fit a few pictures into that. The page we are on require 100 KB, the page it link require 300 KB, and both aren't big and have no image to show.

I try to keep my pages down under 50k, 30k or less 80% of the time. Perhaps it's me but I think anything over 999k is insane unless it's spa or a page full of graphing function. My expectation that others are doing the same might be incorrect.

> Thank you for pointing the real issue with SPAs: they deliver awful user experience.

I don't think I could disagree more with a statement, but the way I browse the internet might be different from the way you browse the internet. SPAs, when done correctly, create rich and interactive GUIs that absolutely bring browsing websites into a entirely new territory for UX. There's a reason why webapps have taken over, including desktop apps.

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.

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.

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.

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.)

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.

Okay I can't believe that either! You're really talking about full Gmail loading in 1/3 of a second? That sounds impossible if we're loading the same Gmail...

Yeah, it's pretty crazy that there would be such a huge difference. Turning off Hangouts and using uBlock Origin might make a big difference because that's all I've really done to modify it.

Would you mind measuring how long it takes on a vanilla browser (e.g. guest mode of Chrome) without anything being turned off?

Takes 2.5 seconds with Chrome on my Quad Core i7 (laptop)

Takes 2 seconds for me on a 2018 MBP

But the reason Gmail is so slow isn't because they've made it a SPA. It's because they made it a shitty SPA. They use nonstandard web technologies that work like ass. It was also a SPA before the new redesign and it worked pretty well.

>>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.

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.

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).

Facebook is not a SPA. It is SSR PHP.

Reply on news.ycombinator.com