Atom ist der Editor meiner Wahl

Seitdem ich im und fürs Internet arbeite habe ich zahlreiche Editoren für meine Arbeit genutzt. Von einfachen Texteditoren bis zu IDEs war alles dabei. Zwei Dutzend werden es gewesen sein. Als ich Ende 2009 von Windows auf MacOSX umstieg, hat mich das minimalistische Interface von Textmate erst abgeschreckt, war ich doch Buttonleisten zum Speichern, Einfügen von Tabellen u.ä. gewöhnt. Andere Editoren wollten mich an die Hand nehmen. Ich sollte CSS anhand von Formularen „schreiben“.

Frühere Versuche mit anderen Editoren

Jahrelang nutzte ich Textmate, doch dieses Programm entwickelte sich nicht weiter. Es kamen andere Editoren mit anderen, sehr interessanten Bedienkonzepten auf. Vor allem Sublime Text war der Liebling der Massen. Mich schreckte das Programm bei meinen zwei Versuchen sofort ab. Erstens war die Konfiguration auf JSON-Files ausgelagert. Keine Menüs, keine bedienerfreundliche Oberfläche. Und zweitens waren die Kommandos im Wesentlichen in einem Popup-Menü versteckt, durch das man sich durchsuchen musste oder sich mit Suchbegriffen annäherte. Sublime und ich wurden keine Freunde.

Brackets entsprach schon eher meinen Wünschen. Die Oberfläche war aufgeräumt und attraktiv und das Angebot an Extensions war schon kurz nach der Veröffentlichung interessant. Es gab auch pfiffige Ideen, wie das direkte Editieren von CSS-Regeln. Da ich aber mein CSS mittels Sass schreibe, war das damals ein für mich unbrauchbares Feature. IDEs wie WebStorm oder PHPStorm waren zu umfangreich für meine Zwecke. Ich brauchte einen Texteditor ohne unnötigen Schnickschnack.

Atom wird veröffentlicht

Als Github den kostenlosen „Atom“ musste ich ihn sofort ausprobieren. Erste Besprechungen zogen Parallelen zu Sublime Text. Allerdings, und das ist wirklich wichtig für mich, hat Atom von Anfang an ein Konfigurationsinterface. Das erleichtert mir die Arbeit ungemein. In Ermangelung anderer sinnvoller Alternativen übte ich mit dem Editor ein paar Wochen und entdeckte dabei ein paar interessante Erweiterungen. Diese Entdeckungsreise hat bisher nicht aufgehört, denn das Ökosystem um diesen Editor herum ist gross.

Codehighlighting in Atom

Codehighlighting in Atom

VS Code

Nach einiger Zeit separierte Github die Basis von Atom als eigenes Projekt und nannte es „electron„. Auf dessen Basis baute Microsoft den sehr interessanten und empfehlenswerten Visual Studio Code. Hätte ich mich nicht so sehr an die Bedienung von Atom gewöhnt, wäre ich mittlerweile möglichweise zu VS Code gewechselt. Auch die Einbindung der Tatstaturbindings von Atom in VSCode brachte da keine echte Verbesserung.

Meinem Eindruck nach startet VS Code schneller als Atom. Die Startzeit ist eine der Schwächen von Atom. Die andere ist die Unfähigkeit, mit wirklich großen Dateien umzugehen. Eine 2 MB große Datei von irgendwas würde ich bewusst nie mehr in Atom öffnen (der Editor friert mit Garantie ein), in VS Code schon eher. Für die normale tägliche Arbeit habe ich Atom schätzen gelernt.

Interessante Erweiterungen

Eine sehr praktische Erweiterung, die ich schon bei Textmate unbedingt haben wollte, ist die Toolbar. Diese Erweiterung ist nur ein Wrapper für die eigentliche Toolbar, die man sich als zusätzliche Erweiterung läd. So habe ich schnellen Zugriff auf das Splitten des Editorfensters, den HTML- oder Markdown-Preview oder kann schnell die Dateiübersicht ausblenden. Der Weg über die Tastatur (Shift+Cmd+P bei mir) und dann die Stichwortsuche nach dem Befehl ist mir einfach zu mühsam.

