Marko: PHP Framework neu gedacht

Magento's Extensibility-System ist gut. Wirklich. Preferences, Plugins, Events, Observer – du kannst jeden Teil des Systems anpassen, ohne eine Zeile Vendor-Code anzufassen. Das Problem ist, dass Magento dieses System in Tonnen von XML-Config, Codegenerierung und Cache-Inkompatibilitäten vergraben hat. Du verbringst mehr Zeit damit, das Framework zu beschwichtigen, als tatsächlich Code zu schreiben.

Mark Shust kennt dieses Gefühl, er kommt aus der Magento-Welt. Und er hat entschieden, das Extensibility-System rauszuziehen, alles drumherum wegzuwerfen und neu zu bauen. Das Ergebnis ist Marko.

Keine XML. Kein Magic. Kein Cache-Flush.

Konfiguration passiert in purem PHP mit nativen 8.5+ Attributen. Deine IDE versteht alles. Es gibt nichts zu generieren, nichts zu kompilieren, nichts zu flushen. Du schreibst Code, der Code läuft.

Das Modul-System funktioniert über drei Verzeichnisse in fester Priorität: app/ schlägt modules/ schlägt vendor/. Marko scannt automatisch, du legst ein Modul rein, fertig. Kein Service-Provider, den du irgendwo registrieren musst.

Die vier Kernfeatures

Preferences: Du tauschst eine Interface-Implementierung mit einem einzigen Attribut aus. #[Preference(replaces: FlatRate::class)] auf deine neue Klasse, und Marko weiß Bescheid. Fertig.

Plugins: Before- und After-Hooks auf jede Methode, ohne den Quellcode anzufassen. #[Before(method: 'place')] und du hängst dich vor eine Methode, die dir nicht gehört.

Events und Observers: Ein Event dispatchen, ein Observer reagiert, komplett entkoppelt. Klassisch, sauber.

Routing über Attribute direkt am Controller: #[Get('/products/{id}')]. Keine separate Router-Datei, keine Magie, deine IDE springt direkt hin.

Interface und Implementierung getrennt

Marko trennt das auf Package-Ebene. marko/cache ist nur der Contract. marko/cache-file ist File, marko/cache-redis ist Redis. Du codierst gegen das Interface. Willst du tauschen? Ein Binding in der module.php, null weitere Änderungen. Das gilt für Datenbank, Mail, Queue, Session, PubSub, Storage – überall.

Für 0.1.0 ist das Ökosystem dabei erstaunlich vollständig: über 70 Packages, Admin-Panel, Auth, SSE, Webhooks, Pest-Testing, ein Blog-Package, sogar eine Demo-App namens MarkoTalk als Real-time-Chat zum Abschauen.

Loud Errors

Das ist das Dritte, was Marko für sich beansprucht und was kein anderes Framework so explizit als Designprinzip behandelt. Kein stilles Scheitern. Jeder Fehler sagt dir was, wo und wie du es fixst. Klingt unspektakulär bis du das dritte Mal in einem Framework-Stack-Trace versunken bist ohne zu wissen wo dein Code überhaupt anfängt.

Vibe Coding

Marko hat einen echten strukturellen Vorteil wenn du mit AI-Agenten arbeitest, und der hat nichts mit Buzzwords zu tun.

Das Problem bei Vibe Coding auf komplexen Frameworks wie Magento ist nicht das Architekturwissen des Agenten, sondern die Anzahl der Schritte, die nichts mit Code zu tun haben. DI kompilieren. Cache leeren. Generierung anstoßen. Wenn dabei ein Fehler entsteht, der kryptisch ist, bricht der Feedback-Loop zusammen und der Agent dreht sich im Kreis.

Marko hat das nicht. Was du schreibst, läuft direkt. Der Agent schreibt ein Modul, du testest, du bekommst ein Ergebnis oder einen verständlichen Fehler zurück. Der Loop funktioniert.

Der Vorbehalt ist real: Marko ist kein Laravel. Es gibt kein riesiges Corpus aus dem ein Agent schöpfen kann. Du musst die Docs mitgeben, du musst das Pattern einmal erklären. Für erfahrene Vibe Coder ist das Routine. Für alle anderen erstmal eine Hürde.

Und jetzt?

Marko ist 0.1.0. Kein Produktiveinsatz, den du dir anschauen kannst, keine große Community, offene Frage ob das Projekt langfristig Fahrt aufnimmt.

Aber die Architektur hat eine Linie. Magento's Extensibility-System ohne den ganzen Ballast neu bauen. Das ist die Idee. Simpel. Und jemand hat sie endlich umgesetzt.

GitHub | Docs