DEV Community: frontendfacile.it

Come adottare le novità CSS senza rischiare regressioni

frontendfacile.it — Thu, 05 Nov 2026 14:01:04 +0000

Baseline, Can I Use, progressive enhancement e @supports: un metodo pratico per usare feature moderne senza “rompere” i layout.

Nel 2026 CSS sta vivendo un’accelerazione continua: nuove proprietà, nuove funzioni, nuove pseudo-classi. Il problema non è “se” sono utili, ma come usarle senza trasformare la compatibilità in una roulette russa.

La buona notizia è che il CSS, per sua natura, offre già diversi strumenti per integrare feature moderne in modo graduale e robusto. La cattiva notizia è che serve un minimo di metodo: leggere bene lo stato di supporto, capire l’impatto di un’eventuale mancata compatibilità e scegliere la strategia giusta (fallback, @supports, build step, o attesa).

1) Baseline: utile, ma non è un via libera automatico

Negli ultimi tempi si è diffuso molto il riferimento a Baseline (iniziativa nata in ambito Chrome e oggi portata avanti dal gruppo WebDX). È una bussola comoda, ma non sostituisce il ragionamento.

In breve, gli stati principali sono:

Baseline: limited availability: non è ancora presente in tutti i motori di rendering.
Baseline: newly available: è presente in tutti i motori, ma da meno di 30 mesi.
Baseline: widely available: è presente in tutti i motori da almeno 30 mesi.

Il punto critico: anche “widely available” non significa automaticamente “sicuro al 100% per il tuo pubblico”. Dipende da:

Qual è l’ultimo browser che l’ha adottata (l’ordine di adozione influisce parecchio sulla copertura reale).
Quali versioni sono effettivamente in uso nel tuo contesto (aziende, dispositivi vecchi, vincoli di aggiornamento).
Stato e varianti della specifica: a volte il supporto è “sì, ma…” (flag, sintassi differenti, implementazioni parziali).

Baseline è ottimo per orientarsi, ma non basta come unica fonte decisionale.

2) Per decidere davvero: guarda la compatibilità “versione per versione”

Quando devi fare una scelta concreta (“posso spedirlo in produzione?”), serve dettaglio. Strumenti come Can I Use restano fondamentali perché mostrano:

versioni specifiche supportate;
feature dietro flag;
note su implementazioni incomplete o differenze di sintassi;
percentuali d’adozione globali/relative.

Occhio speciale a iOS

Molti team, più che guardare “browser generici”, ragionano in termini di versione iOS/Safari. Motivo:

su iPhone, i browser sono vincolati al motore WebKit (di fatto, il comportamento è quello di Safari);
su dispositivi vecchi può esserci un tetto massimo di aggiornamento, quindi una parte degli utenti non può “semplicemente aggiornare”.

Se il tuo prodotto ha traffico mobile significativo, iOS è spesso la variabile che decide quanto puoi spingerti.

3) Domanda guida: cosa succede se la feature non è supportata?

Questa è la domanda che separa le scelte sicure da quelle rischiose.

Il CSS ha un vantaggio enorme: se una dichiarazione non è riconosciuta, viene ignorata. Non “esplode” tutto come può succedere con JavaScript. Questo abilita naturalmente strategie di adozione progressiva.

Caso A — Se fallisce, non succede nulla di grave

Qui entra in gioco il progressive enhancement: aggiungi una piccola miglioria, e se manca il supporto l’esperienza resta accettabile.

Esempio tipico: un miglioramento tipografico come text-wrap: pretty.

Browser moderni: paragrafi con spezzature più gradevoli.
Browser non compatibili: testo normale, nessun layout rotto.

In questi casi, l’adozione è spesso a rischio quasi zero.

Caso B — Se fallisce, può degradare l’esperienza in modo evidente

Ci sono feature che, se non supportate, cambiano davvero il comportamento. Un esempio classico è quando introduci animazioni o transizioni “nuove” che rendono l’interazione più fluida, ma in fallback diventa istantanea.

Un caso interessante è l’abilitazione dell’animazione tra height: 0 e height: auto tramite:

:root {
  interpolate-size: allow-keywords;
}

Se il browser non supporta questa capacità, non è che “si rompe tutto”: semplicemente l’apertura/chiusura può passare da animata a immediata.

Qui devi valutare:

è accettabile che alcuni utenti vedano l’effetto “senza animazione”? spesso sì;
il comportamento resta comprensibile e accessibile? deve essere sempre sì.

4) Fallback via cascata: dichiara due volte (nell’ordine giusto)

Quando la mancata compatibilità sarebbe problematica (es. colori, dove un valore non supportato potrebbe lasciare testo o sfondo non impostati), una strategia semplice è sfruttare la cascata:

.button {
  background: #2f6feb;            /* fallback */
  background: oklch(55% 0.2 260); /* moderno */
}

Se il browser capisce oklch(), usa l’ultima dichiarazione.
Se non la capisce, ignora la riga e resta sul fallback.

È una tecnica banale ma estremamente efficace.

Automatizzare i fallback

Se non vuoi gestire manualmente questi doppioni, esistono strumenti che possono farlo nel build step (es. PostCSS, Lightning CSS), trasformando o affiancando sintassi moderne con fallback più compatibili.

5) Feature queries: @supports come cintura di sicurezza

Quando vuoi introdurre una feature moderna senza rischiare effetti collaterali, la soluzione più robusta è spesso @supports.

5.1) @supports con custom properties (pattern molto pratico)

Le custom properties accettano qualsiasi valore come “valido”, anche se poi non lo è nel punto in cui lo userai. Quindi per fare fallback puliti con variabili conviene usare @supports.

Esempio: vuoi una easing moderna, ma fallback su cubic-bezier().

:root {
  --ease: cubic-bezier(.2, .8, .2, 1);
}

@supports (animation-timing-function: linear(0, 1)) {
  :root {
    --ease: linear(0, 1);
  }
}

.card {
  transition: transform 300ms var(--ease);
}

Così:

dichiari una sola volta dove usi --ease;
cambi il valore della variabile solo se la feature è supportata;
eviti ripetizioni e riduci la probabilità di bug.

5.2) @supports per interi blocchi di layout (es. subgrid)

Ci sono casi in cui non basta un fallback “di valore”: vuoi proprio un layout alternativo.

subgrid è perfetto per questo approccio: puoi implementare un layout base funzionante ovunque, e migliorarlo dove disponibile.

.component {
  display: grid;
  grid-template-rows: auto auto 1fr;
}

@supports (grid-template-rows: subgrid) {
  .component {
    grid-template-rows: subgrid;
  }
}

In questo modo eviti situazioni in cui, senza supporto, combinazioni di span e template possono generare risultati inattesi.

5.3) @supports può testare anche i selettori

Non tutti lo sfruttano, ma @supports può verificare la disponibilità di selettori tramite selector().

@supports selector(:has(*)) {
  .list:has(.item--active) {
    outline: 2px solid currentColor;
  }
}

È un ottimo modo per usare selettori avanzati come “miglioria”, mantenendo un comportamento base per tutti.

6) Polyfill o attesa: quando ha senso

A volte la risposta giusta è:

polyfill, ma con cautela: costo in performance, limiti tecnici, manutenzione;
aspettare: alcune feature sono troppo recenti o troppo “DX-oriented” (pensiamo a funzionalità che cambiano soprattutto l’organizzazione del CSS, non l’output finale). In questi casi forzare l’adozione può creare più problemi che benefici.

Sintesi operativa

Un modo pragmatico per usare CSS moderno senza rompere nulla è questo:

Valuta l’impatto del fallback: se non supportato, degrada bene?
Verifica su Can I Use (e ragiona per versioni, soprattutto su iOS).
Se è una “miglioria”, inseriscila direttamente (progressive enhancement).
Se serve compatibilità certa, usa fallback in cascata o build tool.
Se cambia layout o logica, proteggi con @supports (anche per selettori).

La conseguenza pratica è potente: puoi adottare nuove feature quando ti danno un vantaggio reale, senza trasformare ogni release in una battaglia contro browser e dispositivi. CSS è già progettato per evolvere in questo modo; sta a noi usarne bene gli strumenti.

Articolo originale: https://frontendfacile.it/blog/come-adottare-le-novita-css-senza-rischiare-regressioni

Supply chain, wallet drain e bug nel kernel: la settimana in cui la sicurezza ha ricordato perché non esiste “solo frontend”

frontendfacile.it — Wed, 04 Nov 2026 13:55:32 +0000

Tre incidenti diversi, una lezione comune: il tuo perimetro non finisce nel browser, e nemmeno nel tuo repository.

Negli ultimi giorni si sono incastrati tre eventi che, presi insieme, raccontano benissimo lo stato della sicurezza nel 2026: la fiducia implicita nella supply chain, la fragilità del runtime “attorno” al nostro codice, e l’effetto moltiplicatore dell’automazione (quando non serve più “essere bravissimi”, basta iterare abbastanza velocemente).

Non è un post per fare doomscrolling tecnico. È un promemoria pratico: anche se fai “solo UI”, ogni scelta quotidiana — estensioni, script esterni, CI/CD, laptop di lavoro — può diventare un vettore.

1) Quando un’estensione “ufficiale” diventa un cavallo di Troia

Un’estensione cloud per un editor è stata distribuita e installata da migliaia di persone prima che ci si rendesse conto del problema: scansionava la macchina alla ricerca di chiavi/token e predisponeva un meccanismo per consentire accessi successivi.

Il dettaglio che conta, per chi sviluppa:

Non serve che tu “esegua malware” consapevolmente: basta installare un plugin ritenuto legittimo.
Il danno reale dipende spesso da un fattore banale: i privilegi. Se l’estensione richiede permessi elevati (admin/root) l’impatto può esplodere; se non li ottiene, il raggio d’azione si riduce drasticamente.

Implicazione pratica per team frontend

Le estensioni dell’editor sono parte della supply chain. Trattale come dipendenze eseguibili:

Principio del minimo privilegio: l’editor non dovrebbe avere permessi amministrativi; evita di “sbloccare tutto” per comodità.
Token a scadenza e scope ridotti: se un plugin ruba un token, la differenza tra “read-only” e “admin” è la differenza tra incidente e disastro.
Inventario e policy: in team, una whitelist di estensioni approvate è noiosa… ma è una cintura di sicurezza.

2) Script di terze parti: basta un tag per drenare un’app

Un’altra storia classica, ma sempre attuale: un servizio web ha subito sottrazioni di fondi che avvenivano semplicemente effettuando login. La causa non era “l’utente distratto”, ma un asset JavaScript di terza parte usato per monitoraggio delle performance, che è stato compromesso.

Questo scenario è il motivo per cui gli script esterni sono così delicati:

Hanno gli stessi privilegi del tuo codice nella pagina.
Se la risorsa viene alterata a monte, l’attaccante ottiene una corsia preferenziale: niente exploit sofisticati, basta che il browser esegua lo script.

Implicazione pratica per frontend: terze parti = attacco alla sessione

Se un terzo può eseguire JS nel tuo dominio, può spesso:

leggere/modificare DOM e flussi di pagamento,
intercettare eventi,
in certi casi influire su transazioni o indirizzamenti (anche senza “rubare cookie” in modo diretto).

Mitigazioni concrete:

Self-host dove possibile (o almeno pinning a versioni e checksum).
Subresource Integrity (SRI) per script e stylesheet esterni, quando compatibile con il tuo modello di deploy.
CSP rigorosa (con script-src controllato e, idealmente, nonce/hash). Non risolve tutto, ma alza il costo degli attacchi e riduce i “colpi di fortuna”.
Riduci il numero di tag: ogni vendor aggiunto è una superficie d’attacco.

3) Una vulnerabilità nel kernel Linux diventa “facile” quando puoi automatizzare il timing

Il terzo elemento è quello che cambia davvero la percezione del rischio. È emersa una vulnerabilità critica nel kernel Linux legata alla gestione di nuove connessioni TCP: in certe condizioni di concorrenza, due percorsi di esecuzione finiscono per lavorare sulla stessa connessione e possono generare use-after-free (memoria liberata mentre è ancora in uso). Il risultato può andare da crash a esecuzione di codice.

Il punto non è solo la gravità (CVSS molto alta), ma la dinamica:

Tradizionalmente, exploit di questo tipo vengono sminuiti quando richiedono timing estremamente preciso (“succede 1 volta su un milione”).
Oggi quel modello mentale è fragile: se qualcuno può automatizzare tentativi e adattare la strategia rapidamente, “improbabile” diventa “inevitabile”.

In questo caso è stato dimostrato che un sistema automatizzato è riuscito prima a ottenere leak utili (es. indirizzi di memoria del kernel) e poi ad arrivare all’esecuzione come root su sistemi non patchati.

Implicazione pratica per chi fa web

Anche se scrivi TypeScript e CSS, la tua app gira sopra:

kernel,
container runtime,
orchestrazione,
host condivisi,
networking.

Un bug nel kernel è un bug “sotto” il tuo stack, ma può comunque trasformarsi in:

compromissione dell’host,
movimento laterale in rete,
furto di segreti (chiavi, token CI, credenziali cloud),
compromissione della build pipeline (e ritorno alla supply chain, da un’altra porta).

E qui la priorità diventa semplice: patch management e riduzione della blast radius.

Il filo rosso: la fiducia implicita è il vero bug

Mettendo in fila questi tre episodi, emerge un pattern:

Ti fidi dell’estensione perché “è ufficiale”.
Ti fidi dello script perché “è un vendor noto”.
Ti fidi del kernel perché “è improbabile che qualcuno sfrutti il timing”.

La sicurezza moderna fallisce soprattutto quando la fiducia non è esplicita, non è limitata e non è osservabile.

Checklist finale (pragmatica) per team frontend

Se vuoi portarti a casa qualcosa di immediatamente applicabile:

Estensioni e tooling: niente privilegi admin, whitelist interna, rotazione token.
Terze parti in pagina: meno vendor, più CSP, SRI dove possibile, self-host degli asset critici.
Segreti: minimizza dove vivono (dev machine, .env, CI), riduci scope e durata.
Patch: kernel e infrastruttura non sono “problemi del reparto ops” quando la tua app vive lì sopra.
Blast radius: segmentazione, permessi minimi, separazione ambienti, credenziali diverse per dev/stage/prod.

Conclusione

Questa sequenza di incidenti non è un’anomalia: è una fotografia. La differenza tra un intoppo e un disastro sta quasi sempre nelle stesse cose noiose — privilegi, dipendenze, terze parti, patch — che non fanno mai rumore finché non arriva la settimana sbagliata.

Se lavori sul frontend, il modo più efficace per “fare sicurezza” non è diventare esperto di exploit kernel: è costruire abitudini di difesa attorno alle tue scelte quotidiane, perché oggi il perimetro reale del tuo progetto include l’editor, i tag in <head>, e la macchina che firma i deploy.

Articolo originale: https://frontendfacile.it/blog/supply-chain-wallet-drain-e-bug-nel-kernel-la-settimana-in-cui-la-sicurezza-ha-r

Countdown per festività globali: smettere di lottare con Date e passare a Temporal

frontendfacile.it — Wed, 04 Nov 2026 13:50:32 +0000

Per banner e contatori “fino a…” davvero internazionali, serve un modello di data/ora che conosca calendari e regole: JavaScript Date non basta.

Quando aggiungi un banner “Mancano X giorni a…” sembra un dettaglio UI. Finché non ti chiedono di supportare festività basate su calendari non gregoriani: ricorrenze lunari, calendari tradizionali, regole locali e (peggio) mesi intercalari. A quel punto, il classico approccio con Date e qualche sottrazione di millisecondi diventa un campo minato.

La buona notizia: oggi esiste un modello molto più adatto, pensato proprio per evitare calcoli manuali e ambiguità. Si chiama Temporal.

Perché `Date` porta a implementazioni fragili

Date è comodo per “adesso” e per timestamp, ma appena cerchi di modellare una data nel calendario di riferimento dell’evento, emergono problemi tipici:

Calcoli manuali: differenze tra date, arrotondamenti, gestione di ora locale vs UTC.
Confronti non affidabili: confrontare istanti nel tempo non è la stessa cosa che confrontare “date” in un calendario specifico.
Flessibilità limitata: l’implementazione tende a funzionare per un solo caso (es. una data fissa gregoriana), e si rompe quando cambi ricorrenza o regola.
Bug da calendario lunare: gestire a mano mesi lunari e mesi intercalari (leap month) è esattamente il tipo di logica che non vuoi mantenere in app.

In pratica, finisci a scrivere una piccola libreria di calendari senza volerlo.

Temporal: il cambio di paradigma giusto per festività “global”

Temporal introduce oggetti più precisi (e meno ambigui) per lavorare con date, orari, fusi e calendari.

Per un countdown verso una festività, l’idea è:

Rappresentare la data target nel calendario corretto, invece di “forzarla” nel gregoriano.
Lasciare al runtime la gestione della matematica complessa (inclusi mesi intercalari).
Confrontare date nello stesso sistema (non sottrarre millisecondi a caso).

Un esempio tipico è una festività basata sul calendario cinese (come una ricorrenza lunare). Con Temporal puoi inizializzare una data con una proprietà calendar dedicata, così che l’interpretazione della data sia coerente con quel sistema.

Vantaggio concreto: niente bug da leap month shifting

Le festività lunari non sono “un giorno fisso” nel calendario gregoriano. Se provi a inseguirle convertendo tutto a mano, ti scontri con casi limite (in particolare i mesi intercalari). Temporal, invece, modella la data nel calendario d’origine e delega la complessità alla piattaforma: meno logica custom, meno sorprese in produzione.

Countdown robusto: confrontare date, non timestamp

Un errore comune nei banner di countdown è trattare tutto come differenza tra timestamp. Ma un countdown “umano” spesso deve ragionare in termini di date locali e calendario.

Con Temporal è buona pratica:

usare tipi come PlainDate/PlainDateTime per rappresentare “una data” indipendente dal fuso, quando ha senso;
usare metodi di comparazione tra date nello stesso calendario, invece di confronti manuali;
calcolare la durata con primitive di Temporal e poi renderizzarla come testo leggibile.

Questo porta a un codice più leggibile e, soprattutto, più corretto quando cambiano requisiti (nuove festività, nuove aree geografiche, nuove regole).

Durate “leggibili”: l’ultimo miglio del banner

Un countdown non è solo calcolo: è anche presentazione.

Una volta ottenuta la distanza dall’evento, conviene produrre output coerenti come:

“mancano 3 giorni”
“mancano 2 settimane e 1 giorno”
“inizia oggi”

Invece di concatenare stringhe a mano (con pluralizzazioni e arrotondamenti), conviene centralizzare la formattazione delle durate e mantenere un comportamento consistente in UI.

Un approccio pratico per un banner “global holidays ready”

Se devi implementare un banner di countdown che non si rompa al primo calendario non standard, la checklist utile è:

Identifica il calendario dell’evento (gregoriano, cinese, ecc.).
Rappresenta la data target con Temporal nel calendario corretto.
Confronta e calcola usando le API di Temporal, evitando sottrazioni manuali.
Formatta la durata in modo umano con una funzione dedicata (e testabile).
Aggiungi test per casi limite (passaggi di mese, anno, e ricorrenze lunari).

Sintesi

Un countdown per festività globali non è un “semplice Date meno Date”: è un problema di calendari. Date ti spinge verso calcoli manuali e implementazioni rigide; Temporal ti permette di modellare correttamente date e confronti nel calendario giusto, riducendo i bug e rendendo il codice molto più estensibile.

Se il tuo prodotto esce dai confini del calendario gregoriano, la scelta più pragmatica è smettere di inseguire edge case a colpi di millisecondi e passare a un modello che li conosce già.

Articolo originale: https://frontendfacile.it/blog/countdown-per-festivita-globali-smettere-di-lottare-con-date-e-passare-a-tempora

Vector database per frontend: embeddings, similarity search e perché ti servono davvero nel 2026

frontendfacile.it — Tue, 03 Nov 2026 13:44:37 +0000

Dalla matematica minima (vettori, cosine similarity, distanza euclidea) alla pipeline completa: embedding → indicizzazione ANN → ricerca semantica. Con un focus pratico su ChromaDB.

Perché un frontend dovrebbe interessarsi alle vector database

Se lavori su prodotti con ricerca, contenuti, documentazione, supporto, cataloghi, feed personalizzati o chat con knowledge base, prima o poi ti scontri con un limite: la ricerca per keyword è fragile.

Gli utenti non cercano “parole”, cercano intenzioni. E quando i dati sono non strutturati (testi lunghi, PDF, immagini, audio, codice), il matching esatto non basta.

Le vector database sono nate per questo: permettono di archiviare e interrogare embedding (vettori numerici ad alta dimensionalità) così da trovare risultati simili per significato, non solo per stringa.

Cos’è una vector database (definizione operativa)

Una vector database è un database progettato per:

Memorizzare vettori (embedding) associati a contenuti.
Indicizzare quei vettori con strutture adatte alla ricerca di “vicini” in spazi ad alta dimensionalità.
Cercare rapidamente i vettori più simili a una query (similarity search), abilitando semantic search.

In pratica: invece di chiedere “contiene la parola X?”, chiedi “quali contenuti sono più vicini concettualmente a questo testo/immagine/codice?”.

La pipeline: ingestion e retrieval (il flusso che si ripete sempre)

Quasi tutte le soluzioni seguono lo stesso schema, indipendentemente dal vendor.

1) Ingestion phase: da dato grezzo a vettori indicizzati

Parti da dati grezzi: testo, documenti, immagini, snippet di codice, ecc.
Li passi a un embedding model (un modello che trasforma l’input in numeri preservandone significato e contesto).
Ottieni un embedding: una lista di numeri in virgola mobile (spesso centinaia o migliaia di dimensioni).
Salvi nel DB:
- il vettore
- un riferimento al contenuto originale (id, path, URL…)
- metadati opzionali (lingua, data, categoria, permessi, tenant, ecc.)
Il database costruisce uno o più indici ANN (Approximate Nearest Neighbors) per evitare una scansione lineare.

2) Retrieval phase: query → embedding → vicini più simili