Die Toolbar in Atom, dank der passenden Erweiterung.

Die Toolbar in Atom, dank der passenden Erweiterung.

Sehr wichtig ist auch der Projektmanager. Auch hier wird wieder per Tastatur gearbeitet, die resultierende Projektliste ist aber überschaubar und wird von mir selber angelegt. Minimap ist eine sehr nützliche Erweiterung, die mir zu Zeiten von Textmate schon immer gefehlt hat. Sie zeigt den Code der geöffneten Datei in extremer Miniaturisierung an. Dabei wird der aktuell sichtbare Abschnitt markiert. So kann man sich schnell innerhalb einer Datei orientieren. Da die Minimap auch bewegt werden kann, dient sie als Ersatz für die leider immer sehr dünnen Sidebars.

Das Projektmanagement in Atom

Das Projektmanagement in Atom

Mittlerweile nutze ich für meine tägliche Arbeit immer seltener ein seprates Terminal, sondern nutze das Package terminal-panel. Es ist ausreichend, um Grunt zu starten und zu stoppen. Es arbeitet automatisch um root des aktuellen Projektes, sodass man sich nicht erst durch das Terminal dahin bewegen muss. Für intensivere Arbeiten mit dem Terminal ist es weniger geeignet.

Das Terminal ist in Atom am unteren Rand integriert.

Das Terminal ist in Atom am unteren Rand integriert.

Für ein Projekt habe ich mal das Package remote-sync genutzt. Es kopiert nach dem Speichern automatisch die geänderten Dateien per FTP oder SFTP. Das ist praktisch, wenn man mit Vagrant arbeitet.

Für effektives Arbeiten ist das Package Sublime-Style-Column-Selection wichtig. Einfach die Alt-Taste (auf dem Mac) halten und vertikal ziehen, dann horizontal. Schon ist ein Block innerhalb des Quellcodes markiert. Diese Funktion brauche ich immer wieder. Wenn ich mich recht entsinne, kann VS Code das noch nicht.

Das Paket todo-show bringt eine Funktion, die ich unter Textmate kennen und schätzen gelernt habe: sie sammelt Referenzen zu allen Stellen innerhalb eines Projektes, in denen die Schlüsselwörter „TODO“, „FIXME“, „CHANGED“, „NOTE“ und noch einige mehr stehen. Im Laufe des Projektes kann eine solche Übersicht sehr hilfreich sein.

Obwohl ich noch Linter installiert habe, es gibt sie selbstverständlich in alles Geschmacksrichtungen, habe ich sie alle deinstalliert. An den SCSS-Linter verbinden mich nur negative Erinnerungen. Ich meine mich zu erinnern, dass dieser wegen jeder unwichtigen Kleinigkeit geweint hat und später dann selber Fehler warf. Da war wohl der Package-Programmierer nicht mit den Plattform-Änderungen mitgekommen.

Es gibt auch die Möglichkeit, mit grunt-manager Grunt-Files innerhalb von Atom zu verwalten. Das Gleiche gibt es natürlch auch für Gulp. Doch beide habe ich nach einem kurzen Versuch wieder deaktiviert. Vielleicht gebe ich ihnen nochmal eine Chance. Ich weiss nicht mehr, warum ich sie deaktiviert habe. Sehr wahrscheinlich brachten sie mir entweder keinen Nutzen oder ich begriff nicht schnell und intuitiv, was sie so machten.

Sehr schön finde ich die Markdown-Plugins. Sie halten mich mehr und mehr von meinem spezialisierten Markdown-Editor ab. Neben einem Package, das Markdown auch für einen schreibt – und mit dem man bloggen kann -, gibt es ein Package zum Exportieren als PDF (naja, eigentlich zwei). Eine Markdown-Vorschau kann mit einer Core-Komponente realisiert werden, ist also genereller Bestandteil von Atom. Sehr hilfreich finde ich auch das Package, um ein Inhaltsverzeichnis aus einem Markdown zu erstellen.

