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

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.

Yes, I know in some theoretical scenario where the developers do everything exactly right none of these problems would exist. My argument is not that it's intrinsic to the technology, my argument is that my _experience_ is that the vast majority of (needless) SPAs are like this. Whether it's because frontend developers get all hot to re-implement standard browser features themself using redux, because the tooling is bad, or what, I can't tell you.

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?

> The vast majority of SaaS and such apps are SPA/equivalent and would NOT benefit from being yet-another-installable app.

Could you provide few examples of such apps that would not benefit from being native?

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.

> Very little money is saved from SSR vs CSR

this seems counterintuitive.

SSR means most processing happens on big iron inside a dc, this has to be more efficient than each user buying a new machine every few years just to have that peak js-perf needed for the latest frameworks.

Opera (with the Presto engine) used to do this really well.

My number one annoyance (with Firefox and Auto-Discard extension) is when I open back my tab and get a redirection to some login page. Login, get sent to homepage. Back button sends me to login page. No way to get back to the actual tab I'd left there...

That tab is then lost forever, unless I can find it in the history from whenever I had opened the tab.

Two web apps I use every day at work have this behaviour when I look away and my session times out. Both of them break web expectations by having the same generic URL for every page. I leave half a dozen tabs open, come back later or the next day and if I'm not careful to login again in a new tab before I refresh them, they're lost. It's the kind of thing which makes me convinced the developers never use their own system, never sit with real users, and think a lot less of the vendor even though I have no power to influence the decision to renew them or not.

I think one problem of JavaScript routing is that it needs two groups of people to communicate for it to work: the ops people configuring nginx/CDN need to talk with the JavaScript devs making the SPA. Worse, if they get it wrong it will break in subtle ways (e.g. appear to work unless you reload of share a direct link).

A recipe for disaster.

That happens because someone use js to redirect and didn't use history.replace in the js redirection page to remove the redirection page from history. End up leaving the redirection page in the history. And cause the back button broken.

Long-click the back button to get a list of previous pages in the tab.

Right click for people with real mice

I have a real mouse. I didn't know that until yet!

The long click has still the advantage that you don't need to click more than once: You can just hold the button, mouse-over the wanted entry, and than release the button triggering navigation to the history entry currently under the cursor.

You can do the same thing with right click :)

It's not there. It's like the redirect replaces the history entry.

This! I feel like Back used to get instant results all the time, and now it's almost always a big delay, which is a huge pain -- plus, it loses your position on infiniscroll and other dark patterns.

Part of it is caused by site coding, but part of it is browsers treating "back" as some species of new page load/arrival/selection.

And I know it's possible to get us back to the old days! The functionality I want is almost exactly what I would (already) get if I just opened every link in a new tab and switched back instead of triggering the back button.

(Which, incidentally, is what many sites recommend doing now for that very reason -- at least reddit.)

Back basically works like it always did on static sites. Blame the fashion for single-page apps and endless scrolling for it being broken.

No. Blame browsers for not being user-agents any more. Browsers can cache websites, but only if websites tell them to do so. Users are never asked ( there is no setting ). And since websites usually don't want to be cached (for too long) browsers have to reload them ( which takes time ). Thats the reason Back-buttons are slow. Thats ( one of ) the reason(s) everybody has 100+ tabs open.

SPAs and infinite scroll are (maybe) bad, but not the cause of this problem.

Some infinite scroll-type pages consume ridiculous amounts of memory the further you scroll (and if the page disallows direct navigation to a point in history and you need to find something older that you didn't save a direct link for, you've got no choice but to scroll, and scroll, and scroll…), so limitless caching isn't quite the right answer, either…

AFAIK whether page will be restored or reloaded depends on its cache headers. I remember breaking back button in one of my projects, because users asked for it, as they expected fresh data for some reason. It was not SPA, just old server rendered website, so I disabled caching via response headers and it worked.

Hm I'm going to see if there's a setting to override a site's choice of that header.

I found no setting. Im using an addon "ModHeader" to set the response header (for all websites) "Expires" to a date far in the future. It worked in the past, but doesn't work at the moment. Have to debug it.

Wouldn't you need to modify Cache-Control?

>>If there is a Cache-Control header with the max-age or s-maxage directive in the response, the Expires header is ignored.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex...

Edit: Also I'm not sure that is the relevant one? Reddit sets Cache-Control to "private, max-age=3600 [seconds]", but it definitely reloads the content if I back up in less than an hour.

