Sourcecode-Editor Zed: Erfahrungen aus einem Jahr mit einem Underdog

Inhaltsverzeichnis

Stefan Baumgartner ist Softwarearchitekt und Entwickler. Er schreibt Artikel, Tutorials und Guides zu TypeScript, Rust, React und Softwareengineering und bietet über oida.dev Schulungen an.

Als Entwickler habe ich nach langer Zeit im Lager der Visual-Code-Studio-Nutzer den Umstieg gewagt: Seit nunmehr einem Jahr ist Zed mein Haupteditor. Warum sich auch für alteingesessene Entwicklerinnen oder Entwickler mit einer solide konfigurierten Arbeitsumgebung so ein Sprung in unbekanntes Terrain lohnen kann, möchte ich hier schildern.

Bevor ich den seit Januar als Open-Source-Software verfügbaren Zed verwendet habe, war ich im Lager der Visual-Studio-Code-Nutzer zuhause. Microsofts Sourcecode-Editor hat zu Recht mit geschickter Strategie und einem umfangreichen Ökosystem einen Siegeszug auf mehreren Betriebssystemen hingelegt. Kein Geringerer als Erich Gamma, seines Zeichens Teil der Gang of Four und jahrelanger Leiter des Eclipse-Projekts, zeichnet für das grundlegende Design und die Architektur verantwortlich.

Allroundtalent für die Softwareentwicklung

Visual Studio Code hat das Entwickeln für viele Programmiersprachen vereinfacht, allen voran TypeScript und JavaScript, den beiden Sprachen, für die VS Code ursprünglich gedacht war. Wenig später wurde VS Code ein beliebter Editor für C# und .NET, aber auch Go, Python und Java. Obwohl in einigen Bereichen die Alternativen – vor allem von JetBrains – eine noch stärkere Rolle spielen, bietet VS Code eine solide Basis, um produktiv mit unterschiedlichsten Programmiersprachen arbeiten zu können. Das liegt vor allem an der Einbindung des Language Server Protocol (LSP), einem einheitlichen Standard für die Kommunikation zwischen dem Editor und einem externen Tool, um Informationen über Kompilierfehler, Warnungen oder Autovervollständigung auszutauschen. Das vereinfacht nicht nur die Integration neuer Sprachen, sondern damit ist es letztlich für diese Aufgaben unerheblich, welcher Editor zum Einsatz kommt, da LSP mit nahezu allen Programmierumgebungen kompatibel ist.

LSPs und dazugehörige Plug-ins für VS Code gibt es auch für nischige Sprachen. Als ich das TypeScript Cookbook geschrieben habe, habe ich das Plug-in für AsciiDoc genutzt. Dabei habe ich aber auch gemerkt, wie schnell VS Code mit Fließtext in die Knie geht. Was bei kleinen TypeScript-Dateien und kürzeren Rust-Programmen vertretbar ist, macht sich beim Schreiben eines einfachen Textes besonders bemerkbar: VS Code ist sehr langsam.

Das wurde mir dann vor allem bewusst, als ich nach Alternativen gesucht habe. Zu Beginn war es ein guter alter Freund, Sublime Text, der dank LSP-Unterstützung so ziemlich alle Register zieht, die man im Schreib- und Programmieralltag braucht. Leider ist in den vergangenen Jahren das Ökosystem ein wenig ausgetrocknet. Deshalb wirkt Sublime im Dauerbetrieb oft wie ein Fleckerlteppich voll guter Ideen, die alle nicht so wirklich zusammenpassen. Ein weiterer Kandidat war (Neo)Vim in einer vorgefertigten Distribution, weil mir das Konfigurieren einer eigenen Umgebung als zu viel Aufwand erscheint. Mit Blick auf die Vim-Anhänger muss ich sagen: Ich verstehe, warum euch Vim gefällt, aber ich komme einfach nicht damit zurecht. Ich habe es versucht, ich breche mir die Finger, und ich habe keinen Plan, was ich mit den ganzen Lua-Konfigurationen machen soll. Es liegt nicht an euch, es liegt nicht an Vim, es liegt an mir.

Eines zeigte sich allerdings sehr schnell: Der Geschwindigkeitsunterschied zum Electron-basierten VS Code ist so enorm, dass es schwerfällt, wieder zu VS Code zurückzukehren, auch wenn es noch so gut ausgestattet ist. Ich habe jahrelang unterschätzt, wie wichtig es ist, schnelles UI-Feedback zu den geschriebenen Zeilen zu bekommen. Vor allem, wenn es um größere Software geht und die Navigation zwischen den Programmteilen schnell erfolgen soll. Es war eindeutig: Es gab kein Zurück zu VS Code, auch wenn ich noch nicht wusste, wohin die Reise gehen sollte.

Performante Alternative

