Le Web API native del browser che nel 2026 hanno reso inutili molte librerie JavaScript

Le Web API native del browser che nel 2026 hanno reso inutili molte librerie JavaScript

Ogni volta che avvio un nuovo progetto e apro il `package.json` di una codebase esistente trovo quasi sempre la stessa cosa: decine di dipendenze installate per risolvere problemi che il browser, nel 2026, risolve già da solo. Non è un giudizio sul lavoro di chi le ha scritte, dal momento che molte di quelle librerie erano indispensabili quando nascevano. È soltanto che il web è andato avanti, e l'ecosistema JavaScript non sempre si è aggiornato alla stessa velocità.

La verità è che una parte consistente del codice che installiamo nei nostri progetti ha smesso di essere necessaria. Non tutto, di certo, e non per ogni caso d'uso, ma abbastanza da giustificare una revisione di quello che consideriamo "standard". In questo articolo andrò a mostrare quali API native del browser sono mature al punto da sostituire librerie che usiamo per abitudine piuttosto che per necessità concreta.

Perché continuiamo a installare quello che già abbiamo

Prima di entrare nel merito delle API specifiche, vale la pena capire perché questo succede. Il motivo principale è l'inerzia: quando si lavora su una codebase esistente, si tende a replicare i pattern già presenti. Se il progetto usa Axios per le chiamate HTTP, si continua a usare Axios, anche se il Fetch nativo ormai copre tutti i casi d'uso rilevanti. Se c'è Lodash, si usa Lodash, anche per operazioni banali come il debounce o il cloning di oggetti semplici.

Il secondo motivo è la fiducia nei confronti delle API native. Fino a qualche anno fa era comprensibile: il browser support era frammentato, le API erano incomplete o con bug noti, e una libreria ben mantenuta offriva garanzie che il nativo non poteva dare. Quest'ultimo aspetto è cambiato in modo significativo negli ultimi anni, dal momento che i browser moderni hanno raggiunto un livello di consistenza e maturità che rende molte di queste preoccupazioni obsolete.

Il terzo motivo, infine, è semplicemente la conoscenza. Molte API native non vengono insegnate nei corsi, non compaiono nei tutorial più popolari, e dunque rimangono sconosciute anche a sviluppatori con anni di esperienza. Di fatto, l'ecosistema npm è molto più visibile della documentazione MDN nei risultati di ricerca di chi cerca una soluzione rapida a un problema concreto.

Intersection Observer: addio ai listener sullo scroll

Una delle API più sottovalutate, seppur sia disponibile su tutti i browser moderni da anni, è l'Intersection Observer. Fino a non molto tempo fa, per rilevare quando un elemento entrava o usciva dal viewport, l'approccio standard era attaccare un listener all'evento `scroll` della finestra, calcolare le coordinate dell'elemento con `getBoundingClientRect()`, e applicare una logica condizionale. Questo approccio ha un problema fondamentale: gira sul thread principale, e su pagine complesse può causare problemi di performance significativi, in particolar modo su dispositivi mobili o connessioni lente.

L'Intersection Observer risolve questo problema in modo ELEGANTE. Non gira sul thread principale, è nativo e ottimizzato internamente dal browser, e permette di osservare quando un elemento interseca un target (tipicamente il viewport) senza scrivere una riga di logica geometrica. Nel mio caso, l'ho usato per implementare il lazy loading di immagini su progetti in cui non volevo dipendenze aggiuntive, e per gestire le animazioni che entrano in scena quando una sezione diventa visibile durante lo scroll.

Il codice di base è questo:

```javascript const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { entry.target.classList.add('visible'); observer.unobserve(entry.target); } }); }, { threshold: 0.2 });

document.querySelectorAll('.animate-on-scroll').forEach((el) => { observer.observe(el); }); ```

Nei progetti che seguo ho sostituito diverse librerie di animazione scroll con questa API, riducendo il bundle size in modo misurabile senza perdere funzionalità. Il parametro `threshold: 0.2` indica che l'osservatore si attiva quando il 20% dell'elemento è visibile nel viewport, un valore che si regola facilmente in base alle esigenze specifiche del progetto.