Would love to know if this is practically possible. I use Auto tab discard [] to save memory, but I'd much prefer the ability to retrieve an html file than having to reload the page. A simple way to save that html file of current view when bookmarking a page would also be a useful addition in a similar vein.

[] https://addons.mozilla.org/en-GB/firefox/addon/auto-tab-disc...

Doesn't OS swap covers much of your need ?

Not when the need is to increase battery life (reduce cpu usage). Having a couple of youtube/reddit tabs open in the background can really impact battery life I've found.

This is my pet peeve. Most of the time I notice this when im interested in a reddit thread that's deleted and I lose the ability to review it.

This, plus any sort of live data (think stock market, tweet feed, etc.), plus any sort of form input (input fields should survive since like Firefox 3.5, but then people discovered you could also dynamically build forms with Javascript and the rest is history).

Chromium has "Paint Preview" (aka "Freeze-Dried Tabs") [0] which does something similar. Basically it consists of a capture (Skia Picture and links in a proto), compositing the capture into bitmap tiles, and then playback to play the page using the native UI.

I think it's only supported on Chrome for Android right now.

[0] https://chromium.googlesource.com/chromium/src/+/refs/heads/...

SingleFile [1] is supposed to be able to do that (more or less) by enabling these settings in the options page:

- User Interface > open saved page in a new tab

- User Interface > auto-close the tab after the page is saved

- Auto-save > auto-save on tab discard

Then you have to select in the context menu of the extension: Auto-save > Auto-save all tabs (or Auto-save unpinned tabs)

[1] https://github.com/gildas-lormeau/SingleFile

I think this gets to the root of why you're leaving a tab open. You might have non-persisted state in the page, hence you don't want to close it.

Non-persistent state in a page, or in the tab context itself --- how did I get here, what was I doing, what's the history for this particular session, what other tabs do I have open around this, etc.

None of the usual suspects generally suggested as alternatives to leaving tabs open really addresses any of this. For all the research into browsers and their use, the concept of user state and workflow is utterly ignored.

I can’t speak for Gecko or Blink/Chromium, but I don’t think this would be difficult to implement in a WebKit browser as long as some limits are involved.

Just save the tab’s contents in a webarchive file, then when restoring load that webarchive and inject some JavaScript that makes any kind of interaction aside from scrolling load the page’s live counterpart (with a confirmation prompt, perhaps).

This would also come with the advantage of the cached version showing up in browser history for “free”, so if you inadvertently go to the live page undoing it is as easy as hitting the back button, and if you decide you want to preserve the cached state indefinitely all the browser has to do is copy the webarchive file out of temporary storage to wherever the user indicates.

Can you contact me? Would like to explore implementing this idea in Orion with you.

Sounds like you want WebMemex, specifically the freeze-dry functionality: https://github.com/WebMemex

It'd have to be more than just the HTML, it'd need to be everything the page used. Basically, all the data you'd get by clicking the "download HAR" button in the DevTools Network panel. Including some special sauce on top to replay any XHRs (assuming you want to get to the last state by replaying... otherwise the JS page state would need to serialized some how)

Couldn't the browser just dump the current DOM and JS state onto a disk? Treat it like a computer hibernating.

Yeah it would be cool if it saved the state of the page until you manually refreshed it.

Unless I'm missing something, I want a "Save DOM as file"

I know this doesn't help with the cache part, but if you pin a tab, it used to prevent it from getting unloaded. Might help if a particular tab is important to you and they still honour that.

Firefox dont loses state or information when unloads a tab.

Of course it does. It tries saving the current scroll position and form data that might be present, and a few other bits of information, but for any even-just moderately complex JS-powered page this can easily break down unless the page in question has been properly coded to save and restore its state across a tab closing and re-opening (and a lot of pages haven't been properly coded in that regard).

Just try using any infinite scroll-type page – unless the pages saves the scroll position itself (to name one popular page, Instagram doesn't for example), all your scroll progress is lost once the tab is unloaded.

This is precisely what Edge does on Android, not sure if it's the same behaviour in Chrome on Android.

This is what I'm planning for my browser; the web engine will serialize a continuation of sorts that you can load into new instances and mutate in eg cli tools or another computer. Still chugging through basic features like js for now though.

One way to fix this is to buy more memory (if possible). Then your tabs will be much less likely to be unloaded.