Rethinking Web Browsers: A Case for a Unix-Like Approach

6 min read

Browsers are essential, but they give you none of the transparency and control a Unix-like operating system gives you. This post is about what a browser would look like if it followed the Unix philosophy instead: transparent, configurable, and built from small pieces instead of one black box.

What is a Browser #

You already know what a web browser is. If you don’t, stop reading this post and go learn, it’s pretty crucial knowledge.

For everyone else, here’s how I see it. A browser is basically an operating system running inside your operating system. It loads, runs, and manages other programs, except the programs here are websites instead of desktop apps. It sits between the website and your actual OS, the same way your OS sits between a program and the hardware.

A browser manages memory, handles file access, renders graphics, and does everything else a real OS does for its programs. The programs it’s managing happen to be websites, but they need the same resources and behave the same way desktop programs do.

So I treat a browser as an operating system: a very abstract one, but an OS all the same. And that means I judge it the way I judge any OS. I only respect the ones built on the Unix philosophy, because it’s the only philosophy that’s actually proven itself at scale over the decades.

The Unix Philosophy #

The Unix philosophy boils down to a few rules every program should follow. The big one: do one thing well. That leads to the next one: the output of one program should work as the input to another. Together these push you toward breaking a complex task into small, specialized pieces that each do one job and can be chained together.

Unix also says everything should be treated as a file. That keeps the filesystem clean and standard, so you interact with the machine through plain files instead of a dozen different APIs.

There are more rules than that, but after using Unix-like systems daily for over a decade, they stopped feeling like rules. They’re just how I expect a system to work.

Existing Browsers #

Browsers already act like operating systems. They manage multiple processes (websites) and help both developers and users build, monitor, and update those “processes,” the same way a real OS helps with programs.

Most browsers today just wrap one of a handful of engines, so I’ll talk about engines rather than brand names. That means Opera, Brave, Edge, and Google Chrome all count as “Chromium” to me.

The major engines in use today:

Chromium: powers most browsers, including Chrome, Edge, Brave, and Opera
Gecko: Firefox’s engine
WebKit: Safari’s engine
A handful of others, all fairly niche

No Browser Follows the Unix Philosophy #

None of them are built to act like an OS from the user’s side. Internally they have the same pieces (memory management, disk, graphics), but to the user they’re black boxes. You get very little real control unless you’re a browser or extension developer yourself.

There’s no procfs equivalent, so you can’t just poke around the filesystem and see what’s actually running inside. There’s no /etc-style config directory either. Instead, each browser is its own monolithic system with its own APIs, closed off from the OS and from each other the way Unix tools never are.

Today's browser is a sealed box. A Unix-like one would expose ps, /proc, and /etc instead.

The Ideal Browser #

A browser doesn’t have to be a black box. It could work like a Unix system instead. Picture a browser that:

Exposes its internal state through something like procfs, so you can see exactly what’s running inside it
Reads its config from an /etc-style directory, using the same tools and formats you already use everywhere else
Manages extensions through an actual package manager, instead of every browser inventing its own plugin system

Switching between browser profiles today is like dual-booting. Each profile is a directory full of its own data, but only the browser vendor really knows the layout. Standardize it, and generic tools could inspect and tune any profile without caring which browser made it.

My actual pitch: run the browser like a container manager, the way Docker or containerd run containers. Give each website its own Linux namespace, expose its procfs under the profile folder, and you get all the transparency and control of a Unix system, applied to the browser.

Each open site as its own namespaced container, all sharing one kernel, the way Docker already works.

Conclusion #

Building a browser is a huge undertaking, and I don’t have the time or the skill to do it myself. But I still think we need one built this way. Without it, we’re stuck with browsers quietly eating RAM and CPU with no way to ask why.

Maybe Chromium could be the base, wrapped in a Unix-like interface on top. I’m not a browser engineer, I’m just thinking out loud here. As a user, I want the ability to watch, poke at, and tune my own browser.

I’ve used Firefox, Chrome, Chromium, Opera, and Brave for long stretches. None of them gave me this. I’m on Brave right now, and it’s just another browser with the same limits as the rest.

What I Actually Want #

Here’s the world I want:

Your browser profile lives in a GitHub repo, synced between machines like any other dotfiles setup
ps lists your open tabs and what CPU/RAM each one is using
diff shows you exactly what an extension changed on disk
Config lives in plain text files, not a settings UI buried three menus deep
Extensions install through a real package manager
You can cap CPU/RAM for the whole browser or a single site with one config line
Extensions aren’t locked to one specific browser and version
You can share your whole setup with a friend as easily as sharing a dotfiles repo
Cookies and site storage show up as regular files you can grep and diff
Network traffic for a site is just another process to monitor, no DevTools required

All of this is already possible today, if you’re a deep enough expert in one specific engine’s internals. I don’t want to be that expert. I just want the simple stuff to be simple.