How Zigapagos compares
Every tool here is good at something. This page is about which trade it makes, not which one wins.
At a glance
| Property | Zigapagos | Astro | Next (static export) | Eleventy | Hugo |
|---|---|---|---|---|---|
| Islands / partial hydration | Yes | Yes | No — whole-page hydration | No | No |
| JS on a page with no components | None | None | Framework runtime | None | None |
| Node required | No | Yes | Yes | Yes | No |
| Bundler to configure | No | Vite | Turbopack/webpack | Bring your own | No |
| Component language | TSX | TSX/JSX/Vue/Svelte | TSX/JSX | Templates only | Templates only |
| Build-time props typechecking | Yes | Opt-in (astro check) | Yes (next build) | n/a | n/a |
| Client-routed SPA from the same project | Yes | Via a framework router | Yes | No | No |
| Plugin ecosystem | No | Large | Large | Large | Moderate |
"Build-time props typechecking" is about whether passing the wrong props to a
component is caught before deploy. Zigapagos checks every island's resolved
props against its component's exported Props type as part of the
normal build. Astro can do the equivalent, but as a separate command
(astro check) most projects wire into CI rather than a step
astro build runs on its own. Next.js's production build runs a
project-wide tsc pass and fails on type errors by default, which
catches a bad prop the same way.
In detail
vs Astro
The closest comparison, and the one Zigapagos is designed against. Same
islands model, same directives, similar authoring. The differences are
the toolchain and the type story: no Node, no Vite, no bundler
configuration, and island props are typechecked against the component's
exported Props as part of every build, not as a separate
opt-in step. What Astro has and this does not is an ecosystem —
integrations, adapters, multiple UI frameworks, and years of answered
questions.
vs Next.js static export
Next exports static HTML, but the model underneath is a React application: the framework runtime ships whether or not a given page needs interactivity. Zigapagos inverts that default — a page with no islands ships no JavaScript. If your site is mostly application and incidentally content, Next is the better fit; if it is mostly content with pockets of interactivity, this is.
vs Eleventy
Eleventy is excellent at turning content into HTML and takes no position on client-side components — which is freedom if you want it and work if you do not. Zigapagos has an opinion: components are TSX, hydration is a directive, and the bundling is handled. Eleventy also runs anywhere Node runs and has a far larger plugin ecosystem.
vs Hugo
Hugo is a single fast binary with no runtime dependency, and for a pure content site it is hard to beat — a larger theme ecosystem, a longer track record, and builds that are very fast at scale. It has no islands model. Zigapagos keeps the single-binary property for the content half and adds real components for the interactive half.
Lineage
And the generator this forks
Zigapagos is a permanent fork of Loris Cro's SSG, which contributed SuperMD, SuperHTML, Ziggy and the rendering core — all of it still here and still excellent at what it does. The fork exists to add islands, native SPAs and the Astro migration path. If you want the content pipeline without the component layer, the upstream project is smaller and closer to the source.
Honesty
When not to use Zigapagos
You need server-side rendering at request time
There is no server. Anything personalised per request has to happen in the browser or in a backend you run separately.
You depend on a specific plugin ecosystem
There is no plugin system. A capability that does not exist is not one install away — it is a patch to the generator.
Your team wants Vue, Svelte, or Solid
Islands are TSX on a Preact-compatible runtime. One component model, deliberately, and it is not the one you are using.
You need it stable today
This is pre-1.0 and a minor version may break an API. Windows builds are currently unsupported pending the Zig 0.17 port. If a broken build on a Tuesday is unacceptable, wait.