Fetch API e AbortController: Axios non è più necessario

Axios è una libreria che rispetto, ma devo dire con onestà che nel 2026 il Fetch nativo è maturo al punto da coprire tutti i casi d'uso che giustificavano la sua adozione. Autenticazione tramite header, gestione degli errori HTTP, timeout, cancellazione delle richieste: tutto questo si fa con le API native senza aggiungere dipendenze al progetto.

Il caso più citato a favore di Axios era la possibilità di cancellare una richiesta in corso e gestire i timeout in modo semplice. Con AbortController, quest'ultima funzionalità è nativa da anni:

```javascript const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000);

try { const response = await fetch('/api/data', { signal: controller.signal, }); if (!response.ok) { throw new Error(`HTTP error: ${response.status}`); } const data = await response.json(); return data; } catch (err) { if (err.name === 'AbortError') { console.log('Richiesta annullata dopo 5 secondi'); } throw err; } finally { clearTimeout(timeout); } ```

Questo pattern, seppur leggermente più verboso rispetto ad Axios, non richiede installazione, non aggiunge peso al bundle, e garantisce lo stesso risultato pratico. Nei progetti che seguo, quando si tratta di applicazioni nuove, preferisco sempre il Fetch nativo e tendo a introdurre Axios soltanto se è già presente nella codebase e rimuoverlo richiederebbe un refactoring non giustificato dal valore atteso in quel momento.

C'è anche un dettaglio che spesso sfugge: il Fetch nativo non lancia un errore per le risposte HTTP con status 4xx o 5xx. Restituisce una risposta con `response.ok === false`, e tocca a te decidere cosa farne. Dunque il check esplicito su `response.ok` non è opzionale: è parte del contratto che devi rispettare quando scrivi codice affidabile con il Fetch nativo.

Resize Observer: quando le media query non bastano

Un altro caso classico di "libreria installata per abitudine" riguarda il rilevamento delle variazioni dimensionali degli elementi. Il classico listener su `window.resize` rileva il resize dell'intera finestra, ma non tiene conto di cosa succede a un singolo elemento quando cambia la sua dimensione indipendentemente dalla finestra, per esempio quando un pannello laterale si espande o si contrae in risposta a un'azione dell'utente.

Il Resize Observer risolve questo problema in modo preciso, osservando le variazioni di dimensione di un elemento specifico senza alcun polling:

```javascript const resizeObserver = new ResizeObserver((entries) => { for (const entry of entries) { const width = entry.contentRect.width; if (width < 400) { entry.target.classList.add('compact'); } else { entry.target.classList.remove('compact'); } } });

resizeObserver.observe(document.querySelector('.sidebar')); ```

Ho usato questo pattern in un progetto con una dashboard configurabile, dove certi widget dovevano adattare il proprio layout in base allo spazio disponibile nel pannello in cui erano inseriti, non in base alla dimensione della finestra del browser. Senza Resize Observer avrei dovuto installare una libreria esterna o costruire una soluzione custom con polling, che è di fatto la soluzione peggiore possibile dal punto di vista delle performance, dal momento che il polling significa controllare attivamente lo stato di un elemento a intervalli regolari anche quando non sta succedendo nulla.

Clipboard API: copiare e incollare senza librerie

Quante volte hai cercato "copy to clipboard javascript" e hai trovato soluzioni che usano `document.execCommand('copy')`, una funzione deprecata da anni, oppure librerie di terze parti installate per fare una cosa sola? La Clipboard API nativa è disponibile in tutti i browser moderni e richiede soltanto qualche riga di codice:

```javascript async function copyToClipboard(text) { try { await navigator.clipboard.writeText(text); return true; } catch (err) { console.error('Errore nella copia:', err); return false; } } ```

