Two good Visual Studio Code alternatives

The conductor of my choir famously tells us singers, “I only want everything all the time.” Well, as a developer, my mantra for code editors and IDEs (integrated development environments) is exactly that: I only want everything all the time. What’s “everything” in this context in 2024? It has to be fast enough not to get in my way. It has to be able to support my software development life cycle in all the programming languages that I write, with, at a minimum, syntax highlighting, and preferably some in-line auto-completion and syntax checking. And it has to be able to act as my pair programmer at a useful level.

The four alternatives to Visual Studio Code we’ll examine below—Zed, Eclipse Theia IDE, Lite XL, and Cursor—are all available for Linux, macOS, and Windows, with the slight exception of Zed, which is currently available for Linux and macOS only. The Zed project says a Windows version is coming “soon.” All four products are free, except Cursor, which is available in a limited free version, a pro version that costs $20 per month, and a business version that costs $40 per month (see pricing).

All four products can be extended to support AI-assisted coding, but Zed and Cursor also have native AI integrations that set them apart.

AI-powered pair programming is evolving quickly. It used to be controversial; now most programmers accept AI help for code completion and sometimes for code generation.

I have to repeat the obligatory warning, however: AI code generation is only safe if you knowledgeably review, understand, test, and debug the code. It’s not for beginners. It’s not for generating code in a language you don’t know. Generating code for an unfamiliar library or framework may be OK, as long as you also familiarize yourself at least to the point where you can tell safe usage from unsafe usage.

If you use AI code generation without doing your due diligence, you may still boost your productivity as a programmer. You may, however, be producing buggier, less efficient code; in other words, garbage, dreck, crap.

Inside Visual Studio Code