L’utente fa una query (es. “come posso migliorare la concentrazione?”).
Converti la query nello stesso spazio vettoriale usando lo stesso embedding model.
- Punto chiave: embeddings confrontabili solo se stanno nello stesso “spazio”.
Il DB cerca i vettori più vicini (nearest neighbors).
Applica ranking per similarity score e, se serve, filtri sui metadati.
Restituisce i top-K risultati più rilevanti.

Questo è il cuore di semantic search, recommendation e pattern moderni come RAG.

Perché i database tradizionali non bastano

I database relazionali (e molti motori di ricerca basati su testo) sono eccellenti per:

match esatti
range query
join
transazioni
schema e vincoli

Ma sul non strutturato, la ricerca diventa spesso:

keyword-based
dipendente da sinonimi, forme verbali, lingua, refusi
incapace di “capire” che due frasi diverse possono significare la stessa cosa

Con gli embedding, invece, ottieni un confronto per somiglianza semantica: due contenuti con significato simile finiscono “vicini” nello spazio vettoriale.

Nota importante: una vector database non sostituisce il database tradizionale. Tipicamente il DB classico resta il system of record, mentre la vector DB diventa un layer di retrieval semantico sopra i dati.

Vettori: la definizione minima che serve

Nel contesto ML/vector search, un vettore è una array 1D di numeri in cui ogni posizione rappresenta una “feature” dell’oggetto.

Questa idea è potente perché rende confrontabili cose diverse (testi, immagini, codice) con le stesse operazioni matematiche.

Similarity: cosine similarity e distanza euclidea (quando e perché)

Per decidere “quanto due contenuti si somigliano”, serve una metrica.

Cosine similarity: misura l’angolo tra due vettori (quanto “puntano” nella stessa direzione).
- Spesso è molto usata per embeddings testuali.
- È meno sensibile alla magnitudine e più alla direzione (cioè al pattern).
Distanza euclidea: misura la distanza geometrica diretta.
- Può funzionare bene in alcuni setting, ma in alta dimensionalità va interpretata con attenzione.

Nella pratica, la metrica è una scelta di prodotto e di tooling: dipende da modello di embedding, normalizzazione e librerie/DB.

Il vero trucco: indicizzazione ANN (IVF e HNSW)

Se hai 1 milione di vettori e confronti la query con tutti, fai una ricerca O(n) (troppo lenta e costosa).

Le vector DB scalano perché evitano la brute force e usano indici ANN: cercano un “quasi” nearest neighbor, abbastanza accurato ma molto più veloce.

Due famiglie comuni:

IVF (Inverted File Index)

Approccio basato su clustering:

raggruppa i vettori in cluster
in query time cerca nei cluster più promettenti invece che ovunque

Buono quando vuoi controllare trade-off tra velocità/accuratezza agendo su parametri (quanti cluster scandire, ecc.).

HNSW (Hierarchical Navigable Small World)

Approccio basato su un grafo navigabile:

crea collegamenti tra vettori “vicini”
esegue una navigazione efficiente nel grafo per arrivare rapidamente ai candidati migliori

Spesso apprezzato per ottime prestazioni query-time su grandi volumi.

Tokenizzazione: perché non basta “passare testo al modello”

I modelli non lavorano su stringhe “come le vediamo noi”: prima il testo viene spezzato in token.

Punti da ricordare:

i token non coincidono necessariamente con le parole
la tokenizzazione è il primo step della pipeline che porta agli embedding
impatta costi, limiti di input e, in parte, qualità

Per chi fa frontend: significa che lunghezze, conteggi e limiti non vanno ragionati solo in “caratteri”, ma spesso in token (soprattutto quando costruisci flussi RAG o chat su documenti).

Use case concreti (quelli che toccano davvero i prodotti)

1) Semantic search su documentazione e knowledge base

query naturale dell’utente
recupero paragrafi/FAQ simili
opzionale: feed a un LLM per risposta contestualizzata (RAG)

2) Recommendation

Rappresenti come vettori:

utenti (click, watch/purchase history, preferenze)
item (descrizioni, recensioni, categorie, feature)

Poi cerchi item “vicini” al vettore utente.

3) Anomaly e fraud detection

Eventi o profili vengono vettorializzati; outlier e cluster strani emergono più facilmente con tecniche basate su vicinanza.

Mini-progetto mentale: embeddings + ChromaDB + ricerca per significato

Un workflow tipico (anche per un prodotto piccolo):

Spezzi i documenti in chunk (dimensione gestibile, spesso a token o caratteri).
Generi embedding per ogni chunk.
Salvi in ChromaDB:
- embedding
- id documento e offset
- metadati (categoria, permessi, lingua…)
Alla query:
- embedding della query
- topK similarità
- filtri metadati (es. solo contenuti visibili all’utente)
Mostri risultati come:
- snippet rilevanti
- link al documento
- (opzionale) risposta sintetica via LLM usando i chunk recuperati

Dal punto di vista frontend, i metadati e il post-processing diventano fondamentali: ranking, filtri, deduplica per documento, evidenziazione snippet e UX di esplorazione.

Sintesi: cosa portarti a casa

Una vector database archivia e indicizza embedding per fare semantic search.
La pipeline è sempre: embedding model → storage + metadata → indicizzazione ANN → retrieval top-K.
Non rimpiazza il DB tradizionale: lo completa con un layer semantico.
Il salto prestazionale arriva dagli indici ANN come IVF e HNSW, che evitano la scansione lineare.
Per un prodotto moderno (search, assistenti, RAG, recommendation), capire questi mattoni non è un “extra”: è parte dell’architettura.

Se stai progettando una feature di ricerca o un assistente su contenuti interni, il passo pratico più utile è prototipare una pipeline minima: chunking → embeddings → ChromaDB → top-K results → UI con filtri e snippet. Da lì in poi, l’ottimizzazione (indici, parametri, metadati, caching) diventa iterativa e guidata dal prodotto.

Articolo originale: https://frontendfacile.it/blog/vector-database-per-frontend-embeddings-similarity-search-e-perche-ti-servono-da

Debug dei tool WebMCP con Chrome DevTools for Agents: un flusso pratico per testare, trovare errori e correggerli

frontendfacile.it — Tue, 03 Nov 2026 13:39:36 +0000

Dal listing dei tool all’analisi della console, fino al debug via CLI: un approccio ripetibile per rendere affidabili i comandi MCP che pilotano il browser.

Quando inizi a usare tool WebMCP per pilotare un sito (o un’app) via agente, la domanda non è se avrai bisogno di debug, ma quanto presto. L’integrazione tra Chrome DevTools for Agents e un client MCP ti permette di fare una cosa molto concreta: collegarti a un browser reale, eseguire tool uno dopo l’altro e, quando qualcosa va storto, leggere l’errore dove serve davvero—nella console e nei segnali runtime del browser.

Di seguito un flusso pratico e ripetibile, basato su un esempio volutamente semplice (una “pizza builder UI”) ma applicabile a qualunque set di tool MCP che interagisce con la pagina.

1) Collegati al browser e verifica l’ambiente di esecuzione

Il primo passo è lavorare su un browser in esecuzione (spesso una build Canary o un profilo dedicato) così da poter:

collegarti in modo deterministico alla sessione;
ispezionare console, network e runtime;
riprodurre bug senza “sporcare” l’ambiente principale.

In questa fase l’obiettivo non è ancora “fare cose”, ma assicurarti che la connessione al browser sia stabile e che il client MCP veda l’istanza corretta.

2) Elenca i tool WebMCP disponibili (sanity check)

Prima di invocare qualunque comando, è utile chiedere al sistema l’elenco dei tool esposti dal server WebMCP. In un esempio tipo potresti vedere tool come:

add_topping
remove_topping
altri comandi specifici della tua UI

Questo passaggio serve a:

verificare che il server MCP sia quello atteso;
controllare nomi, parametri e capacità effettive dei tool;
ridurre errori banali (tool rinominati, signature cambiate, deploy incompleto).

3) Esegui una sequenza di tool e controlla lo stato risultante

A questo punto puoi testare il comportamento della pagina invocando una serie di tool in un ordine preciso, ad esempio:

aggiungi 10 peperoni;
aggiungi formaggio;
aggiungi 10 funghi.

Qui la cosa importante non è la “pizza”, ma la proprietà che vuoi garantire in produzione:

ripetibilità (stessi input → stesso risultato),
osservabilità (se qualcosa fallisce, sai dove guardare),
verificabilità (puoi controllare che la UI sia davvero nello stato atteso).

Se tutto fila liscio, ottieni un riscontro immediato nella UI e/o nello stato applicativo.

4) Introduci un bug intenzionale per validare il flusso di debug

Un modo efficace per validare davvero la tua pipeline è inserire un errore deliberato: per esempio, far sì che quando qualcuno richiede i funghi venga lanciata un’eccezione.

Riesegui la stessa sequenza di tool. Se l’integrazione è corretta, l’agente (e DevTools) dovrebbe:

intercettare un errore;
correlare il fallimento ai messaggi di console;
rendere evidente quale step ha causato il problema.

In pratica, stai testando la tua capacità di:

riprodurre,
osservare,
diagnosticare.

5) Usa la console come fonte di verità (e non solo come “log”)

Quando un tool WebMCP fallisce, l’errore utile spesso vive in uno di questi posti:

console (exception, stacktrace, errori applicativi);
runtime signals (promise rejection, assertion fallite);
stato UI incoerente (azioni parziali, elementi non aggiornati).

Chrome DevTools for Agents rende questo passaggio più lineare perché il debugging non si riduce a “l’agente ha fallito”: puoi vedere cosa è fallito nel contesto del browser.

6) Correggi e ripeti: il ciclo “fix → re-run” deve essere veloce

Una volta individuato il problema, il valore sta nel rientrare rapidamente nel ciclo:

applica una correzione;
riesegui la stessa sequenza (stessi input, stesso ordine);
verifica che:
- l’errore non ricompaia;
- la UI arrivi allo stato atteso;
- non ci siano regressioni (es. altri topping che ora falliscono).

Un buon flusso di debug è quello che ti permette di arrivare a una sintesi operativa tipo:

“errore trovato in console”,
“fix applicato”,
“sequenza completata con successo”.

Non è solo soddisfazione: è controllo.

7) Debug anche via CLI: utile per automazioni e CI

Oltre all’uso interattivo, è spesso utile collegarsi al browser via CLI, soprattutto per:

script ripetibili;
smoke test;
pipeline CI che devono validare tool MCP a ogni commit.

Il flusso tipico è:

connetti la CLI al browser;
elenca le pagine disponibili;
seleziona la pagina target;
invoca tool come “aggiungi funghi e ananas” e verifica l’esito.

Il vantaggio della CLI è la standardizzazione: lo stesso script può girare localmente e in CI, fornendo segnali immediati se un tool ha rotto qualcosa.

8) Configurazione e flag: trattali come parte del prodotto

Quando lavori con DevTools for Agents + MCP client, i dettagli contano:

come avviene la connessione al browser;
quali permessi/flag abiliti;
come abiliti la modalità di test e debug;
quali log raccogli (e dove finiscono).

La configurazione non è “collaterale”: è ciò che rende il debug affidabile e ripetibile nel tempo, anche quando il team cresce o la base di tool aumenta.

Sintesi operativa

Per rendere solidi i tuoi tool WebMCP, imposta un workflow in tre mosse:

Connetti e osserva: lavora su un browser reale, con console e segnali runtime accessibili.
Esegui sequenze deterministiche: elenca tool, riproduci scenari e valida lo stato finale.
Chiudi il loop rapidamente: intercetta l’errore in console, correggi, riesegui la stessa sequenza; poi automatizza via CLI.

Quando il ciclo “tool → errore → console → fix → re-run” diventa fluido, i tool MCP smettono di essere una demo fragile e iniziano a comportarsi come una superficie di automazione affidabile, pronta per test seri e integrazione continua.

Articolo originale: https://frontendfacile.it/blog/debug-dei-tool-webmcp-con-chrome-devtools-for-agents-un-flusso-pratico-per-testa

L’obfuscation che sfrutta i guardrail delle AI: quando i nomi delle funzioni diventano un’arma

frontendfacile.it — Mon, 02 Nov 2026 14:45:52 +0000

Una tecnica assurda ma efficace: intasare uno script con termini “proibiti” per bloccare la deoffuscazione assistita da LLM (e non solo).

Negli ultimi anni l’obfuscation JavaScript si è evoluta lungo due binari abbastanza prevedibili: da una parte trasformazioni sintattiche (mangling degli identificatori, controllo di flusso, stringhe codificate), dall’altra tecniche operative (caricamenti condizionali, runtime unpacking, anti-debug, anti-headless).

Ora sta emergendo un terzo filone, molto meno “ingegneristico” e molto più opportunista: progettare il codice per far deragliare l’analisi basata su LLM. Non parliamo di vulnerabilità classiche, ma di un uso deliberato dei guardrail (le policy di sicurezza) come meccanismo di difesa contro la deoffuscazione automatizzata.

L’idea è semplice: se un modello rifiuta di lavorare quando vede certi contenuti, allora basta far sì che il codice sembri contenere quei contenuti.

La tecnica: “avvelenare” i nomi per attivare i blocchi di sicurezza

Una variante particolarmente estrema usa una strategia quasi comica:

lo script è pieno di nomi di funzioni e variabili che richiamano argomenti vietati (terminologia legata ad armi biologiche, veleni, dosaggi letali, ecc.);
a livello semantico, però, il codice fa tutt’altro.

Risultato: molte AI, davanti a quel lessico, rifiutano di analizzare il file o interrompono l’output a metà, perché “interpretano” la richiesta come potenzialmente pericolosa.

Questa non è obfuscation in senso tradizionale (non nasconde davvero la logica), è più simile a una difesa per interdizione: impedisce che certi strumenti completino il lavoro.

Perché funziona

Molti workflow moderni di reverse engineering “assistito” seguono questo schema:

estrazione dello script da rete o bundle;
tentativi di deminificazione/deobfuscation automatica;
passaggio del risultato a un LLM per spiegazione, annotazione, ricostruzione.

Se il passaggio 3 si blocca per policy, l’intera pipeline può:

fermarsi;
produrre output incompleto;
perdere contesto e fallire l’attribuzione delle funzionalità.

E spesso basta far scattare il filtro con poche keyword, anche se il comportamento reale è innocuo (o “solo” invasivo lato privacy).

Il contesto reale: fingerprinting e anti-bot mascherati da “horror lessicale”

Il caso più interessante non riguarda un pezzo di malware dichiarato, ma uno script che si presenta come:

anti-bot/anti-scraping (con focus su automazioni stile Playwright/Puppeteer e agenti browser);
browser fingerprinting (raccolta di segnali come user agent, lingue, memoria dispositivo, proprietà di navigator/window, e soprattutto WebGL/canvas).

Questa parte, per chi fa frontend, è la più concreta: lo script non “fa magia”, fa cose note e diffuse nel tracciamento.

Canvas/WebGL fingerprinting in breve

Il fingerprinting grafico usa tipicamente:

rendering su canvas (forme, testi, gradienti);
lettura del risultato (pixel o hash);
variazioni dovute a GPU/driver, font, impostazioni, pipeline di rendering.

Accoppiato a segnali WebGL (vendor/renderer, estensioni, precisioni), può produrre un identificatore molto stabile.

Un livello in più: prompt injection dentro il codice

Oltre ai nomi “tossici”, alcuni script incorporano anche testo strutturato come se fosse un prompt di sistema o un’istruzione per l’AI, con l’obiettivo di:

far cambiare obiettivo al modello;
forzare la generazione di contenuti che inevitabilmente attivano i guardrail;
interrompere la spiegazione nel momento cruciale.

Non serve che quel testo venga “eseguito” dal browser: basta che finisca nel contesto che l’LLM sta leggendo.

È la stessa famiglia di attacchi concettuali delle prompt injection, ma applicata a uno scenario “code review automatizzata”.

Il dettaglio che preoccupa davvero: comportamento condizionale in ambiente Node

Un’ulteriore componente emersa in queste analisi è l’idea di inserire “trappole” che si attivano se lo script viene eseguito in un contesto Node.js (ad esempio durante analisi dinamica automatizzata o tooling improvvisato).

In quel caso, il rischio non è più solo “bloccare l’AI”: diventa un tema di sicurezza operativa, perché si entra nel territorio di accesso a file locali, variabili d’ambiente e credenziali di build/CI.

Anche quando l’obiettivo dichiarato è anti-bot, questo tipo di ramo condizionale è un campanello d’allarme: l’analisi non va mai fatta in un ambiente fidato.

Cosa insegna a chi fa frontend (anche se non fa reverse engineering)

Questo episodio è utile perché mette insieme tre realtà che nel lavoro frontend si toccano spesso:

Script di terze parti (analytics, anti-bot, CDN, “protections”) che entrano nelle pagine con privilegi enormi.
Fingerprinting come pratica industriale: non è fantascienza, è codice ordinario in produzione.
Automazione dell’analisi: affidarsi ciecamente a strumenti (LLM inclusi) è fragile quando il contenuto è ostile.

Workflow pratico per analizzare script sospetti senza farsi ingannare

Se devi capire cosa fa davvero uno script (per audit, incident response, o semplice curiosità), alcune regole riducono parecchio il rischio:

Static analysis prima di tutto: niente esecuzione “per vedere che succede”.
Deobfuscation deterministica prima di coinvolgere un modello: decode/rotate/XOR/string tables con strumenti automatici, così l’LLM vede meno “rumore” e più struttura.
Trattare il testo come dati, non come istruzioni: qualsiasi cosa assomigli a prompt, regole, override, va considerata payload ostile.
Sanitizzazione dell’input per tool e modelli: rimuovere o isolare sequenze che possono troncare output o manipolare la conversazione (marker, delimitatori, pattern tipici di injection).
Sandbox usa-e-getta se serve dinamica: VM/VPS isolata, nessun token, nessuna credenziale, nessun accesso a repo o home directory.
Valutare in base alle evidenze, non ai nomi: in questi casi gli identificatori sono progettati per mentire.

Implicazione: i guardrail non sono solo “difesa”, sono una superficie d’attacco

C’è un paradosso interessante: più un modello è attento alle policy, più diventa vulnerabile a questo tipo di “obfuscation sociale”. Non perché sbagli tecnicamente, ma perché si auto-interrompe prima di completare un lavoro legittimo (come l’audit di uno script di tracciamento).

Sintesi

L’obfuscation può oggi puntare non solo a confondere l’umano, ma a disabilitare l’assistenza AI.
Fingerprinting e anti-bot restano il contenuto reale più comune dietro questi script.
La risposta non è “non usare AI”, ma costruire pipeline robuste: deobfuscation deterministica, isolamento, sanitizzazione e static-first.

Quando un pezzo di JavaScript sembra un manifesto delirante, spesso non è follia: è design. E in un web pieno di third-party, il design ostile è una competenza da riconoscere al volo.

Articolo originale: https://frontendfacile.it/blog/l-obfuscation-che-sfrutta-i-guardrail-delle-ai-quando-i-nomi-delle-funzioni-dive

Le “runtime wars” di JavaScript sono finite: ha vinto Node (e Cloudflare si prende il resto)

frontendfacile.it — Fri, 16 Oct 2026 10:47:29 +0000

Deno viene assorbita, i prodotti vengono dismessi e il vero premio diventa l’infrastruttura distribuibile dei Durable Objects

Negli ultimi anni ci siamo abituati a parlare di “runtime” JavaScript come se fossero prodotti concorrenti alla pari: Node, Deno, Bun, Workers… ognuno con la propria filosofia e il proprio ecosistema. Oggi però il panorama si è chiarito in modo brusco: Node resta lo standard di fatto, mentre molte alternative si stanno riallineando (o venendo inglobate) da attori cloud con un obiettivo diverso dal “fare un runtime migliore”.

La notizia che segna davvero la fine di un’epoca è l’ingresso di Deno dentro Cloudflare. Non perché Cloudflare avesse bisogno di “un altro runtime”, ma perché la partita si è spostata altrove: dalla compatibilità delle API alla distribuzione dello stato.

Deno: nata per correggere Node, rallentata da Node stesso

Deno era partita con un posizionamento chiarissimo: ripensare da zero l’esperienza server-side di JavaScript.

I suoi punti di forza iniziali erano difficili da ignorare:

TypeScript di prima classe (esperienza developer immediata, senza configurazioni estenuanti)
toolchain integrata: formatter, linter e test runner inclusi
sicurezza “by default” con un modello di permessi esplicito
una gestione delle dipendenze che voleva evitare alcune storture storiche dell’ecosistema Node

Per un periodo l’idea ha funzionato: c’erano casi d’uso reali e un entusiasmo autentico. Ma il vantaggio competitivo di Deno dipendeva anche da una condizione implicita: che Node rimanesse “uguale a se stesso”.

E invece Node ha iniziato a chiudere il gap, incorporando progressivamente proprio quelle caratteristiche che rendevano Deno “diversa”: API moderne come fetch, un modello di permessi, e perfino la possibilità di eseguire file TypeScript in modo più diretto. Quando lo “standard” assorbe le innovazioni dell’alternativa, l’alternativa perde il suo spazio naturale.

Il problema non era solo tecnico: era di prodotto

Nel frattempo, i prodotti che avrebbero dovuto sostenere il business non hanno trovato abbastanza trazione.

La piattaforma di deploy è stata ridimensionata in modo importante.
Alcuni servizi sono rimasti a lungo in beta.
I framework e i progetti collaterali hanno iniziato a dare segnali di rallentamento.

Quando un’azienda costruita attorno a un runtime si ritrova a fare soprattutto compatibilità con Node, il messaggio al mercato è inevitabile: la battaglia principale non si sta più vincendo.

Ed è qui che arriva la svolta interessante: spostare l’attenzione fuori dal runtime.

Dal runtime al “distributed state”: perché Durable Objects cambiano la conversazione

Se guardi ai limiti pratici delle applicazioni moderne, soprattutto lato edge, non è più solo una questione di performance o sintassi. I “problemi difficili” sono:

distribuire compute su più macchine e region
coordinare stato e consistenza
mantenere connessioni real-time (WebSocket) senza impazzire
scalare senza introdurre una coda di complessità operativa

In questo scenario, il modello dei Durable Objects è attraente: piccoli server single-threaded con stato persistente (spesso associato a un database embedded come SQLite) e la capacità di tenere connessioni vive. È un pattern che piace perché riduce il numero di componenti esterni e rende più naturale gestire sessioni, stanze, code, coordinator e agenti.

