Wer ‚microPHP manifesto‘ googelt, bekommt einen guten Eindruck davon, wie Ed Finklers microPHP-Manifest angekommen ist. Zwar ist die Trefferzahl im Moment noch nicht unbedingt extrem; aber das Manifest ist ja auch noch jung und Finkler hat offensichtlich vielen aus der Seele gesprochen. Das einfache, direkte, spontane, der Packen-wirs-an-Ansatz von PHP, das ist es, was viele an PHP mögen und was fantastische Projekte hervorgebracht hat. Die Gegenbeispiele wirken wie in endlosen Meetings entworfen, alles muss irgendwie rein, an jeder Ecke lauert Berater-Sprech. Und hier sagt endlich mal einer, was für ein Mist das ist.

Als abschreckendes Beispiel eines aus dem Ruder gelaufenen Frameworks nennt Ed Finkler Zend. Und das kurze Code-Snippet, das er zitiert, ist wirklich gräßlich. Ich habe mich schon öfters gefragt, warum Entwickler sich dazu entschlossen haben, sich in Zend einzuarbeiten — Weil sie es mussten? Weil es — dank Anwendungen wie Magento — so erfolgreich ist? Dass jemand durch Zend-Beispiele blättert und spontan überzeugt ist, kann ich mir jedenfalls kaum vorstellen. Das ganze sieht eher aus wie der Versuch, mit einem PHP-Framework PHP möglichst unsichtbar zu machen und das auch noch auf scheußlichste Art. Als würde man alles tun, um PHP zu überwinden, nur um zu zeigen, dass dabei nur hässliches rauskommen kann. Wie kann man sich das nur antun: „…when I see it, I have a visceral negative reaction … I can’t do it. I don’t want it.“

Wenn das nötig sein sollte, um mit PHP größere Applikationen zu schreiben, dann ist PHP nicht die richtige Wahl, dann zeigt sich daran, dass PHP für solche Projekte ungeeignet ist.

Ich will jetzt hier nicht das übliche PHP-Bashing mitmachen; aber wenn es wirklich nicht anders zu machen ist, als auf die Zend-Art, dann sollte man über Alternativen nachdenken. Mich erinnert das an meinen ersten Kontakt mit frühen JavaEE-Versionen. Auch da war meine erste Reaktion: Das ist ja furchtbar, das kann doch alles nicht sein! Und tatsächlich ging es anderen genauso und JavaEE bekam Konkurrenz durch das enorm erfolgreiche Spring. Spring zeigte, wie es auch geht und das lässt hoffen, dass es auch in PHP anders geht.

Nach dem Lesen des Manifests hab ich mir deshalb einige der von Finkler genannten Frameworks angesehen. (Eine Sammlung gibt es hier.)
Epiphany war das erste – und ich war gleich überzeugt. Fast jedenfalls. Nur dreizehn Dateien, vieles drin, alles übersichtlich und super, aber: irgendwas fehlt, irgendwas war nicht so, wie ich es mir wünschen würde. Das galt auch für die anderen Kandidaten, die ich mir angesehen habe. Alle realisierten gute Ideen und wirkten sofort sympathisch. (Kann man das bei Software eigentlich sagen?) Je länger ich aber im Code herumgeblättert hatte, desto deutlich wurde:

Mir war eigentlich gar nicht klar, was ich von einem guten (micro-) Framework erwarte, welche Kriterien es eigentlich erfüllen sollte.

Irgendein Detail toll finden ist das eine; aber hab ich eigentlich eine Vorstellung von einem Framework als ganzem? Finkler gibt da keine Antwort und man kann ihm da kaum einen Vorwurf machen; das Manifest muss das Problem von der hohen Warte aus sehen. Und deswegen wäre das nächste, was zu formulieren wäre, ein Bewertungskatalog für (micro-)Frameworks. Nichts abschließendes, keine auf ewig fixe Framework-Matrix. Vielmehr ein subjektiver Katalog von Kriterien und Features, orientiert an eigenen Entwicklungserfahrungen und -praktiken, der es erlaubt, über Sympathie hinauszugehen.

Wie sähe ein (micro-)Framework aus, mit dem ich so arbeiten könnte, wie ich es gewohnt bin und mag? Mit dem ich schnell zu guten, wartbaren Ergebnissen komme und das sich an PHP orientiert, nicht die Sprache verleugnet, als würde man eigentlich lieber in einer anderen Sprache programmieren?

Ich habe mich mal daran gemacht, Kriterien zu notieren. Mal sehen, was daraus wird.