Sehr praktisch ist die eingebaute Git-Unterstützung. Geänderte und neue Dateien werden farblich markiert. Selbstverständlich kann man auch aus dem Programm heraus mit Git hantieren. Doch ich baue da viel lieber auf Git Tower, ein externes Programm, das es mittlerweile auch für Windows gibt.

Neuderdings habe ich auch SVGO als Erweiterung. In einer offenen SVG-Datei ist der Befehl zur Optimierung bspw. mit der rechten Maustaste erreichbar. Eine prima Geschichte.

Eine nette Sache, aber nicht dringend notwendig ist die Erweiterung, um CanIUse-Daten direkt innerhalb des Editors abfragen zu können. Die Reaktion auf eine Abfrage ist unmittelbar. Das liegt daran, dass die Daten für den Editor heruntergeladen werden. Sie sollten also hin und wieder aktualisiert werden. Umgekehrt kann man sich einen Linter integrieren, der über DoIUse ebenfalls abfragt, ob Probleme mit einer Eigenschaft auftreten können. Letzteres würde ich dann eher an einen Grunt-Task auslagern.

CanIUse in Atom integriert

CanIUse in Atom integriert

Fazit

Für meine aktuellen Aufgaben ist Atom genau der richtige Editor. Er ist auch beliebt genug, dass neben einer Weiterentwicklung der Nachschub an Erweiterungen und Themes immer gewährleistet ist. Für die kommenden Versionen haben die Macher versprochen, an der Performance zu schrauben. Ich bin nicht böse darum, wenn der Editor ein paar Sekunden schneller startet. Aber es stört mich nicht, ein wenig zu warten. Ich bin auf der Arbeit, nicht auf der Flucht.

8 Kommentare

  1. Wie ist das mit dem Autocomplete bei Atom? VS Code hat ja ein sehr gutes mit IntelliSense.

    • Es gibt zumindest ein Package dafür. Aber da bin ich leider der falsche Ansprechpartner, denn ich brauche sowas nicht. Ich nutze für HTML und CSS einfach Emmet. Ohne kann ich nicht leben. Irgendein Autocomplete habe ich aber und das geht mir tierisch auf den Senkel, wenn ich einfach nur Texte in Markdown schreibe. Wenn Dir Intellisense wichtig ist, dann ist VS Code der Editor der Wahl. Die schauen sich aktuell auch Details bei Atom ab. Beide entwickeln sich rasend schnell.

  2. Danke Jens,
    nach vielen Jahren mit TextMate hat mich dein Artikel animiert, mal etwas Anderes zu probieren. Für mich wird es erst einmal Visual Studio Code sein.
    Gruß Fritz

  3. Meine Erfahrung mit Atom und VSCode (und verwendeten Plugins) waren sehr ähnlich, wobei ich mich trotz der größeren Feature/Plugin-Vielfalt vorerst für VSCode entschieden habe, da letzterer einfach signifikant schneller startet und (gefühlt) stabiler unterwegs ist.

    Lediglich was die Linter betrifft, habe ich konträre Erfahrungen gemacht. Besonders eslint möchte ich nicht mehr missen, da es wirklich hilfreiches Feedback gibt! Sofortiges Feedback welche Variable im aktuellen Scope nicht verfügbar ist, was z.B. nach dem Restrukturieren eines JS-Moduls gar nicht mehr verwendet wird, versehentliche Verwendung nicht-typensicherer Vergleiche (== vs ===) uvm. Kann dir nur empfehlen den Lintern noch eine 2. Chance zu geben 🙂

    • Edit: Meinte natürlich „trotz der geringeren Feature/Plugin-Vielfalt von VSCode“. Atom hat da schon deutlich mehr im Angebot.

    • Für JS mögen die Linter prima sein. Ich programmiere kein JS. Und für HTML und SCSS sind diese Linter entweder unnötig oder nervig. Ich validiere dann später per Grunt das HTML – auch die separaten Schnipsel – und der Sass-Interpreter meckert sowieso bei den großen Kloppern.