Veröffentlicht: 22. Oktober 2025
Die Funktion Livebearbeitung von JavaScript-Quellen wird in Chrome eingestellt. Sie wird in Chrome 142 hinter einem Testflag platziert und wir planen, sie in Chrome 145 (Februar 2026) vollständig zu entfernen. Wir entfernen keine anderen leistungsstarken Funktionen im Zusammenhang mit Quelldateien wie lokale Überschreibungen, Arbeitsbereiche oder Snippets, die weiterhin vollständig unterstützt werden.
Das Chrome-Entwicklertools-Team arbeitet ständig daran, Entwicklern leistungsstarke und zuverlässige Tools zur Verfügung zu stellen. Im Rahmen dieser Bemühungen müssen wir manchmal Funktionen einstellen, die nicht mehr die gewünschte Leistung erbringen. Diese Entscheidung wurde nicht leichtfertig getroffen und basiert auf den unverhältnismäßig hohen Wartungskosten der Funktion, der geringen Nutzung und dem Vorhandensein moderner Alternativen, die besser sind. Wir wissen, dass Änderungen an Workflows störend sein können. Deshalb möchten wir in diesem Beitrag unsere Beweggründe erläutern.
Was war die Live-Bearbeitung?
Mit der Live-Bearbeitung können Sie den Inhalt einer Skriptdatei zur Laufzeit im Handumdrehen ersetzen. Das funktionierte sogar, wenn das Skript an einem Haltepunkt pausiert wurde. Sie können JavaScript-Code im Bereich „Quellen“ ändern und die Änderung anwenden, indem Sie die Datei speichern (Befehlstaste+S / Strg+S). Der Debugger würde dann Funktionen patchen, die bereits zur Laufzeit definiert wurden. Wenn sich die geänderte Funktion im Aufrufstack befand, würde sie ebenfalls neu gestartet.
Ziel war es, kleine Änderungen ohne vollständiges Neuladen der Seite zu testen, da dadurch der Anwendungsstatus gelöscht würde. Das Ziel war also ähnlich wie bei Hot Module Replacement (HMR) in modernen Entwicklungsstacks.
Warum wird sie entfernt?
Die Nutzerfreundlichkeit der Livebearbeitung war schon immer eine Herausforderung. Die zugehörige Tastenkombination (Befehlstaste + S / Strg + S) wird normalerweise mit dem Speichern einer Datei in Verbindung gebracht, aber nicht mit weiteren Nebeneffekten, was überraschend sein kann. Wenn das nicht funktioniert, kann das Feedback unklar sein: In den DevTools wird möglicherweise eine Warnmeldung wie „LiveEdit failed: Functions that are on the stack (currently being executed) can not be edited“ (LiveEdit fehlgeschlagen: Funktionen, die sich im Stack befinden (aktuell ausgeführt werden), können nicht bearbeitet werden) angezeigt, die übersehen werden kann. Der Entwickler ist dann unsicher, ob seine Änderung angewendet wurde.
Noch schlimmer wird es, wenn die Live-Bearbeitung mit anderen DevTools-Funktionen für Quelldateien interagiert. Wenn Sie beispielsweise den Inhalt eines DevTools-Snippets live bearbeiten, kann es sein, dass DevTools die Identität der Snippet-Quelle nicht mehr richtig zuordnen kann. Die neue Version wird dann als schreibgeschützte Datei angezeigt. Wenn die Funktion „Workspaces“ aktiviert ist, können die Entwicklertools Quelländerungen im Dateisystem erkennen und diese Änderungen nahtlos auf die Live-Seite anwenden. Dieses Verhalten kann je nach Umgebung des Nutzers und Einrichtung der Toolchain erwartet oder überraschend sein.
Das ursprüngliche Problem, das mit der Live-Bearbeitung gelöst werden sollte – Änderungen vornehmen, ohne den Anwendungsstatus zu verlieren – wird jetzt effektiver durch Hot Module Replacement (HMR) gelöst. HMR ist eine Standardfunktion in modernen Webentwicklungs-Frameworks wie React, Angular oder Vue. Damit wird derselbe Effekt im Userspace und auf einer höheren Abstraktionsebene erzielt. Die Live-Bearbeitung in den Entwicklertools kann zu unerwartetem und fehlerhaftem Verhalten führen.
Diese Probleme führen zu einer schlechten Nutzererfahrung. Auch unsere Nutzungsstatistiken bestätigen, dass die Funktion für die meisten Entwickler nicht zu einem wichtigen Bestandteil ihrer Arbeitsabläufe geworden ist. Die Anzahl der Nutzer, die diese Funktion verwenden, ist sehr gering und nimmt weiter ab.
Hohe Wartungskosten und technische Komplexität
Das Ersetzen von Code auf einer Live-Seite ist nicht einfach, sowohl in Bezug auf die Definition einer angemessenen Semantik als auch auf die Implementierung. Dies verursacht erhebliche Entwicklungskosten für die V8 JavaScript-Engine und die Chrome-Entwicklertools und erfordert eine sorgfältige Berücksichtigung in vielen Teilen von V8. Wenn Sie nicht sehr vorsichtig sind, kann die Live-Bearbeitung zu schwer reproduzierbaren und schwer zu debuggenden Abstürzen führen. Wenn die neue Version einer Funktion beispielsweise eine andere Anzahl von regulären Ausdrücken, Objekt- oder Funktionsliteralen als die frühere Version enthält, muss die Datenstruktur, in der diese Literale erfasst werden, sorgfältig abgeglichen werden.
Dieser Wartungsaufwand verlangsamt die Implementierung neuer JavaScript-Funktionen und zieht Ressourcen ab, die für die Verbesserung häufiger verwendeter Entwicklertools-Funktionen benötigt werden.
Diese Komplexität führte auch zu vielen nicht unterstützten Szenarien, darunter:
- Bearbeiten einer Funktion, die sich im Aufrufstapel, aber nicht im obersten Frame befindet.
- Asynchrone Funktionen oder Generatoren bearbeiten
- Bearbeiten des Codes auf oberster Ebene eines ES-Moduls.
Alternativen
Wie bereits erwähnt, ist Hot Module Replacement (HMR) eine beliebtere Alternative, die in einigen wichtigen Aspekten besser als die Live-Bearbeitung ist:
- Beim Live-Bearbeiten werden Teile der älteren Version der Live-Seite auf Quellcodeebene ersetzt. HMR ersetzt die ältere Version hingegen auf der vom Web-Framework vorgesehenen Abstraktionsebene, was die Wahrscheinlichkeit erhöht, dass der Komponenten- und Anwendungsstatus während eines Live-Updates korrekt migriert wird.
- HMR funktioniert mit Ihrem selbst geschriebenen Quellcode. Sie bearbeiten Ihre Originaldateien (z. B. TypeScript, JSX) in Ihrem Editor und das Build-Tool kümmert sich um die Aktualisierung im Browser. Live-Bearbeitung wirkt sich nur auf bereitgestellte Quelldateien aus, die in vielen Fällen die vom Toolchain generierte Build-Ausgabe sind.
- Sie ist robust und gut integriert. HMR ist ein wichtiger Bestandteil der modernen Entwicklungstoolchain und bietet eine zuverlässige Erfahrung mit klarem Feedback, wenn Updates erfolgreich sind oder fehlschlagen.
Das Entfernen der Livebearbeitung hat keine Auswirkungen auf zwei weitere leistungsstarke Funktionen in Chrome DevTools:
- Mit Lokale Überschreibungen können Sie eine Netzwerkanfrage abfangen und stattdessen eine lokale Datei bereitstellen. Sie ist ideal, um Änderungen auf einer Live-Produktionswebsite zu testen, auf der Sie keinen Zugriff auf den Quellcode haben. Die Änderungen bleiben auch nach dem Neuladen der Seite erhalten.
- Mit Arbeitsbereichen wird DevTools zu einem leistungsstärkeren Editor, da eine bidirektionale Bindung zwischen dem Bereich „Quellen“ und Ihren lokalen Projektdateien erstellt wird. Wenn Sie eine Änderung in den DevTools speichern, wird sie direkt in Ihrem Dateisystem gespeichert. Dadurch wird dann möglicherweise der HMR- oder Live-Reload-Prozess Ihres Entwicklungsservers ausgelöst.
Fazit
Wir entfernen die Live-Bearbeitung, da die hohen Wartungskosten und die geringe Nutzung sie unrentabel machen. Das moderne Webentwicklungs-Ökosystem bietet mit Hot Module Replacement eine weitaus bessere Lösung.
Durch die Einstellung dieser Funktion können wir uns auf wirkungsvollere Bereiche der Chrome-Entwicklertools konzentrieren. Zeitplan für die Entfernung:
- In naher Zukunft: Die Funktion wird in Chrome 142 in ein Experiment verschoben, das als Chrome-Flag (chrome://flags/#devtools-live-edit) verfügbar ist.
- Chrome 145 (Februar 2026): Die Funktion und das entsprechende Chrome-Flag werden vollständig entfernt.
Wir freuen uns über Ihr Feedback zu dieser Änderung. Fügen Sie Ihre Kommentare dem Feedback-Problem hinzu.