React: cos’è, come funziona, a cosa serve e quando usare React JS

React è una libreria JavaScript per costruire interfacce utente attraverso componenti. Non è un nuovo linguaggio, non sostituisce JavaScript e non obbliga a creare una Single Page Application. Il suo compito principale è aiutarti a descrivere l’interfaccia in funzione dei dati e dello stato dell’applicazione, lasciando a React il lavoro di aggiornare il DOM quando qualcosa cambia.

Questa distinzione è importante perché attorno a React circolano ancora spiegazioni troppo semplici: “è un framework per le SPA”, “è veloce grazie al Virtual DOM”, “per iniziare basta Create React App”. Sono scorciatoie che rischiano di costruire un modello mentale sbagliato.

In questa guida partiamo quindi dalle fondamenta: vediamo cos’è React, come funzionano componenti, JSX, props, stato e rendering, che rapporto ha con il DOM, quando conviene usarlo, quali limiti introduce e come iniziare con una configurazione attuale.

Cos’è React e cosa significa React JS

React è una libreria open source dell’ecosistema JavaScript progettata per creare interfacce utente componibili.

L’idea centrale è semplice: invece di trattare una pagina come un insieme di elementi da cercare e modificare manualmente uno alla volta, costruisci l’interfaccia come un albero di componenti. Ogni componente descrive ciò che deve apparire in base ai dati che riceve e allo stato che possiede.

La documentazione ufficiale React introduce infatti i componenti come unità riutilizzabili e combinabili tra loro per costruire interfacce progressivamente più complesse.

React, React.js e ReactJS indicano la stessa tecnologia?

Sì. React, React.js, React JS e ReactJS vengono normalmente usati per indicare la stessa libreria.

Il nome ufficiale del progetto è React. “React.js” e “ReactJS” sono varianti diffuse soprattutto nelle ricerche, nei corsi e negli articoli che vogliono rendere esplicito il legame con JavaScript.

Non esiste quindi una distinzione tecnica da imparare tra React e React JS: cambia il modo in cui viene scritto il nome, non la tecnologia a cui ci si riferisce.

React è una libreria JavaScript, non un linguaggio

React viene utilizzato attraverso JavaScript. Se non conosci bene il linguaggio sottostante, molti concetti della libreria diventano più difficili da interpretare.

Prima di React conviene quindi avere familiarità almeno con:

• funzioni;
• oggetti e array;
• moduli import ed export;
• destructuring;
• metodi come map() e filter();
• eventi;
• Promise e async/await;
• scope e closure;
• sintassi moderna di JavaScript.

Se questi concetti sono ancora poco chiari, la guida su cos’è JavaScript e come funziona è un punto di partenza più utile di un tutorial React copiato riga per riga.

React astrae una parte del lavoro sull’interfaccia, ma non sostituisce le fondamenta del browser e del linguaggio.

Chi mantiene React oggi

React nasce all’interno di Facebook ed è stato successivamente reso open source. Oggi React, React Native e alcuni progetti collegati come JSX fanno capo alla React Foundation, fondazione indipendente ospitata dalla Linux Foundation.

Meta continua a contribuire all’ecosistema ed è uno dei membri fondatori della React Foundation, ma React non è più un progetto di proprietà esclusiva di Meta.

La distinzione non cambia il modo in cui scrivi un componente, ma è importante se vuoi descrivere correttamente la governance attuale del progetto. Gli aggiornamenti ufficiali vengono pubblicati nel blog di React.

Come funziona React: componenti, JSX, props, stato e rendering

Per capire React non serve partire memorizzando decine di Hook. Serve prima comprendere il flusso fondamentale:

dati + stato → rendering dei componenti → interfaccia risultante → aggiornamento del DOM

Quando cambiano dati o stato, React richiama i componenti interessati, determina quale interfaccia dovrebbe risultare e applica al DOM gli aggiornamenti necessari.

È un modo diverso dal programmare un’interfaccia impartendo direttamente una sequenza di comandi a ogni singolo elemento della pagina.

Componenti: costruire l’interfaccia come parti riutilizzabili

Un componente React è normalmente una funzione JavaScript che restituisce markup.

Per esempio:

function Saluto() {
  return <h2>Ciao!</h2>;
}

Questo componente può essere utilizzato dentro un altro componente:

function App() {
  return (
    <main>
      <h1>La mia applicazione</h1>
      <Saluto />
    </main>
  );
}

La possibilità di comporre componenti piccoli in strutture più grandi è una delle caratteristiche centrali di React.

