Titel

Beschreibung 01.01.1977

Ziel dieser Artikel ist es, einen Überblick über existierende und für Webentwicklung verwendbare Texteditoren zu geben.

Zu den ausgewählten Editoren gibt es jeweils einzelne Artikeln. Weiter unten auf dieser Seite geht es dann mehr um Hintergrund und Philosophisches.

Die Editoren

Einzelvorstellungen

Die Berichte sollen einen ersten Eindruck vermitteln und bei der Einrichtung helfen. Sie sind mit Bildern versehen und beschreiben die jeweilige Implementierung einiger typischer Funktionen.

Nach dem Reinschnuppern kann man sich vielleicht den einen oder anderen Editor genauer ansehen. Herausfinden, welcher der Editoren am Besten passt, muss man am Ende selber.

Selbstverständlich sind hier nicht alle Texteditoren erfasst. Und, wie die Berichte selber, ist auch die Auswahl subjektiv.

Zusammenfassung

Es gibt kein "Ranking" ("Die 10 Besten" mit Platz 1 bis Platz 10 oder Ähnliches). So etwas wollen wir hier gar nicht erst versuchen.

Alle vorgestellten Editoren bieten einen riesigen Funktionsumfang, den man als Tante Emma oder Onkel Otto sowieso nicht ausschöpfen kann. Selbst wenn man nur auf den kleinen Ausschnitt an Anforderungen sieht, der sich aus der Konzentration auf HTML, CSS und JavaScript ergibt, dann kann der Eine Dies und der Andere Das besser, aber letztendlich können Alle Alles.

Tipps aus der Hüfte:

Kurzkommentare

Brackets hatte mit den Funktionen Quick View und Preview zwei Alleinstellungsmerkmale. Die weitere Entwicklung ist von Adobe im Herbst 2021 eingestellt worden.

Atom ist ein wirklich guter Allround-Editor und vergleichbar mit VSCodium. Die weitere Entwicklung ist zwar - Stand Q3 2022 - von GitHub noch nicht offiziell eingestellt worden, aber es passiert nichts mehr.

Sublime-Text ist von den Alleskönnern am besten durchdacht. Durchdacht im Sinne von "was braucht man wirklich", und er ist - im Vergleich zu den JavaScript basierten Editoren - wirklich sehr schnell.

VSCodium ist die Open Source Teil von Visual Studie Code. Der Editor kann alles und für das, was er nicht kann, gibt es Plugins. Wenn das Motto von Sublime-Text: "Weniger ist mehr" lautet, so lautet das Motto von VSCodium: "Viel hilft viel".

Bluefish zielt in die Lücke zwischen Baukasten-Websites und Web-Anwendungsentwicklung. Bluefish wird noch immer weiterentwickelt, aber leider nur noch sporadisch.

Bluegriffon ist der einzige freie HTML Editor, der das WYSIWYG Prinzip umsetzt. Ob das Projekt noch lebt, ist im Moment unklar. Wer Bluegriffon benutzen will, muss nehmen, was es gerade gibt.

Kate ist der moderne Vi. Überall zu bekommen, universell einsetzbar, schnell, einfach in der Bedienung und verlässlich.

Emacs ist der Editor mit den vermutlich meisten Funktionen überhaupt. Wenn man den Emacs auf einer Skala Alleskönner einträgt, kommt danach erst einmal eine ganze Weile gar nichts.

Vi ist der Editor unter Unix. Er kann alles, kann auch Zaubern, ist irrwitzig schnell, ist unhandlich und gewöhnungsbedürftig. Benutzer rümpfen entweder die Nase oder sie sind hin und weg.

Seamonkey ist etwas für vintage Liebhaber. Mit dem Editor (WYSIWYG) kann man schnell und komfortabel einfache HTML Seiten erstellen. Mehr nicht, aber mehr will Seamonkey auch nicht können.

Meine Erfahrungen

Ich bin mit Unix groß geworden, daher war lange Zeit der Vi mein Standardeditor. Ansonsten habe ich beim Programmieren IDE's benutzt und, wenn es um reine Texte ging, Kate unter Unix und notepad++ unter Windows. Vor dem dunklen Zeitalter des Internet Explorers konnte ich auch ein paar Erfahrungen beim Entwerfen von HTML Seiten sammeln. Dafür habe ich Netscape Navigator Gold, den Vorgänger von Seamonkey und Bluegriffon, benutzt.

