Poops vs webpack, Rollup & Parcel

The webpack config that nobody on the team can read is a genre. It starts as twenty lines, acquires a loader for Sass, a loader for the loader, a plugin to extract the CSS the loaders just inlined, a resolve.alias block, and a comment saying do not touch this, it took a day. Two years later the project is a landing page with a contact form, and the toolchain has more dependencies than the site has pages.

Poops is the reaction to that: in, out, options — and no place for that config to grow into.

Where the three stand

All read from npm in August 2026:

Feature by feature

The same job, spelled out

Bundle a TypeScript entry, compile SCSS beside it, minify both, keep sourcemaps on the unminified twin. In webpack that is ts-loader (or babel-loader plus a preset), sass-loader → css-loader → MiniCssExtractPlugin.loader, a rules array to wire them to extensions, the plugin in plugins, and optimization.minimizer for the CSS half. In Poops it is the file itself:

{
  "scripts": [{
    "in": "src/js/main.ts",
    "out": "dist/js/main.js",
    "options": { "minify": true, "sourcemap": true, "format": "iife", "target": "es2019" }
  }],
  "styles": [{
    "in": "src/scss/index.scss",
    "out": "dist/css/styles.css",
    "options": { "minify": true, "sourcemap": true }
  }]
}

Both emit main.js + main.min.js and styles.css + styles.min.css. The difference is that the second one has no loader order to get wrong, and the $schema reference at the top of the file makes the editor complete every key — a typo is caught as you type it rather than at build time.

Add "markup" and the same file also builds the pages, which is the part webpack, Rollup and Parcel were never trying to do.

The part Poops refuses

There is no plugin API and there will not be one. A feature that fits in a few lines of config does not get an extension point, and one that does not fit gets argued about in an issue instead. That refusal is the whole design: it is why the dependency list is boring, why the config is JSON, and why there is no version of this project where you write a poops.config.js that imports four packages.

The cost is real and it is exactly webpack's strength: when Poops does not do something, you cannot bolt it on. A custom transform for a file type nobody has heard of is a loader in webpack and a fork in Poops — or a markup engine, which is the one interface left open, because a template language is a whole job rather than a hook.

Use webpack, Rollup or Parcel when

Use Poops when

• The project is a site with a front end: pages, SCSS and TypeScript in one config, one command, plain files out.
• The build should be readable by whoever picks the project up next year — including you. JSON, no imports, with $schema completing the keys in the editor.
• You want the toolchain to be one dependency instead of a bundler plus five loaders plus three plugins that have to agree on versions.
• Nobody on the team wants to own a webpack.config.js again.

The size of the JavaScript is not the deciding factor — esbuild handles large bundles fine. What decides it is whether you need managed chunks, a manifest and federation, or whether you need the config to stay small enough to read.