Open een site — Ontvang een Next.js-project op schijf

Niet zo lang geleden moest ik het interface van een marketingwebsite herstellen waarvan de broncode was verdwenen samen met de aannemer. Meer precies: de klant had alleen een productielink over. Vroeger zou ik een avond bezig zijn geweest met het handmatig kopiëren van de layout, maar deze keer stuitte ik op een project dat het in een minuut doet. En niet via LLM, wat voor mij onverwacht was.

Wat is ditto.site

ditto.site — een open source TypeScript-compiler die een openbare URL neemt en omzet in een zelfstandig project. Standaard output is Next.js App Router, op verzoek — Vite React. Stijlen komen via Tailwind of plain CSS.

Laat me verduidelijken wat de auteur bedoelt met "klonen". Er is geen git clone nodig: je hebt de repository van de site of de broncode niet nodig. Je hebt alleen een link nodig die toegankelijk is vanuit een browser. Het tool opent de pagina, registreert wat de browser daadwerkelijk weergeeft, en schrijft een nieuw project op basis daarvan.

De auteur noemt zijn systeem expliciet een "capture-to-code pipeline" en benadrukt dat de compiler geen LLM is die pagina's auteur. Dezelfde vastgelegde kopie produceert altijd byte-voor-byte identieke output. Trouwens, determinisme wordt hier als hoofdfunctie gepromoot, en dat is eerlijker dan mysterieuze neurale netwerkgeneratie waarbij elke run verschilt.

Het project heeft inmiddels 1580 sterren en 214 forks op GitHub, MIT-licentie. Het project is nieuw, maar de community eromheen vormt zich snel.

Hoe het te gebruiken

Drie manieren. De simpelste is de lokale CLI:

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

Na het installeren van Chromium opent het npm run clone-commando de pagina, legt de status vast en plaatst de kant-en-klare applicatie in output/<site>/app. Dit detail beviel me: zonder de --out-vlag gaan resultaten naar runs/<site>/<timestamp>/, en de symlink runs/<site>/latest wijst altijd naar de laatste kloon. Scripts hoeven niet herschreven te worden voor de nieuwe timestamp.

Er zijn ook lazy modes:

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

De tweede manier is een REST API op api.ditto.site. Maak een sleutel aan via het formulier of curl met e-mailverificatie, exporteer deze naar DITTO_API_KEY, en start een taak:

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"
    }
  }'

De respons bevat een bestandsmap met het pad, de grootte en SHA-256 van elk bestand. Hun CLI-unpacker helpt om de directorystructuur naar schijf uit te pakken, en het hele project kan als een enkel archief worden gedownload via /bundle?format=tgz.

De derde manier is een MCP-server, en eerlijk gezegd is dit het meest interessante deel voor mij. ditto.site verbindt met agents als een reguliere MCP-tool, en de server is ontworpen om zuinig te zijn: eerst ontvangt de agent alleen de taak-ID en metadata, en leest bestanden naar behoefte. Tools zoals clone_website, list_clone_files en read_clone_files stellen de agent in staat om zelf een kloon te starten, te wachten op voltooiing en selectief package.json of een specifieke component te lezen.

Wat er terechtkomt in het gegenereerde project

De output is niet alleen layout. Volgens de README bevat de applicatie:

• herstelde pagina's en route-modules;
• vastgelegde assets, fonts, iconen, manifesten en metadata;
• robots, sitemap, llms.txt en JSON-LD indien gedetecteerd;
• kleine runtime-helpers voor herkende interacties en animaties;
• gegenereerde AGENTS.md en ARCHITECTURE.md voor het overdragen van het project.

Ik merk het laatste punt apart op. De auteur verwacht duidelijk dat een mens of AI-agent daarna aan de code werkt, en neemt meteen instructies op over welke bestanden veilig te bewerken zijn: src/app/content.ts en src/app/components/. Dit is een zeldzaam niveau van zorg voor een generator.

Hoe het intern werkt

