Google Developers Italia: 10 anni di Chrome DevTools

10 anni di Chrome DevTools

24 settembre 2018

code { background-color: transparent } * { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; } Chrome compie 10 anni! Grazie per aver reso la community di sviluppo Web così aperta, collaborativa e solidale. DevTools trae ispirazione da innumerevoli altri progetti. Ecco una panoramica su come è nato e come è cambiato nel corso degli anni.

In principio, c'era FirebugImmagina per un momento che i browser non facciano parte degli strumenti di sviluppo. Come eseguiresti il debug di JavaScript? Avresti fondamentalmente 3 opzioni:

Disseminare chiamate window.alert() su tutto il codice.

Commentare sezioni di codice.

Fissare a lungo il codice finché gli dei JavaScript non ti suggeriscano l'anelata soluzione.

Come gestiresti i problemi di layout? E gli errori di rete? Anche in questo caso non potresti far altro che condurre laboriosi esperimenti sul codice. Questa era la realtà dello sviluppo Web fino al 2006. Poi è arrivato un piccolo strumento chiamato Firebug che ha cambiato tutto.

Uno screenshot del pannello Net di Firebug, ottenuto da Saying Goodbye to Firebug (sorgente e licenza)

Firebug era un'estensione di Firefox che consentiva di eseguire il debug, modificare e monitorare le pagine in tempo reale. Come sviluppatore Web, sei passato all'improvviso dall'assenza di visibilità nelle tue pagine ad avere quelle che sono essenzialmente le caratteristiche principali dei moderni strumenti di sviluppo. Riuscire a capire esattamente perché Firefox si comportasse così ha dato vita a una grande ondata di creatività sul Web. Senza Firebug, l'era del Web 2.0 non sarebbe stata possibile.

WebKit Web Inspector
Durante lo stesso periodo del lancio di Firebug, alcuni ingegneri di Google hanno iniziato a lavorare su un progetto che avrebbe poi portato a Chrome. Sin dall'inizio Chrome era un mashup di diverse librerie di codice. Nel caso del rendering, gli ingegneri di Chrome hanno optato per WebKit, ossia il progetto open source tuttora alla base di Safari. Un ulteriore vantaggio a favore di WebKit era l'avere in dotazione un pratico strumento chiamato Web Inspector.

Uno screenshot di Web Inspector, ottenuto da Web Inspector Redesign (sorgente e licenza)Proprio come nel caso del pannello Net di Firebug, probabilmente il Web Inspector originale ti risulterà familiare. Gran parte delle sue funzionalità è ancora disponibile nel pannello Elementi in Chrome DevTools. Web Inspector è stato lanciato pochi giorni dopo Firebug e Safari è stato il primo browser a raggruppare gli strumenti per sviluppatori direttamente nel browser.

L'era di Inspect Element
Chrome ha introdotto molte idee innovative nell'ecosistema dei browser, come la omnibox che combinava la ricerca e la barra degli indirizzi, e l'architettura multiprocesso che impediva a una scheda in sospeso di arrestare l'intero browser. Ma la nostra innovazione preferita era poter fornire agli sviluppatori strumenti di sviluppo in ogni build per ogni utente, grazie a un semplice clic del mouse.

Inspect Element in 2010
Prima di Chrome, gli strumenti per sviluppatori erano un'esperienza che richiedeva attivazione. Bisognava installare un'estensione, ad esempio Firebug, o abilitare alcuni flag, come avviene ancora oggi in Safari. Chrome è stato il primo browser a rendere accessibili gli strumenti per sviluppatori da tutte le istanze del browser. Vorremmo poter affermare di aver avuto la grande visione di creare un browser pensato per gli sviluppatori sin dall'inizio, ma la verità è che nelle sue prime fasi Chrome ha avuto molti problemi di compatibilità (il che ha senso poiché nessuno ne aveva pianificato la creazione) e dovevamo offrire agli sviluppatori Web una soluzione semplice che risolvesse questi problemi. Gli sviluppatori Web hanno confermato che era una funzionalità utile e quindi l'abbiamo tenuta.

L'era mobile

Per i primi anni del progetto DevTools, abbiamo essenzialmente aggiunto capitoli alle storie che Firebug e Web Inspector avevano creato. La svolta successiva nel nostro approccio a DevTools è avvenuta quando ci siamo resi conto che gli smartphone erano la nuova realtà.

La nostra prima missione in questo nuovo mondo era consentire agli sviluppatori di eseguire il debug di dispositivi mobili reali dai loro computer di sviluppo, ossia effettuare il debug remoto. Difatti DevTools era ben posizionato per gestire il debug remoto grazie a un'altra funzionalità dell'architettura multiprocesso di Chrome. Nelle prime fasi del progetto DevTools ci siamo resi conto che l'unica maniera in cui un debugger poteva accedere in modo affidabile al browser multiprocesso era attraverso un protocollo client-server, con il browser che fungeva da server e il debugger da client. Quando è arrivato Chrome mobile, era già dotato di protocollo, quindi abbiamo solo dovuto far comunicare i DevTools in esecuzione sul computer di sviluppo con Chrome in esecuzione sul dispositivo mobile tramite il protocollo. Questo protocollo costituisce ancora oggi la spina dorsale di DevTools, ed è ora conosciuto come il Chrome DevTools Protocol.

