Sviluppo moderno
Il browser di oggi fa da solo molto più di quanto pensi.
Meno JavaScript e più piattaforma: cosa usare oggi, come misurare la velocità, perché l’accessibilità è diventata un obbligo e come lavorare con l’AI senza perdere il controllo.
Cose che prima richiedevano JavaScript
Molti componenti che scrivevamo a mano oggi sono HTML e CSS nativi, supportati da tutti i browser principali. Meno codice vuol dire meno bug, meno cose da mantenere e pagine più leggere.
Finestre modali con <dialog>
showModal() gestisce da solo lo sfondo, il focus, il tasto Esc e rende inerte il resto della
pagina. La finestra di fine partita nella Home di questo sito è fatta proprio così.
Prima JavaScript
// Sfondo, focus e tasto Esc: tutto a mano
modal.classList.add('is-open');
document.body.style.overflow = 'hidden';
lastFocus = document.activeElement;
modal.querySelector('button').focus();
document.addEventListener('keydown', onEsc);
// ...più una "focus trap" per non uscire con Tab
Oggi HTML
<dialog id="conferma">
<p>Vuoi davvero uscire?</p>
<form method="dialog">
<button>Chiudi</button>
</form>
</dialog>
<script>conferma.showModal();</script>
Menu e tooltip con l’attributo popover
Il browser chiude il menu con un clic fuori o con Esc, e lo mostra sopra tutto il resto senza combattere con lo z-index. Zero righe di JavaScript.
Prima JavaScript
button.addEventListener('click', () => {
menu.classList.toggle('open');
});
document.addEventListener('click', (e) => {
if (!menu.contains(e.target) && e.target !== button) {
menu.classList.remove('open');
}
});
// ...e un altro listener per il tasto Esc
Oggi HTML
<button popovertarget="menu">Menu</button>
<div id="menu" popover>
<a href="/">Home</a>
<a href="/radar/">Giochi e news</a>
</div>
Componenti che si adattano al loro spazio
Con le container query un componente risponde allo spazio che ha, non alla larghezza dello schermo: lo stesso blocco funziona in una colonna stretta e a tutta pagina. L’overlay dei giochi di questo sito le usa.
Prima JavaScript
new ResizeObserver(([entry]) => {
card.classList.toggle(
'is-wide',
entry.contentRect.width > 480
);
}).observe(card);
Oggi CSS
.card-wrap {
container-type: inline-size;
}
@container (width > 30rem) {
.card { grid-template-columns: 1fr 2fr; }
}
Il “selettore genitore” :has()
:has() seleziona un elemento in base a ciò che contiene. Uno stato in meno da tenere
sincronizzato in JavaScript, e un bug in meno quando ti dimentichi di farlo.
Prima JavaScript
checkbox.addEventListener('change', () => {
card.classList.toggle(
'is-selected',
checkbox.checked
);
});
Oggi CSS
.card:has(input:checked) {
border-color: var(--accent);
}
CSS annidato, senza preprocessori
L’annidamento è nativo: per molti progetti Sass non serve più. Una dipendenza e un passaggio di build in meno, con la stessa comodità.
Prima Sass
// serviva un preprocessore
.card {
padding: 1rem;
&:hover { border-color: violet; }
.title { font-weight: 700; }
}
Oggi CSS
/* funziona così nel browser */
.card {
padding: 1rem;
&:hover { border-color: violet; }
& .title { font-weight: 700; }
}
Velocità: si misura, non si indovina
Google misura l’esperienza reale degli utenti con tre metriche, i Core Web Vitals. Questi sono i valori considerati “buoni”, da raggiungere per almeno il 75% delle visite.
-
LCP
≤ 2,5 s
Largest Contentful Paint. Quanto ci mette a comparire il contenuto principale della pagina.
-
INP
≤ 200 ms
Interaction to Next Paint. Quanto velocemente la pagina risponde a clic, tocchi e tasti. Ha sostituito FID nel marzo 2024.
-
CLS
≤ 0,1
Cumulative Layout Shift. Quanto “salta” il layout mentre la pagina carica.
Come ci arrivi
-
Immagini leggere e dimensionate. AVIF o WebP, con
widtheheightsempre dichiarati: così il layout non salta. -
Font self-hosted. Solo i pesi che usi, con
font-display: swap. Niente richieste a server esterni. - JavaScript solo quando serve. I tre mini-giochi di questo sito si scaricano quando stanno per entrare nello schermo.
- Metti in pausa ciò che non si vede. Un’animazione fuori schermo consuma batteria per niente: IntersectionObserver la ferma, requestAnimationFrame la riprende.
- Misura su dispositivi veri. PageSpeed Insights mostra i dati degli utenti reali; il pannello Performance di Chrome ti dice dove si perde tempo.
Accessibilità: non è più un extra
Dal 28 giugno 2025 nell’Unione Europea si applica l’European Accessibility Act: e-commerce, servizi bancari, e-book, trasporti, smartphone e computer immessi sul mercato devono essere accessibili alle persone con disabilità. Sono escluse le microimprese di servizi (meno di 10 dipendenti e meno di 2 milioni di fatturato), ma la direzione è chiara.
E al di là della legge: un sito accessibile funziona meglio per tutti, dalla persona che naviga con la tastiera a chi legge il telefono sotto il sole.
Prova adesso
Metti via il mouse e naviga questo sito solo con Tab, Invio e le frecce. Anche i giochi.
Le basi che risolvono gran parte dei problemi
- HTML semantico.
buttonper le azioni,aper i link, un soloh1, titoli in ordine. - Tutto usabile da tastiera, con il focus sempre visibile.
- Contrasto del testo almeno 4,5:1 per il testo normale (WCAG livello AA).
- Testi alternativi per le immagini che portano informazioni.
- Etichette vere sui campi dei form, non solo il placeholder.
- Rispetto per
prefers-reduced-motion: meno animazioni per chi le ha disattivate.
La cassetta degli attrezzi
Non serve inseguire ogni novità. Questi strumenti coprono il flusso completo, dal primo file al rilascio.
-
Scrivere
Un dev server che parte in un attimo e tipi che trovano gli errori prima del browser.
Vite, TypeScript
-
Qualità
Regole automatiche: le discussioni sullo stile finiscono prima di cominciare.
ESLint o Biome, Prettier
-
Test
Unit test per la logica, test end-to-end che cliccano la pagina come farebbe una persona.
Vitest, Playwright
-
Rilascio
Ogni modifica passa dai test automatici e ha un’anteprima con un link da condividere prima di andare online.
Git, GitHub Actions, Cloudflare Pages o Netlify
-
Osservare
Dopo il rilascio il lavoro continua: velocità reale e errori degli utenti, non solo quelli sul tuo computer.
PageSpeed Insights, Sentry
Lavorare con l’AI senza perdere il controllo
Gli assistenti di codice accelerano molto il lavoro. Ma il codice che finisce online resta tuo, con i suoi bug e le sue vulnerabilità.
- Rileggi ogni riga. Se non sai spiegare cosa fa un pezzo di codice, non è pronto per la produzione.
- Controlla che i pacchetti esistano davvero. In uno studio su 16 modelli circa un pacchetto suggerito su cinque non esisteva. E c’è chi registra proprio quei nomi inventati con dentro codice malevolo: si chiama slopsquatting.
- Niente segreti nei prompt. Chiavi API, password e dati dei clienti non vanno incollati in una chat.
- Chiedi i test insieme al codice. E falli girare: un test che non hai visto fallire non prova niente.
- Usala per capire, non solo per scrivere. “Spiegami perché” insegna più di “scrivimi questo”.