Single-Core: Wunschtraum, Praxisbremse
Der Gedanke ist alt: Ein Framework-Kern, alles drin, alles geregelt. Routing, Auth, Datenbank, Security, Frontend. Einmal sauber gebaut, muss nie wieder angefasst werden. Soweit die Theorie.
2026 sieht es anders aus. Die Projekte sind zu verschieden, die Anforderungen springen hin und her. Wer alles in einen Kern presst, bekommt am Ende ein System, das zwar vieles irgendwie kann, aber nichts davon richtig. Typisch: Der Routing-Teil wird zu generisch, Auth und Security hängen hinterher, Spezialfälle? Schwierig. Im eigenen C-Framework wurde das schmerzhaft schnell klar. Zwei neue Anforderungen und der Kern war schon wieder ein Minenfeld. Ein Fix an einer Stelle, zwei neue Fehler an anderer. Spaß macht das nicht.
Modularität: Nicht neu, aber endlich Standard
Was muss ein Framework heute abdecken? Routing, Middleware, Events – und das alles möglichst performant. Dazu Frontend-Kram: Webcomponents, SSR, vielleicht sogar Realtime. Sicherheit? Klar. Und alles erweiterbar, bitte. Das mit einem festen Kern? Funktioniert selten vernünftig.
Synchrones Design bremst asynchrone Prozesse aus – und umgekehrt ist die Lernkurve für viele zu steil. Im C-Projekt: Routing im Kern war schnell, aber sobald Auth oder DB reinmussten, wurde es wild. Modular getrennt lief es besser. Routing bleibt pures C, Auth ein extra Modul, DB-Zugriffe gekapselt. Fehler in einem Modul? Rest läuft weiter. Updates? Kein Stress. Feature-Wunsch? Modul dazu, fertig.
Praxis: C-Framework – Monolith raus, Module rein
Monolithische Frameworks altern schnell. Im C-Projekt erst alles im Kern gebaut, nach einem Jahr komplett refactored. Jetzt: Minimaler Routing-Kern, Rest als Modul. Middleware, Security, Datenbank – alles getrennt, einzeln tauschbar. Vorteil: Anpassungen kosten weniger Nerven, Übersicht bleibt. Bei Bedarf ein neues Modul rein, der Rest bleibt unberührt. Typisch für größere Projekte: Anforderungen ändern sich, Kunden wollen plötzlich SSO oder OAuth. Mit Modulen kein Problem. Im Monolith? Viel Spaß beim Debuggen.
Was heißt das für Agenturen und Selbstständige?
Ein fester Kern sieht am Anfang schlank aus, spart aber selten wirklich Zeit. Modular kostet am Anfang etwas mehr Denkarbeit, zahlt sich aber schnell aus. Agenturen mit mehreren Projekten merken das sofort: Ein Modul für Auth, eins für DB, eins für Payment – nicht überall das Rad neu erfinden. Updates? Nur das betroffene Modul testen, nicht das ganze System. Freelancer können gezielt nur die Module einbauen, die ein Kunde braucht. Kein Ballast, kein Kern-Monster, schneller am Ziel.
Fast 30 Jahre Webentwicklung: Mein Fazit
Nach etlichen Relaunches, Updates und einigen durchgebrannten Nächten: Monolithen sind Wartungsfallen. Modularität ist nicht hübsch, aber praktisch. Im C-Projekt war es am Ende egal, wie schick der Kern war – sobald Routing, Auth, DB getrennt waren, lief es besser. Performance-Probleme lassen sich gezielt angehen, ein kaputtes Modul reißt nicht das ganze System runter.
Für Agenturen mit 5–10 Entwicklern: Weniger Angst vor Updates, schneller Features nachliefern, weniger Stunden im Debugging-Sumpf. Wer allein arbeitet, muss nicht jede Framework-Marotte ausbaden. Lieber kleine Module, schnell gewechselt, verstanden und verbessert.
Modular? Ja, aber nicht im Klein-Klein ersticken
Klar: Mehr Module, mehr Schnittstellen, mehr Überblick nötig. Wer es übertreibt, verliert sich in Mini-Bibliotheken. Für kleine Projekte reicht manchmal ein solider Kern. Aber sobald die Anforderungen wachsen oder ein Kunde „nur noch eine Kleinigkeit“ will, ist modular die bessere Versicherung. Die Monolith-Idee hat ihren Reiz – in der Praxis selten durchgehalten.
Fazit: Single-Core ist tot, modular lebt
Der Traum vom perfekten Framework-Kern ist 2026 durch. Jedes Projekt bringt neue Anforderungen, kein Kern kann alles elegant lösen. Besser: Klare Schnittstellen, gezielte Module, die sich bei Bedarf tauschen lassen. Keine Angst vor ein bisschen mehr Struktur, das spart am Ende Stunden.
Pragmatische Empfehlung:
- Kein Framework mit allem im Kern kaufen
- Modularen Aufbau bevorzugen
- Nur die Module nutzen, die wirklich gebraucht werden
Wer das beherzigt, bleibt flexibler und hat weniger Ärger mit Updates. Neue Anforderungen? Modul dazu, keine Kernsanierung.
Diskussionen und Erfahrungsberichte dazu im Forum: Back to Basics: Warum 2026 klassische PHP-Architektur in vielen Webprojekten wieder vorne liegt und Klassisches PHP oder Framework? Alltagstest 2026.
Wer sich von Monolithen trennt, spart 2026 Zeit, Nerven und graue Haare.
bye
mo