Seleziona e configura gli strumenti di creazione in base alle best practice.
Oggi web.dev lancia una nuova iniziativa chiamata tooling.report. Si tratta di un sito web che offre agli sviluppatori web una panoramica delle funzionalità supportate in una selezione di strumenti di creazione popolari. Abbiamo creato questo sito per aiutarti a scegliere lo strumento di creazione giusto per il tuo prossimo progetto, decidere se vale la pena eseguire la migrazione da uno strumento a un altro o per capire come incorporare le best practice nella configurazione degli strumenti e nel codebase. Gli strumenti hanno aree di interesse diverse e soddisfano un insieme di esigenze diverse, il che significa che la selezione e la configurazione degli strumenti comporta il raggiungimento di compromessi. Con strumentoing.report, il nostro obiettivo è spiegare questi compromessi e documentare come seguire le best practice con ogni strumento di creazione.
Sembra interessante? Visita Tooling.report per iniziare a esplorare o continua a leggere per saperne di più su perché e come abbiamo sviluppato questo sito.
Creare strumenti spesso ostacolano
In GoogleChromeLabs abbiamo creato app web come Squoosh e Proxx, oltre a siti web come quello per il Chrome Dev Summit 2019. Come per qualsiasi progetto di sviluppo web, in genere iniziamo parlando dell'infrastruttura del progetto come l'ambiente di hosting, i framework e la configurazione del nostro strumento di creazione. L'infrastruttura viene aggiornata man mano che il progetto avanza: vengono aggiunti nuovi plug-in per supportare i framework o le tecniche che adottiamo oppure il modo in cui scrivi il codice cambia in modo che i nostri strumenti di creazione capiscano meglio gli obiettivi che stiamo cercando di raggiungere. Durante questo processo, ci siamo accorti spesso che gli strumenti che selezioniamo finiscono per ostacolare il processo.
Il nostro team si impegna a fornire la migliore esperienza web agli utenti, il che spesso si traduce in un perfezionamento del modo in cui le risorse di frontend vengono assemblate e fornite. Ad esempio, se uno script del thread principale e uno script del worker web hanno dipendenze condivise, vorremmo scaricare le dipendenze una volta anziché raggrupparle due volte per ogni script. Alcuni strumenti supportano questa funzionalità fin dal primo avvio, altri richiedono un notevole impegno per la personalizzazione per modificare i comportamenti predefiniti, altri invece è completamente impossibile.
Questa esperienza ci ha portato a capire cosa possono e non possono fare i diversi strumenti di creazione. La nostra speranza era quella di creare un elenco di controllo per le funzionalità, in modo da poter valutare e scegliere lo strumento più adatto al progetto la prossima volta che iniziamo un nuovo progetto.
Il nostro approccio
Come possiamo valutare e confrontare diversi strumenti di creazione in un unico posto? Lo abbiamo affrontato scrivendo scenari di test.
Il nostro team ha discusso e progettato criteri di test che riteniamo rappresentino le best practice per lo sviluppo web. Ci siamo concentrati in particolare su come offrire esperienze utente veloci, reattive e fluide, escludendo intenzionalmente i test relativi all'esperienza degli sviluppatori per evitare di misurare due risultati incomparabili.
Una volta creato l'elenco di test, abbiamo scritto uno script di build per ogni strumento al fine di verificare se lo strumento soddisfa i criteri di successo del test. All'inizio abbiamo deciso di esaminare Webpack v4, Rollup v2 e Parcel v2. Abbiamo anche testato Browserify + Gulp, poiché molti progetti utilizzano ancora questa configurazione. Affinché un test abbia esito positivo, è possibile utilizzare solo le funzionalità dello strumento documentate pubblicamente o un plug-in per lo strumento. Dopo aver scritto il set iniziale di test, abbiamo collaborato con gli autori dello strumento di creazione per assicurarci di utilizzare i loro strumenti correttamente e di rappresentarli in modo corretto.
Usiamo solo ${tool_name}. Mi interessa ancora?
In molti team ci sono persone dedicate alla manutenzione dell'infrastruttura di build e altri membri del team potrebbero non avere mai la possibilità di fare una scelta quando si tratta di creare strumenti. Ci auguriamo che questo sito ti sia utile anche per te, come modo per definire le aspettative in merito agli strumenti su cui fai affidamento. Per ogni test, abbiamo incluso una spiegazione dell'importanza del test insieme a risorse aggiuntive. Se vuoi adottare una best practice con lo strumento che preferisci, la configurazione del test nel nostro repository contiene i file di configurazione necessari.
Posso contribuire al sito?
Se ritieni che una determinata funzionalità debba essere testata e al momento non sia disponibile, proponila in merito a un problema di GitHub per avviare la discussione. Il nostro obiettivo è racchiudere casi d'uso reali ed eventuali test aggiuntivi che valutino meglio questi risultati sono ben accetti.
Se vuoi scrivere test per strumenti che non abbiamo incluso nel set iniziale, accogliamo con favore anche questo! Consulta il sito CONTRIBUTING.md per ulteriori informazioni.