Bevor ich diesen Artikel begonnen habe, kannte ich die meisten der anderen Editoren nicht. Beim Schreiben habe ich sie alle fleißig ausprobiert, mal den Einen, mal den Anderen genommen. Felderprobung.

Irgendwann habe ich festgestellt, dass ich den überwiegenden Teil der Arbeit mit Sublime-Text erledige. Das war keine bewusste Entscheidung, sondern hat sich einfach herauskristallisiert.

VSCodium benutze ich in den Fällen, in denen ich auf Vorschläge zu Syntax Wert lege, also auf Hilfestellungen und Führung. Das wird aber immer seltener, je besser ich die Sprachen kenne. Auch die Rechtschreibprüfung "Spell Right" benutze ich gerne, weil sie zwei Sprachen gleichzeitig prüfen kann.

Für bestimmte Aufgaben nutze ich aber immer wieder den Vi. Spätestens wenn es darum geht, viele ähnliche, aber nicht identische, Änderungen in vielen Dateien vorzunehmen, wird er hervorgeholt. Darin ist der Vi einfach unschlagbar.

Kategorien und gemeinsame Eigenschaften

Schubladendenken

Schweizermesser

Die Editoren in dieser Schublade können für das Schreiben von Briefen, zum Programmieren und zum Editieren von Konfigurationsdateien benutzt werden. Zumindest ist das ihr Selbstverständnis.

Sie sind auch mehr oder weniger alltagstauglich, für das ausschließliche Bearbeiten von Konfigurationsdateien sind sie alle aber ein wenig Overkill.

In diese Kategorie gehören:

Die Gemeinsamkeiten dieser Editoren sind:

Urgesteine

Das sind Alleskönner, die aus einer anderen Zeit stammen und sich hinsichtlich Oberfläche und Benutzerführung deutlich von moderneren Editoren unterscheiden.

Es gibt in dieser Kategorie nur zwei. Das sind

Mal abgesehen davon, dass diese Beiden in keiner Übersicht über Editoren fehlen dürfen, ist es auch so, dass sich mit Beiden - wenn man sich einmal auf sie eingelassen hat - extrem effizient arbeiten lässt.

Sie gelten als die beiden ältesten Programme auf der Welt, die in ihrer ursprünglichen Fassung - mit ein paar Anpassungen - immer noch aktiv im Einsatz sind. Beide kommen aus der Zeit, als Unix laufen lernte, d.h. es gibt sie seit fast 50 Jahren.

Ansonsten ist ihre einzige Gemeinsamkeit die, dass sie keine Gemeinsamkeiten haben. Weder untereinander, noch im Vergleich mit anderen Editoren.

HTML-Spezialisten

Sie sind von ihrer Zielsetzung her - Erstellen und Bearbeiten von HTML Dateien - ein wenig "out dated". Durch das Aufkommen von Frameworks auf der einen und von Webanwendungen auf der anderen Seite, ist der Bedarf an purer HTML Entwicklung allgemein zurück gegangen.

Aber: Menschen, die ihre Seiten selber bauen, wenig JavaScript einsetzen und auf Baukästen verzichten wollen, sollten in diese Schublade auf jeden Fall hineinsehen.

Mitglieder sind

Die Anderen

von denen keiner hier auftaucht, sind:

Spezielle Themen

Exkurse und Begriffe

WYSIWYG: What You See Is What You Get

Was du (bei der Bearbeitung) siehst, ist das, was du (woanders) bekommst.

Der Begriff war eine Zeit lang die Rettung der Welt, heute gehört WYSIWYG in vielen Bereichen zum Alltag und wird gar nicht mehr erwähnt.

Jede moderne Textverarbeitung und alle Office Programme setzen das Prinzip um. Dabei werden die Steuerzeichen, die für das Layout des Textes verantwortlich sind, gegenüber dem Anwender versteckt und schon bei der Anzeige während der Bearbeitung für die Darstellung ausgewertet.

Texteditoren sind da anders. Texteditoren zeigen das an, was in einer Datei steht. Dazu gehören auch die Steuerzeichen. Diese werden angezeigt und können editiert werden, wie alle anderen Zeichen auch. Aber sie werden nicht interpretiert.

Für HTML gibt es heute noch zwei Editoren, die das Konzept umsetzen, wenn es bei der Anzeige um die Anzeige in einem Browser geht: Semonkey und Blugriffon. Beide gehen mehr oder weniger direkt auf Netscape Navigator Gold zurück.

