Feature 2 is really useful. When I land on a technical article I know chances are there will be a nice HN discussion, that may sometimes even refute the main point of the article.
Feature 1 is IMO less useful. It just suggests that people are bad at window management. We didn't like overlapping windows and finding them, so we created tabs inside windows. Then we wanted to see two things at the same time, so we created split views inside tabs (Chrome and Firefox both had this). With a good window manager neither would be necessary. Sadly the community prefers to solve this at the application level rather than the desktop level; I'm currently using Forge (https://github.com/forge-ext/forge) but sadly it's becoming unmaintained.
> Sadly the community prefers to solve this at the application level rather than the desktop level
Not only does it "prefer", they actually enforce this. I haven't found any sensible way of completely disabling tabs in either Firefox or Chromium. FF has some janky extension that kinda sorta works, but it's a hideous workaround consisting of hiding the tab bar and automatically detaching most new tabs. With the rest of the tabs, you're SOL. Haven't found anything at all for chrome.
I very much prefer managing windows with my my... window manager. Which works the same way with all applications.
I think there are, see the other comment about tree-style tabs or similar for Firefox. I can absolutely see the value in that and I don't argue for that option to be removed or otherwise degraded.
But that's not the point. I'm not against applications offering those possibilities, and when I have to use Windows for work, I'm happy browsers have them.
My point is that they shouldn't force users into this way of working. Browsers already support multiple windows. Why can't I just disable the whole tab feature if I don't care for it? A while ago, when tabs were still new, you had to actively opt in. The default was a new window for everything. Now this option is completely gone for some reason.
Not sure if I agree about using windows instead of tabs. I have hundreds of tabs open, and dozens loaded, at any moment. I'm sure that it's possible to manage all the context with separate windows via a window manager, but it would have to be a REALLY good window manager to be able to provide equivalent features of tree style tabs and separate panes and whatever else that something like Sidebery provides, and it is always easier for each application developer to implement tabs suitable for that application's requirements.
I think one of the point of the author is making might also be that a window manager could do just more, like managing windows as tabs as well.
So that any application could have tabs, if the desktop manager would allow you to group windows as such. Same with showing a split view within such a tab as well.
I think I agree with that. I could imaging that the browser containers of tabs would make a ton of sense if I could make a container of windows handled as tabs across different applications at the window manager level.
Ideally the manager would have windows and containers. Containers can be nested and can be floating windows, splits and tabs. There is no reason why tabs inside a window should belong to one application.
All that being said, navigation in such a structure would be a mess that would need a lot of learning. Also I’m sure a window manager like this already exists somewhere.
A system wide search within tabs would help more maybe.
> So that any application could have tabs, if the desktop manager would allow you to group windows as such. Same with showing a split view within such a tab as well.
Not only that, but you could actually mix "tabs" from separate applications!
Windows (IE) tried to give WM visibility into tabs long ago, but this quickly revealed a problem: if tabs are now also separate windows, they enter the Alt+Tab ring, and suddenly you're Alt+Tabbing between 5 applications and dozens of open tabs. N=1, as a tab hoader, I absolutely hated it (it also made Alt+Tab itself very slow to show and cycle).
The general problem is that having WM handle in-app tabs means the WM has to support every single hare-brained idea about meaning and role of tabs that app developers invent, which is infeasible. Even with browsers - until recently, you had like just two types of tabs: regular tabs, and porn-mode (er, "private browsing") tabs. Then came "account containers" or whatever it was in Firefox. Then came tab groups, reading groups, and tons of other nonsense.
OTOH, I can dream of an ideal world where the OS manages all tabs for all apps via combination of Sidebery (better "tree style tabs") and a tiling WM.
I use Sway and happily manage my terminal windows using its tabs and splits. I can mix other "graphical" apps with the terminals or move them to another screen, all with the same keybindings. I agree, though, that I wouldn't want to replace my Sidebery vertical tabs with this setup, but I ultimately don't see why equivalent functionality couldn't be implemented inside the window manager in some alternate universe.
There are sadly hardly any WMs now with tabs, so having them support tree style tabs as well doesn't look too realistic.
Do you really need hundreds of open tabs though? To me this suggests a workflow issue rather than a tab management problem.
I only keep tabs open that I'm actively working on right now (or am imminently about to switch back to). I regularly close tabs (and windows for that matter) that are only open because I forgot about them, or that I might use again but not until hours or days later. If I need them later I just open them again.
For me, having hundreds of things open at once just creates clutter that makes it harder to focus.
Using Sidebery panes and treestyle tabs makes it really easy to organize your tabs, I have a tree with all my tasks with relevant documentation or subtasks under each task, and I have a separate panes with all the documentation I refer constantly at the top and everything I'm reading right now at the bottom. I definitely have a lot of tabs I opened to read and never closed, but that doesn't matter since everything is arranged in an approximation of a 2D space, I still know where to look for something specific. I'm sure you feel this is weird because you've never used a tree-style tab manager, but personally I can't go back to a regular browsing setup.
I think I'd still maintain a conceptual difference between sites that are source material (e.g. documentation) or apps (e.g. Google Translate), and those that are just for browsing (e.g. news, blogs) and are more ephemeral (I may read it now, or keep it for later, but either way I'll be done with it).
You'd open a PDF, Word document, or app in its own window which you'd manage with your DE / WM. To me it feels like a bit of an anti-pattern to have some of this type of content handled by my WM, and others by a tree-style tab manager, when they are the same "type" of content. I want to be able to press the same keyboard shortcut to switch to my documentation whether it happens to be a PDF or a website.
On the other hand, there isn't anything else really equivalent to browsing-type content, so the tree-style tab manger feels more natural to me there.
I've actually created a Chrome extension for [feature 2] ages ago (mostly for myself). If the current URL is on HN - it shows it (with the number of upvotes)
I got used to opening a new tab for things to read before RSS first invented. So I guess it became a 2nd nature. I also think it is better to read the article first before going to the comments session. So Feature 1 isn't that useful.
For feature 2 it is great. Although thinking about it I kind wish this could be done without browser extension but an actual site feature by HN.
Feature 1 is IMO less useful. It just suggests that people are bad at window management. We didn't like overlapping windows and finding them, so we created tabs inside windows. Then we wanted to see two things at the same time, so we created split views inside tabs (Chrome and Firefox both had this). With a good window manager neither would be necessary. Sadly the community prefers to solve this at the application level rather than the desktop level; I'm currently using Forge (https://github.com/forge-ext/forge) but sadly it's becoming unmaintained.