Visual Studio Code is a free, lightweight, and yet powerful source code editor that is available for Windows, macOS, Linux, and Raspberry Pi OS. It comes with built-in support for JavaScript, TypeScript, and Node.js and it has a rich ecosystem of extensions for other programming languages (such as C++, C#, Java, Python, PHP, and Go), and for runtimes (such as .NET and Unity), environments (such as Docker and Kubernetes), and clouds (such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform). As I put it in a previous article about VS Code, “Come for the fast editing. Stay for the debugging, source code management support, and huge ecosystem of extensions.”

The code in Microsoft’s Visual Studio Code (vscode) repository is open source under the MIT License. The Visual Studio Code product itself ships under a standard Microsoft product license, as it has a small percentage of Microsoft-specific customizations. It’s free despite the commercial license. The vscode repository is formally called Visual Studio Code – Open Source (“Code – OSS”).

The core Code-OSS repo isn’t the whole story, however. The Code project consists of the vscode repository plus a number of satellite projects. One of the more important satellite projects is the Language Server Protocol, which defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references, etc. The goal of the Language Server Index Format (LSIF, pronounced like ‘else if’) is to support rich code navigation in development tools or a Web UI without needing a local copy of the source code. Another important satellite project is the standalone Monaco Editor, which is the full-featured code editor from Visual Studio Code.

Because Visual Studio Code is a hybrid app built on Chromium and Node.js running inside a native Electron shell, it isn’t as small or as fast as it would be if it were written as a native application. That’s an opportunity for those who want to build smaller, faster code editors and IDEs.

Inspired by Visual Studio Code: An overview

It shouldn’t come as a surprise that others have built products that look and behave like Visual Studio Code, and may even use parts of Code OSS, both for the desktop and the cloud.

Zed is billed as “a next-generation code editor designed for high-performance collaboration with humans and AI.” Zed looks like VS Code and has many of its features, but it was “written from scratch in Rust to efficiently leverage multiple CPU cores and your GPU.” It’s about half the size of VS Code and much faster on my M1 MacBook Pro. It’s even faster than Sublime Text. Zed also has access to many large language models (LLMs), both inline and in a separate window, in the spirit of Tabnine.

Eclipse Theia is a framework for building IDEs and other development tools; the Eclipse Theia IDE is a cloud and desktop IDE built on the Theia framework. Theia IDE actually uses the Monaco editor component, and provides language support via Visual Studio Code’s LSP (Language Server Protocol) and DAP (Debug Adapter Protocol). Further, it can host VS Code extensions (it has 83 extensions built-in, although most are very basic) and provides terminal access. About half-a-dozen other products have been built from the Theia framework. Theia IDE is neither smaller nor faster than VS Code, and has numerous issues.

Lite XL is pitched as a “lightweight, simple, fast, feature-filled, and extremely extensible text editor written in C, and Lua, adapted from lite.” It supports a LSP plug-in for language support, and a terminal plug-in. (I was able to install the terminal plug-in, but not get it to run on my M1 MacBook Pro.) Various other common editing features are also implemented as plug-ins. Lite XL is about a tenth of the size of Visual Studio Code. It installs on macOS using MacPorts. It is also supposed to install using builds on its releases page, but that version wouldn’t start on my M1 MacBook Pro.

Cursor, a fork of Visual Studio Code, is built to make you “extraordinarily productive,” and claims to be “the best way to code with AI.” Cursor has several code completion and chat models of its own built-in, and can also use Claude Opus and the premium models GPT-4, GPT-4o, and Claude 3.5 Sonnet. In the course of this review, more models were released, such as o1-mini. Exactly what models you can call, how often, and at what priority, depend on your Cursor and GitHub Copilot subscription plans and what API keys you supply. Cursor’s own code completion does more than GitHub Copilot. It can edit the code around your cursor and remove text, not just insert text at your cursor position. Cursor is about the same size as VS Code.

Comparing the contenders

Overall, I find Theia IDE too slow and underpowered for my taste. I currently can’t get many plug-ins to run in Lite XL, meaning that I can only use it as a basic programming editor, albeit a small, fast, theoretically extensible programming editor. The other two Visual Studio Code alternatives, Zed and Cursor, are more to my taste. It’s worthwhile comparing the two to VS Code and to each other.

Zed

The Zed editor was developed by the team that wrote Atom, Electron, and Tree-sitter. They didn’t want to use a JavaScript/Electron framed web application approach again. Instead, they decided to go for speed, using Rust and GPUI. Rust, as you probably know, is a fast, memory-efficient, compiled programming language that has features to ensure memory safety and thread safety.

Have I mentioned that Zed is fast? Compared to Visual Studio Code, it’s night and day. I already knew first-hand that VS Code is slower than Sublime Text, but I thought the slowdown was an inevitable consequence of VS Code being an IDE rather than an editor. Zed proves that what I thought is wrong.

Using Rust rather than JavaScript would only partially explain the speed of Zed. The other major factor is the use of GPU acceleration, which is a little surprising because some other new editors haven’t been able to achieve any noticeable speed boost from trying to use the GPU.

GPUI is a GPU-accelerated UI framework for Rust, developed by the Zed team in parallel with Zed, and currently part of the Zed repository. On macOS, GPUI uses Metal, an Apple-specific integrated graphics and compute API with a shading language for rendering. Metal has functionality that combines that of OpenGL GPU-accelerated vector graphics and OpenCL parallel programming of diverse accelerators. Using the Metal API is something I would expect in a real-time game, but not an editor.

On Linux, Zed requires a Vulkan 1.3 driver; Vulkan is a GPU-only API usually used for real-time game programming. Zed can use either the X11 window manager or Wayland, a newer combined window manager and display server, depending on which is present in the Linux system. If both are present, Zed will prefer Wayland unless you tell it not to.

How does Zed know whether to use Metal or Vulkan? I didn’t find an explicit platform-dependent switch or if statement, as I would expect in C/C++ code. As I discovered by asking the Zed Assistant while browsing the GPUI app.rs file in Zed, GPUI uses a Platform trait to abstract platform-specific functionality, and the actual platform implementation is injected when creating the app.

Traits are a feature of the Rust language; they define the functionality or behavior a particular type has, a bit like interfaces in Java or C#. Using a file search for “platform,” I found an implementation of platform-dependent code injection using #[cfg(target_os = …)] directives in platform.rs. That Rust directive is similar to the C/C++ #ifdef preprocessor directive.

I mentioned using the Zed Assistant to explain code. Zed’s generative AI integration has two parts: the inline assistant, and the Assistant panel. The Assistant panel is more than an AI chat — it’s a context editor.

That bears explanation. Zed calls the Assistant panel a context and documents that: “Contexts are like conversations in most assistant-like tools. A context is a collaborative tool for sharing information between you, your project, and the assistant/model.” This allows you to work back and forth between the code in your project and your conversation with the model. It’s habit-forming once you get used to it. (See the eight-minute introductory video to get an idea how all this works.)

Slash commands augment what you can do in the context window. They range from simple insertions, such as /now (time and date) and /tab (contents of active or open tabs), to /workflow (establishing a context for the assistant to suggest edits to your code). In addition, Zed keeps a history of all your queries and its responses so that you can always look at them again.

The Zed inline assistant is closer to what you might expect from Visual Studio Code’s inline GitHub Copilot assistant, but still has additional twists. Press ctrl-enter or click the assistant icon at the top right of the edit pane, and you’ll either send the current line or the current selection to the model for completion. The inline assistant uses the assistant panel to provide context or instructions that direct the model about how to modify the inline code. You’ll get the hang of that quickly, even though it may be confusing at first.

Zed can use models from Anthropic, GitHub Copilot Chat, Google, Ollama, and OpenAI. You get more access if you supply the corresponding API keys or, in the case of GitHub Copilot, have a subscription that Zed can look up. To use open source (or partially open source) models like Llama, Mistral, and Gemma in Ollama, you need to be running Ollama in your machine, which takes significant memory.

Zed has an extensive collaboration feature that includes topic-specific channels and named contacts. As I’m kind of a lone wolf these days, I rarely use such things. If you’re working on a project with several other people, it sounds like it should be useful, but you have to trust anyone you allow to collaborate with you, since the feature gives them access to your local file system.

Zed has most of the editing features you’ll find in VS Code, Sublime Text, and BBEdit. These include multi-buffer editing, interactive programming with REPLs and notebooks, support for many languages, a terminal and task runner, full Vim bindings, and remote development (still in preview). Zed currently lacks debugger support, although it does have nice integrated REPL support for interpreted languages. Debugger support is on its roadmap.

Cursor

Since Cursor AI is a fork of VS Code, it’s no faster than VS Code, and not nearly as fast as Zed. Its major improvement over VS Code is its handling of code completion and chat. Some of that couldn’t have been accomplished as an extension.

The distinguishing features of Cursor are mostly focused around AI. When generating code, Cursor sees your recent changes, so it can predict what you want to do next. It can suggest multiple edits at once, something that you’ll also find in Zed. If you type incorrect code that’s close enough to guess your intent, Cursor will fix it. Cursor can also predict your next cursor position.

In the chat tab, Cursor can answer questions about your code base, refer to code you reference, use images as input, and refer to the web if you ask it to. It can apply code suggestions from chat back into your code base, and refer to libraries or documentation that you mention.

In a code context, you can pop up a prompt bar to give Cursor instructions, and optionally supply a highlighted range. You can also ask quick questions from this bar. Finally, you can ask Cursor for help in the terminal window and it will generate commands.

While I’m not going to abandon Visual Studio Code or Sublime Text, or give up on the free level of Cursor, I expect to adopt Zed as my primary code development environment. It’s currently free. I don’t know how I’ll react, however, if they ask for a subscription price that’s over my budget.