Auch LibreOffice Writer und MSOffice Word sind in dem Sinne WYSIWYG Editoren, die HTML erzeugen. Die erzeugte HTML Datei kann in einem Browser angezeigt werden kann und sieht dort (fast) so aus, wie bei der Bearbeitung.

Aber, während Semonkey und Blugriffon ein HTML Dokument erzeugen, dass sich weiter verarbeiten lässt, ist das Ergebnis von LibreOffice und MSOffice dafür nicht geeignet. Die Office Systeme haben ihren Schwerpunkt in der Textverarbeitung und bieten dazu - als Zusatz - die Möglichkeit, ein erstelltes Dokument auch in HTML abzuspeichern.

Wer in Versuchung ist, seine Webseiten mit einer Textverarbeitung zu erstellen (weil es so schön einfach und vertraut ist), sei daher gewarnt: Es geht, aber dann ist der Weg zu Ende.

Die Integration von HTML, dass von einer regulären Textverarbeitung erzeugt wurde, in einen Web Auftritt zusammen mit JavaScript und CSS - oder auch nur die nachträgliche Bearbeitung mit anderen Werkzeugen - ist schwer bis gar nicht möglich.

Rechtschreibprüfung

Ein Texteditor, den man zur Entwicklung von Web-Seiten benutzt, muss eigentlich eine Rechtschreibprüfung bieten. Das ist bei Editoren, die zum Erstellen von Software gedacht sind, durchaus nicht selbstverständlich. Dennoch bieten alle hier vorgestellten Editoren eine Unterstützung bei der Rechtschreibung.

Allerdings ist das Angebot nicht so selbstverständlich vorhanden und integriert, wie z.B. in einer echten Textverarbeitung oder einem E-Mail Programm.

Teilweise müssen dafür Wörterbücher und/oder Erweiterungen installiert werden.

Weil das Thema von Fall zu Fall erstaunlich nervig werden kann, gibt dazu einen eigenen Artikel Rechtschreibprüfung in Texteditoren.

Performance

Performance bei Texteditoren? Macht diese Frage überhaupt Sinn?

Über Performance redet man bei Datenbanken, Suchmaschinen und meinetwegen Browsern. Aber bei Texteditoren?

Auf meinem "normalen" Desktop Rechner habe ich bei der Arbeit mit den unterschiedlichen Editoren wohl schon leichte Unterschiede bemerkt, aber wirklich gestört oder gar behindert hat das bei der Arbeit nicht.

Ich bin der Sache trotzdem einmal nachgegangen und habe ein paar Versuche angestellt, nur um herauszufinden, was es damit auf sich hat.

Die typische Arbeit mit einem Texteditor ist zwar manchmal mit großen Anforderungen an den Autor, aber selten mit großen Anforderungen an den Editor verbunden. Daher habe ich auf die Schnelle erstmal auch keinen aussagekräftigen Testfall gefunden.

Das Wort "Donaudampschifffahrtsgesellschaft" tausendmal in eine Datei schreiben und dann alle Vorkommen in Elbedampschifffahrtsgesellschaft" umändern? Ok, habe ich gemacht. Laufzeit ca. 0,3 ms oder auch 0,003ms?.

Am Ende bin ich auf mein Windows Surface Go 2 Notebook umgestiegen. Das Notebook war schon immer etwas schwach auf der Brust, nur dazu gedacht, an Online Meetings teilzunehmen oder ein paar schnelle Notizen im Zug zu machen. Nach der Umstellung auf Windows 11 ist es nur noch mit viel Geduld zu bedienen. In dieser Umgebung habe ich den einfachsten Testfall durchgeführt, der mir eingefallen ist und bei dem man sicher sein kann, dass der Rechner etwas zu tun bekommt.

Der Testfall heißt: Start des Editors.

Der Testfall:
Starten eines Editors.
Messpunkt 1:
Fenster aufgebaut. Das Editor-Fenster hat sich vollständig aufgebaut, ist aber u.U. noch nicht voll bedienbar. Hintergrundaktivitäten mit hohem CPU- und Speicherverbrauch laufen noch.
Messpunkt 2:
Betriebsbereit. Der Startvorgang ist beendet. Der Cursor ist keine Eieruhr mehr, der CPU Verbrauch im Windows Taskmanager hat sich wieder beruhigt, der Speicherverbrauch hat sich auf dem Arbeitsniveau eingependelt.
Messmethode:
Sekunden zählen. Laut 21, 22, 23, 24 ... aussprechen.
Umgebung:
Win 11, MS Surface Go 2, 4 GB Hauptspeicher. Alle Programme sind geschlossen, nur der Taskmanager läuft mit.
Durchführung:
Jeder Editor wird 5 mal hintereinander gestartet. Die ersten 2x sind zum Aufwärmen. Dann wird 3x gemessen und der Mittelwert notiert.

