Scaricare i siti web che utilizzano core-js

Informazioni su core-js

Quasi nessuno decide di installare core-js. Essendo una libreria modulare di polyfill, arriva all’interno di un bundle JavaScript, inclusa come dipendenza transitiva di un preset di un transpiler o di un modello di partenza di un framework, e spesso la persona responsabile del sito web non ne ha mai sentito parlare. Chi analizza il web alla ricerca di core-js non sta quindi misurando l’adozione nel senso consueto di una preferenza o di un acquisto. Quello che la scansione misura sono i residui delle pipeline di build, e una volta accettata questa chiave di lettura i dati diventano più utili, non meno.

Un polyfill esiste perché le funzionalità più recenti del linguaggio continuino a funzionare nei motori più vecchi. Un sito che distribuisce core-js è un sito la cui toolchain è stata configurata, a un certo punto, per supportare browser che i suoi visitatori potrebbero aver abbandonato da tempo, e una configurazione del genere viene rivista di rado. Il peso del front end, i budget di velocità delle pagine e il lento declino dei siti non mantenuti derivano tutti dallo stesso fatto. Pubblicata per la prima volta nel 2014 e distribuita con licenza MIT, la libreria è sopravvissuta a diverse generazioni di politiche di supporto dei browser, ed è per questo che un bundle servito oggi può ancora contenere shim di compatibilità per motori che quasi nessuno usa più.

È la scala a dare forma a questo schema. A ottobre 2026 rileviamo core-js su 20.429.135 siti, di cui 9.880.391 negli Stati Uniti, e l’insieme è fortemente sbilanciato verso l’estensione .com. Qui la geografia dice poco su dove viene scritta la libreria e molto su dove si concentra lo sviluppo web commerciale fortemente basato sui framework, perché il codice viaggia insieme agli strumenti che agenzie e team di prodotto adottano come standard.

Il rilevamento procede per inferenza e sottostima la diffusione reale. Le impronte sopravvivono alla minificazione in modo irregolare, i bundler rinominano ed eliminano il codice inutilizzato con il tree shaking, e una build che incorpora solo una manciata di polyfill potrebbe non lasciare assolutamente nulla di riconoscibile. La nostra scheda per questa voce, inoltre, non contiene una ripartizione per versione utilizzabile, quindi il dataset può indicare dove la libreria è presente ma non quale release viene distribuita. Chi pianifica un lavoro che dipende da una release specifica deve trattare l’elenco come un insieme di candidati e verificare sui siti che contano.

Le persone che ci chiedono questo elenco rientrano in alcuni gruppi. I team di sicurezza e della supply chain vogliono conoscere la diffusione di un pacchetto di cui moltissimi si fidano e che ha una base ristretta di manutentori, perché è la diffusione a rendere una dipendenza degna di essere attaccata. I fornitori di soluzioni per le prestazioni vogliono i siti che distribuiscono codice di compatibilità legacy di cui non hanno più bisogno. I manutentori di framework e browser vogliono prove concrete prima di abbandonare il supporto a qualcosa di vecchio. Controllare un singolo dominio non risponde a nessuna di queste domande, e controllare un singolo dominio è comunque facile, perché il pannello per sviluppatori di un browser lo fa in pochi istanti.

Quello che un elenco scaricabile aggiunge è la query inversa. Invece di chiedersi che cosa usa un sito noto, ci si chiede quali siti di un paese, sotto una determinata estensione, su una determinata piattaforma di ecommerce o dietro una determinata rete di distribuzione contengono anche questa dipendenza, e si ottiene l’intera popolazione sotto forma di righe da incrociare con i propri dati sugli account. Ricostruire tutto questo a partire da ricerche per singolo dominio significa scansionare da sé l’intero spazio dei nomi registrati, ed è proprio il lavoro che abbiamo già svolto.