React per chi viene da HTML e CSS: modello mentale, JSX e componenti

Molti sviluppatori che conoscono bene HTML e CSS si avvicinano a React con una sensazione ricorrente:

“Non è difficile… ma non mi entra in testa.”

Il problema non è React.
E non è nemmeno il fatto che “serva JavaScript avanzato”.

👉 Il vero problema è che lo stai affrontando con il modello mentale sbagliato.

Se vieni da HTML e CSS, è naturale pensare che React sia:

• HTML scritto in JavaScript
• un modo più moderno di costruire interfacce
• una semplice evoluzione del markup

Ed è proprio qui che inizi a rallentare.

React non è HTML evoluto.
È un modo completamente diverso di pensare l’interfaccia.

Passare dal mondo strutturato di HTML e CSS a un framework JavaScript può sembrare un salto nel vuoto. Questa guida è pensata per colmare quel divario, introducendo le basi di React in modo semplice e diretto, mostrando come le tue competenze attuali siano il trampolino di lancio perfetto per creare interfacce utente moderne e interattive.

In questa guida trovi:

• Perché React se già conosco HTML e CSS?
• Il vero cambio di paradigma: UI come funzione, non come struttura
• JSX: sembra HTML, ma non lo è
• Pensare in componenti
• Come progettare componenti senza pensare in HTML
• Errori tipici di chi arriva da HTML e CSS
• Come partire nel modo giusto (senza overengineering)
• Cosa imparare subito (e cosa puoi ignorare all’inizio)
• React non sostituisce HTML e CSS (li usa diversamente)
• Conclusione: React non è difficile, è diverso

Perché React se già conosco HTML e CSS?

HTML e CSS sono fantastici per creare pagine web statiche. Definisci la struttura con i tag, applichi lo stile e il gioco è fatto. Tuttavia, quando un’applicazione web diventa complessa, con dati che cambiano e interazioni utente dinamiche, gestire tutto manipolando il DOM manualmente con JavaScript puro diventa macchinoso e soggetto a errori.

React introduce un approccio dichiarativo: descrivi come dovrebbe apparire la tua UI in un dato stato, e React si occuperà di aggiornare il DOM in modo efficiente quando i dati cambiano. Questo rende il codice più prevedibile e facile da manutenere.

Perché HTML e CSS non ti preparano a React come credi

HTML e CSS ti insegnano una cosa fondamentale:
descrivere una struttura statica.

Scrivi markup, applichi stili, il browser renderizza.
Il flusso mentale è lineare.

React nasce per risolvere un problema diverso:
interfacce che cambiano nel tempo.

In React non stai dicendo:

“Questa è la pagina”

Stai dicendo:

“Se lo stato è questo, l’interfaccia deve apparire così”

È lo stesso cambio di prospettiva spiegato nella documentazione ufficiale quando si parla di pensare in React: prima lo stato, poi il rendering.

Se continui a ragionare in termini di:

• “aggiungo un elemento”
• “modifico il DOM”
• “mostro o nascondo un div”

stai lavorando contro React, non con React.

Il vero cambio di paradigma: UI come funzione, non come struttura

In React l’interfaccia non è più un insieme di elementi.
È il risultato di una funzione.

Concettualmente:

UI = f(stato)

UI = f(stato)

Questo significa che:

• non “aggiorni” l’interfaccia manualmente
• non manipoli il DOM
• non pensi in termini di azioni visive

Tu cambi lo stato, e React ridisegna l’interfaccia.

È il cuore del modello dichiarativo di React, in cui non controlli come avviene il cambiamento, ma cosa deve essere mostrato in base allo stato corrente, come spiegato anche nella panoramica MDN su React.

Questo è destabilizzante per chi arriva da HTML e CSS perché:

• perdi il controllo diretto
• non “vedi” più il processo passo dopo passo
• devi fidarti del framework

Ma è esattamente questo che rende React scalabile.

Dal DOM al Virtual DOM: cosa fa React al posto tuo

Con HTML e JavaScript classico, ogni modifica (come cambiare il testo di un paragrafo) riscrive direttamente una porzione del Document Object Model (DOM) del browser. Questa operazione può essere lenta se ripetuta frequentemente.

React utilizza un “Virtual DOM”, una copia leggera del DOM reale tenuta in memoria. Quando lo stato della tua applicazione cambia, React crea una nuova versione del Virtual DOM, la confronta con la precedente (un processo chiamato “diffing”), e aggiorna solo le parti del DOM reale che sono effettivamente cambiate. Così eviti di aggiornare a mano il DOM e React riduce al minimo le modifiche reali alla pagina.

JSX: sembra HTML, ma non lo è

Una delle prime cose che noterai in React è JSX (JavaScript XML). Sembra HTML, ma è in realtà una estensione della sintassi di JavaScript. Ti permette di scrivere la struttura dei tuoi componenti in un modo familiare e intuitivo.

HTML tradizionale