Debug remoto

Il debug remoto è stato un passo importante nella direzione giusta e fino a oggi è ancora lo strumento principale per garantire che i siti si comportino correttamente sui dispositivi mobili veri e propri. Nel corso del tempo, tuttavia, ci siamo resi conto che il debug remoto può rivelarsi laborioso. Durante le prime fasi di creazione di un sito o di una funzione, di solito bisogna ottenere solo un'approssimazione di primo ordine dell'esperienza mobile. Ciò ci ha spinto a creare un set di funzioni di simulazione mobile, quali ad esempio:

Emulazione precisa dell'area visibile mobile, simulando l'input basato sul tocco e sull'orientamento del dispositivo.

Limiti della connessione di rete, come nel caso di 3G e CPU, per simulare hardware per dispositivi mobili meno potenti.

Spoofing di user-agent, geolocalizzazione, dati dell'accelerometro e altro ancora.

Ci riferiamo collettivamente a queste funzioni chiamandole Modalità dispositivo.

Uno dei primi prototipi di Modalità dispositivo

Modalità dispositivo nel 2018

L'era della performance

Con l'avanzare dell'era mobile, le app di grandi dimensioni, come Gmail, oltrepassavano i limiti del Web. Bug in scala Gmail chiamati per gli strumenti in scala Gmail. Uno dei nostri principali contributi all'ecosistema degli strumenti è stato mostrare una scomposizione play-by-play di esattamente tutto ciò che Chrome doveva fare per visualizzare una pagina.

Il pannello Timeline originale, come annunciato in Do More with Chrome Developer Tools

Il Pannello performance in 2018

Questi strumenti sono stati un passo importante nella giusta direzione, ma per individuare le opportunità di ottimizzazione è stato necessario conoscere ogni singolo dettaglio su come i browser operano e setacciano grandi quantità di dati. Ultimamente abbiamo sfruttato questo principio per fornire informazioni guidate sulla performance. Il nuovo motore Lighthouse alimenta il pannello Audits ed è anche disponibile come modulo Node per l'integrazione con i sistemi CI.

Suggerimenti sulla performance nel pannello Audits

L'era di Node.js

Fino approssimativamente al 2014, abbiamo concepito DevTools soprattutto come uno strumento per la creazione di grandi esperienze su Chrome. Il successo di Node ci ha spinto a riconsiderare il nostro ruolo nell'ecosistema Web.
Nei primi anni di Node, gli sviluppatori coinvolti si sono trovati in una situazione simile a quella degli sviluppatori Web prima di Firebug o degli sviluppatori Gmail prima del pannello Timeline: la scala delle app Node superava la scala degli strumenti Node. Considerando che Node viene eseguito sul motore JavaScript di Chrome, V8, DevTools si è rivelato il candidato ideale per colmare questo divario. Il supporto per il debug di Node con DevTools è arrivato nel 2016 e includeva le consuete funzioni di DevTools, quali breakpoint, esecuzione di istruzioni del codice, blackboxing, mappe di origine per il codice transpiled e così via.

Node Connection Manager

L'ecosistema del protocollo DevTools

Il nome Chrome DevTools Protocol (CDP) suggerirebbe un'API che solo DevTools può utilizzare. In realtà ha un significato più ampio, è l'API che consente l'accesso programmatico a Chrome. Negli ultimi anni alcune librerie e applicazioni di terze parti hanno aderito all'ecosistema del protocollo:

chrome-remote-interface fornisce l'accesso JavaScript di basso livello al protocollo.

Puppeteer lo porta al livello successivo di astrazione e consente l'automazione del browser Headless Chrome, sempre valido, con l'attuale API JavaScript.

Lighthouse automatizza il processo di ricerca dei modi di migliorare le prestazioni e la qualità delle pagine.

Siamo contenti che migliaia di progetti dipendano da questi pacchetti che abilitano un'interazione completa con Chrome. Se lavori nel settore degli strumenti o dell'automazione, ti consigliamo di andare a vedere il protocollo per scoprire nuove opportunità nel tuo dominio. Ad esempio, i team VS Code e WebStorm lo utilizzano per abilitare il debug di JavaScript nei rispettivi IDE.

Novità in arrivo

La nostra missione principale è fornire strumenti che aiutino a creare esperienze straordinarie sul Web. Ci affidiamo enormemente al tuo feedback per decidere quali prodotti o funzionalità creare.

Rimani aggiornato sulle nuove funzionalità con i nostri post What's New

Proponici nuove funzionalità nella mailing list

Segnalaci i bug nel Chromium Bug Tracker

Seguici su Twitter per scoprire nuove funzionalità e i flussi di lavoro di dimensioni ridotte

Pubblica le tue domande su Stack Overflow per ricevere assistenza su come usare DevTools

Prendi in mano la questione e contribuisci a DevTools

Grazie per aver creato una community così vibrante. Continuiamo a creare il Web insieme per altri 10 anni!

Pubblicato dal team Chrome DevTools

10 anni di Chrome DevTools

Etichette

Archivio Blog

Feed