Ritiro della modifica in tempo reale delle origini JavaScript in Chrome DevTools

Data di pubblicazione: 22 ottobre 2025

Chrome sta ritirando la funzionalità di modifica in tempo reale delle origini JavaScript. Verrà spostato dietro un flag sperimentale in Chrome 142 e prevediamo di rimuoverlo completamente in Chrome 145 (febbraio 2026). Non rimuoveremo altre potenti funzionalità relative ai file di origine come Override locali, Spazi di lavoro o Snippet, che continueranno a essere completamente supportate.

Il team di Chrome DevTools lavora costantemente per fornire agli sviluppatori strumenti potenti e affidabili. Nell'ambito di questo impegno, a volte dobbiamo ritirare le funzionalità che non sono più utili. Questa decisione non è stata presa alla leggera e si basa sul costo di manutenzione sproporzionatamente elevato della funzionalità, sul suo scarso utilizzo e sull'esistenza di alternative moderne superiori. Siamo consapevoli che le modifiche a qualsiasi workflow possono essere disruptive e questo post ha lo scopo di spiegare chiaramente il nostro ragionamento.

Che cos'era la modifica live?

La modifica in tempo reale consente di sostituire i contenuti di un file di script in fase di runtime, al volo. Funzionava anche quando lo script era in pausa in un punto di interruzione. Puoi modificare il codice JavaScript nel riquadro Sources e applicare la modifica salvando il file (Command+S / Ctrl+S). Il debugger quindi applica patch alle funzioni già definite in fase di runtime. Se la funzione modificata si trovava nello stack di chiamate, verrà riavviata.

L'obiettivo era fornire un modo per testare piccole modifiche senza ricaricare completamente la pagina, altrimenti lo stato dell'applicazione verrebbe cancellato. In questo modo, il suo obiettivo era simile a quello che si ottiene con la sostituzione a caldo dei moduli (HMR) negli stack di sviluppo moderni.

Perché lo stiamo rimuovendo?

L'esperienza utente per la modifica live è sempre stata difficile. La scorciatoia correlata (Command+S / Ctrl+S) è in genere associata al salvataggio di un file, ma non a ulteriori effetti collaterali, il che potrebbe sorprendere. In caso di errore, il feedback può essere poco chiaro: gli Strumenti per sviluppatori potrebbero mostrare un messaggio di avviso come "LiveEdit failed: Functions that are on the stack (currently being executed) can not be edited", che può essere trascurato, lasciando lo sviluppatore incerto se la modifica è stata applicata.

La situazione peggiora ulteriormente quando la modifica in tempo reale interagisce con altre funzionalità di DevTools correlate ai file sorgente. Ad esempio, la modifica in tempo reale del contenuto di uno snippet di DevTools potrebbe confondere DevTools in riferimento all'identità dell'origine dello snippet, con conseguente visualizzazione della nuova versione come file di sola lettura. Quando la funzionalità Workspaces è attivata, DevTools potrebbe rilevare le modifiche alla sorgente nel file system e applicarle senza problemi alla pagina pubblicata. Questo comportamento potrebbe essere previsto o sorprendente a seconda dell'ambiente dell'utente e della configurazione della toolchain.

Il problema originale che la modifica in tempo reale cercava di risolvere, ovvero apportare modifiche senza perdere lo stato dell'applicazione, ora viene risolto in modo più efficace dalla sostituzione a caldo dei moduli (HMR). HMR è una funzionalità standard nei framework di sviluppo web moderni come React, Angular o Vue. Ottiene lo stesso effetto nello spazio utente e a un livello di astrazione più elevato. La modifica in tempo reale in DevTools potrebbe interferire con il comportamento previsto, causando un funzionamento imprevisto e difettoso.

Questi problemi contribuiscono a un'esperienza utente difficile. Inoltre, come confermato dalle nostre statistiche di utilizzo, la funzionalità non è diventata una parte fondamentale dei flussi di lavoro della maggior parte degli sviluppatori. Il numero di utenti che utilizzano questa funzionalità è molto basso, con una tendenza al ribasso.

