Warum Laravel?

Hinweis: Dies ist ein technischer Beitrag.

Nachdem ich Monica auf Hacker News vorgestellt hatte, erreichten mich viele Fragen, warum ich das Werkzeug mit PHP und insbesondere mit Laravel geschrieben habe. Ich war überrascht, dass es so viele Fragen dazu gab, denn ich finde, die Sprache spielt keine Rolle. Es zählt nur, was man damit macht.

In diesem Beitrag erkläre ich, warum ich PHP und Laravel gewählt habe und welche Schwierigkeiten ich beim Bau der ersten Version überwinden musste. Der Text soll keinen Krieg zwischen Sprachen anzetteln.

PHP hat eine interessante Geschichte. Viele großartige Webentwickler, die PHP heute vermutlich nicht mehr nutzen, haben damit die Grundlagen des Programmierens gelernt. Es war so einfach zu benutzen und einzusteigen, und obwohl es keine elegante Sprache war, ebnete es den Weg für Karrieren in der Webentwicklung. Mit der Zeit wurde PHP dann weniger geliebt, bis es fast schon peinlich war, PHP zu verwenden oder auf einem Meetup zu sagen, dass die eigene Firma es einsetzt. Andere, wohl elegantere Sprachen gewannen dank großartiger Frameworks stark an Beliebtheit (Python, Ruby). Zugleich erschienen neue PHP-Frameworks, Symfony zum Beispiel. Doch Symfony war weiterhin schwer zu erlernen und zu benutzen. Und dann starb PHP. So hieß es jedenfalls, wobei offenbar ignoriert wurde, dass sehr viele Unternehmen es weiterhin einsetzten und schätzten. Dann kam PHP 5.5, gefolgt von PHP 7, und ein neues Framework mit einem seltsamen Namen tauchte auf: Laravel. Und die Einstellung der Leute änderte sich vollständig. PHP ist immer noch nicht so elegant wie andere beliebte Sprachen, aber vieles ist deutlich besser geworden. Und schnell ist es obendrein.

Trotzdem ist PHP nach wie vor die Sprache, die man liebend gern hasst, besonders auf Hacker News. Es heißt, PHP skaliere nicht. Vermutlich deshalb setzen Facebook und Mailchimp, neben anderen großen Namen, heute PHP ein, und zwar in großem Maßstab.

Warum habe ich mit diesem Hintergrund PHP und Laravel gewählt?

• PHP ist leicht zu lernen und leicht zu benutzen.
• Es gibt viele PHP-Entwickler, und wenn Menschen mit mir am Projekt arbeiten wollen, ist der mögliche Pool an PHP-Entwicklern zumindest dort, wo ich lebe, größer als der an Ruby- oder Python-Entwicklern. Außerdem nutzen viele Leute auf GitHub PHP, und wenn dieses Open-Source-Projekt Zuspruch finden sollte, musste ich es in einer Sprache schreiben, in der Menschen mit ganz unterschiedlichem Kenntnisstand leicht beitragen können.
• Das Wichtigste bei der Wahl eines Technologie-Stacks für ein neues Projekt ist, wie leicht es sich auf lange Sicht warten lässt. PHP ist einfach. Es ist leicht zu debuggen (auch wenn das besser sein könnte) und leicht zu skalieren (auch wenn das derzeit überhaupt nicht mein Thema ist).
• Laravel ist mit Abstand das beste PHP-Framework, das ich je benutzt habe. Es macht komplexe Dinge sehr einfach. Man merkt, dass es entworfen wurde, um neue Webanwendungen wirklich schnell zu starten, und es macht große Freude. Seine herausragende Stärke ist jedoch die Qualität der Dokumentation, verglichen mit anderen PHP-Frameworks und sogar mit vielen Frameworks anderer Sprachen. Alles ist ausgesprochen gut dokumentiert. Ich kann gar nicht genug betonen, wie wichtig gute Dokumentation ist (was mich daran erinnert, dass ich Monica noch besser dokumentieren sollte).
• Rund um PHP und besonders Laravel gibt es eine riesige Gemeinschaft: Laracasts, Forge, Envoyer und eine starke Slack-Gemeinschaft, um nur einige zu nennen. Wenn Sie Hilfe brauchen, stehen viele Menschen bereit.

