Tauri Desktop Integration in Land

Code Editor Land uses Tauri through the Mountain element. Tauri lets the editor use the operating system WebView instead of bundling Chromium, while Mountain keeps native services in Rust.

The source-backed claim is architectural: no bundled Chromium in the Tauri desktop path, native Rust service code in Mountain, and configured targets for multiple operating systems. Public size, memory, and startup comparisons should come from a repeatable benchmark.

The Electron Problem

VS Code with a medium project uses 500 MB to 1.5 GB of RAM. Three open windows means three Chromium renderer processes, each carrying a full heap. Every OS interaction crosses a serialized JSON IPC pipe. Where Electron takes 200 ms to open a dialog, Mountain takes 2.

Tauri replaces the Electron shell with a native binary that delegates rendering to the OS WebView: WKWebView on macOS, WebView2 on Windows, WebKitGTK on Linux. The result is a smaller binary, less memory, and direct FFI access to native operations.

Mountain: The Tauri Application

Mountain implements the Tauri application lifecycle. Its startup path is organized around build, registration, initialization, and services:

main.rs -> Binary::Main -> Build -> Register -> Initialize -> Services

• Build: Configures the Tauri application with window settings, custom schemes (land:, vscode-file:, vscode-webview:), and security policies.
• Register: Wires Tauri commands and IPC handlers for filesystem, terminal, clipboard, search, configuration, and workbench events.
• Initialize: Prepares runtime state — the thread-safe ApplicationState struct that serves as the single source of truth.
• Services: Starts the Vine gRPC server and spawns Cocoon before the Tauri event loop takes over the desktop session.

ApplicationRunTime and Effects

Mountain implements the abstract service traits from Common through the ActionEffect system. Business logic is described as declarative, composable effects, executed by a central ApplicationRunTime. This replaces the typical async/await sprawl with a structured execution model where error channels are typed and resource cleanup is deterministic.

Key Mountain modules:

IPC: Two Layers, Two Jobs

The editor has two independent IPC paths:

Sky and Wind to Mountain - Tauri IPC

Sky’s UI and Wind service layer call Mountain through Tauri IPC. The implementation lives in Source/IPC/TauriIPCServer.rs, including the mountain_ipc_receive_message and mountain_ipc_get_status entry points. This path handles native work: files, terminals, clipboard, search, configuration, and workbench events.

Mountain to Cocoon - Vine gRPC

Mountain and Cocoon communicate over a bidirectional gRPC channel described by Vine proto files. Mountain owns the Rust-side services and Cocoon owns the TypeScript-side extension-host services. The protocol covers extension-host startup, document notifications, language providers, tree views, command execution, cancellation, and streaming routes.

Mist handles DNS isolation and secure service-boundary code. It is not a universal transport for all editor traffic.

Platform Targets

The repository contains Tauri configuration for macOS, Windows, Linux, iOS, and Android. A configured target is not the same as a published installer or verified release artifact. Today:

Build Commands

The development command that drives Tauri:

pnpm cross-env \
	NODE_ENV=development \
	NODE_VERSION=22 \
	Clean=true \
	Browser=true \
	Dependency=Microsoft/VSCode \
	Bundle=false \
	Compile=false \
	NODE_OPTIONS=--max-old-space-size=16384 \
	pnpm tauri dev

Bundle and Compile are false because tauri dev uses Vite, which handles module bundling on-the-fly for hot-reloading.

For production:

pnpm cross-env NODE_ENV=production pnpm tauri build

NLnet Funding

This work is funded through the NGI0 Commons Fund (grant No. 101135429), operated by PlayForm under the NLnet Foundation.