Costi di manutenzione elevati e complessità tecnica

La sostituzione del codice in una pagina pubblicata non è semplice in termini di definizione di una semantica ragionevole, ma anche nella sua implementazione. Comporta un costo di ingegneria significativo per il motore JavaScript V8 e per Chrome DevTools, richiedendo un'attenta valutazione in molte parti di V8. Se non si presta la massima attenzione, la modifica in tempo reale può causare arresti anomali difficili da riprodurre e da eseguire il debug. Ad esempio, se la nuova versione di una funzione contiene un numero diverso di espressioni regolari, oggetti o valori letterali di funzione rispetto alla versione precedente, la struttura dei dati che tiene traccia di questi valori letterali deve essere riconciliata con attenzione.

Questo carico di manutenzione rallenta l'implementazione di nuove funzionalità JavaScript e sottrae risorse al miglioramento delle funzionalità di DevTools più utilizzate.

Questa complessità ha portato anche a molti scenari non supportati, tra cui:

  • Modifica di una funzione che si trova nello stack di chiamate, ma non nel frame più in alto.
  • Modifica di funzioni asincrone o generatori.
  • Modifica del codice di primo livello di un modulo ES.

Alternative

Come accennato in precedenza, la sostituzione a caldo dei moduli (HMR) è un'alternativa più popolare e superiore alla modifica in tempo reale per alcuni aspetti chiave:

  • La modifica in tempo reale sostituisce parti della versione precedente della pagina pubblicata a livello di codice sorgente. D'altra parte, HMR sostituisce la versione precedente a livello di astrazione previsto dal framework web, aumentando la possibilità di eseguire la migrazione corretta dello stato del componente e dell'applicazione durante un aggiornamento live.
  • HMR funziona sul codice sorgente creato. Modifichi i file originali (ad esempio TypeScript, JSX) nell'editor e lo strumento di compilazione gestisce l'aggiornamento nel browser, mentre la modifica live interessa solo i file di origine di cui è stato eseguito il deployment, che in molti casi sono l'output di compilazione generato dalla toolchain.
  • È robusto e ben integrato. L'HMR è una parte fondamentale della toolchain di sviluppo moderna, in quanto fornisce un'esperienza affidabile con un feedback chiaro in caso di esito positivo o negativo degli aggiornamenti.

La rimozione della modifica dal vivo non influisce su altre due potenti funzionalità di Chrome DevTools:

  • Override locali ti consente di intercettare una richiesta di rete e pubblicare un file locale. È ideale per prototipare le modifiche su un sito di produzione attivo in cui non hai accesso al codice sorgente. Le modifiche vengono mantenute anche dopo il ricaricamento della pagina.
  • Workspace trasforma DevTools in un editor più potente creando un binding bidirezionale tra il riquadro Sources e i file di progetto locali. Quando salvi una modifica in DevTools, questa viene salvata direttamente nel file system. Questo potrebbe quindi attivare l'HMR o il processo di ricarica dinamica del server di sviluppo.

Conclusione

Stiamo rimuovendo la modifica live perché i costi di manutenzione elevati e il basso utilizzo la rendono insostenibile. L'ecosistema di sviluppo web moderno ha fornito una soluzione di gran lunga superiore con la sostituzione a caldo dei moduli.

Ritirando questa funzionalità, possiamo concentrare i nostri sforzi di ingegneria sulle parti più efficaci di Chrome DevTools. Le tempistiche per la rimozione sono le seguenti:

  • Prossimamente: la funzionalità verrà spostata in un esperimento in Chrome 142, disponibile come flag di Chrome (chrome://flags/#devtools-live-edit).
  • Chrome 145 (febbraio 2026): la funzionalità e il flag di Chrome corrispondente verranno rimossi completamente.

Saremmo felici di ricevere il tuo feedback in merito a questa modifica. Aggiungi i tuoi commenti al problema di feedback.