Welche Herausforderungen hatte ich bei der Entwicklung dieses Projekts?

Insgesamt hatte ich bei der Entwicklung der aktuellen Version von Monica nicht allzu viele Herausforderungen. Es ist keine komplexe Anwendung, und ich habe keine Skalierungsprobleme, da die Nutzerbasis noch recht klein ist (rund 7800 Nutzer insgesamt, 4300 aktive). Doch es gibt Umsetzungsdetails, die ich falsch gemacht habe. Nicht, weil es schlechte Praxis war, sondern weil meine technischen Fähigkeiten nicht ausreichten, um diese Probleme kurzfristig zu lösen. Hoffentlich hilft diese Liste anderen, die Fehler nicht zu wiederholen, oder nette Menschen schreiben mir, wie ich sie hätte beheben können.

• In früheren Versionen habe ich viele Events und Listener benutzt. Das Konzept ist großartig, doch wegen ihnen hatte ich große Probleme beim Unit-Testen der Basisklassen. Zudem geschah, je mehr ich sie einsetzte, umso mehr Magie im Hintergrund. Ich dachte, wer in die Codebasis einsteigt, würde sich schwertun zu verstehen, warum beim Erzeugen eines Objekts bestimmte Dinge passieren. Aus meiner Sicht machten Events und Listener die Anwendung schwerer verständlich, also habe ich sie alle entfernt (nun ja, 99 Prozent davon, zwei Listener muss ich noch loswerden).
• Anfangs war die Datenbank vollständig verschlüsselt. Aus Gründen, die ich bis heute nicht verstehe, gab es hin und wieder Fehler beim Entschlüsseln, was zu Daten führte, die ich nicht wiederherstellen konnte. Da ich mich zu diesem Zeitpunkt nicht damit befassen wollte, habe ich die Verschlüsselung entfernt. Außerdem machten verschlüsselte Daten jede Art von Sortierung oder Suche in meinen Abfragen unmöglich, was auf Dauer problematisch geworden wäre. Sicher gibt es Lösungen für beide Probleme, aber ich wollte mich auf neue Funktionen konzentrieren, statt dieses eine Problem zu lösen.
• Ich habe vor dem Start der Anwendung keine Unit-Tests geschrieben. Das hat sich bitter gerächt. Ich glaube nicht, dass wir 100 Prozent Testabdeckung anstreben sollten, aber zumindest sollte es Tests für die Hauptfunktionen der Seite geben. Sonst landet man bei einem Berg von Fehlern, an die man nie gedacht hat, und während man sie behebt, sind andere Teile der Anwendung von der Korrektur betroffen. Das wird schnell zum Albtraum. Laravel macht Unit-Tests sehr einfach. Ich hätte das ernster nehmen sollen. Ab der nächsten Version wird kein Pull Request mehr übernommen, wenn keine Unit-Tests und vielleicht sogar funktionale Tests dabei sind.

Fazit

Das sind einige Gründe, warum ich Laravel gewählt habe. Wie eingangs gesagt: Bei Ihrem Projekt geht es nicht um die Sprache. Sofern es in Ihrem Projekt nicht gerade darum geht, eine neue Sprache zu lernen, sollten Sie keine Wochen mit der Wahl einer Sprache oder eines Frameworks verbringen. Bleiben Sie bei dem, was Sie kennen, und bauen Sie einfach etwas. Ihren Nutzern ist es egal, ob Ihr Code hässlich ist oder ob Sie Python statt Ruby gewählt haben.