Il punto critico? È una feature profondamente legata a una piattaforma.

CellD: la vera ragione dell’acquisizione

La mossa che cambia tutto è la comparsa di CellD: un’implementazione self-hostabile del modello “Durable Objects”, pensata per girare su infrastruttura propria.

Questa è la parte davvero strategica:

porta fuori dal recinto cloud un paradigma tipicamente “platform-locked”
rende possibile pensare a Workers + oggetti con stato persistente come stack distribuibile
sposta il valore dall’ennesimo runtime JS a un modello operativo per costruire sistemi stateful a latenza bassa

Da qui, l’acquisizione diventa più leggibile: Cloudflare non compra “un runtime peggiore”, compra una soluzione concreta a un problema che voleva risolvere da tempo: rendere davvero self-hostable il proprio approccio, con supporto ufficiale.

Cosa succede ora a Deno (runtime, Deploy e resto)

Qui la parte meno piacevole: Deno come runtime entra in modalità mantenimento.

per un periodo limitato arrivano patch e fix (soprattutto sicurezza)
poi lo sviluppo si ferma
per chi usa la piattaforma di deploy, la finestra di migrazione è stretta

In pratica: l’asset che continua a vivere e a ricevere energia è quello allineato con la strategia Cloudflare (Workers runtime open source + CellD/Durable Objects). Il resto viene progressivamente congelato.

Implicazioni pratiche per chi fa frontend e piattaforme

Anche se lavori principalmente lato frontend, questa storia ha conseguenze concrete:

Node rimane il denominatore comune
- tool, bundler, SSR, framework, CI: l’ecosistema gravita ancora lì.
Le “runtime wars” si trasformano in “state wars”
- la differenza tra piattaforme edge non è più solo “quanto è veloce il runtime”, ma “come gestisci stato, connessioni e coordinamento”.
Occhio al lock-in mascherato da feature
- quando una capability ti semplifica la vita (stateful edge, real-time, agenti), chiediti subito quanto sia portabile.
- la direzione verso componenti self-hostable è una buona notizia, ma va verificata nella pratica (API, compatibilità, operatività, costi reali).
Se stai su Deno oggi, pianifica una migrazione senza romanticherie
- l’aspetto tecnico è solo metà della storia: conta roadmap, supporto, ecosistema e tempi.

Sintesi: Node ha vinto, ma la partita interessante non era quella

Il risultato netto è che Node non è stato rimpiazzato: è stato rincorso, copiato, e infine superato su un altro asse — quello dell’infrastruttura.

Deno non diventa “il nuovo Node”; diventa (in parte) un acceleratore per rendere Workers + Durable Objects un modello più distribuibile e, potenzialmente, più universale.

La lezione più utile per chi costruisce prodotti web oggi è semplice: scegliere una runtime conta, ma conta di più scegliere un modello di stato e distribuzione che non ti blocchi domani. Quando la complessità vera si sposta su persistenza, real-time e coordinamento, la tecnologia “vincente” non è quella con l’API più pulita: è quella che ti permette di evolvere architettura e deployment senza rifare tutto da capo.

Articolo originale: https://frontendfacile.it/blog/le-runtime-wars-di-javascript-sono-finite-ha-vinto-node-e-cloudflare-si-prende-i

Immagini in dark mode senza media query: usare light-dark() in CSS

frontendfacile.it — Fri, 16 Oct 2026 10:42:29 +0000

Una singola dichiarazione per gestire varianti chiare/scure (anche per background-image) e mantenere controllo sui componenti.

Perché le immagini in dark mode sono sempre state scomode

Per colori e variabili, il passaggio tra light e dark mode è ormai routine. Le immagini, invece, spesso costringono ancora a:

duplicare regole con @media (prefers-color-scheme: dark);
mantenere asset separati e logiche “a rami”;
gestire componenti annidati in contesti diversi (un widget scuro dentro una pagina chiara, o viceversa).

Negli ultimi tempi CSS ha fatto un salto importante: light-dark() permette di scegliere tra due valori in base allo schema colore attivo, senza scrivere media query. E la parte interessante è che può essere usata anche con le immagini.

Il passaggio base: da prefers-color-scheme a light-dark()

Il modello mentale è semplice: invece di “se dark allora…”, dichiari direttamente cosa usare in light e cosa usare in dark.

Esempio tipico con colori:

