No build tool zoo, one bundle per namespace instead of one per page

A modern frontend build usually means a bundler, a CSS preprocessor, a minifier, and a config file coordinating all three. Phlo folds all of it into the transpiler that already turns .phlo source into PHP: every <style> and <script> block across the app compiles straight into a shared bundle, by default one app.css and one app.js for the whole app, and that is the entire asset pipeline.

CSS without the preprocessor tax

<style>
.card {
    background: $surface
    border: 1px solid $border
    .card-title {
        color: $primary
    }
}
.card:hover: border-color: $primary
</style>

No semicolons, real nesting, a one-line form for a single declaration, and $name variables that resolve per active theme, compiled to real CSS custom properties. There is no runtime CSS-in-JS cost and nothing browser-side interprets this syntax, the transpiler has already done the work by the time it ships.

One bundle per namespace, not one per page

The default is a single app.css/app.js pair, but it is not a hardcoded rule: a <style> or <script> block can opt into a different namespace with ns=, and data/app.json controls the mapping. This site actually uses that: the main pages share app.css/app.js, but the syntax highlighter and the Presentation player each get their own bundle, so a heavier, less-frequently-loaded piece of code does not sit inside every page's default download. The point was never "exactly one file no matter what," it is that a page loads the one or two bundles its namespace actually needs, never a bespoke bundle assembled per page and never a dozen small stylesheets that can quietly drift out of sync with what a page uses.

Where the payoff shows up

Building once at build::run time and shipping a small, stable set of cacheable bundles is what falls out of not shipping a build tool zoo in the first place: no unused CSS from a component library that only needed three classes, no duplicate polyfills from mismatched bundler configs, no framework runtime to hydrate before the page is interactive. It is the same build whether the app is a five-route prototype or the fleet-managing Dashboard, because there is only one pipeline to have, tour.phlo.tech, an otherwise unmodified Phlo app, scores 100 out of 100 on Lighthouse's four audits running on exactly this pipeline.

Where to read more

The performance chapter in the guide covers the mechanics in more depth: how the CSS transpiler resolves variables per theme, the namespace/bundle model in the configuration chapter, and what the build actually produces under release/www/ for production.