Stack frontend per solo founder: scegliere Astro, Next.js, React, Tailwind e shadcn/ui

Il progetto contiene quattro superfici: /blog, /tools/image-resizer, /dashboard/settings e /pricing. Conviene metterle tutte in Next.js o separare il blog Astro dalla dashboard Next.js? Un blog Astro che aggiunge login, pagamenti e cronologia fa pensare a una migrazione. Al contrario, anche un progetto Next.js con venti articoli Markdown richiede di capire cache, Server/Client Components e deploy.

La scelta frontend di un’azienda individuale non è una classifica dei framework. Tipo di pagina, dati dinamici e costo di manutenzione determinano framework, confine del repository e responsabilità sul codice shadcn/ui copiato. Bisogna distinguere quando bastano le islands, quando App Router costa più di quanto offre e quando React + Vite è più semplice.

Backend, deploy, database, pagamenti e autenticazione restano per gli articoli successivi.

Tabella decisionale dei framework

Si parte dal tipo di pagina, non dalla popolarità.

Più superfici nello stesso prodotto

Con circa 80% contenuti e 20% dashboard, Astro può restare l’app principale; la dashboard può usare islands React o un’app Next.js separata.

Con 80% applicazione e 20% blog, Next.js può contenere il prodotto e generare il blog staticamente.

Con una divisione vicina a 50/50, un’app Astro per i contenuti e una Next.js per la dashboard rendono il confine esplicito. Un monorepo può conservarlo.

Due app aggiungono dipendenze e deploy, ma impediscono che le regole di cache di una superficie influenzino tutte le pagine.

Avviso sul costo di manutenzione

Cache Next.js, confini Server/Client e differenze tra Vercel, Cloudflare e server proprio richiedono verifica. Con poche pagine dinamiche, Astro o React + Vite possono costare meno.

Il confronto Astro vs Next.js approfondisce l’architettura.

Siti di contenuti: Astro e architettura Islands

Astro è rivolto a blog, documentazione, marketing e altri siti content-driven. Server-first e zero JS by default significano che l’HTML nasce al build o sul server; solo i componenti dichiarati interattivi caricano JavaScript nel browser.

Le content collections organizzano, validano e tipizzano Markdown o dati strutturati. Frontmatter e query per data, tag o categoria possono essere controllati al build.

Islands: HTML statico e interazione locale

La maggior parte della pagina resta HTML. Una piccola area interattiva diventa island e client:load o client:visible decide quando caricarla.

Un pulsante di invio può essere l’unico componente React con client:load.

Un selettore del tema può leggere localStorage e cambiare variabili CSS.

Un visualizzatore di immagini può attendere client:visible.

Così non serve idratare l’intera pagina per un form o un piccolo tool.

Quando Astro non deve gestire tutto

Se quasi ogni route verifica l’identità, carica dati privati, condivide molto stato o richiede routing client complesso, Astro non è più la base ovvia. Una dashboard piena di islands autenticate è spesso più chiara in Next.js o in un’app React autonoma.

Il caso Astro 5 e Lighthouse mostra collections e islands in un sito reale.

Tool e prodotti interattivi: React + Vite vs Next.js

Un tool si concentra spesso su un’azione; un prodotto interattivo aggiunge route, stato condiviso, collaborazione o editor.

Quando funziona React + Vite

React + Vite è adatto a una SPA client o a un tool indipendente senza rendering server.

Un compressore elabora i file nel browser.

Un formattatore JSON analizza l’input localmente.

Alibaba Cloud - Scelta top per sviluppatori, 15% di sconto esclusivo su Lighthouse

Ottieni -15% →Pubbl.

Un editor Markdown combina modifica, anteprima e localStorage.

Deploy statico e assenza dei confini cache di Next.js semplificano il sistema. Se la ricerca è centrale, una SPA client richiede una strategia SEO esplicita.

Quando funziona Next.js

Next.js è utile con rendering server, più route o rendering misto.

Home, tool e risultato possono avere route renderizzate.