Un pulsante, una scheda prodotto, un menu, un campo di ricerca o un’intera pagina possono diventare componenti. La granularità giusta dipende però dal progetto: dividere ogni singolo elemento in un componente non rende automaticamente il codice migliore.

Un buon componente tende ad avere una responsabilità riconoscibile, confini comprensibili e un’interfaccia chiara verso il resto dell’applicazione.

JSX: perché sembra HTML ma non è semplicemente HTML

Il markup usato più spesso nei componenti React è JSX.

Per esempio:

function Profilo({ nome }) {
  return <p>Ciao, {nome}</p>;
}

JSX assomiglia a HTML, ma è una estensione di sintassi che permette di descrivere markup all’interno di JavaScript. Le parentesi graffe consentono di inserire espressioni JavaScript:

const prezzo = 19;

function Prezzo() {
  return <strong>{prezzo} €</strong>;
}

Ci sono inoltre differenze sintattiche da conoscere. Una delle prime che incontri è className al posto dell’attributo HTML class:

<div className="card">Contenuto</div>

JSX non elimina HTML dal progetto. Per scrivere interfacce corrette devi comunque conoscere struttura, semantica, form, pulsanti, link e gli altri elementi descritti nella guida a HTML.

Il vantaggio di JSX è piuttosto un altro: porta vicini la struttura dell’interfaccia e il codice che determina ciò che deve essere mostrato.

Props: i dati che un componente riceve

Le props permettono a un componente di ricevere informazioni dal componente che lo utilizza.

Considera:

function Utente({ nome, ruolo }) {
  return (
    <article>
      <h3>{nome}</h3>
      <p>{ruolo}</p>
    </article>
  );
}

Puoi poi utilizzare il componente così:

<Utente nome="Marta" ruolo="Frontend Developer" />

In questo caso nome e ruolo sono props.

Le props rendono il componente configurabile: non devi scrivere un componente diverso per ogni utente, prodotto o voce dell’interfaccia.

È utile pensarle come input del componente. Il componente riceve dati e li utilizza per determinare il proprio output.

State: la memoria del componente

Le props arrivano dall’esterno. Lo state rappresenta invece informazioni che un componente deve ricordare tra un rendering e il successivo.

Un contatore è il caso più semplice:

import { useState } from 'react';

function Contatore() {
  const [conteggio, setConteggio] = useState(0);

  return (
    <button onClick={() => setConteggio(conteggio + 1)}>
      Click: {conteggio}
    </button>
  );
}

useState(0) restituisce due elementi:

1. il valore corrente dello stato;
2. una funzione che permette di aggiornarlo.

Quando chiami setConteggio, React conserva il nuovo valore e pianifica un nuovo rendering del componente.

La documentazione ufficiale sullo state descrive proprio lo stato come la memoria specifica del componente: dati che devono persistere tra un rendering e l’altro e che, quando cambiano, possono modificare ciò che appare sullo schermo.

Hooks: cosa sono e perché compaiono ovunque in React moderno

useState è un Hook.

Gli Hook sono funzioni React che permettono ai componenti di utilizzare funzionalità come stato, context, riferimenti o sincronizzazione con sistemi esterni.

Tra i più conosciuti trovi:

• useState;
• useEffect;
• useContext;
• useReducer;
• useRef.

Questo elenco non va però interpretato come una checklist da utilizzare in ogni componente.

Un errore frequente nei primi progetti React è aggiungere useEffect ogni volta che qualcosa deve “succedere”. La documentazione ufficiale insiste invece sul fatto che gli Effect servono soprattutto per sincronizzarsi con sistemi esterni. Se un valore può essere calcolato direttamente dalle props e dallo stato durante il rendering, spesso non hai bisogno di un Effect.

Capire perché usare un Hook è molto più importante che conoscerne a memoria la firma.

React DOM, rendering e DOM reale

Il browser lavora con il DOM reale. React non elimina questo livello.

Con JavaScript imperativo potresti, per esempio, scrivere:

const bottone = document.querySelector('#contatore');
bottone.textContent = 'Click: 1';

Il codice indica direttamente quale elemento trovare e quale modifica apportare.

Con React il ragionamento cambia. Descrivi invece quale dovrebbe essere l’interfaccia per un determinato stato:

<button>Click: {conteggio}</button>

React gestisce il passaggio tra l’output precedente e quello nuovo.

La documentazione su render e commit separa il processo in due passaggi concettualmente importanti:

• render: React chiama i componenti per determinare quale output devono produrre;
• commit: React applica al DOM le modifiche necessarie.

Questo modello è molto più utile del pensare a React come a una tecnologia che “sostituisce il DOM”.

