Geen build tool zoo, één bundle per namespace in plaats van één per pagina.

Een moderne frontend build betekent meestal een bundler, een CSS preprocessor, een minifier en een configuratiebestand dat al deze drie coördineert. Phlo voegt dit allemaal samen in de transpiler die al .phlo broncode omzet in PHP: elke <style> en <script> blok in de app compileert standaard rechtstreeks in een gedeelde bundel, meestal één app.css en één app.js voor de hele app, en dat is de volledige asset pipeline.

CSS zonder de preprocessor belasting

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

Geen puntkomma's, echte nesting, een eenregelige vorm voor een enkele declaratie, en $name-variabelen die per actieve thema worden opgelost, gecompileerd naar echte CSS-custom properties. Er zijn geen runtime CSS-in-JS kosten en niets aan de browserzijde interpreteert deze syntaxis; de transpiler heeft het werk al gedaan tegen de tijd dat het wordt verzonden.

Eén bundel per namespace, niet één per pagina

De standaard is een enkele app.css/app.js-pair, maar het is geen hardcoded regel: een <style> of <script>-blok kan kiezen voor een andere namespace met ns=, en data/app.json beheert de mapping. Deze site gebruikt dat eigenlijk: de hoofdpagina's delen app.css/app.js, maar de syntax highlighter en de Presentation-speler krijgen elk hun eigen bundel, zodat een zwaarder, minder vaak geladen stuk code niet binnen elke pagina's standaarddownload zit. Het punt was nooit "exact één bestand, ongeacht wat," het is dat een pagina de een of twee bundels laadt die zijn namespace daadwerkelijk nodig heeft, nooit een op maat gemaakte bundel die per pagina is samengesteld en nooit een dozijn kleine stylesheets die stilletjes uit sync kunnen raken met wat een pagina gebruikt.

Waar de opbrengst zichtbaar wordt

Een keer bouwen tijdens build::run-tijd en het verzenden van een kleine, stabiele set cachebare bundels is wat voortkomt uit het niet verzenden van een build tool zoo in de eerste plaats: geen ongebruikte CSS van een componentbibliotheek die slechts drie klassen nodig had, geen dubbele polyfills van mismatched bundler-configuraties, geen framework-runtime om te hydrateren voordat de pagina interactief is. Het is dezelfde build, of de app nu een prototype met vijf routes is of het fleet-managing Dashboard, omdat er maar één pipeline is om te hebben; tour.phlo.tech, een anders ongewijzigde Phlo-app, scoort 100 uit 100 op de vier audits van Lighthouse die precies op deze pipeline draaien.

Waar je meer kunt lezen

Het prestatiehoofdstuk in de gids behandelt de mechanica in meer detail: hoe de CSS-transpiler variabelen per thema oplost, het namespace/bundelmodel in het configuratiehoofdstuk, en wat de build daadwerkelijk produceert onder release/www/ voor productie.