COSMIC and WEFT OS: two ways to build a Rust desktop
I’ve been thinking a lot about what a modern desktop actually is once you strip away the branding, the defaults, and the decades of inherited assumptions.
At the core, the shape is surprisingly simple:
- A compositor owns the screen, the input devices, and window placement.
- A shell defines the experience around those windows.
- An app model decides how software starts, what it can access, and how it talks to the rest of the system.
That is why System76’s COSMIC and my experimental project WEFT OS are so interesting to compare.
They both live in the Rust + Wayland world. They both use Smithay as an important building block. But they point in different directions.
COSMIC asks: what does a polished, practical, Rust-first desktop environment look like?
WEFT asks: what happens if the shell becomes web-native, the app logic becomes WebAssembly, and the OS is designed around explicit boundaries from the start?
This is not a competition piece. It is a structural comparison.
The common ground: Wayland and Smithay
Both projects start from the same place.
Wayland is the protocol that lets clients present windows and receive input.
A compositor is the part that actually owns the screen. It decides:
- which window is visible
- where it appears
- who receives keyboard, mouse, or touch input
- how everything is composed into the final frame
Smithay matters because it gives Rust projects a serious foundation for building that layer.
That shared foundation is important. It means COSMIC and WEFT are not separated by language or by rendering era. They are separated by design choices.
COSMIC: a full desktop environment made of Rust components
The easiest way to understand COSMIC is to look at its shape.
It is not just a compositor. It is a desktop environment made of many coordinated Rust projects: panel, settings, terminal, file manager, session manager, applets, launcher, notifications, and more.
That tells you a lot before you even read the code.
COSMIC is trying to be a real desktop people can live in.
Its compositor, cosmic-comp, reflects that ambition. It is built to handle the realities of a desktop environment rather than a narrow demo path. It supports multiple backends, integrates XWayland, runs a Wayland event loop, and includes practical debugging and profiling hooks.
That breadth matters. A production desktop has to survive mixed environments, odd hardware, legacy applications, and the boring-but-essential details of logging, profiling, and session management.
So when I look at COSMIC, I do not mainly see “Rust desktop hype.” I see a serious attempt to answer a very difficult question:
Can you build a complete, modern Linux desktop in Rust without making it feel like an experiment?
That is what makes COSMIC important.
WEFT OS: a smaller system with stricter boundaries
WEFT OS is not trying to be a general-purpose desktop environment in the same way.
It is an experimental operating system project with a narrower, more controlled structure:
weft-compositor
├─ owns Wayland surfaces, input, and display composition
├─ hosts the system panel surface from weft-servo-shell
└─ hosts application surfaces from weft-app-shell
weft-servo-shell
└─ renders the system UI in Servo
weft-appd
├─ starts and stops app sessions
├─ supervises runtime state
├─ relays per-session IPC
└─ launches the per-app shell when the runtime is ready
weft-runtime
└─ runs the app logic as a WASI WebAssembly component
weft-app-shell
└─ renders the app UI in an isolated Servo WebView
weft-file-portal
└─ mediates file access for the session
The difference in philosophy shows up immediately.
COSMIC grows outward from the idea of a desktop environment.
WEFT grows inward from the idea of process boundaries and explicit contracts.
Every major responsibility has its own place:
- the compositor composes
- the shells render
- the daemon supervises
- the runtime executes app logic
- the portal mediates filesystem access
That makes WEFT feel less like “a desktop with some apps” and more like “a small operating system made of cooperating parts.”
The real fork in the road: what the shell is
This is where the two projects stop merely looking different and start thinking differently.
In COSMIC, the shell is native
COSMIC’s user experience is built out of Rust-native components. The compositor is a key piece, but the desktop itself is a collection of native programs and libraries working together.
That is a very strong model if your goal is to ship a responsive, integrated desktop that behaves like people expect a Linux desktop to behave.
In WEFT, the shell is a document
WEFT takes a different path.
The system UI is rendered through Servo. App UIs are also rendered through Servo, in isolated per-app shells.
That means the shell is not just “a UI toolkit in Rust.” It is a browser engine embedded into the operating system model.
That changes the conversation.
When your shell is HTML and CSS, a few things happen at once:
- layout becomes document layout
- interaction becomes event-driven in a web sense
- styling becomes a first-class part of the platform
That can be powerful. It can also be dangerous if the boundaries are vague.
So the important part is not simply “WEFT uses Servo.” The important part is how it uses Servo: as one piece in a system where the compositor, shell, runtime, and policy layer are kept separate.
That separation is doing a lot of work.
It is what makes “browser engine as shell” feel like an operating system design choice instead of a shortcut.
Two different ideas of what an app should be
This is the second major split.
COSMIC’s app model
COSMIC is a desktop environment. It is built to host the world Linux users already live in:
- Wayland-native applications
- X11 applications through XWayland
- COSMIC-native applications built in Rust
In other words, COSMIC is designed to be a place where existing desktop software can live comfortably.
WEFT’s app model
WEFT is stricter.
In WEFT, an app is really two things at once:
-
logic, running as a WebAssembly component in
weft-runtime - UI, rendered in a separate Servo-based app shell
The launch path reflects that design:
- The system UI asks
weft-appdto launch an app. -
weft-appdcreates the session context, including IPC and, when needed, a file portal. -
weft-appdstartsweft-runtime, which runs the app logic. - Once the runtime is ready,
weft-appdstartsweft-app-shell. - The app shell creates the Wayland surface and presents the UI through Servo.
That structure is not just about startup order.
It is the app model made visible.
The app logic does not silently become the UI process. The UI process does not silently gain full filesystem access. Lifecycle is supervised. Filesystem access is mediated. IPC is part of the design, not a hidden implementation detail.
That is the heart of WEFT.
What Smithay makes possible
One of the most interesting lessons here is that Smithay does not force a worldview on you.
It gives you the infrastructure for a compositor, but it does not tell you what kind of desktop must sit on top of it.
That is why both of these can exist on the same technical foundation:
- a production-oriented desktop environment like COSMIC
- an experimental, shell-and-runtime-driven system like WEFT
That flexibility is exactly why Smithay matters.
It is not only a toolkit. It is an enabler of architectural diversity.
Why Servo is still interesting
Servo is easy to talk about in abstract terms, but it becomes more interesting when you place it inside an operating system design.
In WEFT, Servo is not being used just to say “look, web tech on the desktop.” That would be shallow.
The interesting part is that Servo becomes the rendering engine for a shell that is still constrained by:
- compositor rules
- process boundaries
- lifecycle supervision
- capability boundaries
That makes Servo feel less like a gimmick and more like a deliberate experiment in what a desktop shell could be.
Not a browser pretending to be an OS.
An OS deciding that document rendering can be a first-class part of its user interface model.
What I take away from the comparison
When I look at COSMIC, I see confidence in the idea that Rust is ready for mainstream desktop infrastructure.
When I look at WEFT, I see a different question being asked:
If we take the compositor seriously, the boundaries seriously, and the web seriously, what kind of OS falls out of that?
That is why I think these two projects sit well next to each other.
COSMIC shows how far a modern Rust desktop can go when the goal is completeness, polish, and practical deployment.
WEFT explores what happens when you use the same low-level world—Wayland, Smithay, process isolation—but point it toward a different model for shells and apps.
Both are valuable.
Both are modern.
And both say something important about where the Linux desktop might still go.
Closing thought
The most interesting part of the current Rust desktop moment is not that people are rewriting old ideas in a new language.
It is that the same technical base is now strong enough to support genuinely different visions.
COSMIC is one vision: a serious, full desktop environment built in Rust.
WEFT is another: a more experimental system where shells are rendered through Servo, apps are split between WebAssembly logic and web UI, and the operating system is shaped around clear process contracts.
That difference is exactly what makes the comparison worth having.
marcoallegretti
/
WEFT_OS
WEFT OS is an experimental operating system built around WebAssembly, Servo, and Wayland, designed to run secure, GPU-accelerated web and Wasm applications in a modular package-based system.
WEFT OS
WEFT OS is a Wayland compositor and application runtime where every app is a WebAssembly component rendered in an isolated Servo WebView. No capability is granted by default; all resource access is declared in a per-app manifest and enforced at runtime.
What is implemented
Compositor — weft-compositor is a Smithay-based Wayland compositor with DRM/KMS and winit backends. It implements the zweft-shell-unstable-v1 protocol extension, which typed shell slots (panel, application) register against.
System shell — weft-servo-shell embeds Servo (feature-gated, --features servo-embed) and renders system-ui.html as a Wayland panel. Without servo-embed, the binary builds as a no-op stub. Navigation gestures from the compositor are forwarded to weft-appd over WebSocket.
App shell — weft-app-shell is a per-process Servo host for application WebViews. It resolves weft-app://<id>/ui/index.html, injects a weftIpc WebSocket bridge into the page, and registers with the compositor as an application surface. Also feature-gated behind servo-embed.
App…
Top comments (0)