Virtual DOM: cosa significa e cosa non garantisce sulle performance

L’espressione Virtual DOM viene spesso utilizzata per spiegare che React lavora con una rappresentazione dell’interfaccia dalla quale può determinare quali modifiche applicare al DOM.

Come semplificazione iniziale può essere utile. Diventa però fuorviante quando viene trasformata nella formula:

Virtual DOM = React è sempre più veloce

Non funziona così.

React può evitare modifiche DOM non necessarie, ma la performance reale di un’applicazione dipende da molte altre variabili:

• quantità di JavaScript inviata al browser;
• frequenza e posizione degli aggiornamenti di stato;
• costo dei rendering;
• struttura dell’albero dei componenti;
• data fetching;
• rete;
• immagini e altre risorse;
• lavoro sul main thread;
• strategia di rendering;
• codice scritto nell’applicazione.

La distinzione tra render e commit è quindi più precisa del semplice slogan “React è veloce grazie al Virtual DOM”.

Il Virtual DOM è un meccanismo del modello di rendering, non una garanzia automatica di performance.

A cosa serve React nella pratica

React serve soprattutto quando devi costruire interfacce con parti che cambiano in risposta a stato, dati ed eventi.

Può essere utilizzato per dashboard, aree riservate, ecommerce, editor, applicazioni collaborative, pannelli amministrativi, strumenti SaaS, interfacce di ricerca e molti altri prodotti digitali.

Il punto non è però il tipo di sito scritto sull’etichetta del progetto. Conta quanto è complessa l’interazione che devi gestire.

Interfacce dinamiche e applicazioni web

Immagina una dashboard con:

• filtri;
• tabelle;
• dati caricati da servizi esterni;
• pannelli che si aprono e chiudono;
• form;
• notifiche;
• stato di autenticazione;
• aggiornamenti dell’interfaccia.

Senza un modello chiaro, le dipendenze fra tutti questi stati possono diventare rapidamente difficili da seguire.

React offre un approccio in cui l’interfaccia viene descritta in funzione dello stato corrente. Quando quello stato cambia, l’interfaccia viene ricalcolata.

È particolarmente utile quando esistono molte combinazioni possibili dello stato visuale.

React può essere aggiunto anche a un progetto esistente

React non richiede necessariamente di riscrivere tutto il sito.

La documentazione di installazione prevede esplicitamente l’adozione graduale: puoi provarlo senza installazione locale, aggiungere interattività a un progetto esistente oppure costruire un’applicazione React completa.

Questa caratteristica è importante perché il passaggio a React non deve per forza essere “tutto o niente”.

In un progetto esistente potresti, per esempio, introdurre React soltanto in una parte particolarmente interattiva e lasciare invariato il resto dell’applicazione.

Naturalmente questa strategia ha senso solo se il vantaggio supera il costo di introdurre una nuova toolchain e un nuovo modello di sviluppo.

React non significa necessariamente Single Page Application

Una Single Page Application, o SPA, è un’applicazione in cui navigazione e numerosi aggiornamenti avvengono lato client senza richiedere il caricamento tradizionale di un nuovo documento HTML a ogni passaggio.

React può essere usato per costruire SPA, ma React non è una SPA.

La documentazione corrente sulla creazione di applicazioni React distingue infatti diverse strategie. Nell’ecosistema React possono esistere client-side rendering, SPA, generazione statica e rendering lato server.

Scegliere React non decide automaticamente:

• come gestirai il routing;
• dove verrà renderizzato il contenuto;
• come recupererai i dati;
• come gestirai cache e mutazioni;
• come distribuirai l’applicazione.

React risolve principalmente il livello dell’interfaccia. Un’applicazione completa richiede altre decisioni.

React e API: come arrivano i dati all’interfaccia

Molte applicazioni React visualizzano informazioni provenienti da servizi esterni o da un backend.

Un percorso tipico può essere:

database → backend → API → browser → stato React → interfaccia

Se il concetto non ti è familiare, nella guida alle API trovi la distinzione tra endpoint, richiesta, risposta e contratto dei dati.

React non definisce da solo il backend. Può utilizzare API costruite con Node.js, PHP, Python, Java o qualsiasi altra tecnologia capace di esporre dati al client.

Se scegli PHP sul server, Laravel è una delle opzioni da valutare: può funzionare come backend API separato oppure essere integrato più strettamente con React nello stesso stack applicativo.

React Native è collegato a React, ma non è React per il Web

React Native utilizza i principi di React per costruire applicazioni native.

Condivide concetti come componenti, props, stato e Hook, ma il target non è il DOM del browser. I componenti vengono collegati alle primitive native della piattaforma.