:root {
  --bg: light-dark(#ffffff, #0b0d12);
  --text: light-dark(#111827, #e5e7eb);
}

body {
  background: var(--bg);
  color: var(--text);
}

Il sito seguirà automaticamente la preferenza dell’utente (o l’emulazione nei DevTools) senza bisogno della media query.

La svolta: light-dark() funziona anche con le immagini

Dove diventa davvero interessante è quando vuoi cambiare un’immagine (o un background) tra light e dark.

Per esempio, un hero con background diverso:

.hero {
  background-image: light-dark(
    url("/img/hero-light.jpg"),
    url("/img/hero-dark.jpg")
  );
  background-size: cover;
  background-position: center;
}

In pratica:

in light mode userai hero-light.jpg;
in dark mode userai hero-dark.jpg;
senza @media (prefers-color-scheme: dark).

Questo riduce duplicazioni e rende le regole molto più leggibili, soprattutto quando l’immagine è solo uno dei tanti dettagli che devono adattarsi.

“Bloccare” un componente in una color scheme specifica

Oltre al cambio automatico, c’è un altro aspetto utilissimo: puoi isolare una sezione e farle mantenere un certo schema colori anche quando il resto della pagina cambia.

Questo è particolarmente utile quando:

integri componenti riusabili in contesti diversi;
hai card/promobox con un look fisso;
vuoi garantire contrasto consistente indipendentemente dal tema globale.

Esempio: forzare una sezione a comportarsi come “dark”, anche se la pagina è in light mode.

.promo {
  color-scheme: dark;

  /* valori che reagiscono allo schema (che qui è forzato) */
  background-color: light-dark(#ffffff, #0b0d12);
  color: light-dark(#111827, #e5e7eb);

  background-image: light-dark(
    url("/img/promo-light.jpg"),
    url("/img/promo-dark.jpg")
  );
}

Con color-scheme: dark; stai dicendo al browser: questa porzione di UI deve ragionare come dark. E di conseguenza, light-dark() userà il valore scuro.

Attenzione: l’ereditarietà può sorprenderti

Se “blocchi” una sezione ma non imposti esplicitamente i colori del testo, potresti vedere comportamenti incoerenti. Il motivo è che:

il testo spesso eredita color dal body;
se il body cambia colore in base al tema, il testo dentro la sezione potrebbe cambiare anche se tu stai mantenendo uno sfondo/immagine scuri.

Soluzione: quando isoli un componente, dichiara anche i colori chiave (testo/sfondo/bordi) nello stesso contesto.

Supporto browser: cosa aspettarsi oggi

light-dark() ha ormai un supporto buono e, soprattutto, è disponibile nei principali motori moderni. Detto questo:

come funzione per i colori è mediamente più affidabile;
l’uso con immagini può essere leggermente meno uniforme (dipende dal browser e dalla versione).

In pratica: è una scelta sensata se stai lavorando con un target moderno e fai già uso di CSS recente. Se devi coprire ambienti più datati, valuta un fallback.

Sintesi operativa

Se stai ancora gestendo light/dark con @media (prefers-color-scheme: dark), light-dark() ti permette di semplificare e rendere più dichiarativo il CSS.
Puoi usare light-dark() anche per switchare asset grafici, inclusi i background.
Con color-scheme puoi isolare componenti e farli comportare come light o dark indipendentemente dal tema globale.
Quando “blocchi” una sezione, non dimenticare di impostare i colori del testo per evitare effetti collaterali dovuti all’ereditarietà.

La conseguenza pratica è un CSS più pulito, meno duplicato e più modulare: esattamente quello che serve quando i temi diventano parte strutturale del design system.

Articolo originale: https://frontendfacile.it/blog/immagini-in-dark-mode-senza-media-query-usare-light-dark-in-css

V+ (Vit Plus): l’ambiente “tutto incluso” che mette ordine in linting, formatting, test e workflow

frontendfacile.it — Thu, 15 Oct 2026 11:15:53 +0000

Un solo CLI, un solo file di configurazione, strumenti coerenti tra loro: meno colla, meno tool scollegati, più velocità e standard condivisi.

Negli ultimi anni abbiamo normalizzato una certa “frammentazione” nel setup dei progetti frontend: scegli un bundler, poi un runner per i test, poi un formatter, poi un linter, poi il package manager “giusto”, poi i git hooks, poi la CI… Il risultato è spesso un mosaico di tool ottimi singolarmente, ma incollati insieme con configurazioni ridondanti e punti di rottura continui.

V+ (Vit Plus) nasce esattamente per eliminare quella colla. L’idea è semplice e ambiziosa: prendere le esigenze ricorrenti di quasi ogni app web e offrirle come un’esperienza unificata, con una configurazione centralizzata e comandi coerenti.

Il problema reale: non sono 2-3 strumenti, è un ecosistema

Quando si pensa allo “stack minimo” di un’applicazione web, vengono subito in mente quattro pilastri:

Linting (tipicamente ESLint)
Formatting (tipicamente Prettier)
Testing (Jest, Vitest, ecc.)
Bundling/dev server (spesso Vite)

In pratica però ogni progetto porta con sé altro:

Package manager (npm/pnpm/bun…)
Continuous Integration (config e pipeline)
Git hooks (pre-commit, pre-push)
Build di librerie (non solo app, ma package riusabili o tool interni)

Il punto non è che manchino strumenti: è l’opposto. Esistono troppe combinazioni possibili per ogni voce, e spesso il team finisce con:

configurazioni duplicate
standard difficili da imporre
comportamenti diversi tra macchina locale e CI
tempi di esecuzione non ottimali

Cos’è V+: un punto di ingresso unico

V+ prova a fare una cosa precisa: raggruppare ciò che serve a un progetto moderno in un unico CLI e un’unica configurazione, con integrazione “di default” tra i vari pezzi.

Questo significa:

creazione progetto (app, monorepo, libreria)
lint + format integrati
test integrati
comandi dev/build/preview integrati
workflow di controllo qualità (check, stage, hook) già pronti

Installazione e filosofia d’uso

V+ si comporta come un tool “di sistema”: l’approccio tipico è installarlo globalmente e usarlo ovunque, un po’ come faresti con Node o un package manager.

Una volta installato, il CLI espone una serie di comandi sotto vp.

Creare un progetto: app, monorepo o libreria

Il comando chiave è vp create, che guida nella creazione di:

standard application (setup classico)
monorepo (struttura app + packages)
library (codice da distribuire/riusare)

Durante lo scaffold puoi scegliere, ad esempio:

package manager (es. pnpm)
inizializzazione git
setup di hook pre-commit
file/standard per agenti AI (utile se il team usa strumenti assistiti)

Il risultato più interessante non è tanto la cartella generata, quanto l’assetto: pochi file di config, e un fulcro unico.

Una sola configurazione: `v.config`

La caratteristica che cambia davvero il modo di lavorare è che la configurazione tende a concentrarsi in un solo file (ad esempio v.config).

Qui vengono gestiti:

regole di formatting
regole di linting
opzioni di type checking
task di check/qualità
comportamento dei file “staged” (pre-commit)

Lint e format integrati (stack OXC)

V+ usa Oxlint e Oxformat, strumenti basati su Rust con l’obiettivo di essere vicini a ESLint/Prettier come capacità, ma molto più rapidi e più semplici da far convivere, perché nativamente inseriti nello stesso sistema.

In pratica:

vp lint esegue il linter
vp format formatta il codice
vp check fa entrambe le cose in sequenza

Type checking dentro il workflow di lint

Un dettaglio importante: la pipeline può includere type-aware linting e type checking. In molti progetti oggi si finisce a eseguire:

ESLint
Prettier
tsc --noEmit

con tre comandi e tre logiche diverse.

Con V+ l’idea è rendere naturale che i controlli di tipo facciano parte del “check” complessivo, riducendo la possibilità di far passare codice che “sembra” OK ma non lo è.

Git hooks e pre-commit: standard forzati (nel modo giusto)

Uno dei vantaggi più pratici: il controllo qualità può diventare un blocco reale prima del commit.

Il meccanismo tipico è:

sui file staged viene eseguito vp check (spesso con fix automatico)
se qualcosa è fixabile, viene corretto
se restano errori non risolvibili automaticamente, il commit viene interrotto

Questo è utile sempre, ma diventa fondamentale quando:

il team è grande
le PR arrivano da contesti diversi
si usa molto codice generato (incluse soluzioni assistite): senza guardrail rigidi, la qualità degrada in fretta

Integrazione editor: formatting e linting mentre scrivi

Per lavorare bene serve che l’editor “senta” le stesse regole del progetto.

In VS Code, un extension pack dedicato abilita lint/format automatici coerenti con v.config: salvi un file e viene formattato secondo gli standard del repository, senza dipendere da configurazioni locali strane o estensioni sovrapposte.

Template e bootstrap di framework: partire da Vite (e oltre)

V+ non obbliga a un singolo tipo di progetto. Puoi:

creare un progetto “base”
oppure usare template/shortcut per partire con scaffolding noti

Ad esempio, puoi innestarti su una creazione stile Vite e scegliere framework (React, ecc.) e varianti (TypeScript). Il valore aggiunto è che il progetto nasce già allineato ai controlli di V+ (lint/format/hook/check), invece di doverli aggiungere e farli combaciare dopo.

Monorepo: struttura e comandi più lineari

Con l’opzione monorepo, trovi tipicamente:

apps/ per le applicazioni
packages/ per i moduli condivisi

I comandi diventano più ergonomici perché V+ può offrire scorciatoie per eseguire task su porzioni del repo (es. una singola app), e ogni area può avere configurazioni specifiche quando serve, senza perdere il controllo centrale.

Generator: scaffolding interno per pacchetti/progetti

Un’idea molto interessante è il supporto ai generator, cioè la possibilità di creare rapidamente nuovi package/app all’interno del monorepo seguendo template definiti.

Se il team ha un modo standard di iniziare un progetto (struttura cartelle, dipendenze, script, convenzioni), un generator riduce la variabilità e accelera il provisioning.

Testing: `vp test` con Vest

Per i test, l’esperienza è volutamente minimale:

vp test per eseguire la suite
vp test watch per la modalità watch
vp test --coverage per la copertura

Sotto il cofano viene usato Vest, con un’impostazione molto familiare a chi arriva da Jest: aspettati un modello simile, ma integrato nello stesso “mondo” dei comandi V+.

Dev/build/preview: tutto quello che ti aspetti da Vite, ma unificato

Dato che V+ si appoggia a Vite per la parte app, i comandi tipici restano immediati:

vp dev avvia il server di sviluppo
vp build genera la build di produzione
vp preview serve la build in locale per verificarla

Il beneficio qui non è reinvenzione: è coerenza. Usi lo stesso entrypoint CLI per tutto il ciclo di vita.

Packaging: librerie ed eseguibili

Oltre alle app, V+ include comandi per packaging di librerie o eseguibili (ad esempio vp pack), evitando di introdurre tool ad hoc anche per questa parte quando il progetto non è “solo una web app”.

Perché ha senso: meno decisioni ripetute, più standard eseguibili

La promessa di V+ non è “un tool magico”. È più concreta:

riduce il numero di scelte che rifai ad ogni progetto
accorcia il tempo di setup (meno file, meno incastri)
rende gli standard parte del workflow (soprattutto con pre-commit e check)
aumenta la velocità (stack Rust per lint/format)

Implicazione pratica

Se oggi il tuo repo ha:

ESLint + Prettier + script custom
tsc a parte
husky/lint-staged o equivalenti
CI che replica a fatica ciò che fai in locale

…un approccio unificato come V+ diventa interessante perché sposta il focus da “manutenere tooling” a “scrivere software”, con regole chiare e verificabili automaticamente.

Sintesi

V+ mette insieme ciò che normalmente è sparso: scaffold, lint/format, type checking, test, workflow pre-commit, comandi di build e supporto a monorepo. Il valore non è avere più funzionalità, ma averle integrate, veloci e configurate in un solo posto.

Se l’obiettivo del tuo team è ridurre attrito, configurazioni duplicate e divergenze tra ambienti, questo tipo di tool “batteria inclusa” non è una comodità: è un investimento diretto sulla qualità e sulla sostenibilità del progetto.

Articolo originale: https://frontendfacile.it/blog/v-vit-plus-l-ambiente-tutto-incluso-che-mette-ordine-in-linting-formatting-test-

S3 è “stupido” per design, ed è proprio per questo che regge mezzo Internet

frontendfacile.it — Thu, 15 Oct 2026 11:10:52 +0000

Da quattro verbi a primitive distribuite: consistenza forte e write condizionali stanno trasformando l’object storage in un mattone su cui costruire log, code e persino database.

S3 è una di quelle tecnologie che sembrano quasi banali finché non ti rendi conto di quanta parte dell’ecosistema moderno ci sia costruita sopra. L’API, ridotta all’osso, è imbarazzante per semplicità: carichi un oggetto, lo leggi, lo elimini, ne fai la lista. Fine. Niente query, niente transazioni, niente indici, niente join.

Eppure basta toccare S3 nel punto sbagliato perché “mezza Internet” inizi a tremare. Questo paradosso è interessante: com’è possibile che un servizio che non fa query e non fa transazioni sia così centrale per così tanti sistemi complessi?

La risposta sta in due fattori:

S3 è un primitivo volutamente “stupido”: pochi concetti, poco comportamento, molta stabilità nel tempo.
Le garanzie sono fortissime (durabilità, scalabilità, disponibilità) e le complicazioni vengono spostate “sopra”, nei pattern architetturali.

Negli ultimi anni, però, non è cambiato solo “cosa ci costruiamo sopra”: sono cambiate anche alcune proprietà di base di S3 che lo rendono, oggi, una piattaforma di coordinamento sorprendentemente potente.

Perché l’API minimale di S3 è un vantaggio (non un limite)

Un’API piccola è una promessa: meno superficie significa meno breaking change, meno ambiguità, meno comportamenti “magici”. Non è raro trovare codice scritto molti anni fa che continua a funzionare senza modifiche, proprio perché i mattoni sono sempre gli stessi.

In cambio, S3 si prende in carico il lavoro più pesante:

replica interna su più macchine e data center
durabilità elevatissima
scala massiva sia per numero di oggetti che per throughput

Il trade-off storico è sempre stato chiaro: tu rinunci a semantiche ricche (file system, transazioni, lock) e in cambio ottieni un servizio “boringly reliable”.

Il punto, però, è che per molto tempo mancava un ingrediente fondamentale per usare S3 come base di sistemi “coordinati”.

Il vecchio problema: l’eventual consistency ti impediva di ragionare

S3, per anni, ha operato con eventual consistency in scenari cruciali come overwrite e delete.

In pratica:

scrivi una nuova versione di un oggetto
S3 ti dice “ok”
per un intervallo breve (di solito millisecondi, talvolta secondi) alcune letture potevano ancora vedere la versione precedente

Questo è fastidioso per un avatar che “non si aggiorna subito”. È catastrofico se stai simulando un database:

leggi saldo = 100
scrivi saldo = 150
rileggi e ottieni ancora 100

Non puoi costruire aggiornamenti corretti, né coordinarti tra writer multipli.

Il risultato: per usare S3 come storage… ti serviva un database

In molte pipeline big data e data lake, la soluzione è stata appoggiarsi a un sistema esterno (spesso DynamoDB) per:

tenere traccia di quali file “esistono davvero”
evitare conflitti tra writer
serializzare commit

In altre parole: S3 come layer dati + database come layer di coordinamento.

2020: strong consistency (finalmente)

A fine 2020 è arrivata una svolta fondamentale: strong consistency.

Da quel momento, una volta che S3 conferma una write:

ogni successiva GET vede la versione nuova
ogni successiva LIST è coerente
vale anche per overwrite e delete

Senza cambiare API, senza costi extra, senza migrazioni: semplicemente le stesse chiamate hanno iniziato a restituire “la risposta giusta”.

Ma attenzione: questa proprietà risolve una sola domanda.

“Leggo l’ultima versione?”

Non risolve invece la domanda che distrugge i sistemi concorrenti.

“Cosa succede se due writer aggiornano nello stesso momento?”

Strong consistency non ti salva dal classico lost update:

A legge 100
B legge 100
A scrive 150
B scrive 150

Tutto perfettamente consistente. Eppure è sbagliato: un deposito è sparito.

Per evitare questo, serve una semantica del tipo: scrivi solo se…

2024: write condizionali, ETag e il ritorno del Compare-and-Swap

Nel 2024 S3 ha aggiunto un’idea che, in pratica, porta dentro al bucket un mattoncino tipico dei database: la conditional write.

Una conditional write è una normale PUT, ma con una precondizione. Se la condizione fallisce, la write viene rifiutata con un errore (tipicamente 412 Precondition Failed). Importante: il controllo e la write avvengono in un singolo passo.

1) `If-None-Match`: crea solo se non esiste

Questa regola ti permette di dire:

“crea questo oggetto solo se non esiste già”

È un abilitatore enorme per pattern append-only:

log di commit numerati (commit-42 può esistere una sola volta)
code basate su oggetti immutabili
meccanismi di “claim” (un solo writer si prende un ID)

Dove prima serviva un coordinatore esterno, ora può bastare il bucket.

2) `If-Match` + ETag: aggiorna solo se nessuno ha cambiato

Ogni oggetto in S3 ha un ETag, un identificatore che cambia quando cambia il contenuto (pensalo come “impronta” della versione corrente).

Con If-Match puoi dire:

“scrivi questa nuova versione solo se l’ETag è ancora quello che ho letto”

Questo è, di fatto, un Compare-and-Swap (CAS):

leggo valore + ETag = V1
calcolo il nuovo valore
provo a scrivere con If-Match: V1
se qualcuno ha scritto prima, ricevo 412, rileggo e riprovo

È la base concettuale di:

update sicuri
lock leggeri
leader election / single-writer
coordinamento di metadati

E soprattutto: non richiede un database esterno per evitare lost update.

Pattern che funzionano bene su S3: log e manifest

Uno schema che sta prendendo piede è questo:

ogni write produce un nuovo oggetto immutabile (append)
esiste un piccolo file indice/manifest che “punta” agli oggetti (o ne elenca l’ordine)
l’aggiornamento del manifest avviene via CAS (ETag + If-Match)

Così ottieni:

immutabilità dei dati (più facile da rendere robusta)
rollback e audit naturali (le vecchie entry restano)
coordinamento ridotto a un singolo punto piccolo (il manifest)

È lo stesso modo di ragionare tipico di molti formati da data lake (log di commit + file dati), e oggi diventa più accessibile perché il “coordinamento minimo” può stare nello stesso object storage.

La portabilità come effetto collaterale: l’API S3 non è più “solo AWS”

Un altro aspetto pratico: S3 come API è diventata uno standard de facto.

Molti provider e prodotti implementano un’API compatibile S3 (object storage self-hosted e cloud). Questo sposta il valore dal servizio specifico al contratto:

scrivi contro “S3 API”
cambi backend con modifiche minime

Non è una garanzia assoluta di compatibilità al 100% (ci sono differenze), ma come direzione è potente: investire in questi pattern significa spesso investire in qualcosa di più portabile di quanto sembri.

Perché (ancora) non è la scelta giusta per tutto

L’entusiasmo va bilanciato con tre limiti molto concreti.

1) Latenza

Una richiesta a object storage tende a costare decine di millisecondi. Un disco locale lavora in microsecondi. Se il tuo dominio richiede single-digit milliseconds end-to-end, S3 come “database primario” ti mette immediatamente in salita.

2) Costi per request

