Ein Rundgang durch das Web-Museum

Wenn man heute auf Tech-Events, in Coworking-Spaces oder in Entwicklerforen über Webhosting spricht, dauert es meist nicht lange, bis dieser Blick kommt.

„Ach, LAMP? Linux, Apache, MySQL, PHP? Das ist doch Web-Museum.“

Stimmt. Willkommen im Web-Museum!

Aber vielleicht stehen dort nicht nur verstaubte Exponate herum. Vielleicht liegen dort auch ein paar Werkzeuge, die deshalb so lange überlebt haben, weil sie zuverlässig funktionieren. Auch dann, wenn der Hype weitergezogen ist.

In Episode 161 des goneo Webmacher Podcasts geht es genau darum: Brauchst du für dein Webprojekt wirklich React, Next.js, Vite, Supabase, serverless Functions, Edge Rendering und eine Build-Pipeline, die sich anfühlt wie ein kleines Raumfahrtprogramm?

Oder reicht für sehr viele Projekte etwas deutlich Bodenständigeres: ein solides Backend, semantisches HTML, PHP, MySQL, ein verlässlicher Webspace und ein Setup, das nicht bei jeder kleinen Änderung nach DevOps, Dependency-Management und Container-Orchestrierung ruft?

Kurz gesagt: Wir machen einen Rundgang durchs Web-Museum. Und stellen fest: Manche Ausstellungsstücke sind erstaunlich lebendig.

Saal 1: Die Vibe-Coding-Illusion

Starten wir im ersten Ausstellungsraum der Moderne. Hier stehen die aktuellen Lieblinge der Szene: Tools wie v0, Lovable oder Bolt.new.

Du gibst einen Prompt ein, wartest kurz, und schon entsteht eine schicke Oberfläche. Tailwind-Klassen, Icons, Animationen, Komponentenstruktur, dunkler Modus, Dashboard-Optik. Das fühlt sich beeindruckend an. Fast wie Magie.

Der Haken: Unter der Haube entsteht sehr häufig genau derselbe Stack. React-Komponenten, Vite oder Next.js, dazu irgendeine Cloud-Datenbank, häufig Supabase, plus ein ganzer Schwung npm-Pakete.

Das passiert nicht unbedingt, weil diese Architektur für dein konkretes Projekt die beste Wahl ist. Es passiert, weil Large Language Models aus dem schöpfen, worüber Entwicklerinnen und Entwickler in den letzten Jahren besonders viel geschrieben haben. Und über React, Next.js und moderne JavaScript-Toolchains wurde sehr viel geschrieben.

Für einen Prototypen ist das wunderbar. Für eine Demo sogar beeindruckend. Die ersten 70 Prozent wirken schnell, elegant und produktiv.

Dann kommt Tag zwei.

Plötzlich braucht das Projekt echte Geschäftslogik. Nutzerrechte. Rollen. Formulare, die nicht nur hübsch aussehen, sondern Daten sauber validieren. Fehlerbehandlung. E-Mail-Versand. Importfunktionen. Datenschutz. Backups. Zugriffskontrolle. Vielleicht sogar ein paar Sonderfälle aus dem echten Leben.

Und auf einmal steht da nicht mehr der schöne Prototyp. Da steht ein verteiltes System mit hunderten oder tausenden Abhängigkeiten, mehreren Diensten, Build-Prozessen, Secrets, API-Keys und einer Architektur, die gepflegt werden will.

Das ist der Moment, in dem aus „mal eben gebaut“ sehr schnell „wer betreibt das jetzt eigentlich zuverlässig?“ wird.

Saal 2: Das Performance-Märchen der Single-Page-App

Eines der großen Versprechen moderner JavaScript-Frameworks lautet: Single-Page-Applications sind schneller.

Das kann stimmen. Muss aber nicht.

Gerade auf leistungsstarken Entwickler-Laptops mit schnellem Netz sehen viele Anwendungen hervorragend aus. Die eigentliche Frage ist aber: Wie verhalten sie sich auf echten Geräten, in echten Netzen, bei echten Nutzerinnen und Nutzern?

Hier wird es spannend. Denn seit Google mit Core Web Vitals wie INP, also Interaction to Next Paint, die Reaktionsfähigkeit von Websites stärker bewertet, geraten viele moderne JavaScript-Architekturen unter Druck.

Das Problem hat einen Namen: Hydration.

Viele moderne Frameworks rendern zunächst HTML auf dem Server, damit Suchmaschinen und Browser schnell etwas sehen. Danach muss der Browser jedoch JavaScript herunterladen, parsen und ausführen. Anschließend wird die Komponentenlogik wieder mit dem bereits vorhandenen DOM verbunden.

Das ist technisch clever. Aber es kostet Zeit, Speicher und Rechenleistung. Besonders auf Smartphones.

