Ich bin mir sicher, dass viele von Ihnen wie ich sind und mehrmals den Code-Editor gewechselt haben. Ich glaube, mein erster großer Editor war Coda. Dann bin ich zu TextMate gewechselt, als ich hauptsächlich lokal gearbeitet habe. Dann Sublime Text. Und zuletzt VS Code. Ich wette, Ihre Reise war anders. Ich kenne viele Leute, die Atom, Brackets, WebStorm und sogar BBedit lieben. Machen Sie Ihr Ding!
Für mich sind das vier Änderungen in einem Dutzend Jahren, also eine Änderung alle drei Jahre. Umziehen ist nichts, was ich schnell mache. Hier ist eine Sammlung von Gedanken rund um die Idee, Editoren zu wechseln.
Beim Umzug muss ich mir Zeit nehmen, um sicherzustellen, dass er **ziemlich genau wie der alte** funktioniert.
Andernfalls werde ich ihn bis zu dem Punkt verabscheuen, an dem ich ein oder zwei Tage später zurückwechsle. Das ist mir jedes Mal passiert, wenn ich gewechselt habe. Ich habe kleine Fehlstarts nach einem Wechsel, bei denen ich zum alten Editor zurückkehre, weil mich etwas zu sehr gestört hat oder meine Produktivität beeinträchtigt hat und ich aufgegeben habe. (Da ich jetzt weiß, dass ich das tue, lasse ich nicht zu, dass ein *einziger* Fehlstart mir das Gefühl gibt, der Editor, den ich ausprobiere, sei *nie* eine Möglichkeit.)
Mein letzter Wechsel war von Sublime Text zu VS Code. Ich hatte mich sehr an die Tastenkombinationen (z.B. CMD+Shift+d zum Duplizieren einer Zeile) in Sublime Text gewöhnt, sodass VS Code das glücklicherweise abdeckt.
Ich war erstaunt zu sehen, dass selbst meine VIM-Freunde sich in VS Code wohl und zufrieden fühlten. (Fun Fact: Auch wir haben in CodePen Tastenkombinationen.)
Nichts kann zu aufdringlich sein.
Bei einem meiner ersten Versuche, zu wechseln, empfand ich die Benutzeroberfläche von VS Code als zu überladen und die Funktion "Im Projekt suchen" als etwas langsam und umständlich. Diese Dinge störten mich so sehr, dass sie zu Fehlstarts führten und ich zu Sublime Text zurückkehrte.
Bei diesem letzten Wechselversuch (meinem 3. oder 4. vielleicht?) habe ich endlich ein Theme, das mir gut gefällt (ein wenig angepasst), einige Einstellungen gefunden, um die Benutzeroberfläche aufzuräumen (ich habe die Whitespace-Indikatoren entfernt, die für mich überwältigend waren, und die intensive blaue Fußzeile durch etwas Entspannteres ersetzt).
Durch intensiveres Arbeiten mit "Im Projekt suchen" habe ich mich daran gewöhnt. Ich mag es vielleicht sogar mehr als Sublime, da der Seitenleistenansatz konsistenter ist als das Öffnen eines neuen Ergebnis-Tabs. Ich finde, die Sprung-zu-Zeile-Funktion funktioniert konsistenter und die Suche fühlt sich mehr wie die First-Class-Bürger an, die sie sein sollte.
Ein weiterer Faktor wäre Emmet. Ich bin mir ziemlich sicher, dass es mich zu sehr ärgern würde, HTML und CSS in einem Editor ohne Emmet zu schreiben, und ich würde einfach etwas anderes verwenden, das es hat. Emmet ist in VS Code nicht einmal eine Erweiterung, es ist integriert.
Kleine Änderungen nach einem erfolgreichen Wechsel sind für mich in Ordnung.
Sobald ich es tatsächlich *geschafft* habe und den Wechsel zur Vollzeitnutzung vollzogen habe, *dann* kann ich einige Änderungen vornehmen. Vielleicht lerne ich einige neue Tastenkombinationen. Vielleicht füge ich eine Erweiterung hinzu, die Funktionalität hinzufügt, die ich noch nie zuvor hatte. Vielleicht beeinflusst der Editor einen Workflow auf eine Weise, die ich jetzt ausprobieren möchte.
Der neue Editor sollte eine Killerfunktion haben, die mich zum Wechsel motiviert.
Wenn er genau gleich ist, warum die Mühe?
Der neue Editor muss schneller (oder gefühlt genauso schnell) sein. Oder besser aussehen. Oder ein fantastisches Paket haben, das nur darauf verfügbar ist. Idealerweise alles davon.
Bei meinem jüngsten Wechsel war das GitLens.
Er sollte eine Plugin-Architektur haben.
Das heißt, jeder kann Code schreiben, um den Editor zu erweitern. Ich bin ziemlich sicher, dass eine Plugin-Architektur (plus eine gesunde Portion Community-Schwung) der Schlüssel zum Erfolg eines jeden Editors ist. Sublime's Paketmanager und die nachfolgenden integrierten Paketfunktionen von VS Code scheinen entscheidend zu sein. Nicht nur für die Funktionalität, sondern auch nur für das Aussehen des Editors. Ich würde keinen Editor mit einem Aussehen verwenden, das ich hasse, aber ich wäre versucht, wenn die Funktionalität fantastisch wäre. Das ist bei einem Plugin-basierten Editor kein Problem. Open Source scheint auch klug zu sein.
Vorsicht vor diesen Fallstricken.
Einer davon war für mich die Rechtschreibprüfung. In Sublime Text war es eine Option im Menü "Ansicht". Ich hatte es die ganze Zeit angehakt und es hat die ganze Zeit Rechtschreibprüfung durchgeführt.
Das ist in VS Code keine Funktion. Das war gefährlich nach dem Wechsel, denn wer weiß, vielleicht habe ich überall Tippfehler begangen. Glücklicherweise scheint diese Erweiterung den Trick zu machen. Gott sei Dank für Erweiterungen!
Ihre Gedanken!
Ich dachte, es wäre interessant zu fragen, was Sie alle beim Wechsel von Code-Editoren denken. Es gab *viele* Antworten. Ich habe hier so viele wie möglich herausgesucht und mich auf eine Sache konzentriert, die Sie erwähnt haben.
- Jani Hartikainen kümmert sich um VIM-Tastenkombinationen.
- Morgon wünscht sich Version Control Integration.
- Stu Robson möchte, dass er nicht abstürzt, wenn man riesige Dateien öffnet.
- Gabriel Vaquer möchte nicht, dass er Electron ist.
- gryzzly möchte, dass er schnell startet.
- Josh Betz wünscht sich eine menschenlesbare Konfigurationsdatei.
- Dan Finlay möchte, dass er Maus-frei ist.
- Frank Spin kümmert sich um GitHub-Sterne.
- Elijah Manor möchte, dass er Erweiterungen unterstützt.
- Max Sandelin wünscht sich visuelle Git-Steuerelemente.
- Matt Obee wünscht sich Geschwindigkeit.
- Kuldar wünscht sich weniger Benutzeroberfläche.
- Devon wünscht sich etwas, das sein alter Editor nicht hat.
- Brett Jankord möchte, dass er aktiv entwickelt wird.
- Jordan Koschei möchte, dass er von Leuten genutzt wird, denen er vertraut.
- PaulMDev wünscht sich Nachtmodus.
- Brad Frost wünscht sich Zuverlässigkeit.
- Will Browar wünscht sich mehrere Cursor.
- Umar Taufiq wünscht sich Code-Hints.
- Thomas Faller wünscht sich Community und Support.
- code witch sam wünscht sich Community-Engagement.
- Steve Gardner wünscht sich Geschwindigkeit.
- Nathan Knowler macht sich Sorgen um den Bildschirmplatz.
- hearsay wünscht sich eine Live-Vorschau.
- Keith Grant legt Wert auf Syntax-Highlighting-Themes.
- Mike Reithmuller legt Wert auf Geschwindigkeit.
- Nori Code legt Wert auf RAM-Auslastung.
- droan legt Wert auf Ligaturen.
Ich habe VS Code ausprobiert, da der PHP-Debugger und die IntelliSense besser funktionieren als in Sublime Text. Aber ich bin mir noch nicht sicher, ob ich komplett umziehen werde.
Ich habe meine Editoren einmal gewechselt. Als ich in der High School war, benutzte ich Microsoft FrontPage. Als ich aufs College kam, hatte ich mein Betriebssystem von Windows auf Linux umgestellt und meinen Editor auf Emacs gewechselt. Ich benutze Emacs seit 2002. Ich habe im Laufe der Jahre mehrere andere Editoren ausprobiert, aber die Lernkurve ist immer steiler, als ich bereit bin, Zeit und Mühe zu investieren, wenn ich in Emacs bereits sehr produktiv bin.
Es würde mich nicht überraschen, wenn ich Emacs nie verlassen würde. Es verbessert sich ständig und seine Funktionen sind genau das, was ich möchte. Während es stimmt, dass Lisp heutzutage keine verbreitete Sprache ist und das Schreiben von Plugins dafür eine steile Lernkurve hat, habe ich keinen Bedarf gefunden, für den nicht bereits jemand eine Lösung gefunden hat.
Ich würde die beiden Hauptgründe umkehren. Ich werde wechseln, wenn es einen großen Vorteil gibt... aber wenn nicht, warum sollte ich mich bemühen? Nachdem ich gewechselt habe, möchte ich auch nicht alles neu lernen müssen. Tatsächlich hat mich das davon abgehalten, zu VSCode zu wechseln. Ich benutze Atom und es ist ziemlich gut. Ich probiere VSC aus und... es ist auch gut, aber anders und ich habe noch keine signifikante "Wow, das kannst du hier tun und in Atom nicht!"-Funktion gesehen.
Ich mag VS Code wirklich, aber eine Sache, die mich dazu veranlassen könnte, zu einem anderen Editor zu wechseln, ist, dass die Benutzeroberfläche manchmal überwältigend und verwirrend sein kann, insbesondere das Einstellungsmenü, bei dem man anstelle von Kontrollkästchen und Dropdown-Menüs manuell JSON eingeben muss.
Ich liebe die Tatsache, dass Emmet integriert ist und der Erweiterungs-Marktplatz großartig ist, aber eine leichter verständliche Benutzeroberfläche würde ihn für mich praktisch unschlagbar machen!
Außerdem ist es angesichts der Qualität und der Funktionen, die man bekommt, kaum zu glauben, dass er kostenlos ist!!
Das höre ich viel in meinem Büro, einem Microsoft-Shop, der traditionell in .NET mit Visual Studio entwickelt hat. Aber wir arbeiten jetzt an einem Angular/TypeScript-Projekt und VS Code ist unser Editor der Wahl geworden.
Gute Nachrichten! Das VS Code-Team hat kürzlich einen Insiders-Build veröffentlicht, der eine neue Benutzeroberfläche für Einstellungen enthält. Vielleicht müssen wir in naher Zukunft keine JSON-Konfigurationen mehr für grundlegende Editor-Einstellungen bearbeiten.
Es sieht so aus, als könnten Sie die neuesten Informationen einsehen und sich hier an der Diskussion beteiligen
https://github.com/Microsoft/vscode/issues/50249
Kontrollkästchen und Dropdown-Menüs sind vorhanden. Nur in der Beta. Sie werden bald veröffentlicht.
Sie arbeiten derzeit an einer viel weniger beängstigenden Version der Präferenzverwaltung!
Für mich geht es hauptsächlich um Geschwindigkeit, besonders wenn man mit riesigen Verzeichnissen zu tun hat. Ich bin unzählige Male von Sublime zu VS Code gewechselt, habe aber kürzlich Brackets eine neue Chance gegeben, als mein Laptop sich weigerte zu arbeiten, und es hat mich so sehr überrascht, dass ich es auf Dauer behalten werde.
Es ist leicht, es ist schnell, es bietet praktisch alles, was ich an anderen Texteditoren geliebt habe, und es enthält bereits viele Funktionen, die bei anderen Plugins sind. Zum Beispiel JS Lint, ES Lint, Emmet und sogar einen Live-Vorschau-Server (obwohl ich dafür normalerweise andere Lösungen verwende).
Interessanterweise hat das Hinzufügen der Funktionen von VSCode zu VIM mit Plugins dazu geführt, dass mein VIM tatsächlich langsamer ist als VSCode!
Der Vim-Modus in VSCode hat sich so gut entwickelt, dass ich Vim immer seltener benutze. Ich werde Vim immer beherrschen, also werde ich mich beim Anmelden über SSH, wenn es passiert, immer noch wie ein Boss verhalten können, um Dateien zu bearbeiten. Ich kam von Netbeans -> Sublime -> Atom -> Vim -> Neovim -> VSCode.
Aus Front-End-Sicht glaube ich, dass ich den Sweet Spot erreicht habe und sehe keinen Grund, meinen Editor in absehbarer Zeit zu wechseln. Der Node-Debugger und das Debugging im Allgemeinen haben mich gefesselt.
15 Jahre lang habe ich viele verschiedene Editoren ausprobiert. Bis ich Vim fand. In Vim haben Sie absolute Kontrolle über den Editor, Sie können beliebige Befehle, Makros, Snippets ausführen, Tasten nach Belieben neu zuweisen, Sie können sehr kreativ mit diesem Editor umgehen. Aber die Lernkurve von Vim ist sehr steil. Um Vim zu meistern, kann es Jahre dauern. Sie lernen vielleicht jeden Tag etwas Neues über Vim. Ich habe noch niemanden gesehen, der stolz sagen kann: "Ich weiß alles über Vim".
In der Industrie ist für mich auch WebStorm ziemlich gut, wenn neue Leute in ein Projekt einsteigen.
Ich gebe VS Code nicht viel Liebe, ich denke, es könnte Datenschutzprobleme haben. Normalerweise sammelt Microsoft viel mehr Daten, als sie angeben.
Benutzen Sie einfach eine Firewall (unter Mac z.B. Little Snitch), um ausgehende Verbindungen zu MS-Servern zu blockieren.
Ich bin in einem kleinen Team von UI-Entwicklern, die React + Sass machen.
Die anderen sind von Sublime zu VS Code gewechselt.
Ich weigere mich (noch), da Sublime alles tut, was ich von ihm brauche.
Außerdem werde ich älter und das Lernen neuer Dinge wird schwieriger. ;)
Git + Kommandozeilen-Sachen werden in Cmder erledigt.
Ich brauche keine IDE, die das für mich erledigt, mit hübschen grafischen Darstellungen von Git-Branches usw.
Ich achte immer auf zwei Dinge, wenn ich wechsle: Geschwindigkeit und Benutzeroberfläche. Ich liebe PHPStorm und Sublime Text dafür. Während VS vielversprechend aussieht, ist es nicht so leistungsfähig wie PhpStorm und schwerer als Sublime Text.
Ich benutze Pycharm aus den gleichen Gründen. Außerdem denke ich, dass Sublime perfekt zum Bearbeiten von Dateien "außerhalb" meines Projektbereichs ist.
Ich bin von VI zu VIM gewechselt.
Ich bin Coda so viele Jahre treu geblieben, einfach wegen des integrierten FTP. Diese Funktionalität habe ich bei keinem der anderen Editoren gefunden. Es sei denn, ich verpasse etwas.
Du verpasst etwas. Git.
Für mich geht es hauptsächlich um plattformübergreifende Nutzung. Und einfache Erweiterbarkeit. Daher ist mein bevorzugter Quellcode-Editor immer noch Geany. Funktioniert auf allen wichtigen Plattformen, die Kompilierung unter Linux und anderen Unix-Derivaten ist fast trivial, hat eine große Anzahl von Plugins und eine ganze Menge sehr guter Farbschemata.
Ich habe andere getestet, darunter Atom, aber sie scheinen schwach und anfällig für Fehler zu sein; sie funktionieren auf älteren (aber noch unterstützten) Linux-Installationen nicht zuverlässig genug und sind daher für mich ein absolutes No-Go.
@christidtp: Ich benutze ausschließlich Total Commander-Klone für S/FTP-Operationen. Das spricht mich viel mehr an, auch wegen einiger der (meistens) integrierten Funktionen zum Dateivergleich und zur Suche.
cu, w0lf.
Großartige Informationen. Seit letzter Woche sammle ich Details zur HTML-Erfahrung. Es gibt einige erstaunliche Details auf Ihrem Blog, die ich nicht kannte. Danke.
Ich habe mich gefragt, wann Sie den Wechsel vollziehen würden. Ich habe es geschafft, letztes Jahr von Sublime zu VSCode zu wechseln. Ich passe das Standard-Theme stark an: https://gist.github.com/tgallimore/da09ddbec8bda4e4a1c64876aa757cb9
Ich benutze auch GitLens, aber die Standard-Git-Funktionen sind auch fantastisch! Ich liebe den Side-by-Side-Vergleich und die Behandlung von Merge-Konflikten.
Ich bin in den letzten Jahren von Sublime zu vim und dann zu vi gewechselt. (Aber für C# benutze ich immer noch Visual Studio mit Vim-Bindings.)
Eine Sache, die ich über Plugins hinzufügen möchte: Wenn Sie Mac, Linux oder ein anderes Unix-System verwenden, lohnt es sich, einen Editor zu verwenden, der mit dem Rest des Betriebssystems integriert ist. Sie brauchen kein JSON-Schweizer Taschenmesser-Plugin, wenn Sie 'curl' aufrufen können. Sie brauchen kein REST-Client-Add-on, wenn Sie 'jquery' aufrufen können. Build-System-Integration? Binden Sie 'make' oder 'dotnet build' oder was auch immer an F5, erledigt. Git blame? 'git blame %'. Die Liste geht weiter.
Die Stärke von Unix liegt in der Komposition bereits vorhandener Programme.
Ich benutze PHPStorm als mein Haupt-IDE und VSCode und Notepad++ für schnelle Bearbeitungen.
Was ich etwas seltsam finde, ist, dass einige Leute sagen, sie wollen einen Editor und keine IDE, aber dann laden sie eine Tonne von Drittanbieter-Plugins herunter, um diesen Editor mehr wie eine IDE zu gestalten.