WYSIWYG oder Code-Editor für HTML

Das kleine „oder" in dieser Frage führt schon in die Irre. Es stellt die beiden in den Ring, dabei gibt es keinen Kampf. Weder der visuelle Editor noch der Code-Editor gewinnt für sich genommen — es hängt an der Änderung, die du gerade machst. Eine Überschrift, einen Link, ein Foto korrigieren? Der visuelle Editor ist schneller. Struktur umbauen, ein exaktes Attribut setzen, verstehen, wie die Tags ineinandergreifen? Das ist Code. Und das Werkzeug, zu dem ich wirklich greife, gibt dir beide, nebeneinander, und hält sie synchron.

Also hör ich auf, sie als Gegner zu behandeln, und sortier das Ganze lieber nach der Arbeit.

zwei Werkzeuge, zwei verschiedene Fragen

Ein WYSIWYG-Editor — „what you see is what you get", was du siehst, ist was du bekommst — zeigt dir die gerenderte Seite und lässt dich darauf klicken und tippen. Du änderst die Wörter, legst ein Bild ab, färbst einen Button um, und das Markup aktualisiert sich darunter, ohne dass du ein einziges Tag liest. Du bearbeitest das Ergebnis.

Ein Code-Editor zeigt dir die Quelle. Jedes <div>, jede Klasse, jedes Attribut, im Klartext zum Ändern von Hand. Du bearbeitest die Anweisungen, die das Ergebnis erzeugen.

Das ist die ganze Trennlinie. Das eine lässt dich die Seite anfassen; das andere den Code, der die Seite macht. Wer fragt „welcher ist besser", fragt eigentlich, ob eine Seite besser ist als der Code dahinter — und das ergibt keinen Sinn. Du brauchst den, der zur Änderung in deinem Kopf passt, jetzt gerade.

Wenn du die größere Karte der Wege willst, eine Datei zu öffnen und zu ändern, habe ich sie in wie man eine HTML-Datei bearbeitet ausgebreitet. Dieser Text nimmt nur die eine Abzweigung davon: visuell gegen Code.

jede Änderung in ihre Spalte

So würde ich die üblichen Aufgaben sortieren — nicht danach, welches Werkzeug „mächtiger" ist, sondern welches dich mit weniger Reibung ans Ziel bringt.

Die Änderung, die du machst	Greif zu	Warum
Wortlaut, einen Link oder ein Bild korrigieren	Visuell / WYSIWYG	Du siehst das Ergebnis im selben Moment, keine Tag-Jagd
Struktur umbauen — verschachteln, umordnen, Abschnitte hinzufügen	Code-Editor	Du musst die Tags selbst sehen und bewegen
Exakte Attribute setzen (ein aria-label, ein data--Wert, eine genaue Breite)	Code-Editor	Ein Klick greift nicht, was auf der Seite keinen sichtbaren Griff hat
Lernen, wie HTML wirklich funktioniert	Code-Editor	Der Sinn ist, die Tags zu lesen und zu schreiben, nicht sie zu verstecken
Die Seite jemandem ohne Code-Kenntnisse zum Textändern geben	Nur-Text-Modus (visuell)	Er sperrt das Layout, damit eine Wortänderung das Design nicht zerbricht
Den Code hinter etwas Sichtbarem finden	Zweiseitiger, synchroner Editor	Klick das Element an, und er springt zur passenden Zeile

Die meisten Streits über visuell gegen Code sind in Wahrheit zwei Leute, die an zwei verschiedene Zeilen dieser Tabelle denken und aneinander vorbeireden.

geben wir dem Code-Editor, was ihm zusteht

Ich baue ein visuelles Werkzeug, also will ich fair zur anderen Seite sein, weil sie es verdient.

Bei allem Strukturellen gewinnt der Code, und zwar deutlich. Einen Abschnitt über einen anderen ziehen, drei Elemente in einen neuen Container wickeln, die Einrückung so richten, dass du das Ding überhaupt lesen kannst — da willst du die Tags vor dir haben. Ein visueller Editor kann dir hier Widerstand leisten. Du klickst, und bist dir nie ganz sicher, welches Element du erwischt hast.

Exakte Attribute, dieselbe Geschichte. Für ein aria-label oder eine data-id gibt es keinen Button auf der Seite, also nichts zum Anklicken. Im Code tippst du es einfach.

Und wenn das Ziel ist, HTML zu lernen, ist der visuelle Editor der falsche Klassenraum. Er ist gebaut, um die Tags zu verstecken. Lernen heißt, sie zu sehen, sie kaputt zu machen, sie zu reparieren. Ein Code-Spielplatz wie die, die ich in den besten kostenlosen HTML-Editoren durchgegangen bin, schlägt jedes Zeigen-und-Klicken dafür.

