5 ms·

You can emulate that by opening tabs only in new tabs. It works fine for <10 tabs.

exikyut 6y ago
It also works fine for >10 tabs. For example, my last browsing session only became unusable (16GB RAM + 8GB swap 100% used, machine OOMing renderers, system freezing for about a minute or two at a time) after I reached about 1,081 tabs. :( I find it a huge pity that tab serialization never went anywhere :'( https://developers.google.com/web/updates/2015/09/tab-discarding#future_improvements_the_tab_serializer https://developers.google.com/web/updates/2015/09/tab-discar... it would basically have let you have 10,000 tabs open
- mkl 6y ago
  The Marvellous Suspender on Chrome and Auto Tab Discard on Firefox will let you scale to that (there are other options too). I have something like 7-8000 tabs open counting all my browsers and devices. 1081 tabs is no big deal - I have single windows with more than that, and everything is snappy.
  - exikyut 6y ago
    Okay, 8000 is admirable and scary. :D I used TGS a few years ago, back when I was still limping along on a 32-bit machine. Generally either the browser process would hit ~3GB VIRT and very abruptly terminate, or (back when Chrome would lump all of the open tabs owned by an extension into a single renderer) the renderer would simply thrash so much (because suspending the current tab, or switching between suspended tabs, invoked the mostly-swapped-to-disk renderer process) the browser would effectively become unusable, eg, 30 second stalls switching between tabs or 2 minute stalls opening new tabs. Chrome's built-in tab discarding actually closes the renderer process, which solves all of those design fails, but then there's the browser process to contend with; a few days ago the browser process was basically sitting on about 2.5-3GB RAM. Apparently the data structures associated with remembering/showing a few tabs require a lot of memory...?! The only annoyance with TGS and tab discarding without proper tab serialization/dehydration is page state is thrown out the window. Scrolled 350 pages deep in a tumblr blog or pinterest feed? Permanently gone on restore. I actually actively avoid sites with infinite scrolling where I can ._. Of course, the real problem is that browsers don't provide good simple mnemonics for "I want to come back to this later" that effectively translate from "this is open and currently a thing" to something that works for squishy brains and finite hardware. Chrome's new reading list feature (which doesn't quite work in Dev yet, clicking the menu item randomly decided to start SEGV/MAPADDRing the other day, glad I wasn't using it lol) will be interesting to watch, but looks about as potent as the tag-less bookmark system, sadly. This has actually been a problem for some years... https://news.ycombinator.com/item?id=18325632 https://news.ycombinator.com/item?id=18325632, https://news.ycombinator.com/item?id=16375865 https://news.ycombinator.com/item?id=16375865, https://news.ycombinator.com/item?id=13537600 https://news.ycombinator.com/item?id=13537600 make a few references (^F) to 'The Great Suspender' which I've mostly summarized here. (I accidentally locked `i336_` a few years ago - and I also had the English-language equivalent of "more lines of code = more better" back then too, so yeah, if you do have a look I can recommend ^F.) I've been making "I need to fix this with an extension" noises to myself for years, but the gigantic annoyance is that, at the end of the day, whatever fun system I come up with on desktop will never seamlessly integrate on mobile because of course I can't run extensions there. What on earth is the point of having an external brain if I can't access it without needing to invoke a 30-step process that I have to fully context switch away from whatever I'm doing to perform?!?
  - EGreg 6y ago
    Here is a counterpoint, and I encourage anyone here to tell me where I am wrong: Why have tabs at all? Are you really needing to save the state of the vast majority documents and their JS? The suspender says no. Why not consider all windows in which you aren’t typing a document to have a very small state, such as scroll position. And even the ones where you ARE typing a document can save the form fields in an encrypted file. No, what you basically are saving is the already loaded DOM. And what if browsers took a radical approach to it as they are doing to third party cookie and... removed everything except maybe the latest 10 documents. Yes the latest accessed 10 documents would be actually in buffers. The rest would be UNLOADED and browsers would save the state of their textboxes or scrollig, and restore it once the “same” elements appeared. But mostly they’d enable this new API to save state beforeunload and restore it, and that’s it. It’s not even a new API, you should already be playing nice by using this event and not storing some crazy state. Sure, infinite scrolling thingies would be broken, and the caches of many images would be purged but so what. Users can MANUALLY mark sites where they really NEED the caches to grow so large. Instead, index the text on ALL sites and give the user a way to search their history of all their titles and bodies of all sites, as easily as they search google. Every time the user opens a new tab, what they’re really saying is “bookmark this current site”. But why should they even make those decisions to bookmark. You should be storing are their history locally (and making it searcheable and making encypted backups of it across all their browser sessions on all their personal devices). That’s what the user really WANTS to do. It’s the same idea as “gmail search” had when Google first launched GMail versus ordering all your mail in hierarchical folders. Think about it!
    - rakoo 6y ago
      I've been dreaming of a system like this myself. Every time a page is loaded it would be written on-disk in a format that the browser can easily re-render, and can be nicely displayed by any third-party app. So you'd essentially have a local save of each and every single page you've ever visited; no more "this worked when I last visited it" because the browser could switch to this backup in case upstream is down. Also when you close a tab or switch to another webpage you don't really "close" the website, you just put it back to storage so it can be loaded at a later time. It seems to me using a browser should be closer to using a text editor, where you have one resource you're interacting with at the moment and others are in the background ready to replace the current one, but in a manner that loading them is a benign operation. Tabs, as you say, essentially mean "I want to keep this page in an easy-to-reach place". If you look at gmail in comparison, it's exactly the same as keeping emails in the Inbox: they are important (for varying values of important) and there is something to do regarding them, so keep them there. It's not exactly the same as starring messages because starring is opt-in (needs manual action to mark importance) while the Inbox is opt-out (needs manual action to unmark importance). It seems many people have been using tabs this way and close them when work is done so we can transcribe GTD to browsers: when a tab is open it means I need to do something with it, when I'm done close it. Regarding the previous paragraph it shouldn't be harder to load a file from upstream than from a tab. For this to work there needs to be a very strong search and history side. For me the best representation of browsing is a directed graph: nodes are websites and edges are clicks with a timestamp. There can be multiple edges between the same 2 nodes, if I clicked multiple times. The problem is such a graph is not only hard to represent efficiently, it's even harder to use it to search in history. But the good side is that as long as this data structure is used, you can represent any history (flat, threaded, ...) as you want.
- agumonkey 6y ago
  I forgot the actual number but I remember that above 700~ tabs firefox started to lag, usable but slow. It was funny to hit a structural limit like that and kudos on the devs to allow such a tab-hoarding behavior. I'd love to work on a quick tab group freeze feature. (a 2d graph to order / select and then stash the tabs dom without external resources maybe) ?
  - exikyut 6y ago
    As part of its WebExtensions feature-parity, FF supports tab.discard() :D so you could totally viably implement this however you wanted. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/discard https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
IanS5 6y ago
This + tree style tabs works pretty well for me. It’s kind of a clunky system. I tend to end up with a _lot_ more tabs than I need but it’s nice that the hierarchy in tree tabs shows which site a new tab was opened from, even if I’m not using the original site.

It also works fine for >10 tabs. For example, my last browsing session only became unusable (16GB RAM + 8GB swap 100% used, machine OOMing renderers, system freezing for about a minute or two at a time) after I reached about 1,081 tabs. :( I find it a huge pity that tab serialization never went anywhere :'( https://developers.google.com/web/updates/2015/09/tab-discarding#future_improvements_the_tab_serializer https://developers.google.com/web/updates/2015/09/tab-discar... it would basically have let you have 10,000 tabs open

mkl 6y ago
The Marvellous Suspender on Chrome and Auto Tab Discard on Firefox will let you scale to that (there are other options too). I have something like 7-8000 tabs open counting all my browsers and devices. 1081 tabs is no big deal - I have single windows with more than that, and everything is snappy.
- exikyut 6y ago
  Okay, 8000 is admirable and scary. :D I used TGS a few years ago, back when I was still limping along on a 32-bit machine. Generally either the browser process would hit ~3GB VIRT and very abruptly terminate, or (back when Chrome would lump all of the open tabs owned by an extension into a single renderer) the renderer would simply thrash so much (because suspending the current tab, or switching between suspended tabs, invoked the mostly-swapped-to-disk renderer process) the browser would effectively become unusable, eg, 30 second stalls switching between tabs or 2 minute stalls opening new tabs. Chrome's built-in tab discarding actually closes the renderer process, which solves all of those design fails, but then there's the browser process to contend with; a few days ago the browser process was basically sitting on about 2.5-3GB RAM. Apparently the data structures associated with remembering/showing a few tabs require a lot of memory...?! The only annoyance with TGS and tab discarding without proper tab serialization/dehydration is page state is thrown out the window. Scrolled 350 pages deep in a tumblr blog or pinterest feed? Permanently gone on restore. I actually actively avoid sites with infinite scrolling where I can ._. Of course, the real problem is that browsers don't provide good simple mnemonics for "I want to come back to this later" that effectively translate from "this is open and currently a thing" to something that works for squishy brains and finite hardware. Chrome's new reading list feature (which doesn't quite work in Dev yet, clicking the menu item randomly decided to start SEGV/MAPADDRing the other day, glad I wasn't using it lol) will be interesting to watch, but looks about as potent as the tag-less bookmark system, sadly. This has actually been a problem for some years... https://news.ycombinator.com/item?id=18325632 https://news.ycombinator.com/item?id=18325632, https://news.ycombinator.com/item?id=16375865 https://news.ycombinator.com/item?id=16375865, https://news.ycombinator.com/item?id=13537600 https://news.ycombinator.com/item?id=13537600 make a few references (^F) to 'The Great Suspender' which I've mostly summarized here. (I accidentally locked `i336_` a few years ago - and I also had the English-language equivalent of "more lines of code = more better" back then too, so yeah, if you do have a look I can recommend ^F.) I've been making "I need to fix this with an extension" noises to myself for years, but the gigantic annoyance is that, at the end of the day, whatever fun system I come up with on desktop will never seamlessly integrate on mobile because of course I can't run extensions there. What on earth is the point of having an external brain if I can't access it without needing to invoke a 30-step process that I have to fully context switch away from whatever I'm doing to perform?!?
- EGreg 6y ago
  Here is a counterpoint, and I encourage anyone here to tell me where I am wrong: Why have tabs at all? Are you really needing to save the state of the vast majority documents and their JS? The suspender says no. Why not consider all windows in which you aren’t typing a document to have a very small state, such as scroll position. And even the ones where you ARE typing a document can save the form fields in an encrypted file. No, what you basically are saving is the already loaded DOM. And what if browsers took a radical approach to it as they are doing to third party cookie and... removed everything except maybe the latest 10 documents. Yes the latest accessed 10 documents would be actually in buffers. The rest would be UNLOADED and browsers would save the state of their textboxes or scrollig, and restore it once the “same” elements appeared. But mostly they’d enable this new API to save state beforeunload and restore it, and that’s it. It’s not even a new API, you should already be playing nice by using this event and not storing some crazy state. Sure, infinite scrolling thingies would be broken, and the caches of many images would be purged but so what. Users can MANUALLY mark sites where they really NEED the caches to grow so large. Instead, index the text on ALL sites and give the user a way to search their history of all their titles and bodies of all sites, as easily as they search google. Every time the user opens a new tab, what they’re really saying is “bookmark this current site”. But why should they even make those decisions to bookmark. You should be storing are their history locally (and making it searcheable and making encypted backups of it across all their browser sessions on all their personal devices). That’s what the user really WANTS to do. It’s the same idea as “gmail search” had when Google first launched GMail versus ordering all your mail in hierarchical folders. Think about it!
  - rakoo 6y ago
    I've been dreaming of a system like this myself. Every time a page is loaded it would be written on-disk in a format that the browser can easily re-render, and can be nicely displayed by any third-party app. So you'd essentially have a local save of each and every single page you've ever visited; no more "this worked when I last visited it" because the browser could switch to this backup in case upstream is down. Also when you close a tab or switch to another webpage you don't really "close" the website, you just put it back to storage so it can be loaded at a later time. It seems to me using a browser should be closer to using a text editor, where you have one resource you're interacting with at the moment and others are in the background ready to replace the current one, but in a manner that loading them is a benign operation. Tabs, as you say, essentially mean "I want to keep this page in an easy-to-reach place". If you look at gmail in comparison, it's exactly the same as keeping emails in the Inbox: they are important (for varying values of important) and there is something to do regarding them, so keep them there. It's not exactly the same as starring messages because starring is opt-in (needs manual action to mark importance) while the Inbox is opt-out (needs manual action to unmark importance). It seems many people have been using tabs this way and close them when work is done so we can transcribe GTD to browsers: when a tab is open it means I need to do something with it, when I'm done close it. Regarding the previous paragraph it shouldn't be harder to load a file from upstream than from a tab. For this to work there needs to be a very strong search and history side. For me the best representation of browsing is a directed graph: nodes are websites and edges are clicks with a timestamp. There can be multiple edges between the same 2 nodes, if I clicked multiple times. The problem is such a graph is not only hard to represent efficiently, it's even harder to use it to search in history. But the good side is that as long as this data structure is used, you can represent any history (flat, threaded, ...) as you want.
agumonkey 6y ago
I forgot the actual number but I remember that above 700~ tabs firefox started to lag, usable but slow. It was funny to hit a structural limit like that and kudos on the devs to allow such a tab-hoarding behavior. I'd love to work on a quick tab group freeze feature. (a 2d graph to order / select and then stash the tabs dom without external resources maybe) ?
- exikyut 6y ago
  As part of its WebExtensions feature-parity, FF supports tab.discard() :D so you could totally viably implement this however you wanted. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/discard https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

IanS5 6y ago

This + tree style tabs works pretty well for me. It’s kind of a clunky system. I tend to end up with a _lot_ more tabs than I need but it’s nice that the hierarchy in tree tabs shows which site a new tab was opened from, even if I’m not using the original site.