Per questo “conosco React” e “so sviluppare bene applicazioni React Native” non sono affermazioni equivalenti. Esiste una base concettuale comune, ma cambiano piattaforma, componenti, API e problematiche operative.

Perché usare React: i vantaggi che contano davvero

React non è utile semplicemente perché è molto diffuso. Ha senso quando il suo modello riduce la complessità del problema che devi risolvere.

I vantaggi più interessanti emergono soprattutto quando l’interfaccia cresce, più parti dipendono dallo stato e il riuso dei componenti diventa realmente utile.

Componenti e composizione dell’interfaccia

Il vantaggio più evidente è la possibilità di suddividere l’interfaccia in componenti con responsabilità riconoscibili.

Questo può aiutare a:

• riutilizzare parti della UI;
• isolare logica e stato;
• ragionare per confini;
• testare unità più piccole;
• costruire design system;
• condividere componenti tra pagine.

Il riuso non è però automatico. Un componente progettato soltanto per essere “riutilizzabile ovunque” può diventare più complesso di ciò che sostituisce.

La composizione funziona meglio quando nasce da esigenze reali del progetto.

Modello dichiarativo: descrivere il risultato invece della sequenza di modifiche

Nel codice imperativo dici spesso al browser come cambiare l’interfaccia:

1. trova questo nodo;
2. sostituisci il testo;
3. aggiungi una classe;
4. nascondi quell’elemento;
5. mostra un altro elemento.

Con React descrivi più spesso come deve apparire l’interfaccia per lo stato corrente.

Se utenteAutenticato è vero mostri una cosa; altrimenti ne mostri un’altra.

function AreaUtente({ autenticato }) {
  return autenticato ? <Dashboard /> : <Login />;
}

Questo approccio diventa particolarmente utile quando le combinazioni di stato aumentano, perché riduce la necessità di mantenere mentalmente sincronizzate molte modifiche manuali al DOM.

Flusso dei dati più esplicito

Le props favoriscono un flusso dei dati comprensibile tra componente padre e componenti figli.

Quando un valore cambia, puoi seguire più facilmente da dove proviene e quali componenti lo utilizzano.

Questo non significa che ogni applicazione React abbia automaticamente una buona architettura. Stato globale mal progettato, Context utilizzato ovunque o catene di Effect possono rendere il codice difficile da seguire quanto qualsiasi altra codebase.

React mette a disposizione un modello. La qualità dipende da come lo applichi.

Ecosistema e adozione incrementale

React beneficia di un ecosistema molto ampio.

Esistono soluzioni mature per routing, framework applicativi, gestione dei form, testing, component library, data fetching e molti altri problemi ricorrenti.

Allo stesso tempo React può essere adottato progressivamente. Questo consente a un team di introdurlo dove crea valore senza dover necessariamente riscrivere l’intera applicazione.

Il rovescio della medaglia è che un ecosistema ampio comporta anche più decisioni. React da solo non stabilisce un’unica architettura obbligatoria.

React con TypeScript

React può essere utilizzato sia con JavaScript sia con TypeScript.

Nei componenti TypeScript permette, per esempio, di descrivere la forma delle props:

type ProfiloProps = {
  nome: string;
  eta?: number;
};

function Profilo({ nome, eta }: ProfiloProps) {
  return (
    <p>
      {nome}
      {eta ? `, ${eta} anni` : ''}
    </p>
  );
}

In un progetto piccolo questa quantità di tipizzazione può sembrare superflua. Quando invece componenti, oggetti, API e collaborazione tra sviluppatori aumentano, il controllo statico diventa più utile.

La guida su TypeScript approfondisce cosa aggiunge rispetto a JavaScript e perché i tipi scompaiono prima dell’esecuzione nel browser.

React non richiede TypeScript. La combinazione diventa interessante soprattutto quando cresce il costo degli errori nei contratti tra componenti e dati.

Limiti di React e quando non conviene usarlo

Una buona scelta tecnologica non parte dalla domanda “quanto è popolare React?”, ma da un problema più concreto: la complessità che React rimuove è maggiore di quella che introduce?

In molti progetti la risposta è sì. In altri no.

React non è un framework applicativo completo

React si concentra principalmente sulla UI.

Quando costruisci un’applicazione reale devi comunque decidere come affrontare problemi come:

• routing;
• caricamento dei dati;
• mutazioni;
• caching;
• autenticazione;
• gestione degli errori;
• rendering server-side;
• generazione statica;
• build;
• deployment.

