Compare

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
Built-in image optimization	Yes (opt-in)	Yes (`astro:assets`)	No under static export	Official plugin	Yes (template functions)
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.

"Built-in image optimization" means the generator itself turns a committed image into responsive variants at build time. Zigapagos does it with one config field — .image_optimize = {} emits WebP variants at configured widths as a <picture> with a full srcset/sizes, AVIF opt-in via an external encoder you supply. Astro's astro:assets does the same job with per-image control through its <Image> component. Hugo processes images through template functions, so the variants are built in but the markup is yours to write. Eleventy covers it with an official plugin rather than a core feature, and Next.js's image optimizer runs at request time, which a static export does not have — it needs a custom loader or ships the originals.

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 offers static pages, selective islands, and native SPAs on a shared Preact runtime. Choose based on the rendering model and library compatibility your application needs; application frontends are a supported Zigapagos use case.

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

Zigapagos renders at build time. Personalised data comes from a backend API and is rendered in the browser. ZigBase can serve both the API and frontend on one origin, but does not add request-time component rendering to Zigapagos.

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.

How Zigapagos compares