Overview

Zigapagos builds rich interfaces with simple output: HTML, CSS, JavaScript where needed, and static assets. The native core generates pages; Bun renders and bundles Preact-compatible TSX at build time. Deploy the release directory to a compatible static host, with no production Bun or Node process for the frontend.

Use familiar web languages with explicit template and configuration conventions. Write plain CSS, bring a framework’s generated stylesheet, or use your design system. Work directly or with an agent; the same APIs and local tools support both. The application guide covers styling, frontend-only deployment, and optional ZigBase pairing.

The three inputs

A Zigapagos project has three kinds of source file, and each is handled by a different part of the pipeline.

Content lives in content/ as SuperMD (.smd) — Markdown with Ziggy frontmatter and a few extensions. A file’s frontmatter names the layout that renders it. A directory becomes a section when it contains an index.smd.

Layouts live in layouts/ as SuperHTML (.shtml). These are HTML templates with attribute-driven directives rather than a template language embedded in strings, which means an editor can check them as HTML. Layouts compose with <extend template="base.shtml"> and <super>.

Components live wherever you like as .island.tsx, and are declared with a --island= flag on the build command. They are ordinary TSX using the hooks exported by @z/runtime.

How a build runs

The pass order is fixed and worth knowing, because it decides what a failure costs you:

  1. Config validation, content scan, parse, analyze.
  2. SPA prerender — this runs early on purpose. It is the pass that executes your own code (the sidecar calls each .spa.tsx’s describe and staticPaths) and it carries the spec validation. Running it before any page is written means a bad SPA declaration aborts before the output tree has been touched.
  3. Page render and emit.
  4. The props-check gate — every rendered island’s resolved props are typechecked against its exported Props type.
  5. Asset installs, last, because earlier passes bump refcounts the install phase reads.

What it is not

Zigapagos does not run your components on a server at request time. Its frontend output is static files; the dev server and production host are separate concerns. It does not ship a virtual DOM to pages that have no islands. And it does not have a plugin ecosystem — the toolchain is the binary plus Bun, which is the point, but it does mean a capability that does not exist is not one npm install away.

Where to go next

The quick start has a site building in about five minutes. The tutorial builds a real one. If you are moving an existing project, start with migrating from Astro, migrating from Rails, or the other framework mappings: zigapagos migrate --target writes the deterministic parts into a separate buildable project and records everything that still needs a decision.