How Zitegen uses Astro
What gets generated, what ships to the browser, and why we build static-first instead of hydrating framework islands.
Every site is a real Astro project
When you export or publish a site, Zitegen emits a genuine, buildable Astro 7 project — package.json, astro.config.mjs, src/pages/*.astro, src/components/*.astro, and layouts. Development previews and production deploys run a real npm install && astro build against that project — the same command you would run yourself.
This is a claim you can verify, not just take on faith: download the code, run astro build, and you get the same output Zitegen ships. There is no proprietary runtime wrapped around it — it is your Astro project, and you own it.
Static-first, by design
Generated sites use output: "static". That means the whole site is pre-rendered to HTML at build time and ships with zero JavaScript by default. This is not a shortcut — it is Astro's core thesis: send HTML, add JavaScript only where a page genuinely needs it.
For the marketing pages, portfolios, blogs, and content sites Zitegen is built to produce, static-first is what keeps them fast, cheap to host on Cloudflare's edge, and effortless to keep performant.
Interactivity without framework islands
Astro is famous for its islands architecture — hydrating small framework components (React, Vue, Svelte) on the client with client:* directives. Islands are Astro's optional escape hatch for when a piece of the page truly needs a component framework at runtime. They are not the definition of "using Astro."
Zitegen takes the other, equally idiomatic path. Interactive behavior — modals, forms, content filtering, cookie consent, analytics — is authored as small progressive-enhancement scripts wired to plain elements through data-* attributes. There is no framework runtime and no hydration step; the behavior enhances HTML that already works.
A navigation modal is the clearest example: it compiles to a native <dialog> element plus one shared script that wires open, close, and backdrop-dismiss. It behaves identically in the fast Quick Preview and in a full production build, precisely because there is no hydration boundary to reconcile between them.
Is this really Astro?
Where your site actually lives
The canonical source of truth is Zitegen's visual component model — a structured tree that the AI chat, the visual editor, and the code editor all write into. The .astro source is generated deterministically from that tree every time it changes, which is why the Code and Source tabs always reflect the current state no matter which layer made the edit.
Being direct about the tradeoff: this is generated Astro, not code you hand-write file by file. In exchange you get three editing layers that all stay in sync, and an export that is still a clean, ordinary Astro project you can take anywhere.
If you need framework-hydrated widgets
- Real Astro 7 project you can build and host anywhere.
- Zero JavaScript shipped unless a page actually needs it.
- Interactivity via progressive enhancement, not framework hydration.
- One component model behind the AI, visual, and code editors.