Hacker News new | ask | show | jobs
by bogidon 1714 days ago
I was surprised recently to learn about the back/forward cache (bfcache) [1], a common browser optimization that sort of does what you're describing but stores a more complete snapshot of the page, including the JS heap. I'm not sure if it's used in this new FF feature (the article doesn't give details about the mechanism of unloading).

However the bfcache unsurprisingly causes edge cases in JS-heavy pages/SPAs, and a prevailing solution [2] is for the page to force a reload when it is restored from this cache rather than explicitly handling those edge cases, nullifying the optimization.

[1] https://web.dev/bfcache/

[2] https://stackoverflow.com/a/13123626/14665201

3 comments

Only recently when I flew backwards through about 50 history steps (entirely different webpages) on my phone did I think more deeply about how impressive it was that it was so seamless.
Sadly lots of modern sites break it completely. I regularly have issues getting back to HN threads from websites, usually I end up at the HN home instead. Quite frustrating.
This should help, if it ever gets implemented: https://mozilla.crowdicity.com/post/728459
You can get this effect just by loading some document into the sidebar e.g. Show all bookmarks -> check Load this bookmark in the sidebar -> click that bookmark - I'm not sure how to do this easy in newer Firefox versions - with Browser Console maybe ?

If you want full Side by side browsing mode:

Some part of it is extremely easy - to display ALL tabs side by side:

  profile/chrome/userChrome.css :

  tabpanels {
    display: -moz-box !important;
  }

  tabpanels > notificationbox {
    -moz-box-flex: 1;
    border-width: 2px !important;
    border:solid #888;
  }
For the other part - to have only two panels, sibling is easy, otherwise you would need some JS to mark a tab as something like content-secondary and handle it (e.g. there was an extension last_selected_tab doing like this AFAIR) - as you have only:

  tabpanels > notificationbox > browser[type=content-primary]
(Just tested in Firefox 60.4.0.esr - newer versions may need some minor adjustements in CSS, toolkit.legacyUserProfileCustomizations.stylesheets preference set to true and probably some other fixes. In 2008 I had a Norton Commander 'clone' made in such incredibly simple way, ALL file and media formats preview (plugins), with a bit of custom code for nsIProtocolHandler, and nsIURIFixup fixes :) , kudos to archView extension by Pike/Solar Flare.)

R.I.P. Firefox.

I'm not convinced that you fully understood the point of this idea. The point is not just to just have any two web pages sitting next to each other (this is what your modifications do, right?), but more importantly the interaction between those pages.

I can already have two pages next to each other using Windows 10, by snapping two windows to the two sides of the screen. However, while that provides the correct visual shape, the user experience is completely different, as clicking a link in the left window will not open that page in the right window, replacing what's already there.

That's exactly how Load this bookmark in the sidebar works, you can have any document loaded into the sidebar, clicking any link on it will result in replacing document in the active tab (the only one visible).

https://mozilla.crowdicity.com/post/728459 says about Side by side browsing mode which I see as: with any two tabs, the content of the default active/content-primary tab will be replaced by link clicked on the other visible tab.

Nice idea.

Again something that used to work in Firefox.

FWIW: I use Tree Style Tabs (or Sideberry) to see why I arrived at a page. Not exactly the thing specified here but it works today.

> Again something that used to work in Firefox.

Yeeep, I used it for a while: https://archive.is/ovRDX (addon no longer exists, it broke with Firefox Quantum)

Yet another instance of SPAs pointlessly reinventing problems we solved decades ago.
Can you seriously not think of a single use case for SPAs?
There are a few. But they're good for a vastly smaller range of use cases than they're applied to.

You're writing Google Docs? Good for you, you can use an SPA. You're writing a social networking site? That should be a regular HTML page, with a sprinkling of JS. Blog? HTML page. Issue tracker? HTML page.

Every site I've used that's been plain HTML and CSS, with maybe minor supplements in Javascript, is much nicer to use than any SPA. People claim they load faster, but I've never experienced that in practice - a plain HTML page loads in milliseconds, but downloading a giant gzip of Javascript and waiting for it to make a zillion API calls takes seconds.

GMail's HTML-only interface fully loads and renders in ~630ms for me. The SPA version takes 11.69 seconds.

lite.cnn.com loads in 287ms. CNN.com takes 4.25 seconds.

thin.npr.org loads in 112ms. NPR.org takes 1.47 seconds.

Need I go on? Even for the lightest one, NPR, if you assume loading an article on the SPA version is instantaneous, you'd need to load 14 articles to make up for the slowness of the initial SPA load. The others are all much worse. And this is with an adblocker enabled - this will only get worse with one disabled.

Using SPAs when they aren't strictly necessary is a great way to shoot your site's performance, usability, and accessibility in the foot. You can fix the usability and accessibility problems, but you need to devote substantial engineering resources to doing so, and those are free if you just use the damn plain HTML.

To me a SPA is fine and usually preferable for anything I keep open for long periods of time. Sure, Gmail takes 10+ seconds to load. But I only load it once every few days at most because it stays open in my browser.
Cool. I don't feel like permanently dedicating a couple hundred megs of RAM to every site I need to use that decided to go chasing the latest counterproductive trend.
Single-page apps are forgivable for media oriented sites, so the video/music can keep playing as you navigate the site. in the past this was done with pop-up players and was generally messier, so I like SPAs for this.

Literally every other type of website on the planet should use traditional loading pages.

SPAs can easily handle routing via the history API, the problem is that companies haven’t migrated correctly.
It’s usually crappy though, like the URL and the history don’t accurate recreate the state of the app on refresh at all, or the history gets so clogged with every mutation of app state that the back button is effectively useless.
Twitter does it rather well, and that’s a site where it’s difficult and matters.
Again, that’s a development shortcoming, not a technical limitation. All of your concerns can show up in non-SPAs too.
Aside from cost-savings for the business I can’t really think of one.
This is not an angle I’ve heard before - how does an SPA save money?
It’s cheaper to build single page apps using web developers than to build and maintain multiple platform-specific native apps.
Not everything needs to be a native application, nor should it be. The vast majority of SaaS and such apps are SPA/equivalent and would NOT benefit from being yet-another-installable app.

Could you provide examples (not exceptions) maybe to support your PoV?

So the smaller-scale correlate would be that SPAs can make more sense for proof-of-concept or hobby-developed applications that need some cross-platform access.
Offload computations and rendering to the client
Which computations and what rendering? Very little money is saved from SSR vs CSR, rather the lower data transfer saves everyone money and time.
Opera (with the Presto engine) used to do this really well.