Poops vs Astro, Hugo & Next

This page is the one where Poops loses most of the rows, and that is the correct result. Astro, Hugo and Next are frameworks: they own the project, they bring a mental model, and in exchange they solve problems Poops does not attempt — partial hydration, content layers, server rendering, ten-thousand-page builds.

Poops attempts fewer things so that the config stays one file you can read in a sitting. The question is not which is more capable. It is whether you need the capability enough to rent the model.

Where the three stand

Feature by feature

One interactive component, concretely

Astro's client:visible is one word on a component. The Poops equivalent is a reactor entry — pre-render the component to HTML at build time, inject it into the template, ship a hydration bundle for it:

{
  "reactor": [{
    "component": "src/js/Counter.jsx",
    "inject": "counter_html",
    "in": "src/js/counter-hydrate.jsx",
    "out": "dist/js/counter.js",
    "options": { "minify": true }
  }]
}

The template drops it in with {{ counter_html | safe }} and the page ships that component's JavaScript and nothing else — the full walkthrough is three files long. For one or two components this is less machinery than a framework. For twenty it is twenty entries, and Astro's one word is the better trade.

What Poops wins

Nothing to learn beyond the keys. No islands directives, no template lookup order, no rendering modes, no adapters, no .astro file format. The config is JSON, the config reference is the whole API, and $schema completes it in the editor.

No framework in the output. A Poops page is the HTML your template produced, plus whatever script tags you wrote. Nothing hydrates a page you did not ask to hydrate, there is no client router to hit a bug in, and no rendering-model migration lands in your inbox next year.

The assets are in the same file as the pages. SCSS, TypeScript, PostCSS, images and pre-rendered React are keys beside markup — not integrations, not adapters, not a Vite config you inherit from the framework and have to reason about through two layers.

Static output that goes anywhere. dist on any host, file:// included, because the default path prefixes are relative. No adapter per platform, no Node process to keep alive.

What each wins outright

Astro — islands as the model. If half your pages need interactive components and the other half must ship zero JavaScript, client:visible beats twenty reactor entries. Poops' version is the same idea hand-wired, and hand-wiring does not scale past a handful.

Hugo — scale and portability. One binary, no node_modules, and it is what people reach for at thousands of pages. Poops has never been measured at that size, and this page will not pretend otherwise.

Next — anything with a server in it. Sessions, ISR, API routes, streaming. Poops writes files to a directory and exits; if you need a request handler, nothing here helps.

Which to pick