Lo storage è economico. Le request no, soprattutto se fai tantissime piccole write. È uno scenario in cui il costo può diventare dominante rispetto ai GB archiviati.

3) Semantica non-POSIX

S3 non è un file system:

niente append “vero” a un file
rename non è un’operazione atomica economica come su FS tradizionali
devi progettare intorno al concetto di oggetti immutabili e “nuove versioni”

C’è anche la possibilità di usare tier più veloci, ma spesso con trade-off di resilienza/replica (ad esempio vincoli di zona).

Regola pratica: eccelle come stato durevole, soffre come stato caldo

Una buona euristica:

Ottimo per

log append-only
code e stream “a chunk”
data lake (Iceberg/Delta-style)
backup, snapshot, archivi
vettori/embedding quando lavori a segmenti grandi e con caching

Sconsigliato per

workload user-facing con latenza rigidissima
carichi “chatty” ad altissima frequenza di piccole write

Quando si adotta S3 come fonte di verità, spesso funziona bene una strategia ibrida:

S3 come source of truth
cache locale / storage veloce per hot path
CAS su manifest/metadati per decidere chi vince e mantenere coerenza

Sintesi: quattro verbi, garanzie forti, e un nuovo spazio di design

S3 resta un’API minimale — ed è proprio questa la sua forza. Per anni la consistenza eventuale lo ha tenuto fuori dal perimetro “database-like”. Con la strong consistency e le write condizionali basate su ETag, oggi S3 offre primitive che permettono:

letture coerenti
aggiornamenti sicuri senza lost update
coordinamento leggero tra writer

Il risultato non è “S3 rimpiazzerà tutti i database”, ma qualcosa di più interessante: un primitivo distribuito estremamente semplice su cui progettare sistemi che prima richiedevano più componenti, più operational burden e più punti di rottura.

La domanda utile, quindi, non è se S3 sia “troppo stupido” o “geniale”. È: quanto del tuo stato è davvero caldo e transazionale, e quanto invece può essere trattato come log durevole con caching intelligente? Quando la risposta pende verso la seconda opzione, S3 smette di essere un posto dove “buttare file” e diventa una base architetturale sorprendentemente moderna.

Articolo originale: https://frontendfacile.it/blog/s3-e-stupido-per-design-ed-e-proprio-per-questo-che-regge-mezzo-internet

Quando un “agente” ti tradisce: la lezione (scomoda) sulla sicurezza interna nelle aziende AI

frontendfacile.it — Thu, 15 Oct 2026 11:05:51 +0000

Dalla ricerca delle sale riunioni al microcontroller avvolto nella carta igienica: perché i controlli tecnici e di processo contano più del mito dell’infallibilità.

Negli ultimi anni abbiamo normalizzato l’idea che i rischi “seri” per un’azienda tech arrivino da fuori: exploit, supply chain, credential stuffing, zero-day. Ma c’è un fronte molto meno cinematografico e molto più concreto: la minaccia interna.

Un recente caso che ha coinvolto un ingegnere di primo piano su una piattaforma di “agenti” in un’azienda AI mette in fila, in modo quasi didattico, diversi errori di processo e diverse contromisure che invece hanno funzionato. Il punto interessante per chi fa frontend (e, più in generale, prodotto) non è il gossip: è capire come si scopre un abuso, perché spesso la differenza tra “incidente” e “catastrofe” sta tutta nei dettagli operativi.

1) La minaccia interna non è un concetto astratto

Quando si parla di insider threat molti pensano a scenari da spionaggio internazionale. In realtà, nella pratica quotidiana, la minaccia interna è spesso:

uso improprio di strumenti interni (ricerche anomale, scraping di calendari, consultazione di asset “sensibili” senza ragioni operative)
accessi e movimenti fisici in aree dove non serve andare
introduzione di hardware non autorizzato (il classico “USB device”, o dispositivi IoT “innocui”)

La cosa più scomoda? Chi lavora dentro conosce i processi, sa cosa “sembra normale” e dove le procedure sono più lasche.

2) Un pattern ricorrente: ricognizione → esecuzione → copertura maldestra

Nel caso emerso, la sequenza è quella tipica di un attaccante interno:

Ricognizione: uso di un sistema interno (un “agente”) per identificare sale riunioni, capienze, calendari e soprattutto quando si tengono meeting dirigenziali e quando arrivano partner esterni.
Preparazione: ricerca di come assemblare un piccolo dispositivo di registrazione Wi‑Fi con storage cifrato.
Posizionamento: inserimento fisico del dispositivo in una sala riunioni executive (alimentato da una porta USB, per esempio dietro un TV).
Tentativo di copertura: camuffamento improvvisato del device per renderlo meno evidente.

Per chi progetta prodotti, questa è una lezione: la sicurezza non è solo software. Se un attaccante può infilare hardware in una stanza sensibile e alimentarlo da porte lasciate disponibili, il problema non è (solo) l’endpoint.

3) Perché è stato scoperto in fretta: controlli e “banalità” che funzionano

Un aspetto interessante è quanto sia stato rapido il rilevamento: un dispositivo del genere può essere individuato senza “magia”, se esiste disciplina operativa.

Sweep e contro-sorveglianza tecnica

Le sale riservate dovrebbero avere:

sweep periodici (controlli fisici e RF/Wi‑Fi)
inventario degli oggetti presenti e delle porte accessibili
procedure per segnalare anomalie (anche banali: “c’è una cosa nuova dietro al monitor”)

Tracce digitali: MAC address, accessi e correlazioni

Una volta recuperato un device, spesso la parte più facile arriva dopo:

un microcontroller Wi‑Fi espone quasi sempre un MAC address
se quel MAC compare in chat, ticket, log o foto, si crea una correlazione molto forte
la telemetria di rete (anche solo DHCP, associazioni Wi‑Fi, log di NAC) può agganciare il punto di ingresso

La realtà è che molti “piani” crollano perché lasciano tracce banali e verificabili. Non serve un thriller: serve logging tenuto bene e persone che lo sanno leggere.

Il “pezzo” decisivo: la sicurezza fisica

Non si può ignorare la componente fisica:

badge access, controllo aree e percorsi
telecamere e retention ragionevole
policy hardware (no device non autorizzati; porte USB sigillate o disabilitate in aree critiche)

In questo caso, riprese e monitoraggio mirato hanno creato una prova semplice: presenza ripetuta vicino alla stanza e ritorno sul luogo.

4) Cosa c’entra con chi fa frontend (molto più di quanto sembri)

Chi lavora sul frontend spesso gestisce (o tocca indirettamente) aspetti delicati:

dashboard interne con calendari, sale riunioni, accessi e ruoli
strumenti di supporto che aggregano dati (CRM, partner, pipeline)
UI per agenti/automazioni che rendono più semplice interrogare sistemi aziendali

Se costruisci interfacce o agenti interni, stai anche costruendo superpoteri di ricognizione. Alcune implicazioni pratiche:

Principle of Least Privilege: l’UI non dovrebbe rendere “sfogliabile” ciò che non serve al lavoro quotidiano.
Audit trail serio: non solo “chi ha cliccato cosa”, ma anche “quali query”, “quali risultati”, “a quale ritmo”.
Rate limit e anomaly detection: un dipendente che scorre calendari e location come fosse un crawler dovrebbe accendere alert.
Data minimization: se l’obiettivo è prenotare una sala, forse non serve esporre meeting executive, ospiti, note o dettagli.

5) Misure concrete che riducono davvero questo rischio

Senza trasformare l’azienda in un bunker, ci sono misure realistiche:

Classificazione delle sale e hardening fisico
- porte USB disabilitate o bloccate
- controlli periodici e inventory fotografico
Controlli sugli agenti interni
- scope di accesso rigorosi
- “guardrail” sulle query (per esempio bloccare ricerche mirate su “executive”, “leadership meeting”, ecc. se non necessarie)
Logging e correlazione multi-sorgente
- accessi fisici + accessi app + log rete
- retention sufficiente per ricostruire timeline
Segnali deboli, risposta rapida
- canali di segnalazione semplici
- playbook: cosa fare quando trovi un dispositivo sconosciuto
Cultura della sicurezza applicata al prodotto
- threat modeling anche per feature “banali” (prenotazioni, directory, search interna)
- revisione dei permessi come parte delle PR/Design review

Sintesi: l’infallibilità non esiste, ma l’igiene operativa sì

Questo episodio ha un messaggio chiaro: non serve un attacco sofisticatissimo quando processi, spazi e strumenti interni permettono troppe libertà senza tracciamento. Allo stesso tempo, è rassicurante vedere che controlli relativamente “prosaici” — sweep, logging, correlazione, sicurezza fisica — possono fermare un incidente in tempi molto rapidi.

Per chi costruisce software (frontend incluso), l’implicazione pratica è semplice: ogni feature che rende più facile “trovare cose” e “collegare informazioni” deve essere progettata assumendo che qualcuno, prima o poi, proverà a usarla contro l’organizzazione. La differenza la fanno i guardrail: pochi, mirati, misurabili.

Articolo originale: https://frontendfacile.it/blog/quando-un-agente-ti-tradisce-la-lezione-scomoda-sulla-sicurezza-interna-nelle-az

Quando scrivere codice diventa più veloce, cosa si rompe dopo? Il vero collo di bottiglia è il feedback

frontendfacile.it — Thu, 15 Oct 2026 11:00:51 +0000

AI, automazione e deploy rapidi non eliminano i problemi: li spostano. E spesso il prossimo blocco è tutto ciò che sta tra una riga di codice e l’impatto in produzione.

Negli ultimi anni la velocità con cui riusciamo a produrre codice è aumentata drasticamente. Tra librerie mature, toolchain sempre più integrate e — soprattutto — AI che accelera la scrittura e la rifinitura delle feature, il tempo “puro” di implementazione tende a comprimersi.

