Qual è la differenza tra CSR, SSR e SSG?
Il client-side rendering (CSR) spedisce un guscio HTML minimo e costruisce la pagina nel browser con JavaScript, semplice da ospitare ma lento al primo paint e più debole per la SEO. Il server-side rendering (SSR) genera l'HTML completo sul server per ogni richiesta, offrendo primo paint veloce e buona SEO al costo di calcolo sul server e di uno step di hydration. La static site generation (SSG) renderizza l'HTML una volta sola al momento della build così che una CDN lo serva istantaneamente, ideale per contenuti che cambiano di rado. Molti framework moderni permettono di mescolarli per route, scegliendo SSG per le pagine marketing, SSR per le pagine personalizzate e CSR per le dashboard molto interattive.
Quando usare CSS Grid e quando Flexbox?
Usa Flexbox quando disponi gli elementi lungo un singolo asse - una barra di navigazione, una toolbar, la centratura di una card - dove domina l'allineamento in una direzione. Usa CSS Grid quando ti serve controllo bidimensionale, piazzando gli elementi in righe e colonne contemporaneamente, come per un layout di pagina o una griglia di card che deve allinearsi su entrambi gli assi. Sono complementari più che concorrenti: è comune usare Grid per la struttura generale della pagina e Flexbox all'interno dei singoli componenti. Come regola pratica, passa a Grid quando ti ritrovi a combattere con Flexbox per controllare sia righe sia colonne.
Come miglioro i miei Core Web Vitals?
Mira a ciascuna metrica in modo specifico. Per il Largest Contentful Paint (LCP, buono è 2,5s o meno) fai il preload della hero image, rimuovi il CSS e il JavaScript render-blocking e usa un server o una CDN veloce. Per l'Interaction to Next Paint (INP, buono è 200ms o meno) spezza i task JavaScript lunghi, rinvia il lavoro non critico ed evita calcoli pesanti sul main thread durante le interazioni. Per il Cumulative Layout Shift (CLS, buono è 0,1 o meno) imposta dimensioni esplicite o aspect-ratio su immagini ed embed ed evita di inserire contenuto sopra quello esistente. Misura con dati sul campo (Real User Monitoring) e non solo con strumenti di laboratorio, perché dispositivi e reti reali differiscono.
Mi serve un framework JavaScript o posso usare JavaScript puro?
Per siti piccoli e perlopiù statici, HTML semantico e un po' di JavaScript vanilla sono spesso la scelta più semplice, veloce e resiliente, specie con il progressive enhancement. Un framework come React, Angular, Vue o Svelte ripaga il suo peso quando hai stato condiviso consistente, interattività complessa, molti componenti riutilizzabili o un team grande che necessita di una struttura coerente. Il compromesso è bundle più grande, tooling di build e una curva di apprendimento. Scegli in base alla complessità dell'applicazione e alle esigenze del team, non all'hype, e ricorda che puoi adottare un framework in modo incrementale.
Cos'è l'hydration e perché a volte è un problema di performance?
L'hydration è il passaggio in cui il JavaScript lato client collega gli event listener e lo stato reattivo all'HTML renderizzato dal server, rendendo interattiva la pagina statica. Il problema è che per pagine grandi il framework deve scaricare, analizzare ed eseguire JavaScript per l'intero albero prima che qualunque cosa sia interattiva, ritardando la reattività anche se il contenuto è apparso in fretta. Questa "uncanny valley" - visibile ma non ancora cliccabile - ha spinto tecniche come hydration parziale, islands architecture e resumability che idratano solo le parti interattive o evitano la ri-esecuzione. Se il costo dell'hydration danneggia l'INP, guarda a spedire meno JavaScript client per route.
Come rendo accessibile un sito web?
Parti dall'HTML semantico - veri button, heading, liste, label e landmark - perché gli elementi nativi portano gratis il supporto da tastiera e screen reader. Assicurati che ogni elemento interattivo sia operabile da tastiera con un indicatore di focus visibile, fornisci alternative testuali per le immagini, mantieni un rapporto di contrasto di almeno 4,5:1 per il testo del corpo e associa gli input dei form alle loro label. Usa ARIA solo per colmare lacune che l'HTML nativo non copre, seguendo la sua prima regola: preferire un elemento nativo a un ruolo ARIA. Testa con la sola tastiera e con uno screen reader e valida secondo WCAG 2.1 AA, la baseline di conformità comune.
Cosa causa il cumulative layout shift e come lo prevengo?
Lo spostamento di layout avviene quando il contenuto già a schermo si muove in modo inatteso, tipicamente perché un'immagine o un annuncio si è caricato senza spazio riservato, un web font è cambiato provocando un reflow del testo, o JavaScript ha iniettato contenuto sopra quello esistente. Previenilo impostando sempre width e height (o aspect-ratio) su immagini e video così che il browser riservi il box prima che l'asset arrivi, riservando spazio per annunci ed embed e usando font-display: optional o descrittori size-adjust per minimizzare il reflow dei font. Evita di inserire banner o avvisi sopra il contenuto che l'utente sta già leggendo. Il Cumulative Layout Shift obiettivo è 0,1 o meno.
Dovrei usare TypeScript in un progetto front-end?
Per qualsiasi cosa oltre uno script banale, adottare TypeScript conviene in genere perché intercetta un'ampia classe di errori a tempo di compilazione, documenta l'intento tramite i tipi e alimenta funzioni dell'editor come autocompletamento e refactoring sicuro. Il costo è uno step di build, un po' di overhead di annotazione e una curva di apprendimento su generici e tipi avanzati. Puoi adottarlo in modo incrementale - TypeScript è un superset di JavaScript, quindi i file .js esistenti continuano a funzionare - e regolare la severità nel tempo. Per team e codebase di lunga durata i benefici di manutenibilità di solito superano il costo iniziale.
Come riduco la dimensione del mio bundle JavaScript?
Inizia misurando con un bundle analyzer per vedere cosa è davvero grande. Applica il code splitting così che ogni route o feature pesante carichi il proprio chunk su richiesta tramite import() dinamico, fai affidamento sul tree shaking importando solo ciò che usi da moduli ES privi di side effect ed evita di tirare dentro librerie pesanti per piccole esigenze. Sostituisci le dipendenze grandi con alternative più leggere o con API native del browser dove possibile, e fai il lazy load dei componenti below-the-fold e non critici. Infine, imposta e applica un performance budget in CI così che le regressioni siano intercettate prima del rilascio.
Qual è la differenza tra debouncing e throttling?
Entrambi limitano la frequenza con cui un handler scatta in risposta a eventi rapidi come scroll, resize o digitazione, ma si comportano diversamente. Il debouncing attende che gli eventi si fermino per un periodo di quiete definito e poi scatta una volta - ideale per la ricerca-mentre-digiti, dove vuoi interrogare solo dopo che l'utente fa una pausa. Il throttling garantisce che l'handler scatti al massimo una volta per intervallo fisso mentre gli eventi proseguono - ideale per handler di scroll o resize che devono aggiornare periodicamente ma non a ogni frame. Scegliere quello sbagliato porta o ad aggiornamenti mancati o a lavoro eccessivo, perciò abbina la tecnica a se vuoi la chiamata finale o una cadenza costante.
Come dovrei gestire lo stato in un'app front-end?
Mantieni lo stato il più locale possibile: lo stato a livello di componente copre la maggior parte dei casi, e sollevarlo o condividerlo via context gestisce il resto. Ricorri a una libreria dedicata - Redux, Zustand, Pinia o store basati su signal - solo quando hai stato realmente globale, aggiornato di frequente o trasversale che il prop-drilling rende doloroso. Distingui lo stato del server (dati prelevati da API, con caching e invalidazione) dallo stato di interfaccia client, perché librerie come TanStack Query gestiscono il primo molto meglio di uno store generico. Centralizzare lo stato troppo presto aggiunge boilerplate e accoppiamento, perciò lascia che sia il bisogno a guidare lo strumento.
Il Virtual DOM è più veloce della manipolazione diretta del DOM?
Non intrinsecamente - il Virtual DOM esiste soprattutto per fornire un modello di programmazione dichiarativo semplice, non velocità pura. Confrontare un albero virtuale e applicare aggiornamenti minimi aggiunge overhead che una manipolazione diretta del DOM ottimizzata a mano può battere in casi ristretti. Il suo valore è che descrivi l'interfaccia come funzione dello stato e il framework calcola gli aggiornamenti, cosa che scala molto meglio per chi scrive codice rispetto alla mutazione manuale. I nuovi framework reattivi a grana fine (Solid, Svelte, i signal in Angular e Vue) ottengono la stessa ergonomia dichiarativa aggiornando solo i nodi cambiati, spesso superando il diffing del Virtual DOM.
Cos'è una Progressive Web App e me ne serve una?
Una Progressive Web App è un sito web che aggiunge un service worker, un web app manifest e HTTPS per diventare installabile, capace di funzionare offline e simile a un'app, raggiungendo gli utenti senza un app store. Te ne giovi se gli utenti vogliono accesso offline, installazione sulla schermata home, notifiche push o visite ripetute veloci - per esempio uno strumento di produttività, un lettore o un'app da campo su reti instabili. Se il tuo sito è puramente informativo e sempre online, una PWA può aggiungere complessità per poco guadagno. Trattala come progressive enhancement: il sito deve funzionare prima come sito normale, con le funzionalità PWA stratificate sopra.
Come prevengo il cross-site scripting (XSS) in un'app front-end?
Tratta ogni dato controllato dall'utente come non fidato e affidati alla codifica contestuale dell'output, che i framework moderni fanno automaticamente quando interpoli valori nei template. Evita di impostare innerHTML (o dangerouslySetInnerHTML di React) con contenuto non sanificato; se devi renderizzare HTML, sanificalo con una libreria collaudata come DOMPurify. Distribuisci una Content Security Policy rigorosa e basata su nonce come difesa in profondità così che anche uno script iniettato non possa eseguirsi, e usa Subresource Integrity per gli script di terze parti. Non costruire mai markup concatenando stringhe di input utente, e valida l'input anche sul server, perché i controlli lato client da soli non sono una barriera di sicurezza.
Qual è la differenza tra responsive design e adaptive design?
Il responsive design usa un singolo layout fluido che si regola continuamente a qualsiasi viewport tramite griglie flessibili, media flessibili e media o container query, scorrendo in modo morbido su tutte le dimensioni. L'adaptive design invece rileva il dispositivo o la viewport e serve uno tra diversi layout fissi progettati per breakpoint specifici, scattando tra versioni discrete. Il responsive è l'approccio moderno dominante perché gestisce la gamma imprevedibile di dispositivi con una sola codebase e degrada con grazia verso nuove dimensioni di schermo. L'adaptive può dare un controllo più preciso al pixel per dispositivo ma è più impegnativo da costruire e mantenere.
Quando usare un framework CSS come Tailwind invece di scrivere CSS personalizzato?
Un framework utility-first come Tailwind velocizza lo sviluppo, impone un design system coerente tramite token configurati ed evita i problemi di naming e di CSS morto dei grandi fogli di stile scritti a mano, al costo di un markup verboso e di uno step di build. Il CSS puro - magari con funzionalità moderne come proprietà personalizzate, nesting, container query e cascade layer - dà controllo totale, nessun lock-in di framework e markup più pulito, ma richiede disciplina per restare manutenibile su larga scala. La decisione spesso dipende dalle preferenze del team, dalla dimensione del progetto e dal fatto che tu valorizzi l'iterazione rapida con forti convenzioni o il massimo controllo. Entrambi possono produrre risultati eccellenti e performanti se usati bene.