L'unica nota da tenere a mente è che questa API richiede un contesto sicuro (HTTPS) e, in certi browser, richiede che la pagina sia in primo piano e che l'utente abbia interagito di recente con essa. Nella pratica, questo significa che funziona perfettamente in tutti i casi d'uso reali, dal momento che un bottone "copia" viene sempre attivato da un'azione diretta dell'utente. Se hai bisogno anche di leggere il contenuto degli appunti, `navigator.clipboard.readText()` funziona con la stessa logica, richiedendo però il permesso esplicito dell'utente tramite il sistema di permission del browser.

Web Animations API: animazioni senza librerie CSS-in-JS

Un'area in cui vedo ancora molta dipendenza da librerie esterne è quella delle animazioni programmatiche. GSAP è una libreria eccellente, e non sto dicendo di sostituirla in progetti che richiedono animazioni complesse e orchestrate. Ma per casi semplici, la Web Animations API offre un'alternativa nativa che funziona su tutti i browser moderni:

```javascript const element = document.querySelector('.card');

element.animate( [ { opacity: 0, transform: 'translateY(20px)' }, { opacity: 1, transform: 'translateY(0)' }, ], { duration: 300, easing: 'ease-out', fill: 'forwards', } ); ```

Quest'ultima API è particolarmente utile quando hai bisogno di animazioni che devono essere controllate programmaticamente, per esempio avviate, messe in pausa o invertite in risposta a eventi dell'utente. Restituisce un oggetto `Animation` su cui puoi chiamare `.pause()`, `.play()`, `.reverse()`, e registrare handler su `.onfinish`. Nei miei progetti la uso in combinazione con l'Intersection Observer per creare animazioni che si attivano al momento giusto senza installare un singolo pacchetto aggiuntivo.

Quando ha ancora senso usare una libreria

Non voglio creare l'impressione che le librerie JavaScript siano obsolete, perché non è così. Ci sono casi in cui una dipendenza esterna è la scelta giusta, e ignorarlo sarebbe un errore diverso ma ugualmente costoso.

La gestione delle date è ancora uno di questi casi: seppur `Intl.DateTimeFormat` sia migliorata significativamente, non copre tutti i casi d'uso di chi lavora con timezone complesse, parsing di formati arbitrari o manipolazioni avanzate. Date-fns rimane una scelta sensata, in particolar modo per la sua natura modulare che permette di importare soltanto le funzioni che servono.

Anche la gestione dello stato applicativo complesso è un caso in cui le API native non offrono una soluzione comparabile a quello che librerie come Zustand o Jotai permettono di fare in applicazioni React di media e grande dimensione. Il Context API di React non è una sostituzione di un sistema di state management per applicazioni che superano una certa soglia di complessità.

Le animazioni orchestrate con timeline complesse, le visualizzazioni di dati che richiedono librerie come D3.js, la gestione avanzata dei form con validazione e stato derivato: in tutti questi casi, una libreria esterna è giustificata e non dovrebbe essere rimossa per principio.

Dunque il punto non è "zero dipendenze a tutti i costi", bensì che ogni dipendenza dovrebbe guadagnarsi il proprio posto in `package.json`. Dal momento che ogni libreria installata è un pezzo di software che devi aggiornare, monitorare per vulnerabilità e che contribuisce al peso finale del bundle, la domanda giusta da porsi è sempre: "Posso risolvere questo problema con quello che il browser mi offre già?" Se la risposta è sì, di fatto, non c'è motivo di aggiungere una dipendenza.

Il punto di partenza

Il posto migliore da cui cominciare, nella mia esperienza, è MDN Web Docs. Ogni volta che mi trovo ad installare una libreria per risolvere un problema specifico, prima di farlo controllo se esiste un'API nativa che fa la stessa cosa. Spesso la risposta mi sorprende ancora, dopo anni di sviluppo web.

Non si tratta di purismo o di minimalismo fine a se stesso. Si tratta di scegliere consapevolmente cosa includere in un progetto, sapendo che ogni scelta ha un costo in termini di manutenzione, sicurezza e complessità. Il web platform del 2026 è uno strumento POTENTE, e sfruttarlo pienamente significa prima conoscerlo, e poi decidere quando vale la pena andare oltre quello che offre.