È anche per questo che la documentazione ufficiale consiglia di valutare un framework React quando si inizia una nuova applicazione completa.

React può essere utilizzato senza framework, ma in quel caso sei tu a dover scegliere e integrare più pezzi dell’architettura.

Imparare React senza conoscere JavaScript rende fragile il debugging

Puoi seguire un tutorial React anche conoscendo poco JavaScript. Il problema emerge quando qualcosa non funziona.

Se non distingui:

• errore JavaScript;
• comportamento del browser;
• problema del DOM;
• comportamento specifico di React;
• problema della toolchain;

il debugging diventa molto più lento.

React non è quindi un sostituto delle fondamenta. È uno strato costruito sopra di esse.

Un percorso più solido è:

HTML → CSS → JavaScript → DOM e browser → React

Non significa dover conoscere ogni API del Web prima di installare React. Significa avere abbastanza fondamenta da capire ciò che il framework sta astraendo.

Per una pagina semplice può essere complessità inutile

Se devi costruire una pagina prevalentemente statica con pochissima interattività, introdurre React può significare aggiungere:

• dipendenze;
• build;
• bundle JavaScript;
• tooling;
• aggiornamenti;
• maggiore complessità di sviluppo.

Un menu mobile o un semplice accordion non richiedono automaticamente un’applicazione React.

La domanda giusta non è:

“Posso farlo con React?”

Quasi sempre la risposta sarà sì.

La domanda utile è:

“React rende questa soluzione più semplice da costruire, mantenere ed evolvere?”

Se la risposta è no, una soluzione più semplice può essere migliore.

La gestione dello stato può comunque diventare complessa

React fornisce strumenti per gestire lo stato, ma non impedisce di progettarlo male.

Duplicare dati in più state, conservare valori che potrebbero essere calcolati, aggiornare componenti troppo in alto nell’albero o usare Effect per sincronizzazioni interne non necessarie può generare bug difficili da diagnosticare.

Uno dei passaggi più importanti nell’imparare React è proprio capire quali dati devono essere stato e dove quello stato deve vivere.

L’ecosistema richiede scelte

La flessibilità è contemporaneamente un vantaggio e un costo.

Due progetti React possono utilizzare strategie completamente diverse per routing, fetching, form e struttura delle cartelle.

Per un team esperto questa libertà è utile. Per chi inizia può invece creare quella che viene spesso percepita come “fatica decisionale”: il tutorial che stai seguendo utilizza una libreria, il progetto aziendale un’altra e una guida più recente suggerisce un approccio differente.

Per questo conviene imparare prima il modello di React, poi gli strumenti che lo circondano.

React vs JavaScript, Next.js, Vue e Angular: cosa cambia

Questi confronti vengono spesso presentati come se tutte le tecnologie fossero alternative sullo stesso livello. Non lo sono.

JavaScript è il linguaggio sottostante. React è una libreria UI. Next.js costruisce un framework applicativo attorno a React. Vue e Angular offrono modelli differenti per affrontare problemi simili dello sviluppo front-end.

Tecnologia	Cos’è	Relazione con React	Quando entra in gioco
JavaScript	Linguaggio di programmazione	React viene utilizzato attraverso JavaScript	Fondamento dello sviluppo React
React	Libreria per interfacce utente	È il soggetto della guida	UI a componenti e stato
Next.js	Framework costruito attorno a React	Utilizza React e aggiunge infrastruttura applicativa	App e siti React con routing, rendering e funzionalità integrate
Vue	Framework progressivo per UI	Alternativa tecnologica, non dipende da React	Applicazioni front-end con modello Vue
Angular	Framework applicativo strutturato	Alternativa a React per molti progetti	Applicazioni che beneficiano di un framework più opinionato

React vs JavaScript: non sono alternative

Chiedere “meglio React o JavaScript?” è simile a chiedere “meglio una libreria o il linguaggio con cui la utilizzi?”.

React dipende da JavaScript.

Puoi costruire interfacce senza React utilizzando direttamente JavaScript e le API del browser. Non puoi invece comprendere seriamente React ignorando JavaScript.

La scelta reale è quindi:

JavaScript nativo è sufficiente per questo progetto oppure una libreria come React riduce la complessità dell’interfaccia?

React vs Next.js: libreria UI e framework applicativo

Next.js utilizza React ma aggiunge molte decisioni e funzionalità che React, da solo, non fornisce.

Per esempio può occuparsi di routing, strategie di rendering, build e altre parti dell’infrastruttura applicativa.

Per questo React e Next.js non sono concorrenti diretti.

