Apri un sito — Ottieni un progetto Next.js su disco

Non molto tempo fa, avevo bisogno di ripristinare l'interfaccia di un sito web di marketing il cui codice sorgente era scomparso insieme al contractor. Più precisamente, il cliente aveva solo un link di produzione. In passato, avrei passato una serata a copiare manualmente il layout, ma questa volta mi sono imbattuto in un progetto che lo fa in un minuto. E non tramite LLM, il che è stato inaspettato per me.

Cos'è ditto.site

ditto.site — un compilatore TypeScript open source che prende un URL pubblico e lo trasforma in un progetto autonomo. Di default genera Next.js App Router, su richiesta — Vite React. Gli stili arrivano tramite Tailwind o CSS puro.

Voglio chiarire cosa intende l'autore per "clonazione". Non c'è git clone qui: non serve il repository del sito né il suo codice sorgente. Serve solo un link accessibile da un browser. Lo strumento apre la pagina, registra ciò che il browser ha effettivamente renderizzato e scrive un nuovo progetto da quello.

L'autore definisce esplicitamente il suo sistema come una "pipeline di cattura-codice" e sottolinea che il compilatore non è un LLM che genera pagine. La stessa copia catturata produce sempre un output byte-per-byte identico. Tra l'altro, il determinismo è presentato come la funzionalità principale, ed è più onesto del misterioso output delle reti neurali dove ogni esecuzione differisce.

Il progetto ha già 1580 stelle e 214 fork su GitHub, licenza MIT. Il progetto è nuovo, ma la community si sta formando rapidamente.

Come usarlo

Tre modi. Il più semplice è la CLI locale:

git clone https://github.com/ion-design/ditto.site.git
cd ditto.site
npm ci
npx playwright install chromium
npm run clone -- https://example.com/ --out=./output

Dopo aver installato Chromium, il comando npm run clone apre la pagina, cattura lo stato e posiziona l'applicazione pronta in output/<site>/app. Mi è piaciuto questo dettaglio: senza il flag --out, i risultati vanno in runs/<site>/<timestamp>/, e il symlink runs/<site>/latest punta sempre all'ultimo clone. Gli script non devono essere riscritti per il nuovo timestamp.

Ci sono anche modalità lazy:

npm run clone -- https://example.com/ --serve   # клонирует и сразу поднимает dev-сервер
npm run clone -- https://example.com/ --open    # плюс открывает браузер

Il secondo modo è una REST API su api.ditto.site. Crea una chiave attraverso il form o curl con verifica email, esportala in DITTO_API_KEY, e lancia un task:

curl -sS -X POST "$DITTO_API_URL/v1/clones" \
  -H "authorization: Bearer $DITTO_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "url": "https://example.com/",
    "options": {
      "mode": "single",
      "styling": "tailwind",
      "framework": "next"
    }
  }'

La risposta include una mappa dei file con il percorso, la dimensione e SHA-256 di ogni file. Il loro unpacker CLI aiuta a estrarre l'albero delle directory su disco, e l'intero progetto può essere scaricato come archivio singolo tramite /bundle?format=tgz.

Il terzo modo è un server MCP, e onestamente, questa è la parte più interessante per me. ditto.site si connette agli agent come un normale strumento MCP, e il server è progettato per essere economico: prima l'agente riceve solo l'ID del task e i metadati, e legge i file secondo necessità. Strumenti come clone_website, list_clone_files e read_clone_files permettono all'agente di lanciare un clone da solo, aspettare il completamento e leggere selettivamente package.json o un componente specifico.

Cosa finisce nel progetto generato

L'output non è solo layout. Secondo il README, l'applicazione include:

• pagine ripristinate e moduli di routing;
• asset catturati, font, icone, manifest e metadati;
• robots, sitemap, llms.txt e JSON-LD se rilevati;
• piccoli helper runtime per interazioni e animazioni riconosciute;
• AGENTS.md e ARCHITECTURE.md generati per il passaggio del progetto.