<div class="container">
  <h1>Ciao Mondo!</h1>
  <p>Questo è il mio primo paragrafo.</p>
</div>

Equivalente in JSX

Nota due piccole differenze: class diventa className e tutto è scritto all’interno di un file JavaScript.

const mioElemento = (
  <div className="container">
    <h1>Ciao Mondo!</h1>
    <p>Questo è il mio primo componente React.</p>
  </div>
);

Pensare in componenti

Il concetto fondamentale di React è la scomposizione dell’interfaccia utente in piccoli pezzi riutilizzabili chiamati “componenti”. Una pagina non è più un unico, monolitico file HTML, ma un albero di componenti.

• Un componente Header può contenere un Logo e un MenuNavigazione.
• Un componente CardProdotto può essere riutilizzato decine di volte in una griglia.
• Un Bottone può essere personalizzato e usato in tutta l’applicazione.

Un componente in React è semplicemente una funzione JavaScript che ritorna del JSX.

// Questo è un componente funzionale
function Benvenuto(props) {
  return <h1>Ciao, {props.nome}</h1>;
}

// E lo puoi usare come un tag HTML
const app = <Benvenuto nome="Sara" />;

Props e state: gestire i dati

I componenti comunicano e gestiscono i dati attraverso due meccanismi principali:

• Props (Properties): Sono dati passati da un componente genitore a un componente figlio. Sono di sola lettura, come gli attributi HTML. Nell’esempio sopra, nome="Sara" è una prop.
• State: È una memoria interna di un componente. Quando lo state di un componente cambia, React riesegue il rendering del componente per riflettere la modifica. È ciò che rende le UI interattive.

I componenti non sono div più intelligenti

Uno degli errori più comuni è pensare ai componenti React come a:

“blocchi HTML riutilizzabili”

Sbagliato.

Un componente React è:

• una funzione
• con uno stato
• che produce interfaccia

Non serve a organizzare il layout.
Serve a organizzare il comportamento.

Se crei componenti solo per “ordine visivo”:

• frammenti il codice
• aumenti la complessità
• rallenti l’apprendimento

In React, la struttura segue la logica, non il contrario.

Come progettare componenti senza pensare in HTML

Se vieni da HTML e CSS, c’è un errore che quasi tutti fanno quando iniziano con React:
progettare i componenti partendo dal markup.

È istintivo.
Apri il layout, guardi la pagina, e inizi a spezzarla in header, card, sidebar, footer.

Funziona visivamente.
Ma concettualmente è il modo più lento di usare React.

React non chiede di dividere una pagina in pezzi HTML.
Chiede di modellare comportamenti.

E finché non cambi questo approccio, i componenti ti sembreranno:

• troppi
• confusi
• difficili da riutilizzare
• legati al layout

Il problema: componenti progettati come “pezzi di pagina”

Quando progetti componenti come se fossero sezioni HTML:

• crei componenti enormi
• li riempi di div
• li rendi dipendenti dal contesto visivo
• li riusi a fatica (o per niente)

Questo succede perché stai rispondendo alla domanda sbagliata.

❌ Domanda sbagliata

“Quali parti visive vedo nella pagina?”

✅ Domanda giusta

“Quali responsabilità ha questa parte dell’interfaccia?”

React lavora sulle responsabilità, non sui rettangoli.

Il vero criterio: responsabilità prima della struttura

Un buon componente React non nasce perché “serve un box”.
Nasce perché esiste una responsabilità chiara.

Esempi di responsabilità:

• gestire un input
• mostrare uno stato
• reagire a un’azione
• rappresentare un’entità del dominio

Il layout viene dopo.

Questo è coerente con il principio base spiegato nella documentazione ufficiale quando si parla di pensare in React: prima si scompone l’interfaccia in componenti logici, poi si pensa a come renderizzarli.

Se inizi dal markup, invertirai sempre l’ordine.

Perché pensare in HTML porta a componenti fragili

Quando pensi in HTML:

• le props diventano rattoppi
• lo stato finisce ovunque
• ogni modifica rompe qualcos’altro
• il refactor fa paura

Il segnale più chiaro che stai sbagliando è questo:

“Non posso riusare questo componente senza copiarlo.”

Quello non è un componente.
È una pagina spezzata.

Un modello mentale più utile: componenti come funzioni di stato

In React un componente è, prima di tutto:

una funzione che riceve dati e produce interfaccia

Non una sezione.
Non un contenitore.
Non un template.

Concettualmente:

Componente = f(stato, props)

Questo significa che un buon componente:

• ha input chiari
• ha una sola responsabilità
• produce sempre lo stesso output a parità di stato

Errori tipici di chi arriva da HTML e CSS

Se React ti sembra più difficile del necessario, probabilmente stai facendo uno (o più) di questi errori.

❌ Pensare in termini di DOM

In React non:

• selezioni elementi
• aggiungi classi manualmente
• modifichi attributi

Se stai cercando document.querySelector, sei nel posto sbagliato.

