Building YasirOS — a personal operating system in the browser
Why I rebuilt my portfolio as a browser-native OS, the architectural laws that hold it together, and what I learned by treating UI as a kernel.
A portfolio is usually a document. A document tells you what someone did. A system shows you how they think — what they consider essential, what they consider noise, where they spend complexity and where they refuse to. That gap is why I rebuilt mine as YasirOS, a browser-native operating system.
The six laws
Every system worth building has a small set of invariants that everything else respects. For YasirOS they are:
- Everything is an application.
- The terminal is sovereign.
- State is real (persisted, not faked).
- Actions have consequences everywhere — one effect bus, many surfaces.
- The system grows by registration, not patches.
- Precision over spectacle. Tokens, not ad-hoc CSS.
The architecture in one picture
UI clicks and terminal commands dispatch the same Effect objects through a shared bus. The two surfaces cannot diverge because they share the codepath that mutates state.
export function dispatch(effect: Effect): void { useStore.getState()._setLastEffect(effect); apply(effect); // the only place mutation happens} function apply(effect: Effect): void { useStore.getState()._apply((draft) => { switch (effect.type) { case 'open-app': openApp(draft, effect.appId); return; case 'close-window': closeWindow(draft, effect.windowId); return; case 'focus-window': focusWindow(draft, effect.windowId); return; // … } });}Why an OS metaphor
The OS metaphor sounds gimmicky until you notice what it unlocks: windows compose, the dock is a process list, the menu bar is a system tray, the terminal is a programmable user. Each pattern is decades-old and battle-tested. Building a portfolio on top of those primitives is cheaper than inventing a "creative scroll experience" — and far more honest.
“The right metaphor is not the one that impresses. It is the one that disappears.”
What it cost
Three things were expensive enough to need their own writeups (later in this series): the boot sequence, the windowing model, and the terminal command pipeline. Each one is a small kernel of its own.
- Boot + power state machine
- ~3 days
- Window manager (drag, resize, z-stack, snap)
- ~5 days
- Terminal engine (parser, executor, pty-like)
- ~4 days
- Filesystem (overlay VFS, IndexedDB persistence)
- ~2 days
- Visual polish + theme system
- ongoing forever
A portfolio tells you what someone did. A system shows you how they think.
Where to next
The rest of this series is a tour of those subsystems — what I tried first, what didn't work, and the principles that survived the rewrite. Subscribe to the RSS feed if you want the next post to find you.
Read next
Tangents that earned their keep
May 1, 2026 · 1 min
Block-based content models: why every modern CMS converges
Markdown was a great default for a decade. The next decade is typed blocks — and the reasons aren't taste, they're mechanics.
Apr 24, 2026 · 1 min
Five engineering opinions I changed my mind about this year
A list of takes I would have defended at length last year, that I now think are wrong or incomplete.
Discussion
Be the first to reply
Sign in to reply, react, and follow the thread.
Sign inThe thread is empty — for now. Reasonable take? Pushback? Drop it here.