Most "web desktop" or "portfolio OS" projects on GitHub are structured as templates. They look great, but the moment you want to add a custom application, swap out the file system, or customize the window behaviors, you find yourself hacking directly into someone else's monolithic codebase. It's a DX nightmare of spaghetti styling and tightly-coupled state.

We decided to build Open Web Desktop (OWD) to solve this. OWD is a wip modular framework built natively on top of the Nuxt 4 and Vue 3 ecosystem. It provides a clean, programmatic engine API so you don't "fork a template"—you build on top of a chassis. Your apps, your rules, absolute modularity.

The Core Problem: Monoliths vs. Frameworks

When building a web-based desktop environment, you are essentially writing a mini-operating system running in a single-page application. A typical portfolio template couples the window management, state synchronization, visual theme, and desktop apps into one giant block of code.

OWD decouples these responsibilities into three package types:

– Apps (apps/):
Self-contained Vue applications loaded dynamically into desktop windows.

– Modules (packages/):
Plugins and integrations (e.g., file systems, state persistence, auth clients).

– Themes (themes/):
Window chrome styles, taskbar/dock layout, and workspace skins.

Here is what a clean, declarative desktop configuration looks like (desktop.config.ts):

import { defineDesktopConfig } from '@owdproject/core'

export default defineDesktopConfig({
  theme: '@owdproject/theme-win11',
  apps: [
    '@owdproject/app-about',
    '@owdproject/app-todo',
    '@owdproject/app-terminal'
  ],
  modules: [
    '@owdproject/module-fs',
    '@owdproject/module-persistence'
  ]
})

Under the Hood: Agnostic State & Data Isolation

A scalable web desktop shouldn't bind its core application data directly to the active visual components. While windows in OWD rely on efficient v-show toggles for window management (keeping the DOM alive when minimized and unmounting it only upon closure), the state architecture lives entirely at the engine level.

OWD handles application state by giving every application a dedicated, shared Pinia store for metadata. This approach unlocks two advantages:

1. Flexible Multi-Instance Structures

Because the store acts as a metadata hub, applications share a common core context but can easily structure their internal keys to support both singletons or dynamic, multi-window instances depending on the app needs.

2. Pluggable Persistence Modules

Since the application state is completely protocol-agnostic, there is no need to write API or database logic inside the frontend apps. You simply plug in a module: @owdproject/module-persistence will automatically syncs metadata to IndexedDB.

Better yet, because the state is decoupled, it's possible to write or swap a module to sync the Pinia stores to any remote protocol or database (such as a standard REST API, GraphQL, or even the AT Protocol/Bluesky ecosystem) without ever touching the application code.

Environment Control: The Interactive TUI Panel

A framework is only as good as its tooling. To make managing the development workspace fluid, OWD comes equipped with an interactive TUI (Terminal User Interface) Control Panel.

Instead of manually shifting files around or writing boilerplate code, the entire workspace can be handled directly from the terminal. The TUI control panel allows developers and power users to:

• Scaffold and install new applications or modules.
• Instantly hot-swap and preview desktop themes.
• Monitor the overall status of the local environment.

Join the Community: Building an Open Ecosystem

OWD is designed as a completely open, modular canvas. Instead of shipping a pseudo-open product with a locked-down cloud strategy or a rigid roadmap, our immediate goal is to put control back into the developers' hands. It allows frontend developers to easily spin up custom digital gardens, and modular experimenters to build interesting workspace layouts without upstream friction.

There are several ways to get involved:

• Building new applications and modules.
• Designing unique desktop themes.
• Improving documentation and onboarding guides.
• Hardening the core architecture.