❌ Scrivere “HTML dentro JavaScript”

JSX assomiglia a HTML, ma non è HTML.
È solo una sintassi che rende leggibile la descrizione dell’interfaccia.

Se lo tratti come markup puro, perdi il senso di React.

❌ Usare lo stato come una variabile normale

Lo stato non è una variabile.
È una fonte di verità che governa il rendering.

Provare a modificarlo “come prima” rompe completamente il modello.

❌ Separare markup e logica come nel web tradizionale

In React:

• markup e logica convivono
• non per comodità
• ma perché la UI dipende dalla logica

Tentare di separarli rigidamente crea solo confusione.

❌ Componenti troppo grandi

Se un componente:

• gestisce stato
• layout
• logica
• side effects

probabilmente fa troppo.

Un componente che cresce senza controllo è un warning architetturale.

❌ Componenti legati al layout

Se un componente:

• funziona solo in una pagina
• rompe se cambi grid o flex
• dipende da classi esterne

stai progettando HTML con JavaScript, non React.

❌ Spezzare solo per riuso visivo

Creare componenti solo perché “si ripete il markup” è una falsa ottimizzazione.

Il riuso utile in React è:

• riuso di comportamento
• riuso di logica
• riuso di stato

Il resto è estetica.

Come partire nel modo giusto (senza overengineering)

Se stai progettando una nuova UI in React:

1. Scrivi prima il flusso logico (non il JSX)
2. Identifica quali dati cambiano nel tempo
3. Chiediti chi è responsabile di quello stato
4. Solo alla fine pensa a come appare

Questo ti evita:

• componenti inutili
• gerarchie profonde
• dipendenze fragili

E ti permette di cambiare layout senza riscrivere logica.

Creare il tuo primo progetto React

Oggi, avviare un progetto React è semplicissimo grazie a strumenti come Vite. Non è più necessario configurare Webpack o Babel manualmente.

Apri il tuo terminale e digita questo comando:

npm create vite@latest il-mio-primo-progetto-react -- --template react

Segui le istruzioni a schermo, entra nella nuova cartella (cd il-mio-primo-progetto-react), esegui npm install e poi npm run dev. Il tuo primo progetto React sarà attivo e funzionante!

Cosa imparare subito (e cosa puoi ignorare all’inizio)

Se vieni da HTML e CSS, non serve studiare tutto.

Impara subito:

• componenti funzionali
• props
• stato (useState)
• rendering condizionale
• concetto di immutabilità

Puoi tranquillamente rimandare:

• ottimizzazioni premature
• hook avanzati
• state management globale
• pattern complessi
• performance tuning

React diventa difficile quando cerchi di anticiparlo.

React non sostituisce HTML e CSS (li usa diversamente)

HTML e CSS non spariscono.
Semplicemente cambiano ruolo.

• HTML diventa linguaggio di descrizione
• CSS rimane responsabile di layout e stile
• React governa quando e perché qualcosa appare

React decide:

• quando qualcosa viene renderizzato
• perché cambia
• in base a cosa

Il layout rimane responsabilità di:

• CSS
• Grid
• Flexbox

Quando separi davvero queste responsabilità, tutto diventa più semplice.

Se sei bravo in HTML e CSS:
👉 non stai buttando competenze
👉 stai cambiando prospettiva

Conclusione: React non è difficile, è diverso

React non è più complesso di HTML e CSS.
È solo più onesto.

Ti obbliga a:

• pensare allo stato
• accettare il cambiamento
• rinunciare al controllo diretto

Chi arriva da HTML e CSS e capisce questo passaggio mentale accelera molto più velocemente di chi studia API a memoria.

Il vero salto non è imparare React.
È disimparare il modo sbagliato di usarlo.

Passare a React da HTML/CSS non significa buttare via ciò che sai. Al contrario, la tua comprensione della struttura del DOM e dello styling è fondamentale. JSX ti sembrerà subito familiare, e il concetto di componenti ti aiuterà a organizzare il tuo codice in modo più pulito e scalabile.

Se progetti componenti partendo dal markup:

• React ti sembrerà verboso
• il codice crescerà male
• la manutenzione diventerà costosa

Se progetti componenti partendo dalla logica:

• i componenti diventano piccoli
• il codice è prevedibile
• il refactor fa meno paura

Il passaggio chiave è questo:

non chiederti cosa vedi nella pagina, ma cosa deve fare quella parte dell’interfaccia

Quando fai questo salto, React inizia davvero a lavorare con te, non contro di te.

Vuoi continuare da qui?

Ora hai le basi per capire la filosofia di React e iniziare a costruire i primi componenti. Il passo successivo è esplorare gli hook (in particolare useState e useEffect), la gestione dello stato e l’organizzazione del progetto:

• Hook useState e useEffect spiegati semplice
• React: come gestire lo stato senza creare caos
• Componenti React riutilizzabili: best practice
• Architettura React: come strutturare un progetto