Nach ein paar Beiträgen auf Mastodon hat mir die Community einen Blick auf Zed empfohlen. Schnell fand ich Gefallen an der spartanischen, aber produktiven Entwicklungsumgebung, die damals im März 2023 noch relativ neu war.

Die wichtigsten Fakten im Überblick:

Zed ist in Rust geschrieben. Das sagt mir als Rust-Entwickler zu und ist gleichzeitig der Grund für die performante Benutzeroberfläche.

1. Anders als die Projekte in Tauri oder Electron verwendet Zed keine Webtechnologien, sondern ein eigenes UI-Framework, um die Editor-Elemente darzustellen. Das Framework GPUI ist dank Hardwarebeschleunigung besonders performant.
2. Zed hat noch keine offene Plug-in-Entwicklung und liefert alles Notwendige mit. Damit gibt es (noch) kein Ökosystem, aber für die größeren Programmiersprachen arbeitet der Editor gut. Für die von mir hauptsächlich verwendeten Sprachen JavaScript/TypeScript und Rust ist die Unterstützung hervorragend.
3. Tatsächlich hat Zed bei der Anbindung an Tools viel mit Vim gemeinsam. Für die Sprachunterstützung integriert Zed das Language Server Protocol, und kann damit Werkzeuge wie den TypeScript Typechecker oder Rust Analyzer nutzen. Für die Syntaxhilfen ist die Treesitter-Community an Bord, die auch grandiose Vim-Plug-ins geschrieben hat. Treesitter gilt bei Vim als De-facto-Standard für die Syntaxhervorhebung. Alle Debugger bauen auf dem Debugger Adapter Protocol (DAP) auf, das ebenfalls in der Vim-Community beheimatet ist.
4. Und zu guter Letzt bringt Zed alle notwendigen Werkzeuge mit: vom integrierten Terminal über die Anbindung an GitHub Copilot bis zum Vim-Mode. Der wird zwar keine überzeugten Vim-Fans konvertieren, aber er reicht zum Ausprobieren. Auch Themes bietet Zed, darunter sogar ein paar alte Favoriten aus dem Atom-Editor.

Die Nähe zu Atom hat einen einfachen Grund: Hinter Zed steckt das ehemalige Atom-Team. Der Editor, den GitHub 2015 in Version 1.0 veröffentlichte, hat damals die Welt der Entwicklungstools aufgemischt.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Atom war einerseits ein gutes Tool mit einigen tollen Prinzipien, aber andererseits noch langsamer als VS Code. Entwickler Nathan Sobo hat deswegen während seiner Zeit bei GitHub noch an einem Nachfolger gearbeitet: XRay war ebenfalls in Rust geschrieben. Doch als sich Microsoft GitHub einverleibte, war schnell klar, dass Atom und ein möglicher Nachfolger keine Chance gegen Visual Studio Code hätten. Das Team entschied sich, als Start-up weiter zu machen, und hat sich zum Ziel gesetzt, mit einem schnellen, kollaborativen Editor das Feld der Programmierumgebungen neu zu definieren.

Kollaboration ist nicht nur ein wichtiger Aspekt von Zed, sondern auch sein Geschäftsmodell: Zed ist gratis, aber um in einer Ansicht gemeinsam zu arbeiten, fallen Kosten an. Wer wie ich das gleichzeitige Zusammenarbeiten an einer Datei oder einem Projekt nicht benötigt, profitiert von diesem Modell.

Schlank und schnell

Bei Zed überzeugt vor allem die Performance. Dass der Editor absolut abgespeckt ist und nur das Notwendigste mitbringt, was ich bei der Entwicklung benötige, kommt mir persönlich entgegen. Dass manche Funktionen nicht integriert sind, hat je nach Perspektive Vor- oder Nachteile. Beispielsweise fehlt eine Git- oder GitHub-Integration. Zwar zeigt Zed Feedback von Git-Projekten im Editor an, aber Commits direkt aus dem Editor sind nicht möglich. Mich stört das nicht, weil ich in noch keinem Werkzeug mit den eingebauten Git-Tools gearbeitet habe, sondern mit der Kommandozeile deutlich schneller bin.

Dafür bietet Zed eine sehr gute Dateisuche, und die Navigation zwischen Teilen meiner Software ist so komfortabel wie noch nie. Als besonderes Bonbon gibt es mit Multibuffers eine kleine, aber feine Revolution für das Bearbeiten mehrerer Dateien: Eine Klartextsuche findet ein paar relevante Schlüsselwörter, und mit Multiselect kann ich über Dateigrenzen hinweg alles gleichzeitig bearbeiten. Der Multibuffer hilft auch dabei, Programmierfehler in einer Ansicht schnell zu bearbeiten, ohne viele Tabs oder zahlreiche Dateien zu öffnen – eine komfortable Neuerung.