Also nein, ich bin nicht hier, um dir zu sagen, Code-Editoren hätten ihre beste Zeit hinter sich. Sie sind das richtige Werkzeug für einen großen Teil echter Arbeit.

oft willst du mittendrin wechseln

Hier ist, was das „oder" verdeckt. Die meisten echten Änderungen sind nicht das eine oder das andere. Sie sind beides, in denselben fünf Minuten.

Sagen wir, du machst eine KI-generierte Seite fertig. Du tippst die Überschrift neu — visuell, in zwei Sekunden erledigt. Dann siehst du, dass der Button auf die falsche Stelle zeigt, und der Link ist kein sichtbarer Text, sondern ein href, vergraben im Tag, also willst du jetzt Code. Dann willst du die Seite noch mal ansehen, ob sie immer noch richtig sitzt. Visuell, Code, visuell, alles in einer einzigen kleinen Aufgabe.

Wenn deine beiden Werkzeuge getrennt sind — ein Browser zum Schauen, ein Texteditor für die Quelle — verbringst du die Änderung mit Speichern, Alt-Tabben, Neuladen. Diese Wechselkosten sind jedes Mal winzig und über einen Nachmittag riesig. Das ist der wahre Grund, warum „welcher ist besser" die falsche Frage ist. Du willst nicht einen von beiden. Du willst aufhören, den Wegzoll fürs Hin und Her zu zahlen.

die Version, in der du nicht wählen musst

Das ist die Lücke, für die ich HTML Tweak gebaut habe. Es stellt die visuelle Seite und den Code nebeneinander, synchron — ändere die Seite, der Code zieht nach; ändere den Code, die Seite zieht nach. Klick etwas Sichtbares an, und es lokalisiert dir den passenden Code, was die Tag-Jagd zum größten Teil erledigt.

Für den Nicht-Codierer-Fall gibt es einen Nur-Text-Modus, der Struktur und Stile sperrt, damit ein Kollege den Text umschreiben und die Anordnung physisch nicht verschieben kann. Ein „Erst-fragen"-Modus und ein voller Modus sind da, für wenn du doch tiefer rein willst.

Und die Ränder. Es öffnet eine einzige .html-Datei — kein Verwalter für ein React- oder Next-Projekt aus mehreren Dateien. Es läuft kostenlos im Browser und auch als eine einzelne Offline-Datei, die du behältst; der erste Aufruf braucht Internet, danach legt es sich in den Cache und läuft ohne. In Chrome oder Edge speichert es direkt in deine Datei zurück; andere Browser reichen dir eine heruntergeladene Kopie. Ohne Anmeldung, so oder so.

Es ersetzt keinen Code-Editor, um eine ganze Website zu bauen. Es ersetzt das Alt-Tabben, wenn du eine Seite fertigstellst.

die Fehler, die ich am häufigsten sehe

Die Verschwendung geht fast immer auf einen einzigen Reflex zurück — „visuell oder Code" als Entscheidung zu behandeln, die man einmal für die ganze Aufgabe trifft, statt frisch für jede Änderung. Sie zeigt sich auf drei Arten.

Eine Spur für die ganze Aufgabe wählen. Du entscheidest „das ist ein Code-Job" und quälst eine Fünf-Sekunden-Textänderung durch rohe Tags, oder du entscheidest „das ist ein visueller Job" und kannst dann das eine Attribut ohne Griff nicht setzen. Die Aufgabe hat keine Spur. Jede einzelne Änderung schon.

WYSIWYG auf einer Seite laufen lassen, deren Layout zählt, und zusehen, wie es abdriftet. Manche visuellen Editoren schreiben das Markup nebenbei um, und eine Textkorrektur schiebt den Abstand um eine Kerbe. Wenn das Design zu erhalten der Punkt ist, willst du strukturgesperrtes Bearbeiten, kein freies Spiel.

Zum falschen Werkzeug greifen, um zu lernen. Wenn du HTML verstehen willst, begrab es nicht unter einem visuellen Editor — lies die Tags. Und umgekehrt zählt genauso. Dich durch Code zu mahlen für einen Job, den ein Klick beenden würde, verschwendet genauso viel von deinem Tag, nur in die andere Richtung.

Also eine kleine Mutprobe. Wenn du dich das nächste Mal dabei ertappst, visuell gegen Code abzuwägen, verweigere die Frage. Öffne die Datei in HTML Tweak, halt den Code neben die Seite, und wechsle zwischen beiden, wie es jede Änderung verlangt.