Warum dein nächstes Projekt auf PHP laufen wird

Wer heute PHP erwähnt, erntet oft ein müdes Lächeln. Viele Entwickler verbinden die Sprache mit manuellen FTP-Uploads und veralteten WordPress-Installationen. Dieser Ruf entspricht nicht mehr der Realität. Moderne PHP-Projekte nutzen Container, strikte Typisierung und hochperformante Application Server. Wir schauen uns an, was sich im Ökosystem getan hat und warum PHP eine starke Wahl für aktuelle Webanwendungen ist.

Basiert auf “Warum dein nächstes Projekt auf PHP laufen wird” von morice.live. Das Original findest du hier: https://morice.live/your-next-project-will-run-on-php

Executive Summary (TL;DR)

• In-Memory Performance: Moderne Tools wie FrankenPHP halten PHP-Applikationen im Arbeitsspeicher (Worker-Mode) und eliminieren teure Boot-Zeiten pro Request.
• Modulare Monolithen: Anstelle von Microservice-Chaos setzt PHP erfolgreich auf strukturierte, domain-getriebene Monolithen in einem Repository (ideal für KI-Analysen).
• Strikte Laufzeit-Typisierung: Im Gegensatz zu TypeScripts “Compile-Time-Only” Prüfung fängt PHP fehlerhafte Typen sofort zur Laufzeit ab.
• Standardisierung: Etablierte Framework-Strukturen (Symfony/Laravel) bieten LLMs perfekte Trainingsdaten für hochpräzise Code-Generierung.

Deployment ohne Altlasten

Der klassische LAMP-Stack aus Linux, Apache, MySQL und PHP wird kaum noch für neue Projekte genutzt. Lange Zeit war die Trennung von Nginx und PHP-FPM der Standard für bessere Performance. Das erforderte aufwendige Konfigurationen und Berechtigungsmanagement.

Tools wie FrankenPHP vereinfachen diesen Prozess heute grundlegend. FrankenPHP ist ein in Go geschriebener Webserver. Er integriert PHP direkt und macht zusätzliche Verbindungsstücke überflüssig. Die gesamte Anwendung kann als eine ausführbare Datei bereitgestellt werden.

Besonders relevant ist der integrierte Worker-Modus. Die Anwendung wird nur einmal gestartet und bleibt im Arbeitsspeicher aktiv. Das erspart den Neustart des Frameworks bei jeder Anfrage und steigert die Geschwindigkeit enorm.

Beispiel: Ein typisches Worker-Skript lädt das Framework einmalig in den Arbeitsspeicher.

<?php
// worker.php
require __DIR__.'/vendor/autoload.php';

// Framework/App wird nur EINMAL gebootet (In-Memory)
$app = new \App\Kernel();
$app->boot();

// Endlose Event-Schleife: Verarbeitet blitzschnell Requests, ohne neu zu booten
while ($request = \frankenphp_handle_request()) {
    $response = $app->handle($request);
    $response->send();
    $app->terminate($request, $response);
}

Die Rückkehr des Monolithen

Lange Zeit galten Monolithen als unwartbar und Microservices als die logische Lösung für wachsende Anwendungen. Inzwischen erkennen Teams die gravierenden Nachteile verteilter Systeme. Latenzen im Netzwerk und aufwendiges Debugging bremsen die Entwicklung.

Der modulare Monolith bietet hier einen strukturierten Ausweg. Dabei bleibt der gesamte Code in einem einzigen Repository. Die internen Strukturen werden strikt in fachliche Domänen getrennt. Diese Module kommunizieren über einfache Funktionsaufrufe anstatt über das Netzwerk.

Das reduziert die Komplexität und ermöglicht bei Bedarf später die Auslagerung in separate Dienste. Frameworks wie Symfony unterstützen diesen Ansatz perfekt, da sie aus entkoppelten Komponenten bestehen. Entwickler setzen nur die Bausteine ein, die sie wirklich brauchen.

Vorteile für die KI-gestützte Entwicklung

Ein zentrales Repository hat einen weiteren wichtigen Nutzen: KI-Agenten arbeiten effizienter, wenn sie den kompletten Codebestand lokal durchsuchen und analysieren können. Bei verteilten Microservices fehlt den Modellen oft der nötige Systemkontext.

Zusätzlich basieren Frameworks wie Laravel und Symfony auf etablierten Konventionen und einer mächtigen Kommandozeile. Diese festen Strukturen sind in den Trainingsdaten der Sprachmodelle extrem gut repräsentiert. Dadurch generieren Agenten sehr treffsicheren und standardkonformen Code.

Sicherheit durch echte Typisierung

Ein wesentlicher Unterschied zwischen modernem PHP und TypeScript liegt in der Typensicherheit.

• TypeScript prüft Typen nur zur Compile-Zeit. Zur Laufzeit bleibt davon reines JavaScript übrig, das falsche Datentypen nicht selbstständig abfängt. Entwickler müssen für die Laufzeitprüfung separate Validierungsbibliotheken einbinden.
• PHP prüft die Typen direkt zur Laufzeit. Ein falscher Datentyp löst sofort einen Fehler aus und stoppt die Ausführung.

Ergänzt wird dies durch Werkzeuge wie PHPStan für die statische Codeanalyse. Diese Tools scannen den Code vor der Ausführung und erkennen strukturelle Fehler präzise. Entwickler passen die Strenge dieser Prüfungen stufenweise an ihr jeweiliges Projekt an.

Dieses konkrete Code-Beispiel zeigt den Unterschied in der System-Sicherheit bei unvalidierten Daten (z.B. aus einer API):

// --- TypeScript (Compile-Time) ---
function calculateTotal(price: number): number {
    return price * 1.19; 
}

const payload = "100"; // String (aus unvalidiertem JSON)
// Der Compiler schützt uns hier nicht, wenn wir 'any' casten oder JSON parsen.
// JavaScript führt es zur Laufzeit aus und erzwingt durch Type-Coercion ein Ergebnis.
calculateTotal(payload as any); 

// --- PHP (Run-Time) ---
declare(strict_types=1);

function calculateTotal(float $price): float {
    return $price * 1.19;
}

$payload = "100"; // String
// PHP schützt die Applikation aktiv und wirft SOFORT einen Fehler zur Laufzeit:
// Fatal error: Uncaught TypeError: calculateTotal(): Argument #1 ($price) must be of type float, string given
calculateTotal($payload);