De pipeline ziet er zo uit: URL → browser capture → genormaliseerde tussentijdse render → deterministische output → applicatiegeneratie → asset-materialisatie → optionele validatie.

Capture schrijft de DOM, berekende stijlen, layout boxes, bron-CSS, fonts, screenshots en interactiestatussen. Reproduceerbare animaties worden ook vastgelegd indien observeerbaar. Arbitraire JavaScript van derden, authenticatie, betalingen en personalisatie worden echter niet gereproduceerd. Dit is een logische beperking: het tool werkt met wat zichtbaar is in de browser, niet met server-side logica.

De repository heeft een solide architectuur: compiler, Hono REST API naast MCP-server, Drizzle-schema met migraties, task queue worker, artifact storage voor S3/R2. Je kunt alles lokaal draaien via docker compose met Postgres en MinIO, of een vereenvoudigde inline modus zonder database in één commando. Er is ook een MCP-endpoint op localhost:8787/mcp voor de lokale API.

Ik vind het fijn dat er verify en asyncVerify opties zijn: het gegenereerde project kan door validatie worden gehaald en je krijgt bevestiging dat het tenminste bouwt en vergelijkbaar rendert met het origineel.

Waar het van pas komt

Het eerste scenario is voor de hand liggend: een site herstellen wanneer er geen bronnen zijn. Een verlaten landingspagina, verloren aannemer-bronnen, een legacy pagina die naar een moderne stack moet worden verplaatst. Hier lost het tool het probleem in minuten op.

Het tweede scenario is prototyping. Een klant laat zien "ik wil het zoals hier" en geeft een link. In plaats van abstracte discussies krijg je in een paar minuten een werkend project met Next.js-structuur, en dan bespreek je verschillen daarbinnen. Voor een freelancer die de omvang van het werk schat op basis van iemands referentie, versnelt dit de start.

Het derde scenario is automatisering via MCP. Een agent kan de taak krijgen: "kloneer deze site als een Next.js-app, wacht op voltooiing, lees de gegenereerde bestanden". Het "alleen benodigde bestanden"-formaat bespaart de context van de agent, en de auteurs hebben hier duidelijk over nagedacht.

De andere kant en spelregels

Er zijn kanttekeningen. De CLI woont momenteel in de repository en is niet gepubliceerd naar npm, dus npx ditto werkt niet — je moet de hele repository klonen. Dit is niet iets wat je met één regel aan CI kunt toevoegen, maar de auteurs waarschuwen hier eerlijk voor.

Dan is er de ethiek. De README herinnert je voortdurend: gebruik het tool alleen waar je het recht hebt om content te kopiëren en te transformeren. Phishing, merkimitatie, authenticatie-omzeiling en massale capture van andermans sites zijn expliciet verboden, en het project heeft een apart document RESPONSIBLE_USE.md. Dat klinkt goed: de technologie zelf is neutraal, maar het is de moeite waard om het toe te passen op je eigen projecten of met toestemming van de eigenaren.

Nog iets. In zowel het Russisch als het Engels klinkt het woord "klonen" gedurfd, maar in werkelijkheid is het een reconstructie van het zichtbare deel van de pagina. Verwacht niet dat het tool server-side code, een database of bedrijfslogica eruit haalt — het stelt dit eerlijk in de README.

Wie zou het moeten proberen

Als je landingspagina's bouwt, sites migreert naar een nieuwe stack, of een AI-agent een schoon tool wilt geven voor het werken met webinterfaces, neem dan een kijkje bij ditto.site. Begin met de lokale CLI, het vereist geen sleutels: npm run clone -- https://example.com/ --serve, en in een paar minuten heb je een dev-server draaien op het herstelde project. En als je dit in je pipeline wilt inpluggen, zijn de REST API en MCP-server al inbegrepen. Voor een designer of tech lead die vaak "maak het zoals dit" ontvangt, ziet het tool eruit als een eerlijk antwoord op een heel gebruikelijk pijnpunt.