Dit is het vierde deel in onze reeks over moderne PHP-applicatieservers. Lees eerst deel 1, deel 2 en deel 3 als je die nog niet gelezen hebt. In de vorige artikelen hadden we het over wat moderne PHP-applicatieservers zijn, de groeipijnen en de voordelen. In dit artikel gaan we PHPiekeren.
Tijd om te doen waar ik goed in ben: uit mijn nek kletsen. Wel alvast een content-warning: Ik vrees dat ik aan het einde van dit artikel waarschijnlijk mijn PHP-fanboykaart in moet leveren, maar ik hoop natuurlijk van niet.
Andere talen
In de vorige artikelen schreef ik over de mogelijkheden die we nu dankzij moderne PHP-applicatieservers zoals Swoole en FrankenPHP hebben: zoals het kunnen opslaan van bepaalde data in je RAM, zodat je die beschikbaar hebt over meerdere requests. Wij PHP-volk zijn daar laaiend enthousiast over, maar de gemiddelde Java, C#, Ruby of Node.js developer zou zoiets niet bepaald interessant vinden. Sterker nog: het kunnen opslaan van dingen in persistent memory is vanzelfsprekend. PHP is op dit vlak eigenlijk de uitzondering.
Maar deze keuze was een bewuste tradeoff. In andere woorden: PHP was zo bedoeld, PHP was specifiek ontworpen voor deze use-case, met als voordeel dat PHP ongelooflijk simpel was om te gebruiken en te deployen, waardoor het wereldwijd heel populair is geworden.
PHP was eigenlijk nooit bedoeld om in een langlopend proces te functioneren. En je merkt dus ook, wanneer we van dit traditionele model afstappen, dat je eigenlijk iets aan het doen bent waar het niet oorspronkelijk voor bedoeld was. Waar je in C#, indien gewenst, toegang kunt krijgen tot bepaalde low-level management-mogelijkheden met bijvoorbeeld de .NET thread pool, zijn de mogelijkheden in Swoole en FrankenPHP een stuk gelimiteerder. We mogen al heel blij zijn met wat we überhaupt hebben - en dat zijn we ook zeker!
Maar het roept wel een vraag in mij op.
Want er wordt iets gebouwd om een limitatie van PHP op te lossen. Maar deze limitatie was een bewuste keuze, een bewust aspect van deze taal. En we proberen die limitatie op te lossen door dit eraan vast te plakken op de bestaande basis. Wat dat aangaat is FrankenPHP een scherp gekozen naam.
Het voelt bijna als het monteren van een motorblok en dak op je fiets: op een gegeven moment wordt het tijd om een auto te gaan gebruiken, in plaats van een fiets te veranderen in iets wat het eigenlijk niet is.
Als je een fiets en een auto combineert, ben je mogelijk een fauto aan het maken.
Niet zo PHPessimistisch
Dus wat is de situatie? Zijn we lippenstift op een varken aan het smeren? Heeft iemand een grote fauto gemaakt, waar we nu gebruik van maken?
De situatie ligt natuurlijk een stuk genuanceerder. Er zijn heel veel redenen waarom je deze investering in PHP wel wilt voortzetten. Denk aan situaties met grote bestaande code-bases, programmeurs die al goed bekend zijn met deze taal, of bijvoorbeeld de snelheid waarmee je ermee kunt ontwikkelen, al helemaal op het gebied van prototyping, omdat de taal zo flexibel is.
Ook het PHP-ecosysteem is sterker dan ooit. We kunnen kiezen uit fantastische frameworks zoals Symfony en Laravel, we hebben een canonieke en fantastische package management tool (Composer), en een rijke hoeveelheid aan hoge kwaliteit libraries en tools.
Daarnaast is PHP als taal geen statisch iets. De taal heeft door de jaren heen al een behoorlijke groei en verandering doorgemaakt, zoals de introductie van OOP in PHP 3 tot en met PHP 5, en de modernisering en performance improvements in PHP 7 en PHP 8. De taal staat niet stil - dus waarom zou het concept van hoe deze taal het best gebruikt moet worden stil moeten staan?
Dus ik stop voorlopig nog niet met PHP!
Maar ik moest helaas toch mijn PHP-fanboykaart inleveren. Heel PHPijnlijk.