Puoi imparare React senza Next.js. Se invece costruisci un’applicazione completa, può avere senso valutare un framework React perché risolve in modo integrato problemi che altrimenti dovresti assemblare manualmente.

React vs Vue e Angular

Vue e Angular competono più direttamente con React sul problema generale della costruzione di applicazioni front-end, ma hanno filosofie differenti.

React tende a mantenere il proprio nucleo concentrato sull’interfaccia e sulla composizione dei componenti. Vue mette a disposizione un ecosistema coeso con una propria sintassi e convenzioni. Angular offre un framework più strutturato con molte funzionalità integrate.

La domanda “qual è il migliore?” è troppo generica.

Sono più utili criteri come:

• competenze già presenti nel team;
• dimensione e durata del progetto;
• quantità di convenzioni desiderate;
• ecosistema necessario;
• integrazione con sistemi esistenti;
• requisiti di rendering;
• disponibilità di sviluppatori;
• manutenzione futura.

React è una scelta forte quando il suo modello a componenti e il suo ecosistema si adattano bene al problema. Non perché debba vincere ogni confronto.

Come iniziare con React oggi

Il modo migliore di iniziare è diverso da quello mostrato ancora in molti tutorial storici.

Create React App è deprecato. La documentazione React suggerisce un framework per molte nuove applicazioni e contempla strumenti di build come Vite quando un framework non è adatto, vuoi costruire una configurazione più personalizzata o vuoi imparare React partendo dalle fondamenta.

Per un primo progetto didattico, Vite permette di concentrarsi su React senza dover configurare manualmente tutta la toolchain.

Prima di React: HTML, JavaScript e DOM

Non serve diventare un esperto del browser prima di creare il primo componente.

Dovresti però capire almeno:

• la struttura di un documento HTML;
• funzioni e oggetti JavaScript;
• array e map();
• moduli;
• eventi;
• concetto di DOM;
• Promise e asincronia di base.

Se durante un tutorial non capisci se una sintassi appartiene a JavaScript oppure a React, probabilmente conviene fermarsi e consolidare prima quel passaggio.

Questo investimento viene ripagato soprattutto quando inizi a fare debugging.

Perché non conviene iniziare un nuovo progetto con Create React App

Create React App è stato per anni il punto di ingresso più conosciuto nell’ecosistema React.

Oggi il progetto è deprecato per le nuove applicazioni. Continua a esistere in maintenance mode per i progetti già presenti, ma non rappresenta più il percorso consigliato per iniziare.

La comunicazione ufficiale sulla dismissione di Create React App indica due direzioni principali:

• utilizzare un framework;
• utilizzare un build tool come Vite, Parcel o Rsbuild quando un framework non è adatto.

Se trovi un tutorial che comincia con:

npx create-react-app mia-app

non significa che tutto il materiale sia inutile. Significa però che la parte relativa alla creazione del progetto è ormai legacy e va contestualizzata.

Creare un progetto React con Vite

Per un progetto didattico puoi partire da Vite.

Nel terminale:

npm create vite@latest

Il wizard permette di scegliere il nome del progetto, React e il linguaggio desiderato.

Dopo la creazione entri nella directory e installi le dipendenze:

cd nome-progetto
npm install
npm run dev

Vite avvierà il server di sviluppo locale.

La struttura esatta del progetto può cambiare con l’evoluzione degli strumenti, ma il concetto da capire è stabile: Vite gestisce l’ambiente di sviluppo e la build; React gestisce il modello della UI.

Sono due responsabilità differenti.

Quando partire invece da un framework React

Se stai costruendo una vera applicazione destinata alla produzione, non dovresti assumere automaticamente che “React puro + Vite” sia sempre l’architettura migliore.

La documentazione ufficiale consiglia di valutare un framework perché un’applicazione reale richiede normalmente più del rendering dei componenti.

Un framework può integrare decisioni relative a:

• routing;
• caricamento dati;
• rendering;
• code splitting;
• build;
• deployment.

Vite resta molto utile per imparare React, prototipare e per applicazioni in cui scegli deliberatamente di comporre tu l’architettura.

Il criterio deve essere il progetto, non l’abitudine del tutorial che hai trovato.

JavaScript o TypeScript per il primo progetto?

Se stai ancora imparando contemporaneamente JavaScript e React, aggiungere subito TypeScript può aumentare il numero di concetti da gestire.

In quel caso partire da JavaScript può rendere più trasparente il modello.

Se invece conosci già JavaScript o lavori in un progetto strutturato, TypeScript può aiutare a rendere più espliciti props, dati e contratti tra componenti.

Non esiste quindi una regola “React va sempre usato con TypeScript”.