Le pagine esplicative possono essere indicizzate con SSG o SSR.

La presentazione può essere statica e i risultati privati dinamici.

Condizioni per scegliere React + Vite

L’azione principale usa Browser APIs, localStorage o Canvas.

Il tool va distribuito come file statici senza Node.js.

Non servono routing, cache o SSR di Next.js.

Un confine netto tra client e backend è più facile da mantenere.

Se ricerca e route server sono centrali, il loro beneficio deve compensare la complessità aggiuntiva.

React 19 Actions approfondisce form e azioni asincrone.

Dashboard SaaS: Server e Client Components di Next.js

App Router separa lavoro server e interazione nel browser. 'use client' marca il confine client.

Server Components vs Client Components

I Server Components girano sul server o al build senza aggiungere la loro logica al bundle JavaScript del browser.

Sono adatti a contenuti statici, query al database e API.

Non possono usare localStorage, window, useState, useEffect o onClick.

I Client Components girano nel browser e gestiscono interazione, stato e Browser APIs.

Sono adatti a form, pulsanti e aggiornamenti live.

Il file di confine dichiara 'use client'.

Un Server Component può importare un Client Component. Il client non importa direttamente un Server Component, ma può ricevere contenuto renderizzato sul server.

Casi d’uso della dashboard SaaS

App Router si adatta ad autenticazione, dati dinamici e molti form.

Le impostazioni leggono dati utente e salvano preferenze.

Gli ordini mostrano liste, dettagli e cambi di stato.

Gli analytics caricano dati protetti sul server e grafici interattivi nel browser.

L’accesso diretto al data layer aiuta quando identità e permessi sono centrali.

Avviso sul costo di manutenzione

Rendering statico o dinamico, revalidate, confini e runtime devono corrispondere alla versione in uso. La documentazione corrente vale più degli esempi vecchi.

Con poche pagine dinamiche, React + Vite e un backend Node.js o Supabase separato possono essere più semplici.

La serie App Router tratta routing, migrazione, Middleware, Auth e Dark Mode separatamente.

Livello di stile: Tailwind e utility-first

Utility-first combina piccole classi in HTML o JSX. In <div class="bg-blue-500 text-white p-4 rounded-lg">, ogni classe controlla una proprietà.

Tailwind è un livello di collaborazione, non un sostituto del design.

Riduce la necessità di nominare classi CSS.

Mantiene lo stile vicino al markup che lo usa.

Offre a persone e agenti un vocabolario comune per cambiare l’interfaccia.

Railway - Piattaforma di deploy moderna, senza operazioni complesse, online in pochi minuti

Inizia ora →Pubbl.

Tailwind non produce qualità di design

Colori, tipografia, spazi e raggi richiedono regole coerenti.

I token del prodotto sono migliori di utility casuali.

Combinazioni ripetute di pulsanti, card e righe devono diventare componenti.

Senza limiti, il markup diventa più denso senza rendere coerente il prodotto.

Tailwind è indipendente dal framework

Tailwind funziona con Astro, Next.js e React + Vite. Il percorso Vite attuale di Tailwind CSS v4 usa @tailwindcss/vite e @import "tailwindcss";; Astro può usare lo stesso plugin. Verifica la guida ufficiale durante l’implementazione.

Livello componenti: proprietà e integrazione di shadcn/ui

shadcn/ui non nasconde un’implementazione fissa in un package tradizionale. La CLI copia il codice nel progetto, che poi lo mantiene.

Il progetto possiede il codice

Gli aggiornamenti upstream non modificano automaticamente le copie.

Tastiera, ARIA e screen reader vanno provati nelle combinazioni reali.

Colori, raggi e spazi devono allinearsi al design system.

Validazione, invio e logica di business restano codice applicativo.

Il codice visibile e modificabile è il vantaggio; aggiornamenti, accessibilità, tema e stati sono la responsabilità.

shadcn/ui e Tailwind

Le guide attuali per Astro e Next.js presuppongono Tailwind. Tailwind offre il linguaggio di stile; shadcn/ui il codice sorgente mantenuto dal progetto.