Il punto è che un sistema non diventa più efficiente perché accelera un singolo passaggio. Diventa più efficiente quando si riduce il collo di bottiglia che limita l’intero flusso.

E quando quel collo di bottiglia si sposta (perché lo abbiamo risolto), ne emerge immediatamente un altro.

Il collo di bottiglia reale non è il coding: è il feedback

Un modo semplice per vederla è osservare cosa succede quando il team è “bloccato” sul deploy.

Se il rilascio è lento, costoso o burocratico, scrivere più codice non aiuta. Anzi:

accumuli più cambiamenti in un unico rilascio;
aumenti la dimensione del batch (più file, più feature, più rischi intrecciati);
riduci la frequenza del feedback reale (quello che arriva dall’uso in produzione);
rendi più difficile attribuire bug e regressioni a una causa specifica.

In pratica, stai comprimendo settimane di scelte dentro un’unica finestra di verifica. Quando qualcosa va storto, la domanda non è “perché è successo?”, ma “da dove comincio a guardare?”.

La regola resta valida anche nell’era AI: se generi codice 2–5x più velocemente ma rilasci allo stesso ritmo di prima, stai semplicemente aumentando la pressione nel punto di strozzatura.

Deploy come strozzatura: come si aggira (senza barare)

Nel mondo frontend e cross-platform, la flessibilità di rilascio è spesso il moltiplicatore più sottovalutato. Alcune tecniche riducono il problema alla radice perché ti permettono di distribuire cambiamenti più piccoli e più mirati.

Over-the-air updates (mobile)

Su stack come React Native (e alternative affini), gli aggiornamenti OTA possono ridurre drasticamente l’attrito per:

fix rapidi;
miglioramenti incrementali;
rollout progressivi.

Non è “deploy senza controllo”: è deploy con un controllo più fine, purché accompagnato da disciplina (versioning, canali, metriche, rollback chiari).

Delta bundles per JavaScript

Quando i bundle diventano pesanti, spedire ogni volta tutto è inefficiente. I delta bundle (spedire solo la differenza) riducono:

peso del rilascio;
tempi di distribuzione;
frizione percepita dagli utenti.

E, indirettamente, aumentano la voglia del team di rilasciare spesso perché ogni rilascio “costa” meno.

Server-driven UI / SSR: rilasciare parti del prodotto

Quando hai architetture che consentono di modulare l’esperienza lato server (UI guidata dal server, rendering server-side, configurazioni e feature remote), ottieni un vantaggio operativo enorme:

puoi attivare/disattivare subset di funzionalità;
puoi fare rollout selettivi;
puoi limitare l’impatto di una regressione.

Il filo conduttore è sempre lo stesso: ridurre la dipendenza da un singolo “grande rilascio”.

Se non puoi rilasciare spesso, “stai accumulando rischio”

Quando il deploy è la strettoia, il risultato tipico è il “mega rilascio”: tante modifiche insieme, test intensivi a ridosso della scadenza, correzioni in emergenza.

Questo modello ha un effetto collaterale chiaro:

il QA (umano o automatico) viene spostato tardi;
i problemi vengono scoperti quando costano di più;
il team finisce a ottimizzare la consegna invece della qualità intrinseca.

Il miglioramento che cambia davvero l’economia del progetto è portare il feedback prima.

“Shift left”: anticipare la qualità per rendere i deploy un non-evento

Una lezione che non invecchia è questa: spedire in tempo non significa avere successo.

È possibile consegnare una feature “puntuale” e poi pagare tutto con interessi in:

supporto clienti;
bugfix continui;
regressioni;
costi operativi e infrastrutturali;
perdita di fiducia (utenti che se ne vanno dopo un crash o un’esperienza degradata).

Per questo il mantra dello shift left resta centrale: spostare la qualità a monte.

E qui l’AI è utile sul serio, ma a una condizione: devi chiederle le cose giuste.

AI: accelera la qualità solo se la tratti come obiettivo

L’AI può aiutare molto su:

generazione di unit test mirati;
scenari di edge case;
fuzzing e test “aggressivi” su input e stati;
analisi di copertura e miglioramento della suite.

Ma se la usi solo per “scrivere feature”, otterrai esattamente quello: più feature. Non automaticamente più robustezza.

Il passaggio mentale è: non delegare soltanto la produzione del codice, ma la produzione di feedback.

Il rischio che esplode quando il prodotto ha successo: i costi di esercizio

C’è un altro collo di bottiglia che spesso arriva subito dopo: l’operatività.

Anche con un frontend eccellente, se il prodotto scala e non hai ragionato su:

costi cloud (AWS/GCP/Azure) al crescere del traffico;
carichi, caching, pattern di accesso;
degradazione e fallback;
telemetria e osservabilità;

puoi ritrovarti nella situazione paradossale: avere successo e fallire lo stesso.

Il punto non è prevedere il futuro con precisione, ma fare domande scomode:

“Se domani arrivano 10.000 utenti/ora, reggiamo?”
“Se arrivano 1M di DAU in due settimane, quanto ci costa?”
“Abbiamo un piano di rollback e di kill switch credibile?”

Quando il coding accelera, la responsabilità di zoomare out aumenta.

Implicazione pratica: ottimizza il flusso, non la tastiera

Se oggi il tuo team sente di essere “più veloce” ma rilascia con la stessa ansia di sempre, probabilmente non hai risolto il problema: lo hai solo spostato.

Un percorso pragmatico, soprattutto in contesti frontend/mobile:

Riduci la dimensione dei rilasci: piccoli cambiamenti, più spesso.
Sblocca il deploy: OTA, delta bundle, strategie server-driven dove ha senso.
Costruisci feedback rapidi: test automatici utili, non cosmetici.
Misura qualità e costi: osservabilità, crash rate, performance e spesa operativa.
Tratta l’AI come amplificatore di disciplina: non come scorciatoia.

Sintesi

Quando scrivere codice diventa più veloce, il prossimo collo di bottiglia tende a essere tutto ciò che trasforma quel codice in apprendimento: deploy, test, operazioni e feedback reale dagli utenti. Se ottimizzi solo la produzione, accumuli rischio. Se ottimizzi il feedback, rendi i rilasci piccoli, frequenti e — idealmente — un non-evento.

Articolo originale: https://frontendfacile.it/blog/quando-scrivere-codice-diventa-piu-veloce-cosa-si-rompe-dopo-il-vero-collo-di-bo

DEV Community: frontendfacile.it

Come adottare le novità CSS senza rischiare regressioni

1) Baseline: utile, ma non è un via libera automatico

2) Per decidere davvero: guarda la compatibilità “versione per versione”

Occhio speciale a iOS

3) Domanda guida: cosa succede se la feature non è supportata?

Caso A — Se fallisce, non succede nulla di grave

Caso B — Se fallisce, può degradare l’esperienza in modo evidente

4) Fallback via cascata: dichiara due volte (nell’ordine giusto)

Automatizzare i fallback

5) Feature queries: @supports come cintura di sicurezza

5.1) @supports con custom properties (pattern molto pratico)

5.2) @supports per interi blocchi di layout (es. subgrid)

5.3) @supports può testare anche i selettori

6) Polyfill o attesa: quando ha senso

Sintesi operativa

Supply chain, wallet drain e bug nel kernel: la settimana in cui la sicurezza ha ricordato perché non esiste “solo frontend”

1) Quando un’estensione “ufficiale” diventa un cavallo di Troia

Implicazione pratica per team frontend

2) Script di terze parti: basta un tag per drenare un’app

Implicazione pratica per frontend: terze parti = attacco alla sessione

3) Una vulnerabilità nel kernel Linux diventa “facile” quando puoi automatizzare il timing

Implicazione pratica per chi fa web

Il filo rosso: la fiducia implicita è il vero bug

Checklist finale (pragmatica) per team frontend

Conclusione

Countdown per festività globali: smettere di lottare con Date e passare a Temporal

Perché Date porta a implementazioni fragili

Temporal: il cambio di paradigma giusto per festività “global”

Vantaggio concreto: niente bug da leap month shifting

Countdown robusto: confrontare date, non timestamp

Durate “leggibili”: l’ultimo miglio del banner

Un approccio pratico per un banner “global holidays ready”

Sintesi

Vector database per frontend: embeddings, similarity search e perché ti servono davvero nel 2026

Perché un frontend dovrebbe interessarsi alle vector database

Cos’è una vector database (definizione operativa)

La pipeline: ingestion e retrieval (il flusso che si ripete sempre)

1) Ingestion phase: da dato grezzo a vettori indicizzati

2) Retrieval phase: query → embedding → vicini più simili

Perché i database tradizionali non bastano

Vettori: la definizione minima che serve

Similarity: cosine similarity e distanza euclidea (quando e perché)

Il vero trucco: indicizzazione ANN (IVF e HNSW)

IVF (Inverted File Index)

HNSW (Hierarchical Navigable Small World)

Tokenizzazione: perché non basta “passare testo al modello”

Use case concreti (quelli che toccano davvero i prodotti)

1) Semantic search su documentazione e knowledge base

2) Recommendation

3) Anomaly e fraud detection

Mini-progetto mentale: embeddings + ChromaDB + ricerca per significato

Sintesi: cosa portarti a casa

Debug dei tool WebMCP con Chrome DevTools for Agents: un flusso pratico per testare, trovare errori e correggerli

1) Collegati al browser e verifica l’ambiente di esecuzione

2) Elenca i tool WebMCP disponibili (sanity check)

3) Esegui una sequenza di tool e controlla lo stato risultante

4) Introduci un bug intenzionale per validare il flusso di debug

5) Usa la console come fonte di verità (e non solo come “log”)

6) Correggi e ripeti: il ciclo “fix → re-run” deve essere veloce

7) Debug anche via CLI: utile per automazioni e CI

8) Configurazione e flag: trattali come parte del prodotto

Sintesi operativa

L’obfuscation che sfrutta i guardrail delle AI: quando i nomi delle funzioni diventano un’arma

La tecnica: “avvelenare” i nomi per attivare i blocchi di sicurezza

Perché funziona

Il contesto reale: fingerprinting e anti-bot mascherati da “horror lessicale”

Canvas/WebGL fingerprinting in breve

Un livello in più: prompt injection dentro il codice

Il dettaglio che preoccupa davvero: comportamento condizionale in ambiente Node

Cosa insegna a chi fa frontend (anche se non fa reverse engineering)

Workflow pratico per analizzare script sospetti senza farsi ingannare

Implicazione: i guardrail non sono solo “difesa”, sono una superficie d’attacco

Sintesi

Le “runtime wars” di JavaScript sono finite: ha vinto Node (e Cloudflare si prende il resto)

Deno: nata per correggere Node, rallentata da Node stesso

Il problema non era solo tecnico: era di prodotto

Dal runtime al “distributed state”: perché Durable Objects cambiano la conversazione

CellD: la vera ragione dell’acquisizione

Cosa succede ora a Deno (runtime, Deploy e resto)

Perché `Date` porta a implementazioni fragili

Una sola configurazione: `v.config`

Testing: `vp test` con Vest

1) `If-None-Match`: crea solo se non esiste

2) `If-Match` + ETag: aggiorna solo se nessuno ha cambiato