The IDE Wars
Zusammenfassung
Kein Werkzeug in der Softwareentwicklung ist persönlicher als der Editor. Die Geschichte der Entwicklungsumgebungen ist deshalb keine Geschichte von Technologie — sie ist eine Geschichte von Identität, Kontrolle und der Frage, wie viel Maschine denken darf, bevor der Mensch das Gefühl verliert, selbst zu programmieren.
Die Urgötter: Emacs und vi
1976 entstanden, unabhängig voneinander, zwei Editoren, die bis heute aktiv weiterentwickelt werden und deren Anhänger sich seit Jahrzehnten im sogenannten Editor-Krieg gegenüberstehen.
vi schrieb Bill Joy an der UC Berkeley auf einer ADM-3A-Klemme mit Cursor-Tasten auf den HJKL-Tasten — deshalb navigiert vi noch heute mit h, j, k, l. Joy hatte keine numerische Tastatur. Er hatte auch keine schnelle Verbindung: Vi war für 300-Baud-Modems optimiert, jede gesendete Zeichenmenge zählte. Der Modal-Editor — Normal-Modus für Navigation, Insert-Modus für Tippen — war keine philosophische Entscheidung. Er war Bandbreitenökonomie.
Emacs schrieb Richard Stallman (mit Guy Steele u.a.) 1976 ursprünglich als Sammlung von TECO-Makros am MIT; die freie Neuimplementierung GNU Emacs folgte 1985 als politisches Werkzeug. Emacs war nicht nur Editor — es war eine programmierbare Umgebung. Emacs-Lisp erlaubte es, jeden Aspekt des Editors anzupassen. Stallmans Tauschbedingung: Wer Emacs-Erweiterungen schrieb, musste sie teilen. Das war die Urform des Copyleft-Gedankens, noch vor der GPL.
Emacs wurde zur vollständigen Gegenwelt: E-Mail lesen in Emacs, Kalender führen in Emacs, Webseiten browsen in Emacs, Tetris spielen in Emacs. Der Witz war alt, aber treffend: “Emacs ist ein großartiges Betriebssystem, dem nur ein guter Editor fehlt.” Vi-Anhänger bevorzugten das Gegenteil: ein Werkzeug, das eine Sache perfekt beherrschte.
Der Krieg tobt in Foren, Reddit-Threads und Konferenz-Gängen bis heute — ohne Sieger, ohne Waffenstillstand.
Eclipse: Die Enterprise-Lösung
2001 veröffentlichte IBM Eclipse als Open-Source-IDE und übergab das Projekt 2004 an die Eclipse Foundation. Der strategische Hintergrund: IBM wollte einen Standard-IDE für Java schaffen, der niemandes proprietäres Produkt war — und damit den Markt öffnen.
Eclipse funktionierte. Es wurde zum De-facto-Standard für Java-Entwicklung in Unternehmen. Das Plugin-System war mächtig: Tausende Erweiterungen, für jeden Anwendungsfall. Eclipse für Android-Entwicklung (ADT). Eclipse für C++ (CDT). Eclipse für PHP. Eclipse als Universal-Werkzeug.
Das Wachstum trug den Keim des Scheiterns in sich. Eclipse wurde langsam. Der Startup-Zeit wuchs mit jedem installierten Plugin. Die Benutzeroberfläche war konsistent inkonsistent — Perspectives, Views, Workspaces, Editors, alle mit eigenen Interaktionsregeln. Entwickler lernten Eclipse, weil sie mussten; sie liebten es selten.
JetBrains: Intelligenz als Differenzierungsmerkmal
Im selben Jahr wie Eclipse — tatsächlich einige Monate früher (Januar 2001) — brachten drei russische Entwickler, deren Firma in Prag ansässig war, ein Konkurrenzprodukt heraus. IntelliJ IDEA (JetBrains, 2001) war kommerziell, kostete Geld — und war technisch überlegen.
JetBrains’ Kernthese: Ein IDE sollte den Code verstehen, nicht nur anzeigen. IntelliJ analysierte semantisch. Refactoring war präzise, nicht textuell. Autocomplete kannte den Kontext. Der Editor wusste, welche Methoden auf welchem Typ existierten, welche Parameter eine Funktion erwartete, welche Imports fehlten.
Die Strategie war riskant. In einer Welt mit kostenlosem Eclipse für Programmierer zu verlangen. Aber Entwickler, die JetBrains probierten, wechselten selten zurück. Produktivitätsgewinn war spürbar, nicht abstrakt.
JetBrains expandierte das Modell: PyCharm für Python, WebStorm für JavaScript, GoLand für Go, CLion für C++. Jedes IDE spezialisiert, jedes IDE mit demselben Kern. Das Lizenzmodell wurde 2015 auf Subscription umgestellt — kontrovers in der Community, betriebswirtschaftlich erfolgreich.
Info
Der Jetbrains-Effekt auf die Branche: IntelliJ bewies, dass Entwickler für Werkzeuge zahlen, wenn der Produktivitätsgewinn real ist. Das veränderte die Erwartungshaltung der Branche: Ein IDE, das Code nur anzeigt, reicht nicht mehr. Semantisches Verständnis — “Language Server Protocol”, heute Standard — ist JetBrains’ intellektuelles Erbe an die Open-Source-IDE-Welt.
Visual Studio Code: Microsofts unwahrscheinliche Dominanz
2015 war Microsoft keine Firma, von der Entwickler freiwillig Software installierten. Satya Nadella hatte gerade das Ruder übernommen, die kulturelle Wende hin zu Open Source war im Gang — aber nicht abgeschlossen. Dann veröffentlichte Microsoft Visual Studio Code.
VS Code war Electron-basiert — ein Chromium-Browser, der eine Webapplikation ausführte. Für Performance-Puristen war das Häresie. Electron-Apps galten als träge, speicherhungrig, konzeptionell falsch. Die Emacs-Community trat das Electron-Konzept mit Verachtung.
VS Code ignorierte die Kritik und wurde trotzdem dominant. Warum?
Das Extensions-Ökosystem wuchs schneller als bei jedem Vorgänger. Das Language Server Protocol (LSP) — von Microsoft entwickelt und offengelegt — entkoppelte Sprach-Intelligenz von der IDE. Ein LSP-Server für Python funktionierte in VS Code, in Vim, in Emacs, in jedem Editor mit LSP-Client. Das war keine Produktstrategie, es war Infrastrukturdenken.
Der Preis half: kostenlos, open source (MIT). Keine Subscription, keine Stufen. Studenten, Hobbyisten, professionelle Entwickler — gleiche Version.
Bis 2023 nutzten laut Stack Overflow Developer Survey 73,3% aller Entwickler VS Code als primären Editor. Emacs: 4,4%. Vi/Vim: 23,2% (wobei Neovim separat steigt). IntelliJ: 25,1% — aber als Spezialist für spezifische Sprachen, nicht Universalwerkzeug.
Dead End: Eclipse als Universalplattform
Warnung
Eclipse wollte alles sein — und wurde dadurch nichts besonders.
Die Eclipse Foundation versuchte, Eclipse zu einer universellen Anwendungsplattform zu machen: Eclipse RCP (Rich Client Platform) sollte beliebige Desktop-Anwendungen ermöglichen. IBM baute Lotus Notes auf Eclipse RCP. Andere Unternehmen folgten.
Das scheiterte an einem Grundproblem: Eclipse war für Entwickler gebaut, nicht für Endnutzer. Die Plugin-Architektur, die für Entwicklerworkflows Sinn ergab, war für andere Anwendungsdomänen zu komplex und zu langsam.
Was blieb: Eclipse lebt als IDE für Java-Enterprise-Entwicklung und als Plattform für spezialisierte Werkzeuge (Modellierung, Embedded-Entwicklung). Als Universalwerkzeug — IDE für alle Sprachen, Plattform für alle Anwendungen — hat VS Code es vollständig verdrängt. Das Plugin-Ökosystem, das Eclipse groß machte, wurde zur Wartungslast: Inkompatible Plugin-Versionen, gebrochene Builds nach Updates, eine Qualitätskontrolle, die niemand durchsetzte.
Eclipse ist nicht tot. Es ist das Oracle-Datenbankprojekt der IDEs: stabilisiert, spezialisiert, und von keinem geliebt.
Vermächtnis
Der Editor-Krieg ist nicht gelöst — er hat sich verlagert. Emacs und Vim sind lebendiger denn je, getrieben von einer Generation, die Kontrolle und Konfigurierbarkeit über Komfort stellt. Neovim modernisiert Vim mit Lua-Scripting und LSP-Integration. Helix, Zed, Fleet — neue Editoren erscheinen, mit neuen Versprechen.
VS Code hat die Mitte gewonnen: Der Massenmarkt, die Lernenden, die Polyglotten. JetBrains hält die Spezialisten, die für semantische Tiefe zahlen wollen. Vim und Emacs halten die Philosophen.
Die eigentliche Innovation war das Language Server Protocol: Es entkoppelte Sprach-Intelligenz von der IDE und machte den Editor-Krieg ein Stück irrelevanter. Egal welchen Editor man wählt — die Intelligenz kommt aus demselben Server.