Casi adatti

Dashboard, impostazioni e pagine con molti form sfruttano Button, Input, Select, Dialog e Table.

Le impostazioni riusano controlli ed errori.

Registrazione, login e checkout usano primitive, ma l’app mantiene validazione e stato.

Una libreria esistente o un design system completo riducono il vantaggio.

Integrazione con Astro

I componenti React richiedono l’integrazione React.

Tailwind fornisce gli stili.

Sono adatti a form e dialog locali, non a trasformare tutto il contenuto in app React.

Il template ufficiale configura Tailwind e React; controlla i passaggi CLI correnti.

Integrazione con Next.js

shadcn/ui offre un template Next.js e un percorso per progetti esistenti.

Ogni componente deve stare sul lato Server/Client corretto. Non serve convertire l’intera pagina in Client Component.

CLI, preset e registry possono cambiare.

Quando non usare shadcn/ui

Quando serve un design system completo invece di primitive.

Quando il progetto non vuole mantenere codice, aggiornamenti, accessibilità e tema.

Quando Ant Design, Material UI o una libreria interna bastano già.

Quando un sito di contenuti usa pochi form o dashboard.

Il vero costo di manutenzione per un solo founder

Tipo di pagina e dati non bastano: complessità del framework, proprietà dei componenti e revisione del codice generato dall’IA determinano il lavoro a lungo termine.

Manutenzione di Next.js

Una differenza tra intenzione e regole di rendering o cache può servire dati vecchi.

I confini Server/Client decidono dove vivono stato e accesso ai dati.

Vercel, Cloudflare e un runtime Node.js proprio vanno valutati separatamente.

Vultr - Cloud server NVMe ad alte prestazioni, 32 location globali, deploy Docker con un clic

Vedi prezzi →Pubbl.

Con pagine soprattutto statiche, questo costo può superare il beneficio.

Manutenzione di shadcn/ui

Correzioni e aggiornamenti upstream richiedono revisione.

Tastiera, ARIA e screen reader richiedono test di prodotto.

Colori, densità e spazi seguono i token.

Validazione, invio e stato restano interni.

Se questa responsabilità non è desiderata, è meglio una libreria package o poche primitive interne.

Revisione del frontend generato dall’IA

Gli esempi React, Next.js e shadcn/ui sono numerosi, ma la verifica rimane.

Un agente può creare troppi livelli Server/Client.

Può usare cache incompatibile con versione o route.

Può ignorare token e stati di interazione.

L’IA riduce la scrittura, non la revisione di architettura, accessibilità e interfaccia.

Più framework nello stesso prodotto

Astro per i contenuti e Next.js per la dashboard rendono chiaro il confine, ma aggiungono dipendenze, configurazione e CI/CD per due app.

Vanno gestite anche route come blog.example.com e app.example.com.

Entrambe possono vivere in un monorepo. Un prodotto content-first resta soprattutto Astro; uno app-first soprattutto Next.js; uno bilanciato usa due confini espliciti.

Passi successivi e letture

Articoli pubblicati

Scegliere un framework per blog confronta Hugo, Astro e Hexo.

Astro 5 e Lighthouse 100 tratta collections, islands e prestazioni.

Astro vs Next.js confronta architettura e rendering.

React 19 Actions approfondisce form e operazioni asincrone.

Serie Next.js App Router

Routing, migrazione, Middleware, Auth e Dark Mode sono trattati in articoli separati per dashboard SaaS.

Articoli successivi della serie

Questo è il quinto articolo di Solo Founder Tech Stack. I successivi confrontano Node.js, Python, Go, Supabase e API proprie.

Trattano anche Cloudflare, Vercel, server propri e container.

I database confrontati includono PostgreSQL, Supabase, PlanetScale e MongoDB.

L’autenticazione confronta servizi gestiti e soluzioni interne.

Dopo aver classificato le pagine, backend e deploy devono sostenere il confine frontend scelto.