Esiste una progressione ragionevole:

• prima capire JavaScript;
• poi capire il modello React;
• aggiungere TypeScript quando il controllo statico produce un vantaggio concreto.

A cosa serve Node.js nello sviluppo React

Un altro equivoco frequente nasce dal fatto che, per installare dipendenze ed eseguire strumenti come Vite, sul computer trovi spesso Node.js.

Questo non significa che una normale interfaccia React venga eseguita da Node.js nel browser.

Node.js è un runtime JavaScript esterno al browser e può avere almeno due ruoli distinti in un progetto React:

1. tooling di sviluppo, per eseguire package manager, build tool e script;
2. backend o ambiente server, quando l’architettura dell’applicazione lo prevede.

Il browser e Node.js sono ambienti diversi.

Comprendere questa separazione evita uno dei fraintendimenti più comuni di chi entra nello sviluppo full stack partendo da JavaScript.

Il primo componente React: un esempio minimo che spiega davvero il modello

Un esempio utile non dovrebbe soltanto produrre qualcosa sullo schermo. Dovrebbe mostrarti il meccanismo che rende React diverso da una semplice pagina HTML.

Costruiamo quindi un componente con stato.

Creare il componente

Puoi sostituire il contenuto principale dell’app con:

import { useState } from 'react';

function Contatore() {
  const [conteggio, setConteggio] = useState(0);

  return (
    <section>
      <h2>Contatore</h2>

      <p>Hai cliccato {conteggio} volte.</p>

      <button onClick={() => setConteggio(conteggio + 1)}>
        Aumenta
      </button>
    </section>
  );
}

export default function App() {
  return <Contatore />;
}

Non è interessante perché crea un contatore. È interessante perché contiene quasi tutto il modello fondamentale.

Cosa succede nel primo rendering

Quando React esegue per la prima volta Contatore:

const [conteggio, setConteggio] = useState(0);

il valore iniziale di conteggio è 0.

Il componente restituisce quindi un’interfaccia equivalente concettualmente a:

<section>
  <h2>Contatore</h2>
  <p>Hai cliccato 0 volte.</p>
  <button>Aumenta</button>
</section>

React applica il risultato al DOM.

Cosa succede quando clicchi il pulsante

L’evento:

onClick={() => setConteggio(conteggio + 1)}

richiede l’aggiornamento dello stato.

React esegue nuovamente il componente con il nuovo valore.

Questa volta:

conteggio === 1

e quindi il componente descrive:

<p>Hai cliccato 1 volte.</p>

React confronta il risultato con lo stato precedente dell’interfaccia e, nella fase di commit, aggiorna ciò che deve cambiare nel DOM.

Tu non hai scritto:

document.querySelector(...)

né hai impartito direttamente l’ordine di modificare il testo del paragrafo.

Hai cambiato lo stato e descritto quale interfaccia corrisponde a quello stato.

Questo è il passaggio mentale che vale la pena capire.

Perché lo state non va modificato direttamente

Potresti chiederti perché non scrivere semplicemente:

conteggio = conteggio + 1;

Lo stato React non viene gestito come una variabile locale qualsiasi.

Devi utilizzare la funzione di aggiornamento:

setConteggio(conteggio + 1);

perché React deve sapere che lo stato è cambiato e che potrebbe essere necessario un nuovo rendering.

Questo principio ritorna continuamente nelle applicazioni React: lo stato determina l’interfaccia e gli aggiornamenti di stato entrano nel ciclo di rendering di React.

React nel percorso di un web developer e di un full stack developer

React è molto richiesto nello sviluppo front-end, ma impararlo ha più valore quando sai collocarlo nel resto dello stack.

Un professionista non lavora soltanto con componenti. Deve capire browser, rete, accessibilità, dati, debugging, performance e il confine tra front-end e backend.

React come specializzazione front-end

Nel percorso di un Web Developer, React può diventare una specializzazione importante dopo aver consolidato HTML, CSS, JavaScript e funzionamento del browser.

Il rischio è imparare una sequenza di pattern React senza capire il livello sottostante.

Se conosci soltanto:

useState(...)

ma non sai interpretare un evento JavaScript o cosa succede nel DOM, puoi costruire componenti finché tutto segue l’esempio del corso. Quando qualcosa esce dal percorso previsto, diventa molto più difficile capire dove si trova il problema.

Il valore professionale nasce dalla combinazione:

fondamenta Web + JavaScript + browser + React

non dal nome della libreria isolato.

React e Node.js nello stesso stack non fanno lo stesso lavoro

React e Node.js vengono spesso citati insieme perché entrambi appartengono all’ecosistema JavaScript.

