Tabs Were a Mistake

Tabs are everywhere. Every modern web browser. Photoshop. Code editors. Even the file explorer. What started as a pragmatic workaround has quietly become one of the most unquestioned interface patterns in modern computing.

And it's a mistake that needs correcting ASAP, and if you disagree with me you are a bad engineer/UX designer.

The Original Promise of Tabs

Tabs solve a simple problem: they let you multitask and organize multiple contexts inside a single application window. Instead of juggling ten windows, you get one window with ten "things" inside it. Cleaner. Simpler. Supposedly more productive.

But ask what tabs really are.

They're windows; pretending not to be windows.

They fragment state, hide context, consume vertical space, complicate shortcuts, and push responsibility for system-level concerns onto individual applications. Tabs don't reduce complexity; they relocate it, usually to the worst possible layer.

Tabs Are Application-Level Window Managers

Operating systems already have a service whose entire job is to manage running processes: rendering, memory, networking, scheduling, isolation. That service is the OS.

Tabs duplicate that responsibility at the application level.

Every browser implements its own tab lifecycle, grouping, crash recovery, pinning, memory eviction, keyboard shortcuts, drag-and-drop rules, and edge cases. Photoshop does the same. File Explorer does the same. Every app ships its own miniature, inconsistent, and inferior window manager.

This is architectural debt, stupid, expensive and it is absolutely insane that even fucking Windows, the operating system named: WINDOWS, does not even really care about the fundemental design it is named after anymore.

Also MacOS fails often with consistency in this UX. Browsers tabs should be in their own window there aswell.

Browsers Should Not Have Tabs

Browsers are the most obvious example.

A "tab" is already its own execution context: its own memory, JavaScript runtime, network activity, and often its own process. The only reason it lives inside a shared window is historical UI convention.

Instead:

• Each browser window should represent a single page.
• Each window should be a sandboxed instance.
• Shared resources (cache, networking, GPU pipelines, shared state) should be managed by a background OS service, not by the browser UI.

If resources are currently shared only because tabs exist inside the same window, that is not a defense of tabs. It is a failure of the operating system abstraction.

Your operating system should make it very easy to see what windows you have open using alt+tab for example (or cmd+tab on MacOS).

It should automatically group windows beloning to the same application together. Your OS should utilize the taskbar / tray space more efficiently.

When Windows Should Share State

Not every application wants or can fully isolate windows. Some workflows require shared data, shared state, or shared processing across multiple windows by design.

That's fine, and it should be easy.

Operating-system-provided frameworks should make cross-window data sharing explicit, efficient, and safe. But when windows are not sandboxed, that fact should be clearly indicated.

For example:

• A visual indicator in the window title bar (an icon, outline, or badge)
• A disabled-by-default marker only visible to administrators/root
• A clear flag in task switchers or start menus indicating sandboxing state

Users and system operators should be able to see whether a window is isolated or sharing internals with others. Today, this distinction is invisible, and that's a problem.

The Massive Efficiency Gains We're Ignoring

If data sharing, state synchronization, and background processing across windows were standardized at the OS level, we would save massively on:

• Crashes (one window failing shouldn't cascade)
• Accessibility (consistent focus, navigation, screen reader behavior)
• Memory usage (shared resources without shared UI hacks)
• CPU utilization (no redundant preloading or background polling)

Right now, each application reinvents these mechanisms poorly. Tabs actively encourage waste: preloading content "just in case," running hidden logic, keeping inactive UI trees alive, and maintaining internal routing systems that duplicate what the OS already does better.

A design specification that explicitly discourages or forbids tabs would force software to become simpler, more robust, and more efficient by default.

When Tabs Are Okay

They aren't.

Use dropdowns. Use chips. Use drawers. Use submenus. Use pagination. Use separate pages. Use anything else.

Preloading data for tabs people rarely click is pure waste. The technical complexity of dynamically loading, unloading, and synchronizing tab UIs is often unjustified compared to simply opening another window or navigating to another view.

The moment you introduce a tab system, you've almost certainly designed the UI incorrectly.

Tabs Are a Category Error

What qualifies as a "tab" becomes blurry very quickly, just like asking whether a frozen bedsheet mounted in a doorframe counts as a door. It is, but it isn't. You get it.

We all intuitively understand what tabs are. We also understand that some things look like tabs but aren't. This article is not about those edge cases.

We're talking about actual tabs: persistent UI elements that multiplex independent contexts inside a single window.

Those should be standardized.

And then removed.

Alt+Tab Is the Real Interface

Instead of embedding complexity into applications, operating systems should expand their window-management primitives:

• Group all windows of the same application in Alt+Tab
• Allow instant navigation into and out of those groups
• One shortcut to tile all windows of an app
• One shortcut to move an entire app to another desktop
• Predictable, global behavior across all software

This scales. Tabs do not.

A Call to OS Vendors

Windows and macOS should provide:

• A default multi-window-first application framework
• Explicit sandboxing and sharing models
• Visual indicators for window isolation state
• Standardized inter-window interaction
• Strong guidance, if not outright prohibition, against tabs

If the platform does this well, applications become lighter, more consistent, and easier to reason about. UX improves not because apps are clever, but because the foundation is sound.

Tabs Were a Transitional Hack

Tabs made sense when window managers were primitive and hardware was constrained. That era is over.

Today, tabs are legacy UI debt masquerading as productivity. They complicate software, waste resources, and hold back better system-level design.

They were a workaround.

They outlived their usefulness.

And it's time to get rid of them.

One Last Thing

One last thing I want to add to this rant/share of thought.

Microsoft needs to make a decision any decision and actually commit to it.

Microsoft should lean into what the name originally meant: applications living in their own windows. Window-first design. Individual application instances. Clear boundaries. Strong OS-level window management. No ambiguity.

If Microsoft wants to go all-in on new UI paradigms, AI-first workflows, tablet-style surfaces, and whatever comes next, then do that in a new OS. Fork Windows and call it Microsoft OS. Drop the name, the baggage, and the expectation of visual continuity/backwards compatibility.

What doesn’t work, or at least is, let’s put it lightly, very much so anything but optimal, is what we have now.

This endless back-and-forth of new UI layered on top of old UI, layered on top of ancient UI is inefficient, incoherent, and exhausting. Either clean up the old stuff and move forward, or keep it intentionally old and stable. Don’t pretend you’re doing both.

Windows is called Windows for a reason. Because application instances were supposed to live in their own windows.

If Microsoft decides in the future to enforce and encourage application-window-first UX design, then it should also really stick to it. They should stop redesigning the same surfaces every year while claiming backward compatibility as the reason nothing ever truly improves.

And if backward compatibility really is non-negotiable: if we must keep decades-old dialogs alive because some enterprise workflow depends on a prehistoric script triggering a specific keyboard shortcut in a forgotten modal... then fine. Preserve it. Freeze it. Treat it as legacy on purpose.

But don’t keep oscillating between “modern” and “legacy” forever.

Either:

• be a clean, modern, window-first operating system,
• or be a stable, unapologetically old one.

Just pick a direction and commit.

Because this half-baked middle ground where nothing is truly new, nothing is truly stable, and everything is slightly worse than it should be is the real failure.