Build-Tools: Komfort, aber schnell zu viel davon
Webpack, Vite, Rollup – 2026 in fast jedem Agenturprojekt. Kaum ein Launch ohne die übliche Build-Tool-Kette. Anfangs praktisch: Module, Autoreload, alles schick. Dann wächst der Stapel. Bundles werden fett, der Kram wird langsam. Server können noch so schnell sein, die Toolchain hält trotzdem auf. Fehler? Viel Spaß beim Debugging, wenn npm mal wieder spinnt oder irgendein Plugin zickt.
Kleine Seiten, wenig JS? Da fragt man sich oft: Muss das wirklich sein? Oder reicht nicht auch einfach mal PHP mit ein bisschen nativem JS?
Wann machen Build-Tools die Sachen langsamer?
Build-Tools bringen Kompatibilität, klar. Aber halt auch viel Ballast. Aus Agentursicht tauchen immer dieselben Bremser auf:
- Polyfills, die kein Mensch mehr braucht, aber trotzdem mitgeschleppt werden
- Bundles mit Features, die im Projekt überhaupt nicht vorkommen
- Source-Maps und Dev-Kram landen aus Versehen auf dem Server – schon wieder 400 KB mehr
- Jeder Mini-Fix dauert, weil die Pipeline erst mal durchrödeln muss
Besonders bei klassischen Multi-Page-Seiten oder einfachen Landingpages merkt man’s direkt. Aus einem simplen Projekt wird eine Wartungsbaustelle. Toolchain läuft, aber keiner weiß mehr, warum eigentlich.
Minimalismus: PHP & Vanilla JS reichen oft locker
Wer einfach PHP raushaut und nur das nötigste JS dazupackt, schont Nerven. Kein Node.js, kein npm-Gewurschtel. Ergebnis:
- Zwei, drei schlanke JS-Dateien, keine 250-KB-Bundles
- Debugging? Geht direkt im Browser, kein Transpiling-Zirkus
- Mobilgeräte freuen sich, weil weniger geladen werden muss
- Weniger externe Tools, weniger Update-Panik
Gerade bei Verzeichnissen, Infoportalen oder schnörkellosen CMS-Projekten ist das meistens die bessere Wahl. Frameworks landen oft nur drin, weil „man das jetzt so macht“. Das reicht selten als Grund.
Praxisfälle: Von React zurück zu Basics
Beispiel aus dem Alltag: Branchenverzeichnis, ursprünglich mit React. Nach sechs Monaten Frust zurück auf PHP und pures JS. Ergebnis:
- JavaScript schrumpft von 250 KB auf 45 KB
- Mobil lädt die Seite rund ein Drittel schneller
- Bugs lassen sich fixen, ohne den Build neu zu erfinden
Ähnlich in einem SaaS-Projekt mit React/Babel. Die Maintenance war ein einziges Drama. Erst nach Rückbau auf PHP-Templates plus etwas Vanilla JS wurde das Ganze wieder wartbar – und die Ladezeit war plötzlich kein Thema mehr.
Muster: Wer weniger dranbaut, hat weniger Stress. Trends helfen selten, wenn der Use Case nicht passt.
Meine Einschätzung nach fast 30 Jahren Webentwicklung
Seit Ende der 90er kommen Toolchains und Frameworks im Sechsmonatstakt. Wer alles mitnimmt, hat irgendwann keinen Überblick mehr. Klar, Build-Tools machen Sinn – zum Beispiel bei riesigen SPAs oder wenn viele Komponenten wiederverwendet werden. Aber im Alltag? Bei Agenturen mit 5–10 Leuten oder Solo-Projekten? Da killt Komplexität einfach den Spaß. Updates dauern ewig, Onboarding wird zur Geduldsprobe, Hosting wird teurer. Meist läuft’s mit PHP und einfachem JS einfach ruhiger. Weniger Fehler, weniger Zeitverlust, und Kunden beschweren sich seltener über Ladezeiten.
Wo Build-Tools trotzdem Pflicht sind
Richtig groß wird’s nur bei Single-Page-Apps, massiven UI-Bibliotheken oder wenn externe Module wild durcheinanderfliegen. Da kommt man an Bundlern nicht vorbei. Aber auch dann: Bloß nicht alles einbauen, was geht. Sonst wird die Toolchain schnell zum Projekt an sich.
Weiterlesen
Wem klassische PHP-Architektur lieber ist: Back to Basics: Klassische PHP-Architektur 2026 – oft der pragmatischere Weg.
Oder ganz pragmatisch: PHP mit etwas JS: Wieso Agenturen 2026 meist keinen Framework-Zirkus brauchen.
Kurz: Weniger Tooling, weniger Stress
2026 gilt: Wer nicht gerade eine SPA oder ein Framework-Monster baut, fährt mit PHP und ein bisschen JS oft besser. Schneller, einfacher, billiger. Die Toolchain muss zum Problem passen – sonst schafft sie nur neue.
bye
mo