Noto il dernier punto separatamente. L'autore si aspetta chiaramente che un umano o un agente AI lavori sul codice successivamente, e include immediatamente istruzioni su quali file sono sicuri da modificare: src/app/content.ts e src/app/components/. Questo è un livello di cura raro per un generatore.

Come funziona internamente

La pipeline funziona così: URL → cattura browser → render intermedio normalizzato → output deterministico → generazione applicazione → materializzazione asset → validazione opzionale.

La cattura scrive il DOM, gli stili calcolati, i box del layout, il CSS sorgente, i font, gli screenshot e gli stati di interazione. Le animazioni riproducibili vengono anch'esse catturate se osservabili. Tuttavia, JavaScript arbitrario di terze parti, autenticazione, pagamenti e personalizzazione non vengono riprodotti. Questa è una limitazione logica: lo strumento lavora con ciò che è visibile nel browser, non con la logica lato server.

Il repository ha un'architettura solida: compilatore, REST API Hono insieme a server MCP, schema Drizzle con migrazioni, worker della coda di task, storage degli artifact per S3/R2. Puoi avviare tutto localmente tramite docker compose con Postgres e MinIO, oppure eseguire una modalità inline semplificata senza database in un singolo comando. C'è anche un endpoint MCP su localhost:8787/mcp per l'API locale.

Mi piace che ci siano opzioni di verify e asyncVerify: il progetto generato può essere eseguito attraverso la validazione e ottieni conferma che almeno si compila e renderizza in modo simile all'originale.

Dove torna utile

Il primo scenario è ovvio: ripristinare un sito quando non ci sono sorgenti. Una landing page abbandonata, sorgenti di contractor perse, una pagina legacy che deve essere spostata su uno stack moderno. Qui lo strumento risolve il problema in pochi minuti.

Il secondo scenario è il prototyping. Un cliente mostra "lo voglio come questo" e lascia un link. Invece di discussioni astratte, ottieni un progetto funzionante con struttura Next.js in un paio di minuti, e poi discuti le differenze al suo interno. Per un freelancer che stima il lavoro da un riferimento di qualcun altro, questo accelera l'avvio.

Il terzo scenario è l'automazione tramite MCP. A un agente si può assegnare: "clona questo sito come app Next.js, aspetta il completamento, leggi i file generati". Il formato "solo i file necessari" risparmia il contesto dell'agente, e gli autori hanno chiaramente pensato a questo.

L'altra faccia e le regole del gioco

Ci sono delle caveat. La CLI al momento vive dentro il repository e non è pubblicata su npm, quindi npx ditto non funzionerà — devi clonare l'intero repository. Non è qualcosa che puoi aggiungere a CI con una singola riga, ma gli autori onestamente avvisano di questo.

Poi c'è l'etica. Il README ti ricorda costantemente: usa lo strumento solo dove hai il diritto di copiare e trasformare il contenuto. Phishing, impersonificazione di brand, bypass dell'autenticazione e cattura massiva di siti di altri sono esplicitamente vietati, e il progetto ha un documento separato RESPONSIBLE_USE.md. Questo suona giusto: la tecnologia stessa è neutrale, ma vale la pena applicarla ai propri progetti o con il permesso dei proprietari.

Un'altra cosa. Sia in russo che in inglese, la parola "clonazione" suona audace, ma in realtà è una ricostruzione della parte visibile della pagina. Non aspettarti che lo strumento estragga codice lato server, un database o logica di business — lo dice onestamente nel README.

Chi dovrebbe provarlo

Se crei landing page, esegui migrazioni di siti su un nuovo stack, o vuoi dare a un agente AI uno strumento pulito per lavorare con le interfacce web, dai un'occhiata a ditto.site. Inizia con la CLI locale, non richiede chiavi: npm run clone -- https://example.com/ --serve, e in un paio di minuti hai un dev server in esecuzione sul progetto ripristinato. E se vuoi integrare questo nella tua pipeline, la REST API e il server MCP sono già inclusi. Per un designer o tech lead che spesso riceve "fallo come questo", lo strumento sembra una risposta onesta a un problema molto comune.