Während der Browser damit beschäftigt ist, Megabytes an JavaScript zu verarbeiten, fühlt sich die Seite für Nutzerinnen und Nutzer unter Umständen träge an. Ein Button ist sichtbar, reagiert aber noch nicht. Ein Menü ist da, öffnet sich aber verzögert. Die Oberfläche sieht fertig aus, ist es aber noch nicht.

Ein klassisches PHP-Backend macht vieles einfacher: Der Server liefert HTML aus. Ein Link ist ein Link. Ein Formular ist ein Formular. Der Browser kann damit sofort umgehen. Für sehr viele Websites, Shops, Blogs, Portale und Unternehmensseiten ist das kein Rückschritt, sondern ein Vorteil.

Nicht spektakulär. Aber schnell, robust und verständlich.

Saal 3: Shared-Nothing statt Dauerzustand

Weiter geht es in die Maschinenhalle des Web-Museums. Dort steht ein Prinzip, das lange als altmodisch belächelt wurde: Shared-Nothing.

PHP-FPM arbeitet vereinfacht gesagt so: Ein Request kommt rein, ein Worker verarbeitet ihn, Speicher wird verwendet, die Antwort geht raus, der Request ist erledigt. Danach wird aufgeräumt.

Das klingt unspektakulär. Ist aber ein großer Stabilitätsvorteil.

Denn Fehler können sich nicht so leicht über viele Requests hinweg ansammeln. Wenn eine einzelne Anfrage Speicher belegt, wird dieser nach der Verarbeitung wieder freigegeben. Der nächste Request startet weitgehend frisch.

Bei langlebigen Node.js-Prozessen sieht das anders aus. Hier läuft ein Prozess dauerhaft. Wenn irgendwo Speicherreferenzen hängen bleiben, wenn ein Cache unkontrolliert wächst oder wenn eine Closure mehr festhält als gedacht, kann sich das über Stunden oder Tage aufschaukeln. Irgendwann greift im schlimmsten Fall der OOM-Killer des Betriebssystems ein. Der Container stirbt. Die Anwendung ist weg.

Auf Plattformen, die Micro-Instanzen regelmäßig neu starten, fällt das oft weniger auf. Wer solche Anwendungen aber selbst betreibt, merkt schnell: Betrieb ist ein eigenes Thema. Und zwar keines, das man nach dem ersten erfolgreichen Deploy einfach vergessen sollte.

Das heißt nicht, dass Node.js schlecht ist. Es heißt nur: Die Architektur bringt andere Betriebsrisiken mit. Und diese Risiken muss man kennen, wenn man ein Projekt langfristig zuverlässig betreiben will.

Saal 4: Die npm-Supply-Chain als Risikofaktor

Der nächste Saal ist nicht ganz so gemütlich. Hier geht es um Abhängigkeiten.

Das npm-Ökosystem ist riesig, lebendig und produktiv. Es ist aber auch ein attraktives Ziel für Angriffe. Je mehr Pakete ein Projekt einbindet, desto größer wird die Angriffsfläche. Besonders dann, wenn selbst Kleinigkeiten über externe Bibliotheken gelöst werden.

Natürlich gilt das nicht nur für JavaScript. Auch PHP, Python, Ruby oder andere Ökosysteme kennen Supply-Chain-Risiken. Aber im npm-Umfeld sind Paketketten oft besonders tief. Ein direkt eingebundenes Paket bringt weitere Pakete mit, diese wiederum weitere, und am Ende hängt ein Projekt an einer langen Kette von Maintainer-Accounts, Build-Skripten und Versionen.

Für Teams mit Security-Prozessen, Monitoring, Audits und klaren Update-Routinen ist das handhabbar. Für kleine Unternehmen, Vereine, Freelancer oder interne Projekte sieht die Sache anders aus.

Wenn ein Projekt eigentlich nur ein Kontaktformular, eine Produktseite, ein Login, ein kleines Portal oder ein redaktionelles System braucht, ist die Frage berechtigt: Muss dafür wirklich ein komplexer JavaScript-Stack mit massiver Dependency-Struktur her?

Oder reicht ein überschaubarer, bewährter Ansatz mit Server-Rendering, klarer Datenbankanbindung und möglichst wenigen beweglichen Teilen?

Saal 5: Choose Boring Technology

Dan McKinleys berühmter Grundsatz „Choose Boring Technology“ ist aktueller denn je.

Die Idee dahinter: Jedes Projekt hat nur ein begrenztes Budget für technische Experimente. Wer dieses Budget schon für Build-Systeme, Framework-Wechsel, Dependency-Konflikte, Hosting-Spezialfälle und Deployment-Pipelines verbraucht, hat weniger Energie für das eigentliche Produkt.

Für viele Webprojekte ist Technologie kein Selbstzweck. Die Website soll informieren, verkaufen, Leads generieren, Buchungen ermöglichen, Inhalte bereitstellen oder interne Abläufe vereinfachen.

