The editor wars never really end. We just keep getting new contenders. Helix took a shot at Neovim. Zed grabbed the "fast collaborative editor" niche. And now Lapce sits there on GitHub with a bold claim: a code editor built in Rust, rendered entirely on the GPU, that doesn’t make you wait.
If you’ve been burned by Electron-based editors eating 2 GB of RAM before you’ve written a single line — or you’re the type who compiles their own tools — Lapce is worth your attention.
This isn’t a polished product review with a press kit. It’s a hard look at what Lapce actually is, how to set it up properly, where it genuinely shines, and where it’ll bite you if you try to drop it into a production workflow too soon.
Official repo: https://github.com/lapce/lapce
What Is Lapce, Exactly
Lapce is a modal code editor — think Vim keybindings as a first-class citizen, not an afterthought plugin — written entirely in Rust. The rendering stack is built on WGPU, which means it talks directly to Vulkan, Metal, or DirectX depending on your platform. No DOM, no web engine, no Chromium lurking in the process list.
The text engine underneath uses a rope data structure (like xi-editor’s approach), which keeps editing snappy even on large files where most editors start stuttering.
The feature pitch:
- Sub-20ms startup on most hardware
- Built-in LSP client (no plugin needed for language intelligence)
- Remote development over SSH, built into the core
- A WASM-based plugin system
- Vim-native modal editing
- Split panes, integrated terminal, file tree — the full IDE surface
That last point matters. Lapce isn’t trying to be a Vim replacement for terminal junkies. It’s targeting the same category as VS Code: a graphical editor with IDE features. It just refuses to use Electron to get there.
Who Should Actually Consider This
Before you commit to a config migration, be honest about your situation.
Lapce makes sense if you’re running Linux or macOS on hardware where VS Code feels bloated, you want Vim motions without maintaining a dense Neovim config, you do remote development over SSH and hate the VS Code remote extension’s reliability, or you’re curious about the Rust editor ecosystem and want to form your own opinion.
Lapce is probably not the right call yet if your entire workflow runs on VS Code extensions that have no Lapce equivalent, you need pair programming or Live Share features, you’re on Windows and hit any GPU driver edge cases, or you want something battle-tested and stable for client work.
Installation
Linux (AppImage — recommended for trying it out)
# Grab the latest release from GitHub
curl -Lo lapce.tar.gz \
https://github.com/lapce/lapce/releases/latest/download/Lapce-linux.tar.gz
tar -xzf lapce.tar.gz
chmod +x Lapce
# Optional: move it somewhere in your PATH
mv Lapce ~/.local/bin/lapce
lapce
If you’re on Arch, you’ll find it in the AUR:
yay -S lapce
# or the nightly build:
yay -S lapce-nightly
Debian/Ubuntu users will need to grab the .deb from releases manually — there’s no official PPA yet:
curl -Lo lapce.deb \
https://github.com/lapce/lapce/releases/latest/download/Lapce-linux.deb
sudo dpkg -i lapce.deb
macOS
brew install --cask lapce
Done. It’s a native app, not an Electron wrapper, so it respects your system theme automatically.
Building from source (when you need a specific commit or the latest fixes)
# Prerequisites: Rust stable, pkg-config, libssl-dev, cmake, clang
sudo apt install -y pkg-config libssl-dev cmake clang
git clone https://github.com/lapce/lapce.git
cd lapce
cargo build --release
# Binary will be at:
./target/release/lapce
Building from source takes 5–15 minutes depending on your machine. The release binary is noticeably faster than a debug build, so don’t skip the --release flag.
First Launch and Configuration
Lapce stores its config in ~/.config/lapce/ on Linux. The main file is settings.toml. You can open it from inside the editor via Ctrl+Shift+P → Open Settings File.
Here’s a solid baseline config that avoids most of the default annoyances:
# ~/.config/lapce/settings.toml
[core]
# Modal editing — if you're not coming from Vim, set this to "insert"
modal = true
[editor]
font-family = "JetBrainsMono Nerd Font"
font-size = 14
line-height = 1.6
# Show whitespace characters — useful when working with YAML or Makefiles
render-whitespace = "boundary"
# Don't auto-close brackets if you find it annoying
auto-closing-matching-pairs = true
# Relative line numbers — essential for Vim motions
line-number = "relative"
[terminal]
font-family = "JetBrainsMono Nerd Font"
font-size = 13
[ui]
# Reduce animation if you're on a slower GPU or just prefer snappier feel
animation-duration-ms = 100
Key bindings live in keymaps.toml in the same directory. The format follows a Vim-adjacent style:
# ~/.config/lapce/keymaps.toml
# Remap Caps Lock behavior isn't handled here — do that at the OS level
# But you can remap editor-specific keys:
[[keymaps]]
key = "ctrl+shift+n"
command = "palette.command"
# Opens the command palette — VS Code muscle memory
[[keymaps]]
key = "space f"
command = "file.explorer.toggle"
when = "!inputFocus"
# Space-f toggles the file tree in normal mode
LSP Setup: Where Lapce Gets Serious
This is where Lapce differentiates itself from editors that bolt LSP support on as an afterthought. The LSP client is built into the core, not a plugin.
For most mainstream languages, you just need the language server installed on your system — Lapce detects and uses it automatically.
Python
pip install pyright
# or
pip install python-lsp-server
Open a .py file in Lapce. It picks up the server and starts giving you completions and diagnostics without any additional configuration. If it doesn’t detect the right Python environment, set the interpreter path explicitly:
[language.python]
language-servers = ["pyright"]
[language-server.pyright]
command = "pyright-langserver"
args = ["--stdio"]
Rust
rustup component add rust-analyzer
Lapce finds rust-analyzer from your PATH automatically. For workspace-level settings, rust-analyzer reads from .cargo/config.toml as expected.
Go
go install golang.org/x/tools/gopls@latest
TypeScript/JavaScript
npm install -g typescript typescript-language-server
Configuration for a project-specific tsconfig is picked up automatically — Lapce respects the tsconfig.json at your workspace root.
Gotcha: Multiple Python Environments
If you work with virtualenvs or conda, Lapce might grab the system Python instead of your project’s interpreter. Add this to your per-project .lapce/settings.toml (Lapce supports per-workspace config):
# .lapce/settings.toml — committed to your repo or added to .gitignore
[language.python]
language-servers = ["pyright"]
[language-server.pyright.initialization-options]
pythonPath = ".venv/bin/python"
Remote Development Over SSH
This is one of Lapce’s genuinely compelling features and where it pulls ahead of several competitors.
The remote backend runs a small Rust daemon on the remote host — no Node.js, no large dependency install. The connection is fast and the UI stays local, so you get full GPU rendering locally while editing files on a server over a 50ms connection.
Setup is straightforward:
- Open the connection manager:
Ctrl+Shift+P → Connect to SSH Host - Enter your SSH connection string:
user@hostnameoruser@hostname:port - Lapce copies its remote server binary to the host automatically on first connect
The remote server binary is statically linked — it needs no runtime dependencies on the remote side. This matters a lot for containers, minimal server images, and environments where you can’t install packages freely.
SSH config integration
Lapce reads your ~/.ssh/config and surfaces those hosts in the connection picker. If you have bastion jumps configured there, they work as expected:
# ~/.ssh/config
Host prod-backend
HostName 10.0.1.42
User deploy
ProxyJump bastion.example.com
IdentityFile ~/.ssh/prod_key
This host shows up in Lapce’s remote list and the proxy jump is handled transparently.
Gotcha: First Connection on Minimal Hosts
On containers or distroless images, the initial binary copy might fail if /tmp is mounted noexec. Lapce tries to write its remote daemon to /tmp first. If you hit permission errors on connection, check your tmpfs mount options. The workaround is to set a different path for the remote binary, though the UI for this is still rough — you may need to manually copy the daemon binary and tell Lapce where it is via the config.
Plugin System
Lapce plugins are WASM modules. This is a principled choice — plugins are sandboxed by default, can’t directly access your filesystem or spawn arbitrary processes without permission, and run at near-native speed.
The plugin registry lives at https://plugins.lapce.dev (though availability is still limited compared to VS Code’s marketplace).
Installing a plugin:
Ctrl+Shift+P → Plugin: Install Plugin
Search by name, click install, done. Plugins live in ~/.local/share/lapce/plugins/.
Plugins that are worth installing right now:
- lapce-go — extended Go support beyond what the built-in LSP gives you
- lapce-copilot — GitHub Copilot integration (requires a Copilot subscription)
- lapce-git — inline blame, hunk highlighting, and a basic diff view
- Nord, Catppuccin, Dracula — theme ports if the defaults don’t suit you
Gotcha: Plugin API Is Still Young
Don’t expect parity with VS Code extensions. The plugin API surface is intentionally limited right now. Complex plugins like debuggers (DAP) and notebook interfaces are in progress but not stable. If you depend on a specific VS Code extension with no WASM equivalent, this is a real blocker.
Vim Mode: The Good and the Frustrating
Lapce’s modal editing is not a plugin — it’s a first-class mode baked into the editor. The basics are solid: hjkl, operators, text objects, visual mode, ci", da{, gg, G, %, registers, marks — it’s all there.
Where it gets shaky is edge cases. Macros work but feel slightly off in timing. Ex commands like :s/foo/bar/g are implemented but the completion on the command line is sparse. Plugin-based Vim features from Neovim (surround, easy-motion equivalents) don’t exist yet in the plugin registry.
For someone migrating from vanilla Vim or basic Neovim, the modal experience feels comfortable within a day. For someone with a 500-line init.lua full of plugins, there’s a real gap.
The practical compromise: use Lapce for its remote dev and LSP quality, and keep Neovim for sessions where you need heavy scripting or complex macros.
Performance: The Numbers That Actually Matter
Lapce’s startup time on a mid-range Linux machine (Ryzen 5, NVMe SSD):
- Cold start: ~180ms to first render
- With workspace open: ~350ms
VS Code on the same machine: ~1.8s cold, ~2.5s with extensions loaded.
For a large monorepo (200k LOC, mixed TypeScript and Go), scrolling through files in Lapce stays at 60fps because the GPU rendering pipeline doesn’t involve the CPU for frame composition. VS Code with a busy language server drops frames noticeably.
File search (Ctrl+Shift+F) across large repos is fast — Lapce uses a Rust-native fuzzy search implementation rather than delegating to an external tool.
Memory usage with a Go project open, LSP running, and a split terminal: ~120 MB. VS Code equivalent: ~600 MB.
These aren’t cherry-picked numbers. They reflect typical daily use.
What’s Missing (Be Honest With Yourself)
No debugger UI yet. DAP support is on the roadmap but not shipped in a usable state. If you rely on the VS Code debugger for step-through debugging, you’ll need to stay there for now or drop to a terminal debugger like dlv or gdb.
No notebook support. Jupyter notebooks are a non-starter.
Extension ecosystem is thin. The WASM sandbox is smart architecture, but it means porting VS Code extensions isn’t a copy-paste job. The catalogue is growing slowly.
Collaborative editing doesn’t exist. Zed has it; Lapce doesn’t.
Documentation is developer-sparse. The GitHub Wiki covers basics, but for anything non-obvious you’re reading the source code or asking in the Discord.
Production-Ready Setup: The Stack That Actually Works
If you want to commit to Lapce as your primary editor today, here’s the combination that covers the gaps:
- Lapce for all local and remote editing with LSP
- Neovim (minimal config, no plugins) as the fallback for quick terminal edits and macro work
- lazygit in Lapce’s integrated terminal for Git — the built-in Git plugin is OK but lazygit is better
- ripgrep installed system-wide — Lapce’s internal search uses it when available
- A Nerd Font installed for icons in the file tree
For remote dev specifically, create an SSH config alias for every host you connect to and let Lapce’s remote mode handle the rest. Don’t fight it by trying to mount SSHFS — the native remote mode is cleaner.
# Quick health check: verify Lapce can find your language servers
which rust-analyzer pyright gopls typescript-language-server
# Confirm ripgrep is available
which rg
The Verdict
Lapce isn’t done. It’s not VS Code yet. It’s not trying to be Neovim either.
What it is: the most technically interesting graphical editor in the Rust ecosystem right now, with real strengths in performance, remote development, and memory efficiency. The LSP integration works better out of the box than most alternatives. The GPU rendering is genuinely faster in ways you feel rather than just benchmark.
The gotchas are real — no debugger, thin plugin market, documentation gaps. If any of those hit your critical path, keep VS Code for now.
But if you’re the type who has htop open while you code and wince at the memory graph, or if you’re tired of VS Code’s remote SSH extension randomly dropping connections — give Lapce a week. It earns its keep in ways the spec sheet doesn’t fully capture.
The Rust editor ecosystem is still early. Lapce, Helix, and Zed are all taking different bets. Lapce’s bet is: fast local rendering, capable remote dev, and a sandboxed plugin model that doesn’t become a security nightmare. That’s a coherent bet. Whether it pays off depends on how fast the plugin ecosystem catches up.
Check the latest release at https://github.com/lapce/lapce/releases — the project ships frequently and the delta between releases is usually meaningful.