The Architecture of JetBrains Fleet and Zed
The golden era of the monolithic, resource-devouring text editor is drawing to a close. For nearly a decade, developers tolerated the compromises of Electron-based editors because the alternative was returning to terminal setups that required a degree in systems configuration. But a new paradigm is emerging. We are witnessing a battle of highly optimized, modern engines designed specifically to maximize performance while retaining deep IDE intelligence. At the epicenter of this shift stand JetBrains Fleet and Zed.
While both editors target the exact same developer frustration—clunky interfaces, indexing lag, and bloated memory footprints—their underlying architectures could not be more distinct. JetBrains Fleet approach is one of elegant decoupling; it separates the visual editor from the heavy indexing machinery. Zed, by contrast, is a radical exercise in native efficiency. Built from scratch in Rust, it treats the code editor as a highly concurrent, GPU-accelerated graphics application. This is not a superficial comparison of shortcuts or themes. This is a deep dive into two opposing engineering philosophies.
The Architectural Core: Distributed JVM vs. Concurrent Native Rust
The most fundamental difference between these two editors lies in their process models and language runtimes. Fleet is built on the JVM (Java Virtual Machine) ecosystem, specifically leveraging Kotlin. Zed is written entirely in Rust, operating as a compiled, native binary. This choice of substrate dictates every design decision that follows.
Fleet implements a strictly decoupled, distributed architecture. It splits the editor into three distinct components: the frontend, the workspace, and the backend engine. This division of labor is managed asynchronously:
- The Frontend: A lightweight user interface written in Kotlin, rendered using Jetpack Compose Multiplatform and Skia. It is fast, responsive, and handles basic text editing without loading any heavy intelligence.
- The Workspace: A coordinator process that manages local and remote file states, window configurations, and orchestrates communication between the frontend and the backend.
- The Backend: A headless JVM process that executes the actual code analysis. When "Smart Mode" is activated, Fleet spins up a background instance of the legendary IntelliJ code-analysis engine. This backend can run locally, in a local Docker container, or on a high-powered remote cloud server.
Zed rejects this distributed, multi-process overhead in favor of a highly optimized, single-process, multi-threaded native model. Zed does not use a virtual machine. It compiles directly to machine code, utilizing an aggressive, lock-free concurrency model that leverages Rust's safety guarantees to execute tasks across all available CPU cores. Instead of dividing the editor into isolated network-bound layers, Zed uses a unified pipeline. The editor interface, the syntax parser, and the local file watcher all share memory safely through thread-safe data structures and atomic operations. The resulting execution speed is virtually instantaneous, operating with the raw efficiency of a systems-level application.
The Graphics Pipeline: Skia vs. Custom GPUI
To achieve sub-millisecond input latency, both editors bypass traditional operating system UI toolkits (such as Cocoa on macOS or Win32 on Windows). However, the way they render pixels on your physical screen differs significantly in both complexity and execution.
Fleet relies on Skia, an open-source 2D graphics library, via Jetpack Compose. Skia is an incredibly mature, highly stable engine used by Google Chrome and Android. By drawing every button, scrollbar, and character onto a raw Skia canvas, Fleet achieves platform independence. The UI looks and behaves identically on macOS, Windows, and Linux. However, because Compose Multiplatform runs on top of the JVM, Fleet must still pay a rendering tax. There is a layer of garbage collection, object instantiation, and context switching between the Kotlin code and the native graphics API. On high-refresh-rate displays, Fleet remains responsive, but it cannot completely hide its Java lineage when subjected to heavy scrolling during intensive background indexing.
Zed takes graphics acceleration to an extreme. The developers of Zed built their own UI framework from scratch, called GPUI. Written in Rust, GPUI compiles UI layouts directly into GPU-friendly data structures. It bypasses intermediaries entirely. GPUI formats text, calculates layouts, and packages these elements into vertex buffers and draw calls, feeding them directly to graphics APIs like Metal on macOS or Vulkan and DirectX on Linux and Windows. Every UI element in Zed is essentially a 3D geometry piece rendered in a custom shader pipeline. When you scroll through a massive file in Zed, the graphics hardware is updating the screen at a locked 120 frames per second, with zero layout calculations blocking the main rendering thread. It is, quite literally, a video game engine masquerading as a code editor.
Semantic Comprehension: The Legacy Giant vs. The Lightweight Parser
A fast editor is useless if it cannot understand the code you are writing. This is where Fleet's architectural heritage faces off against Zed's modern, lightweight approach to static analysis.
Fleet’s "Smart Mode" is powered by the actual backend engine of IntelliJ IDEA. This is both its greatest strength and its heaviest burden. The IntelliJ code intelligence engine represents decades of refinement. It doesn't just parse text; it understands the deep semantics of complex enterprise frameworks, handles bytecode analysis, compiles on the fly, and tracks dependencies across millions of lines of code. When you run Fleet in Smart Mode on a complex Java or Kotlin project, you get unmatched refactoring capabilities, precise code navigation, and context-aware auto-completion. But this intelligence is heavy. The backend engine requires a substantial JVM memory heap, can spike CPU usage during indexing, and requires a notable startup latency while it maps the project architecture.
Zed approaches code comprehension from a totally different angle. Instead of a monolithic, proprietary static-analysis engine, Zed relies entirely on Tree-sitter and the Language Server Protocol (LSP). Tree-sitter, which was co-created by one of Zed's founders, is an incremental parsing library. When you open a file, Tree-sitter instantly builds a concrete Abstract Syntax Tree (AST). When you type a single character, Tree-sitter doesn't re-parse the file; it performs an incremental update in microseconds on a background thread. For semantic analysis, Zed delegates to external LSPs (like rust-analyzer, gopls, or tsserver) running as separate processes. This design keeps Zed’s core incredibly lean. However, it means Zed's code intelligence is only as good as the external LSP you have installed. While this works beautifully for modern languages like Rust, Go, and TypeScript, it can lack the deep, multi-layered framework integration that JetBrains' proprietary engine provides for enterprise ecosystems.
Collaboration and Workspace Sharing: Cloud-First vs. Native CRDTs
Modern software engineering is increasingly collaborative. How these two editors approach team workflows highlights their differing philosophies on the location of developer compute resources.
Fleet is designed with a cloud-first, space-centric mindset. Because its frontend is fully decoupled from its backend, Fleet allows you to easily outsource the heavy lifting. You can run the Fleet frontend locally while the workspace and backend run on a remote server in Space, GitHub Codespaces, or a custom VM. Collaboration in Fleet is structured around this remote model. Multiple developers can connect their frontends to the same remote workspace, sharing the same terminal sessions, running ports, and file systems. It is an excellent architecture for teams utilizing cloud development environments (CDEs) to standardize developer machines.
Zed rejects the necessity of a heavy remote server for collaboration. Instead, it treats collaboration as a peer-to-peer, real-time multiplayer game. Zed uses DeltaDB, a highly optimized synchronization engine built on Conflict-Free Replicated Data Types (CRDTs). When you collaborate in Zed, you don't necessarily need a shared cloud container. You can invite another developer directly into your local workspace. The CRDT engine synchronizes your text buffers, cursor positions, and even terminal outputs with character-level accuracy and zero perceptible latency. It is direct, secure, and incredibly fast, turning pair programming into a seamless, zero-config experience that feels as instant as editing a shared Google Doc.
Resource Budgets and the Developer Experience
The ultimate trade-off between Fleet and Zed comes down to resource allocation and the nature of your projects.
Fleet offers a transitional path. It allows you to have a beautiful, responsive UI that can scale up to handle the most complex enterprise architectures on earth by offloading the processing to a background JVM or a remote cloud server. If you work in a corporate environment with deep, multi-module projects, legacy JVM languages, and a reliance on cloud development environments, Fleet’s architecture is exceptionally well-suited. But you must accept that when running locally, Fleet will still consume a significant amount of RAM and CPU resources to power its smart backend engine.
Zed is a hyper-optimized racing car. It starts instantly, consumes a fraction of the memory of any JVM-based tool, and offers rendering speeds that make every other editor feel sluggish. Its reliance on Tree-sitter and LSPs keeps it clean and fast, and its built-in multiplayer collaboration is a masterclass in modern systems design. However, it is a tool built for the local machine. It does not have decades of monolithic enterprise static-analysis history behind it. It is designed for developers who value raw, local performance, who work with modern languages, and who want their editor to be as fast as their keyboard can type.
Conclusion
The choice between JetBrains Fleet and Zed is a choice between two distinct futures. Fleet represents the evolution of the IDE: a distributed, cloud-compatible platform that retains the massive, mature intelligence of the JetBrains ecosystem while shedding the UI weight of the classic monolith. Zed represents the revolution of native performance: a compiled, GPU-driven, multiplayer-ready systems-level text editor that proves how fast a modern development environment can be when it is free from the constraints of virtual machines and legacy codebases.
If your work revolves around massive enterprise codebases that require deep, complex refactoring across multiple languages, Fleet provides the necessary intellectual scaffolding. If you seek absolute, local speed, zero-latency rendering, and a lightweight, concurrent workflow optimized for modern languages, Zed is the undisputed speed king of the modern generation.
Comments
Post a Comment