Ma svolgono compiti differenti.

In una possibile architettura:

React
↓
interfaccia nel browser
↓
richieste HTTP
↓
API Node.js
↓
database

React gestisce il livello dell’interfaccia, mentre Node.js può essere utilizzato sul server per implementare API e logica backend.

Questa combinazione permette di lavorare con JavaScript o TypeScript in più livelli dello stack, ma non annulla la distinzione tra client e server.

React nel lavoro di un Full Stack Developer

Per un Full Stack Developer React può rappresentare il livello front-end di uno stack più ampio.

Conoscere React non rende automaticamente full stack.

Servono anche competenze relative a:

• backend;
• database;
• API;
• autenticazione;
• HTTP;
• sicurezza;
• deployment;
• osservabilità;
• architettura.

React occupa quindi una parte importante dello stack, ma non lo sostituisce.

La distinzione è utile anche quando valuti un corso o una posizione lavorativa: “React Developer” e “Full Stack JavaScript Developer” descrivono perimetri di competenza differenti.

React è difficile da imparare?

React non è particolarmente difficile da iniziare: puoi creare un componente e gestire uno stato con poche righe di codice.

La difficoltà aumenta quando passi dal tutorial a un’applicazione reale.

A quel punto devi comprendere:

• dove collocare lo stato;
• come strutturare i componenti;
• quando usare un Effect;
• come gestire dati asincroni;
• come evitare rendering o dipendenze inutili;
• come progettare confini tra componenti;
• come integrare routing e backend;
• come fare debugging.

Per questo la curva di apprendimento ha una forma particolare: l’inizio sembra molto semplice, mentre la qualità architetturale richiede esperienza.

Un percorso di studio sensato

Un percorso ordinato può essere:

1. HTML e CSS;
2. JavaScript moderno;
3. DOM, eventi e asincronia;
4. componenti e JSX;
5. props;
6. state;
7. rendering;
8. gestione degli eventi;
9. lifting state up e composizione;
10. Effect solo dopo aver compreso quando è realmente necessario;
11. routing e data fetching;
12. TypeScript, testing e framework in base al progetto.

Questa progressione riduce il rischio di imparare ricette isolate.

Non serve aspettare mesi prima di scrivere il primo componente React. Conviene però tornare alle fondamenta ogni volta che React sembra comportarsi come una “scatola magica”.

Quando sceglierei React e quando no

Il criterio finale non dovrebbe essere la popolarità della libreria.

Sceglierei React quando l’interfaccia ha abbastanza stato, composizione e crescita futura da beneficiare chiaramente del modello a componenti.

È una scelta particolarmente sensata quando:

• il team conosce già l’ecosistema;
• l’interfaccia è ricca di interazioni;
• molti elementi dipendono da stato e dati;
• esiste un reale bisogno di componenti riutilizzabili;
• il progetto deve evolvere nel tempo;
• il framework o l’infrastruttura scelta ruotano già attorno a React.

Lo valuterei con più cautela quando:

• la pagina è quasi interamente statica;
• l’interattività è minima;
• il progetto non necessita di una vera applicazione client;
• il team non possiede competenze JavaScript sufficienti;
• la dipendenza aggiuntiva non porta un vantaggio misurabile in manutenzione o sviluppo.

React è potente soprattutto quando semplifica una complessità che esiste davvero.

Usarlo per creare complessità che prima non esisteva produce l’effetto opposto.

Conclusione

React è una libreria JavaScript per costruire interfacce attraverso componenti, stato e rendering dichiarativo. È questo il modello da capire prima di pensare a Hook avanzati, framework, state manager o altri strumenti dell’ecosistema.

Il punto fondamentale è anche ciò che React non è: non è un linguaggio, non è sinonimo di Single Page Application, non sostituisce JavaScript e non garantisce automaticamente performance migliori soltanto perché utilizza un modello di rendering intermedio.

Se stai imparando sviluppo web, partirei quindi dalle fondamenta e userei React come livello successivo: prima JavaScript e browser, poi componenti, props, stato e ciclo di rendering. Solo dopo ha senso aggiungere routing, TypeScript, framework e architetture più complesse.

Se invece devi scegliere React per un progetto reale, la domanda decisiva è pratica: il modello a componenti riduce davvero la complessità dell’interfaccia che dobbiamo costruire?

Quando la risposta è sì, React offre un ecosistema maturo e un modello efficace per far crescere l’applicazione. Quando la risposta è no, scegliere una soluzione più semplice non significa usare una tecnologia inferiore: significa evitare complessità che il progetto non richiede.