Waarom Laravel?

Let op: dit is een technisch bericht.

Nadat ik Monica op Hacker News had gelanceerd, kreeg ik veel vragen over waarom ik het hulpmiddel in PHP en met name in Laravel heb geschreven. Ik was eerlijk gezegd verbaasd over zoveel vragen hierover, want ik vind dat een taal er niet toe doet: alleen wat je ermee doet telt.

In dit bericht vertel ik waarom ik voor PHP en Laravel heb gekozen en welke moeilijkheden ik moest overwinnen om de eerste versie van het product te bouwen. Dit bericht is niet bedoeld om een oorlog tussen talen te beginnen.

PHP heeft een interessante geschiedenis. Veel goede webontwikkelaars, die waarschijnlijk allang geen PHP meer gebruiken, hebben er de beginselen van het programmeren mee geleerd. Het was zo eenvoudig om te gebruiken en om mee te beginnen, en hoewel het geen elegante taal was, effende het de weg naar een carrière in webontwikkeling. Daarna werd PHP steeds minder geliefd, tot het punt dat het bijna gênant was om PHP te gebruiken of zelfs maar op meetups te zeggen dat je bedrijf het gebruikte. Andere talen, aantoonbaar eleganter, werden erg populair (Python, Ruby) dankzij prachtige frameworks die erop gebouwd werden. Tegelijkertijd verschenen er nieuwe PHP-frameworks. Symfony bijvoorbeeld. Maar Symfony was nog steeds lastig te leren en te gebruiken. En toen stierf PHP. Dat zeiden mensen althans, en ze negeerden daarbij blijkbaar dat heel veel bedrijven het nog steeds gebruikten en er dol op waren. Toen kwam PHP 5.5, gevolgd door PHP 7, en verscheen er een nieuw framework met een rare naam: Laravel. En het beeld dat mensen hadden veranderde volledig. PHP is nog steeds niet zo elegant als andere populaire talen, maar het is er veel op vooruitgegaan. En het werd ook snel.

Toch blijft PHP de taal die mensen graag haten, vooral op Hacker News. Ze zeggen dat PHP niet schaalt. Dat zal wel de reden zijn dat Facebook en Mailchimp, onder andere grote namen, PHP vandaag op enorme schaal gebruiken.

Waarom heb ik met die achtergrond voor PHP en Laravel gekozen?

• PHP is eenvoudig te leren en eenvoudig te gebruiken.
• Er zijn heel veel PHP-ontwikkelaars, en als mensen met mij aan het project willen werken is de vijver aan PHP-ontwikkelaars, in elk geval waar ik woon, groter dan die aan Ruby- of Python-ontwikkelaars. Bovendien gebruiken veel mensen op GitHub PHP, en als ik wilde dat dit open source project ergens zou aanslaan, moest ik het schrijven in een taal waarin mensen van heel verschillend niveau makkelijk konden bijdragen.
• Het belangrijkste bij het kiezen van een technische basis voor een nieuw project is hoe makkelijk het op de lange termijn te onderhouden zal zijn. PHP is eenvoudig. Het is makkelijk te debuggen (al kon dat beter) en makkelijk te schalen (al is dat op dit moment totaal mijn zorg niet).
• Laravel is verreweg het beste PHP-framework dat ik ooit heb gebruikt. Het maakt ingewikkelde dingen zo eenvoudig. Het is duidelijk dat het framework is gemaakt om heel snel nieuwe webapplicaties te beginnen, en het is echt een genot om mee te werken. Maar de sterkste eigenschap van Laravel is de kwaliteit van de documentatie, vergeleken met andere PHP-frameworks en zelfs met veel frameworks in andere talen. Alles is uitstekend gedocumenteerd. Ik kan niet genoeg benadrukken hoe belangrijk goede documentatie is (wat me eraan herinnert dat ik Monica nog beter zou moeten documenteren).
• Er is een enorme gemeenschap rond PHP en Laravel in het bijzonder: Laracasts, Forge, Envoyer en een sterke Slack-gemeenschap, om er een paar te noemen. Heb je hulp nodig, dan staan er veel mensen klaar om die te geven.

Welke uitdagingen kwam ik tegen tijdens dit project?

Al met al liep ik tijdens het bouwen van de huidige versie van Monica niet tegen zoveel uitdagingen aan. Het is geen ingewikkelde applicatie, en ik heb geen schaalproblemen omdat het aantal gebruikers nog vrij klein is (ongeveer 7800 gebruikers in totaal en 4300 actief). Maar er zijn wel wat implementatiekeuzes die ik verkeerd heb gemaakt, niet omdat het slechte programmeergewoontes waren, maar omdat mijn technische vaardigheden op dat moment niet goed genoeg waren om die problemen snel op te lossen. Hopelijk helpt het opsommen van die fouten anderen ze te vermijden, of sturen aardige mensen me een mail over hoe ik ze had kunnen oplossen.

• In eerdere versies gebruikte ik veel events en listeners. Het concept is prachtig, maar ik had er veel problemen mee bij het unittesten van de basisklassen. Bovendien gebeurde er, hoe meer ik ze gebruikte, hoe meer magie achter de schermen. Ik dacht dat mensen die in de code doken moeite zouden hebben te begrijpen waarom sommige dingen gebeurden zodra er bijvoorbeeld een object werd aangemaakt. In mijn hoofd maakten events en listeners de applicatie moeilijker te begrijpen, dus besloot ik ze allemaal te verwijderen (nou ja, 99% ervan, er zijn nog twee listeners waar ik vanaf moet).
• In het begin was de database volledig versleuteld. Om redenen die ik nog steeds niet begrijp gingen er af en toe dingen mis bij het ontsleutelen, wat leidde tot gegevens die ik niet kon herstellen. Omdat ik dat probleem in dit stadium niet wilde oplossen, besloot ik de versleuteling te verwijderen. Daar kwam bij dat versleutelde gegevens het onmogelijk maakten om in mijn queries te sorteren of te zoeken, wat op de lange termijn lastig had kunnen worden. Er zijn vast oplossingen voor deze twee problemen, maar ik wilde me richten op het maken van nieuwe functies in plaats van op dat ene probleem.
• Ik heb geen unittests geschreven voordat ik de applicatie lanceerde. Dat heeft me flink pijn gedaan. Ik denk niet dat we naar 100% testdekking moeten streven, maar zorg op zijn minst voor enige tests voor de belangrijkste functies van je site. Anders eindig je met een berg bugs waar je niet aan gedacht had, en terwijl je die probeert op te lossen raken andere delen van de applicatie beschadigd door je oplossing. Dat wordt al snel een nachtmerrie. Laravel maakt unittesten heel eenvoudig; ik had dat serieuzer moeten nemen. Vanaf de volgende versie van Laravel wordt geen enkele pull request samengevoegd zonder unittests en misschien zelfs functionele tests.

Conclusie

Dit zijn een paar redenen waarom ik voor Laravel heb gekozen. Zoals ik aan het begin van dit bericht zei: je project gaat niet over de taal. Tenzij je project juist bedoeld is om een nieuwe taal te leren, moet je geen weken besteden aan het kiezen van een taal of framework. Blijf bij wat je kent en maak gewoon iets. Je gebruikers zal het niets kunnen schelen dat je code lelijk is of dat je Python boven Ruby hebt gekozen.