devgine / web.

Warum eine eigene Engine

Frameworks lösen Probleme, die viele Projekte gar nicht haben — und bezahlen das mit Komplexität, Magie und Update-Zwang. devgine/web geht den anderen Weg: die PSR-Standards sauber selbst implementieren, alles Wesentliche mitbringen und dabei vollständig verständlich bleiben. Wer devgine liest, versteht, was passiert. Kein Layer, den niemand erklären kann.

So fühlt sie sich an

// Routen: explizit, benannt, ohne Magie
$router->get('/projekte/{slug}', [PageController::class, 'projekt'])
       ->name('projekte.show');

// Controller: Argumente kommen aus Route und Container
public function projekt(string $slug): ResponseInterface
{
    return $this->responder->make('pages.projekt', [...]);
}

// Views: reines PHP, Layouts, Komponenten mit gebündeltem CSS/JS
<?= $this->component(Alert::class, ['variant' => 'info'], 'Fertig.') ?>

Was drinsteckt

Qualität als Regel, nicht als Ziel

• PHPStan auf Level max — ohne Baseline

  Jeder Befund wird gefixt, nicht unterdrückt. Kein @, keine leeren catches, kein mixed, wo ein präziser Typ möglich ist.

• Tests für jede öffentliche API

  PHPUnit-Abdeckung ist Bedingung fürs Mergen — genau wie ein Guide-Kapitel mit lauffähigem Beispiel für jedes Feature.

• Strikte Konventionen

  PSR-12 via php-cs-fixer, strenges SemVer ab 0.x, Conventional Commits, Changelog im Keep-a-Changelog-Format.

• Security by default

  Auto-Escaping in Views, CSRF für alle state-changing Requests, nur parametrisiertes SQL, Krypto nur mit Standard-Primitiven.

Aus derselben Familie