Hier die Ergebnisse;

Öffnungszeiten
Editor Messpunkt 1 Messpunkt 2 max CPU
GVim * * *
Kate 2 sek. 3 sek. 7 %
Sublime-Text 3 sek. 4 sek. 17 %
Brackets** 9 sek. 12 sek. 34 %
VSCodium 10 sek. 20 sek. 60 %
Atom** 14 sek. 19 sek. 62 %

* Nicht messbar. ** Gibt es nicht mehr.

Der Startvorgang beim Vi ist tatsächlich nicht messbar. Bevor der Taskmanager überhaupt mitbekommt, das da ein neuer Prozess ist, ist der Vi vollständig durchgestartet und taucht irgendwo ganz unten in der nach CPU % sortierten Prozessliste auf.

Dass der Abstand zwischen Kate und ST so klein ist, hatte ich nicht erwartet. Im Prinzip starten sie gleich schnell, da man bei meiner Messmethode Differenzen von einer Sekunde vernachlässigen kann.

Dass die drei Editoren, die auf die eine oder andere Art auf einem JavaScript Framework beruhen und deshalb ziemlichen viel Ballast mit schleppen, langsamer starten, war zu erwarten.

Allerdings vermute ich, dass das nicht alles ist. Kate schleppt schließlich die ganze Qt - Bibliothek mit und Sublime-Text kommt mit einem Haufen Python Code im Gepäck. Ich denke, dass da auch eine Menge effizienter Programmierung mit im Spiel ist.

Alles in allem sind diese Unterschiede schon frappierend; schließlich handelt es sich um Programme, die im Wesentlichen das Gleiche tun und einen vergleichbaren Funktionsumfang haben.

Open Source

Außer Sublime-Text, der offen nicht offen ist, stehen alle hier vorgestellten Editoren, zumindest teilweise, unter einer Open Source Lizenz.

Bei VSCodium bzw. code-oss handelt es sich um Auslieferungen von Visiual Studio Code, in der die proprietären Zusätze von Microsoft weggelassen wurden und die somit, im Gegensatz zum Original, tatsächlich Open Source sind.

Bluegriffon ist grundsätzlich Open Source, bietet aber zusätzliche, kostenpflichtige Features, die im binären Standardpaket zwar enthalten sind, aber über einen Lizenzschlüssel freigeschaltet werden müssen. Nach meinem Verständnis sind diese Zusätze auch nicht im offenen Quellcode enthalten.

Sublime-Text ist ein proprietäres Produkt, bei dem allerdings alle Plugins unter einer Open Source Lizenz stehen.

Die Entwicklung der 3 Editoren VSCode, Atom und Brackets wirft nebenbei ein interessantes Licht auf das Konzept Open Source.

Alle drei basieren auf einem Open Source Entwicklungsprojekt. Alle drei Projekte sind von einem Mega-Konzern ins Leben gerufen und finanziert worden. Brackets wurde durch Adobe ins Leben gerufen und finanziert, Atom ist oder war der Hauseditor von GitHub und VSCode wird von Microsoft finanziert.

Mit der Entwicklung von Brackets und Atom wurde so um 2012 begonnen, VSCode startete 2016.

Der dokumentierte Einstieg von Microsoft in die Entwicklung von VSCode 2016 ist explosionsartig: An einem Tag noch nicht vorhanden, am nächsten Tag mehr Entwicklerbeiträge als Brackets oder Atom zu ihren besten Zeiten hatten. Die Entwicklung beider Projekte wurde eingestellt.

Charts zu den Entwicklungsstatistiken.

Adobe hat im September 2021 seine Unterstützung für Brackets gekündigt und das Projekt eingemottet, GitHub ist im Dezember 22 gefolgt.

Auch die Entwickler von Open Source Software müssen essen und möchten deshalb bezahlt werden. Man vergisst das manchmal.

Ein Open Source Projekt, dass auf den Zuwendungen eines einzigen Sponsors basiert, steht vor enormen Problemen, wenn der Geldgeber abspringt.

Das Konzept Open Source schützt nicht vor Marktmacht. Ob es vor deren Missbrauch schützt, bleibt abzuwarten.