Dafür braucht es nicht immer den neuesten Stack. Oft braucht es:

• kurze Ladezeiten
• zuverlässigen Betrieb
• einfache Wartung
• klare Datenstrukturen
• gute Auffindbarkeit
• Datenschutz
• bezahlbare Infrastruktur
• ein System, das auch nach zwei Jahren noch verstanden wird

Genau hier spielen klassische Hosting-Setups ihre Stärke aus. PHP, MySQL, Apache oder Nginx, WordPress, Joomla, TYPO3, Laravel, Symfony und ähnliche Werkzeuge sind nicht deshalb verbreitet, weil niemand etwas Neues kennt. Sie sind verbreitet, weil sie für viele Anwendungsfälle wirtschaftlich, stabil und gut betreibbar sind.

Das ist Pragmatismus.

Moderne Reaktivität ohne JavaScript-Overkill

Natürlich bedeutet das nicht, dass moderne Nutzererlebnisse tabu sind. Niemand möchte zurück zu schwerfälligen Formularseiten, bei denen jede Kleinigkeit einen kompletten Seitenwechsel auslöst.

Aber zwischen „gar keine Interaktivität“ und „alles als React-App“ liegt ein großer Bereich.

Werkzeuge wie HTMX, Symfony UX mit Turbo und Stimulus oder Laravel Livewire zeigen, dass sich moderne Bedienkonzepte auch mit serverseitigen Architekturen verbinden lassen. Viele Interaktionen lassen sich damit elegant lösen, ohne gleich die gesamte Anwendung in den Browser zu verlagern.

Das Ergebnis: weniger JavaScript, weniger Hydration-Overhead, weniger Abhängigkeiten und trotzdem eine Oberfläche, die sich modern anfühlt.

Für hochgradig interaktive Browser-Software wie Figma, komplexe Whiteboards, Echtzeit-Editoren oder sehr zustandsintensive Anwendungen ist React absolut nachvollziehbar. Dort spielt ein komponentenbasierter Frontend-Ansatz seine Stärken aus.

Aber für die meisten Webprojekte? Unternehmensseiten, Magazine, Blogs, Shops, Buchungssysteme, KMU-Portale, Vereinsseiten, Landingpages, interne Tools?

Da ist React oft nicht die Voraussetzung für Erfolg. Manchmal ist es sogar zusätzlicher Ballast.

Der LAMP-Stack ist nicht tot.
Er ist langweilig gut.

Vielleicht ist das die eigentliche Pointe unseres Rundgangs: Der LAMP-Stack wirkt nicht modern, weil er nicht ständig neu erklärt werden muss.

Linux, Apache, MySQL und PHP sind keine Tech-Show. Sie sind Infrastruktur. Sie laufen, sie sind verstanden, sie sind dokumentiert, sie sind bezahlbar und sie lassen sich auf klassischem Webspace zuverlässig betreiben.

Für viele Website-Betreiberinnen und Website-Betreiber ist genau das entscheidend. Nicht, ob der Stack auf der nächsten Konferenz Applaus bekommt. Sondern ob das Projekt schnell lädt, sicher läuft, gut auffindbar ist und ohne unnötigen Administrationsaufwand gepflegt werden kann.

Bei goneo gehört diese Art von pragmatischem Web seit vielen Jahren zum Alltag: Webhosting, PHP, MySQL, Domains, E-Mail, SSL und Server in Deutschland. Keine große Show, sondern eine verlässliche Grundlage für echte Webprojekte.

Und ja: Das darf man Web-Museum nennen.

Solange die Ausstellungsstücke funktionieren, schnell sind und ihre Aufgabe zuverlässig erfüllen, ist das gar kein schlechtes Museum.

Fazit: React ist ein Werkzeug, keine Pflicht

Die Frage lautet also nicht: Ist React gut oder schlecht?

Die bessere Frage lautet: Braucht dein Projekt React wirklich?

Wenn du eine komplexe, zustandsintensive Anwendung im Browser baust, kann React genau richtig sein. Wenn du ein Team hast, das diesen Stack sicher betreiben kann, spricht nichts dagegen.

Wenn du aber eine Website, ein Portal, einen Shop, ein Magazin oder ein solides KMU-System betreibst, lohnt sich ein nüchterner Blick. Vielleicht brauchst du keine maximale Frontend-Komplexität. Vielleicht brauchst du einfach eine stabile technische Basis, gute Performance, Datenschutz, klare Wartbarkeit und ein Setup, das auch ohne Spezialteam zuverlässig funktioniert.

Manchmal ist die beste Technologie nicht die aufregendste.

Manchmal ist sie einfach die, die läuft.

🎧 Mehr dazu gibt es in Episode 161 des goneo Webmacher Podcasts: „Brauchst du wirklich React? Ein Rundgang durch das Web-Museum“ auf social.goneo.de.