PHP.

Hallo, lieber Kay, hallo, liebe Leute da draußen. Herzlich willkommen zu einer neuen Folge vom Webcafé. Hallo, das ist mein Einsatz jetzt. Hallo, ja, hallo, lieber Felix. Hallo, liebe Menschen da draußen. Ja, Kay, ich habe einen ganz leckeren Tee mitgebracht für eine Folge, die längst überfällig war in unserem Podcast und steigt da direkt ein. Ich habe nämlich einen Hunky-Dory-Breakfast-Tee. Klingelt es da bei dir? Also, das Wort jetzt nicht, aber ich hoffe, das ist der Tee, den ich dir mitgebracht habe. So ist das, genau. Wir waren zur Projektabschlussfeier in Wien jetzt vor ein paar Wochen und da bist du auf die wunderbare Idee gekommen,

mir einen Tee zu kaufen in einem kleinen Teeladen. Und das ist eben genau dieser, den ich hier habe. Das ist ein schwarzer Pu-er-Tee. Das ist so aus der Region Yunnan in China. Teeliebhaber kennen das ganz gut. Da kam mindestens mal früher sehr viel Tee her. Eine ganz bekannte Teeregion. Und das ist so ein Tee, da ist tatsächlich so Ahornsirup drin, Vanille-Aroma, ein bisschen Honig ist mit drin. Also super runde Sache. Ich probiere gerade live. Ich bin ganz erstaunt, weil ich habe ihn dir ja gekauft und trotzdem bin ich jetzt auf deiner blumigen Beschreibung ganz begeistert, was das denn für ein Getränk ist.

Ja, und ich bin nämlich tatsächlich von dem Tee auch ganz begeistert. Der ist so relativ süßlich und aber unglaublich mild. Ich habe ein bisschen Schluck Milch auch drin. Und ich glaube, ich habe noch keinen Schwarztee getrunken, der so rund, mild und süßlich ist. Also ganz toller Tee, der mir ganz viel Spaß macht. Also an der Stelle nochmal ganz herzlichen Dank. Gerne. Das freut mich natürlich. Ich habe gar keine Ahnung von Schwarztee und habe da einfach mal ins Regal gegriffen. Aber es freut mich, dass ich da was Gutes getroffen habe. Und ich habe auch natürlich auch mir einen Tee gekauft. Nicht so ein fancy Schwarztee wie du, aber es ist ein Fruity Jungle Tee, steht hier drauf.

Ich habe die Dose bei mir. Und es ist eine delicious blend of sweet honeybush, refreshing mango and coconut. Kommt auch in so einer, tja, bernsteinfarbenen Optik daher. Ich nehme auch gleich einen Schluck. Ich habe ihn nicht lange genug ziehen lassen, glaube ich. Aber es ist auch sehr, sehr mild und sehr fruchtig. Und ich habe aber auch noch, um mich, also wir nehmen das hier an einem Nachmittag auf, und um mich jetzt über den bevorstehenden, aufregenden Podcast zu tragen, habe ich mir noch gerade einen leckeren Cappuccino gemacht. Ja, wunderbar. Dann bist du ja fit genug. Genau. Jetzt habe ich hier die Dual Hands, um damit zu arbeiten.

Das ist gut. Kay, wir wollen in dieser Folge über PHP sprechen. Und ich wundere mich, dass ich noch keine Folge mit dir über PHP gemacht habe oder so in der Richtung. Oder ich kann sagen, dass ich mich irre, aber ich kann mich jedenfalls nicht daran erinnern. Beim ersten Durchscrollen habe ich nichts gefunden. Und das ist ja schon ein großer Teil von unserer Arbeit. Und deswegen müssen wir das heute machen. Es ist schon ein bisschen jetzt zuletzt ins Hintergrund getreten, muss man sagen, weil die jüngsten Projekte, die wir haben, eher so aufs Frontend ausgerichtet sind. Und die ganzen Themen mit TypeScript und Typisierung haben wir ja alle schon durchgeackert.

Aber PHP, das läuft halt so die ganze Zeit mit den alten, beständigen Projekten im Hintergrund mit. Deswegen glaube ich auch, es ist allerhöchste Zeit, dass wir das jetzt mal rauskramen. Genau. Und wenn du sagst, alte Projekte, das sind eben Kunden, die wir über Jahre und man kann schon sagen Jahrzehnte betreuen. Das heißt jetzt aber nicht, dass die Code-Basis da angestaubt ist, sondern im Wesentlichen, also es sind ja viele Laravel-Projekte aber auch, versuchen wir ja schon, die relativ aktuell zu halten. Also das ist jetzt nicht so, dass wir da jetzt auf Legacy-Code oder so arbeiten, sondern da sind wir schon oft auch zeitgemäß unterwegs.

Und gleichzeitig haben wir natürlich viele WordPress-Shopware, also Seiten mit CMS dahinter im Betrieb. Und die haben natürlich dann auch immer aktuelle Versionen von PHP im Einsatz. Historisch eher daher, weil das ja die Programmiersprache ist, mit der wir, beziehungsweise ja insbesondere du, original immer angefangen haben mit der Webentwicklung. Genau, da sagst du auch ein gutes Stichwort mit der Historie. Die Sprache PHP wurde ja 1995 von Rasmus Leerdorf entwickelt. Hieß da damals noch ein bisschen anders, PHP-FI oder PHP-FI. Und hatte auch noch ein bisschen andere Bezeichnungen oder war ein anderer Gedanke dahinter.

1997 kam dann PHP-III raus und 2000 dann PHP-IV. Und eigentlich kann man sagen, ab 2000 war PHP dann wirklich eine veritable Sprache, die man dann auch verwenden konnte. Vorher war das, würde ich jetzt mal sagen, eher so experimentell. Und ich bin mir nicht ganz sicher, wann ich eingestiegen bin mit PHP. Aber das muss jetzt also 20 Jahre auf jeden Fall schon her sein. Das heißt, ich würde mal schätzen, dass ich so PHP seit 2003, 2004 verwende. Ich weiß auf jeden Fall, als ich angefangen habe, war PHP 4 noch aktuell und PHP 5 gab es noch nicht. Und PHP 5 ist 2004 dann rausgekommen. Genau, also ich hätte nicht gedacht, dass ich so früh da mit der Sprache eingestiegen bin.

Also kam mir damals schon einigermaßen weit entwickelt vor. Ja, PHP 4 hat ja dann, also da haben die dann so Send-Entwickler mitentwickelt. Send ist ja auch so ein Framework und die haben so eine Engine entwickelt. Die haben dafür gesorgt, dass das Ding dann eine deutlich bessere Performance hatte und eben wirklich einsetzbar war und ja, dann auch diese Wahnsinnsverbreitung im Web gefunden hat. Also war dann wirklich massentauglich. Weißt du, wie viel Prozent der Webseiten heutzutage auf PHP laufen? Ich glaube, du hattest mir schon mal so eine Frage gestellt. Und damals war es schon eine Fangfrage, weil das ein bisschen eine unsichere Beschreibung ist.

Es hängt halt davon ab, was man da so mit reinzählt. Wenn du jetzt sagst, wirklich Webseiten und da so Web-Andungen mit rausnimmst. Also alles, was so öffentlich zugänglich im Web ist. Sag es mir. PHP macht da tatsächlich fast 80 Prozent aus. Stark. Und ich hätte jetzt gedacht, dass das rückläufig ist in den letzten Jahren, weil PHP doch, ja, so von außen betrachtet wird es schon oft gerne gehatet und hat ja nicht den allerbesten Ruf. Trotzdem ist in den letzten Jahren, also man kann eigentlich sagen, in den letzten zehn Jahren stagnieren so die Benutzungszahlen und gehen aber jedenfalls auch nicht zurück, was mich schon ein bisschen gewundert hat.

Ich glaube natürlich, dass das dran liegt, dass die ganzen CMS da einen Riesenanteil machen. Und WordPress hat ja einen Marktanteil von fast 40 Prozent der Webseiten. Ich bin mir nicht ganz sicher, ob die Zahl jetzt brandaktuell ist, aber so um den Dreh. Und das ist natürlich schon mal alles PHP. Also da haben die natürlich schon mal einen großen Anteil dran. Aber ich glaube, ein Stück der Wahrheit ist auch, dass PHP eben nicht so schlecht ist wie sein Ruf. Und da kommen wir später sicherlich auch nochmal drauf zu sprechen. Weißt du, was die anderen Sprachen sind, die nicht PHP sind? Die im Web verbreitet sind?

Genau. Oha. Nee, weiß ich tatsächlich nicht. Oder ich weiß es nicht sicher. Wenn ich jetzt vermuten würde, würde ich sagen, dass Java da weit oben liegt. Und dann gibt es natürlich diese ganzen .NET-Sprachen, die sicherlich noch einen Anteil ausmachen. Ich werde es dir aber gleich sagen, nachdem ich das hier bei Google parallel eingegeben habe. Ich glaube noch nicht. Die Kurve ist ja sehr viel PHP. 80 Prozent, hast du gesagt. Und ich glaube, das korreliert mit der Komplexität der Webseiten. Das heißt, die ganzen einfachen Webseiten, WordPress, du hast es gerade schon genannt, einfache Shops und sowas, das ist alles PHP, bis man zu einem Level kommt,

wo man wirklich im hochkomplizierten Anwendungsbereich ist, wo riesige Firmen sind, so weiß ich nicht, Facebook, Google und Co. Die werden sicherlich auch PHP einsetzen irgendwo. Aber da wird es dann Richtung Go, Java, weiß ich nicht, was solche Späße sein. Sage ich jetzt mal so. Ja, sehe ich auch so. Die Online-Suche läuft. Also, laut ChatGPT, und ich habe gerade schnell eine Anfrage hier gemacht, macht PHP 74,5 Prozent aus. Das ist jetzt Stand 7. April 2025. Wie gesagt, das ist von ChatGPT, deswegen etwas mit Vorsicht zu genießen. Das ist einfach nur für eine schnelle Zahl hier im Podcast. Und dann wundert es mich doch sehr, weil ich dachte, dass die Zahlen deutlich höher zugunsten zum Beispiel von Java

oder den .NET-Sprachen ausfallen. Aber Ruby ist dann hier als nächstes angegeben mit 6,2 Prozent. Also, es geht um Backend-Webtechnologie für Webseiten. Dann kommt ASP.NET mit 5,2, Java 5,1. Und JavaScript dann 4,3 Prozent. Ich bin mir nicht ganz sicher, ob das dann Node.js ist. Gehe ich mal erstmal von aus und dann kommt Scala mit 4,2 Prozent. Und dann geht das so weiter, Python 1,3 Prozent. Also, ganz interessant. Ich hätte gedacht, dass Java dann einen deutlich größeren Anteil ausmacht, weil Java ja in meiner Wahrnehmung eine sehr beliebte Sprache für Backends ist. Dazu muss man aber sagen, dass ich natürlich viel aus dem Corporate-Bereich unterwegs bin,

bei größeren Webseiten. Und ich glaube, Java ist gerade eben für so klassische Web-Anwendungen dann auch sehr beliebt, wo große Datenbanken hinterstehen. Ganz spannend. Also, wirklich, ja, so ein großer Vorsprung für PHP. Das macht wahrscheinlich die Menge der kleinen Websites dann aus, wie wir schon gesagt haben. Ja, vielleicht gehen wir nochmal auf die Entwicklung von PHP ein. Und wir haben dann 2004 eben PHP 5 gehabt, mit ganz großen Fortschritten in der Objektorientierung.

Also, PHP 5 war wirklich nochmal so ein richtiger Fortschritt, so ähnlich wie das dann die ES 2015 oder ECMAScript 2015 ES6 in JavaScript war.

Und dann wurde die Sprache natürlich auch immer schneller. Und 2015 kam dann PHP 7 raus. Das war ja eine irre lange Zeit, bis PHP 7 dann tatsächlich erschien. Und ich meine, dass es die PHP Version 6 auch nie gab, sondern die wurde dann angefangen zu entwickeln. Und dann hat man sich aber irgendwann entschieden, ein bisschen einen anderen Weg zu gehen. Und dann ist letztlich PHP 7 bei rausgekommen. Wieder mit einem deutlichen Performance Boost, angeblich fast doppelt so schnell wie PHP 5, mit einer neuen Engine, ganz vielen neuen Features und dann bessere Effizienz.

Und vielen Sachen, die wir eben auch heute benutzen, also wie dieser Doppelfragezeichen-Operator, den wir ja sehr lieben. Und da waren eben viele praktische Funktionen dabei. Und dann haben wir 2020 PHP 8. Da gibt es dann so Features wie dieser Just-in-Time-Compiler, Union-Types, Named-Arguments. Das sind aber Features, wo ich jetzt sage, die benutzen wir jetzt nicht unbedingt im Alltag, es sei denn, du willst mich da korrigieren. Teilweise, sage ich mal. Genau, also soweit zur Historie. Vielleicht gehen wir gleich so auf einzelne Features der einzelnen Versionen noch nochmal ein. Aber so grob kann man wirklich sagen, also es hat sich eigentlich in jeder Major-Version richtig viel getan, bis PHP 8 kann man eigentlich sagen.

Also PHP 1 bis 3 würde ich fast ein bisschen zusammenfassen. Das waren so die Anfänge von PHP, wo das sich so ein bisschen zurechtgerugelt hat. PHP 4 im Jahr 2000 war dann das, was man wirklich verwenden konnte. Und mit PHP 5 2004, PHP 7 2015 kamen dann die ganz großen Schritte. Und jetzt sind wir wahrscheinlich in so einem State, wo die Sprache wirklich gut verwendbar ist. Wo so aus unserer Sicht noch viel so Legacy-Zeug drin ist, wo so alte Funktionen drin sind, die man vielleicht irgendwann nochmal rausschmeißen müsste. Und die Abwärtskompatibilität da dann irgendwann mal sich von der verabschieden müsste.

Aber insgesamt ist das natürlich heute eine Sprache, mit der man toll arbeiten kann. Ich bin mir aus dem Stand gar nicht sicher. War das nicht mit PHP 8, wo die ganzen Methoden und Objekteigenschaft, Typisierung dazukamen? Das war, glaube ich, nochmal ein ordentlicher Sprung, was so den Entwicklerkomfort anging. Das weiß ich jetzt aus dem Sprung auch nicht, genau. Aber das kann gut sein. Ja, und die Funktionen, die uns ja heute noch nerven oder das, was uns am PHP noch so nervt, ist einfach diese Inkonsistenz. Also das fängt ja damit schon an, dass du diese Standardfunktionen in PHP zum Beispiel groß und klein schreiben kannst.

Also wenn wir jetzt so ein STR-Post zum Beispiel mal nehmen, also da sucht man ein Zeichen innerhalb eines Strings. Und ich glaube, jeder von uns wird das klein schreiben, also komplett klein, STR-Post. Und du kannst es aber auch zum Beispiel am Anfang mit großem S schreiben oder du kannst es komplett groß schreiben. Also das führt natürlich schon zu einiger Verwirrung, wenn man so Code sieht. Also sieht halt nicht einheitlich aus. Und der STR-Post ist dann auch ein gutes Beispiel für eine Funktion, wo jetzt einfach nur alles zusammengeschrieben ist in dem Funktionsnamen, wie zum Beispiel bei HTML-Entities auch.

Und dann gibt es aber Funktionen wie Array-Merge zum Beispiel, Array-Push, wo das dann mit Unterstrich geschrieben wird.

Oder JSON-Encode, da ist dann zwischen JSON und Encode auch ein Unterstrich. Und so weiß man irgendwie nie so richtig, wie die Funktionen geschrieben werden. Und man turnt dann ständig in der Dokumentation rum. Und genauso gibt es dann Inkonsistenzen zum Beispiel darüber, welcher Rückgabewert zurückgegeben wird. Also wir haben dann so Sachen wie zum Beispiel STR-Post, um dabei mal zu bleiben. Da hast du dann die Reihenfolge Haystack-Needle. Also du hast am Anfang den String, in dem gesucht wird. Und hinten dann die Needle, also das, was im String gesucht wird. Also die Parameter meinst du? Genau.

Und dann hast du so Funktionen wie Array-Search. Und da ist es dann Needle-Haystack. Also genau andersrum. Und das ist natürlich so endverwirrend, dass ich, der, also ich habe ja eben schon gesagt, ich arbeite jetzt bestimmt seit 20 Jahren mit PHP, eher mehr als weniger. Und ich kann mir bis heute absolut nicht merken, welche Reihenfolge diese Parameter haben. Ist ja jetzt heute nicht mehr so relevant mit diesen ganzen AI-Code-Helferchen und so. Da wird ja natürlich vieles vorgeschlagen. Deswegen, ja, tappt man da nicht in die Falle. Aber früher, als man wirklich noch ohne Hilfe gecodet hat, war man ständig auf der PHP-Webseite und hat sich angeguckt, wie diese Funktionen denn, also wie die Parameter, in welcher Reihenfolge deren sind.

Also da ist dann dieser eingebaute Dokumentationshelper in der IDE Goldwert, der dir dann genau sagt, was der erste oder zweite Parameter ist. Und ich glaube, die haben jetzt in den letzten Jahren, bei den letzten Versionen auch damit angefangen, dann so ein paar Inkonsistenzen zu bereinigen und das aufzuräumen und einheitlich zu machen.

Ja, genau. Angefangen auf jeden Fall. Das merkt man zum Beispiel an diesen MySQL-Funktionen schon. Ich glaube, diese klassischen MySQL-Funktionen gibt es ja nicht mehr, wie MySQL-Connect und so, sondern das ist ja jetzt alles über diese, boah, jetzt kriegst du mich hier.

Jedenfalls ist es ersetzt worden durch andere Funktionen. Das macht man ja heutzutage nicht mehr. Das lässt man sich ja alles durch die Frameworks und so abnehmen. Aber ich weiß, als ich angefangen habe, da hat man immer noch diese MySQL-S-Hoc-Funktion und eben wirklich MySQL-Connect und sowas gemacht.

Das würde man jetzt heute jedenfalls nicht mehr so machen. Ist auch nicht mehr so relevant. Aber klar, da wurde natürlich schon einiges aufgeräumt und ein bisschen Abwärtskompatibilität auch schon gekickt.

Aber nichtsdestotrotz gibt es einfach noch viele Sachen, die man so ohne weiteres nicht los wird. Jetzt haben wir gerade die ganze Zeit darüber gesprochen, wo PHP eigentlich insgesamt herkommt. Was machen wir denn damit eigentlich? Ja, programmieren. Ja, was machen wir damit? Warum hast du damit angefangen? Ja, das ist natürlich ganz klar, weil PHP so die Sprache fürs Web war. Und ich war immer schon fokussiert auf Web-Technologien und Webseiten. Gerade damals war PHP ja das Einzige, was man richtig sinnvoll verwenden konnte. Irgendwann kamen da so Sachen wie Ruby und Rails und so. Aber das hatte alles immer so den Nachteil, man musste da irgendwas auf den Servern installieren, man musste auf den Servern rumkonfigurieren.

Wenn Kunden Server direkt mitgebracht haben, also Web-Spaces, dann lief da überall PHP, aber es lief nicht überall Ruby oder Java oder andere Sachen.

Und deswegen war immer das Einfachste, einfach PHP zu nehmen, weil im PHP-Skript konntest du überall hochladen. PHP-Interpreter lief überall. Und ja, das war einfach die Sprache fürs Web. Und das ist ja nicht nur, dass es überall läuft auf den ganzen Web-Servern, sondern es hat natürlich für einen Einsteiger super praktische Features. Also dadurch, dass man einfach loslegen kann, das Ding nicht kompilieren muss. Das ist natürlich sehr einfach. Aber auf der anderen Seite integriert es sich natürlich auch wunderbar in HTML. Und wenn wir an unsere schönen alten Tage zurückdenken, wo wir HTML und PHP noch fröhlich gemischt haben und CSS alles in einer Datei, JavaScript auch noch mit rein.

Also keine Trennung von Funktionen, Design und so weiter. Da war das natürlich eine klasse Sprache, weil man einfach in einem HTML-Dokument einfach einen PHP-Tag aufmachen konnte, da PHP reinschreiben konnte mit dem Echo.

Und dann ging es los. Also das war natürlich wunderbar integriert und brachte natürlich diese ganzen web-spezifischen Funktionen, wie dass man auf Get-Variablen direkt zugreifen konnte und so weiter, brachte das natürlich direkt mit.

Also du hast ja jetzt nicht, wer weiß, wie eine umfangreiche Evaluierung gemacht, welcher Tech-Stack denn wohl das geeignetste wäre, sondern du wolltest eine Webseite bauen und da ging eigentlich nur PHP.

Ja, die Frage stellte sich eigentlich auch gar nicht. Also das war klar, da gab es eigentlich nur PHP für Web und das hat jeder so gemacht und damals war das ja eine Sprache, die eigentlich eher sogar gehypt war.

Also da hat keiner negativ über die Sprache gesprochen. Das war ja eine Zeit, wo alle Sprachen noch so ein bisschen Kraut und Rüben waren und da ist das eigentlich keinem aufgefallen, dass in PHP auch diese Inkonsistenzen drin waren, die ja andere Sprachen vielleicht von Anfang an nicht so mitgebracht haben.

Aber das war eine Zeit, in der man dann auch so Sprachen wie COBOL und so kannte. Also da war man mit einem PHP schon sehr glücklich. Ich weiß, ich kann mich noch daran erinnern, als ich PHP angefangen habe, da wurden zum Beispiel die ganzen Get-Variablen noch als Globals registriert. Also wenn du dann irgendwie einen Get-Parameter hattest, der hieß dann zum Beispiel Name oder so, dann wurde halt eine Variable Dollar Name, hattest du einfach im Code verfügbar.

Also du musstest nicht auf diese Dollar-Unterstrich großgeschrieben Get und dann Name zugreifen, sondern du konntest direkt auf Dollar Name zugreifen, weil diese Eigenschaft hieß Register Global, das konnte man auch abschalten, wurde dann auch immer empfohlen.

Jedenfalls wurde die dann registriert und da konnte man natürlich wunderbare Spaces auf anderen Webseiten mit erstellen, weil man sich dann einfach ein Formular gemacht hat. Das hieß dann irgendwie Passwort oder so und da konnte man ganze Seiten damit zerschießen. Also das war noch so ein bisschen wilder Westen. Das klingt ja abgefahren. War eine Zeit, wo auch noch mal SQL Injections funktioniert haben. Das war auch immer klasse. Du hast das gerade gesagt, PHP einfach irgendwo auf den Server und drauf losgelegt. Und das ist ja eigentlich schon, vielleicht nicht Vorteil, aber zumindest schon mal ein entscheidendes Unterscheidungskriterium an PHP.

Nämlich da gibt es nicht so richtig einen Kompilier-Step, wie man es vielleicht von Java kennt, sondern auf dem Server liegt die PHP-Datei in Klartext, sage ich mal.

Und wenn man dann die Seite aufruft, wird es zur Laufzeit die Datei umgewandelt, sage ich mal, in Code, den auch der Computer versteht, sage ich mal, ganz trivial.

Und dann wird das ausgespielt. Und wenn du die Datei veränderst, dann wird beim nächsten Aufruf die geänderte Datei benutzt. Und man hat nicht noch so ein, wer weiß, wie kompliziert Setup drumherum. Genau, das macht PHP natürlich auch sehr einfach und, ja, wie ich auch eben schon gesagt habe, für Anfänger total verständlich. Und ich glaube, dass das auch bis heute eine gute Einsteigersprache ist. Das ist natürlich, wenn man danach auf so ein Java oder sowas umsteigt, muss man schon ein bisschen umdenken. Und das ist mir auch dann schwergefallen, zum Beispiel als ich an der Uni war und wir da Java gemacht haben oder in der Ausbildung.

Das ist schon sehr anders, wie man da programmiert. Aber in PHP natürlich, ja, du bist irre schnell im Entwickeln. Früher hat man ja von der Datei auf den FTP gezogen, hat das mit einem Editor direkt auf den FTP connected und direkt online bearbeitet. Konnte ein F5 drücken damals bei Windows und hat seine Änderungen gesehen. Das war fantastisch. Also das machen wir ja heute auch noch so, ne? Bei WordPress-Seiten, bei Shops, Shopware und so weiter. Das ist alles PHP und das funktioniert alles nach dem gleichen Prinzip. Irgendwo liegt dieser Code und man kann, wenn man möchte, direkt da per FTP drauf.

Und an der Quelle das verarbeiten, wenn man will. Dieser Schritt, den wir jetzt eher seit relativ kurzer Zeit machen, nämlich mit so einem relativ elaborierten, naja, Build-Step in Anführungszeichen davor.

Das ist ja eine relativ neue Sache, die wir jetzt machen. Ja, genau. Wir versuchen natürlich, wenn möglich, heute alle Codes irgendwie in Git zu bekommen, damit sie auch versioniert sind. Das ist natürlich ein Riesen-Nachteil gewesen von diesem direkt auf dem Server bearbeiten. Aber genau, also prinzipiell funktioniert das bei den allermeisten Seiten heute zumindest mal eben zum Debuggen noch. Und vielleicht einen großen Unterschied bei PHP, den wir noch unterschlagen haben, warum das im Web auch gut funktioniert, ist ja, dass PHP so Request-basiert ist.

Das ist mir gerade eingefallen, als du das gesagt hast. PHP läuft ja immer von oben nach unten durch für eine Anfrage, kann man so ganz grob sagen. Und das ist natürlich anders als in Java oder andere Programmiersprachen, die im Hintergrund dauerhaft laufen und dann Anfragen annehmen, ist bei PHP immer klar.

Das läuft von oben nach unten durch. Und das ist, wenn man das verstanden hat, ganz gut verständlich und eben für das Web ganz cool geeignet. Deswegen funktioniert das auch mit dem Endern im Live-Betrieb so gut, weil man wirklich für jeden Request eine komplett neue Instanz, wenn man so möchte, von PHP bootet,

die den kompletten Code einmal durchgeht, kompiliert und dann damit arbeitet und bei dem nächsten Request dann nochmal. Das ist natürlich aber auch gleichzeitig ein Nachteil, weil das natürlich zeitaufwendig ist. Wenn wie bei Java die ganze Zeit im Hintergrund ein Programm läuft, was gestartet wurde, was schon im Arbeitsspeicher ist und so weiter, kann es sehr schnell Anfrage entgegennehmen, verarbeiten und das Ergebnis zurückspielen, weil es nicht erst diesen ganzen Kompilier-Step dazwischen machen muss. Das ist so ein bisschen das, was eigentlich bei PHP Fluch und Segen zugleich ist. Das ist dieser Kompilier-Step, der einfach, ja nicht wegfällt, aber der zur Laufzeit erst passiert,

weil relativ viele Features, können wir gleich in den Rabbit Hole ein bisschen reingehen, da sich eigentlich dran stoßen. Also was eigentlich PHP oder eine von PHP's größten Stärken ist, ist auch gleichzeitig Ursache für viele der Schwächen,

nämlich halt, dass es langsam ist, dass man da ein bisschen Mühe machen muss, um dieses ständige Kompilieren zu umgehen und solche Sachen. Das finde ich ganz spannend. Ja, bei dem langsamen, das ist ja immer so eine Sache, also wir haben ja mitunter schon sehr, sehr große Anwendungen auch gebaut und ich habe damals, als ich noch für eine Plattform gearbeitet habe, ja eigentlich so eine Ferienhaus-Plattform, kann man sagen, wo man Ferienhäuser buchen konnte und da haben wir zum Teil mit Millionen von Datensätzen gearbeitet und dann in diesem klassischen selbstgebauten Setup von PHP und MySQL. Und wenn man das vernünftig macht, war das jedenfalls keine Größe, wo PHP an seine Grenzen gekommen ist oder wo wir jetzt gesagt hätten,

dass wir jetzt, also eine Million Datensätze auszuwerten, wäre da jetzt mit PHP nicht mehr möglich, weil zu langsam. Also wir konnten auch live suchen und so weiter, also ohne weiteres in PHP bauen und massenhaft Anfragen annehmen und so weiter. Also wenn man sich die nackten Zahlen anguckt, ist PHP ja schon langsamer als dann beispielsweise in Java und trotzdem konnte ich in der Praxis für mich jetzt noch nicht feststellen, dass es an irgendeinem Punkt langsam war. Oder anders gesagt, also wenn eine Anwendung langsam ist im PHP, dann liegt es, also zu 99 Komma dürft ihr euch aussuchen,

an demjenigen, der eben nicht effizient gecodet hat. Und die Programmiersprache selbst macht da, glaube ich, einen kleineren Teil als der Programmierer, der das Ganze dann bedient. Also wie gesagt, die reinen Zahlen, natürlich ist PHP langsamer als dann zum Beispiel ein kompiliertes Java, aber in der Praxis hat das für mich eigentlich keine Relevanz. Das ist das Ding bei solchen Vergleichen. Da stellt man dann so automatische Benchmarks zusammen, die irgendwie eine Milliarde Operationen pro Sekunde simulieren und irgendwelche superlangen Arrays durchiterieren und da zeigst du dann, ja hier, PHP ist hundertmal langsamer als Go oder weiß ich nicht was.

Aber in der Realität machst du das ja nicht. Und ob du jetzt eine Webseite öffnest und die 500 oder 600 oder 700 Millisekunden dauert, sicher ist jetzt nicht das Allergeilste,

aber es gibt wenig Leute, die sagen, nee, das benutze ich nicht, weil das dauert ja unter eine Sekunde. Und klar kann man da dann noch total drauf ausrasten und das weiß ich nicht, in welche Höhen treiben oder andersherum in irgendwelche Performance-Tailer,

wo dann das nur zehn Millisekunden pro Anfrage braucht und sowas. Aber so zumindest jetzt in dem Breitengrad, wo wir uns herumtreiben, da ist das eigentlich noch nicht relevant. Sehe ich nämlich auch so. Und wenn das jetzt 100 Millisekunden Unterschied machen würde beim Website-Laden, das wäre ja fast sogar schon relevant. Aber ich glaube, wir sind da in ganz anderen Bereichen unterwegs, die deutlich kleiner sind, wenn beide Anwendungen vernünftig geschrieben sind. Und ich habe das gerade auch gesagt, dieses Kompilieren zur Laufzeit. Und auch das ist natürlich nur theoretisch wahr, weil da gibt es natürlich schon mit so Sachen wie OP-Cache-Varianten, wo eben so zwischenkompiliert wird.

Das heißt, beim ersten Mal, wo der PHP-Code läuft, wird ja dann kompilierter Output, sage ich mal, in so einem temporären Cache gespeichert.

Und wenn es dann danach nochmal aufgerufen wird, nutzt er eben schon die gecached Variante. Und das macht auch nochmal einen deutlichen Performance-Unterschied aus. Plus natürlich, das wäre das Problem, kannst du nicht immer so aktualisieren. Also wie oft mir OP-Cache schon auf die Füße gefallen ist, weil ich auf der Webseite irgendwas ändern wollte. Ist das so? Also hattest du schon Situationen, in denen du gemerkt hast, der OP-Cache ballert dir da jetzt rein? Ja, schon. Das eine oder andere. Also jetzt nicht regelmäßig, aber schon so, dass ich dachte, ich habe doch jetzt hier die Datei geändert.

Und sie ist auch wirklich per FTP auf dem Server angekommen, aber es wurde nicht aktualisiert. Und dann einmal OP-Cache aus und wieder angemacht und dann hat es geklappt. Also jetzt auch nicht so oft, dass es mir, also wahrscheinlich bringt es mehr Vorteile als Nachteile auf der anderen Seite. Nur das ist immer das Problem bei solchen Cache-Sachen. Das ist interessant, weil das habe ich für mich noch nie festgestellt. Eine andere Sache, die jetzt auch relativ neu ist, vor allem im Laravel-Universum und ich sage relativ neu, ist eben auch der Gedanke wie von Java, dass du eine dauerhaft laufende Anwendung in PHP hast,

die fortlaufend mehrere Requests verarbeitet und was nochmal einen Performance-Boost bringen soll, wenn man eben nicht für jeden Request separat dieses Ganze kompilieren und sowas machen soll. Stichwort ist da Octane bei Laravel. Und das ist eben auch schon so ein bisschen auch der Versuch, PHP mehr zu entwickeln zu so fancy Sprachen wie Java,

wo du eben so einen dauerhaft laufenden Prozess hast, der die Anfragen entgegennimmt. Aber das hat natürlich auch ganz eigene Probleme, die man dann berücksichtigen muss. Also es ist einerseits Vor- und Nachteil dieser elegante Gedanke von PHP, so pro Anfrage läuft einmal das Programm durch und danach ist fertig. Es gibt keinen globalen State, der dauerhaft überlegt oder sonst irgendwas. Ja, ich bin auch gar nicht sicher, ob das Sinn macht, sich von diesem Konzept dann gänzlich zu verabschieden. Also ich bin natürlich immer ein großer Fan davon, wenn neue PHP-Versionen auch eine schnellere Engine und so weiter mitbringen.

Aber in dem Moment, wo man jetzt sagt, man will die schnellste Sprache haben und eine kompilierte Sprache mit all den Vor- und Nachteilen, dann kann man ja eine andere Sprache verwenden. Es bleibt ja jedem offen, heute dann zum Beispiel auch in Java oder andere Sprachen zu verwenden oder Node.js mit anderen Vor- und Nachteilen. Und ich glaube, dass das fast Sinn macht, wenn PHP schon seine Nische, die ja offensichtlich relativ groß ist, auch behält und in der Nische entwickelt wird, anstatt da jetzt zu gucken, dass man links und rechts das Ding verbiegt. Ich glaube, dass viele Sachen von denen, die du jetzt genannt hast, ja auch optional sind.

Das heißt, die kann sich derjenige raussuchen, der sie dann nutzen möchte. Aber ich glaube, dass ich das nicht so richtig durchsetzen kann, weil es dann eben andere Sprachen gibt, die insgesamt passender sind für die anderen Anwendungsfälle. Das ist, glaube ich, tatsächlich so ein bisschen der übergeordnete Metastory-Bogen, der sich im PHP-Universum gerade abspielt. Nämlich, dass es diese beiden Lager gibt, die sagen, einerseits PHP soll eigentlich so bleiben, wie es ist. Eine simple, relativ simple Skriptsprache für einfache Webseiten, die Request entgegennimmt, einmal durchläuft, fertig, aus.

Das Team A und Team B ist dann, nee, wir wollen eine richtig, wie Java, eine vollumfängliche Programmiersprache mit Compiler,

mit allem, was dazugehört und so weiter und so fort. Wir wollen das immer mehr entwickeln, auch von der Syntax her, Richtung Java oder andere so hardcore-typisierte, objektorientierte Sprachen.

Da haben wir jetzt auch so, fällt mir Begriff nicht ein, so Attribute bekommen für Klasseneigenschaften und solche Späße. Und das finde ich einen ganz interessanten, tja, Kampf, der da gerade ausgetragen wird. Vielleicht ist das eine gute Gelegenheit, mal so ein bisschen in den Ausblick von PHP reinzugehen. Da frage ich dich mal, Felix, was vermisst du denn noch? Hm, also, das ist ja, glaube ich, eben schon so ein bisschen rausgekommen, als ich auch so die Nachteile von PHP angesprochen habe. Was mich natürlich insgesamt stört und was der Sprache schadet, ist wirklich diese Inkonsistenz. Also, wenn dann eine Funktion bei Fehler-False zurückgibt, die Angriff-Null, die andere Throw-In-Error.

Das sind Sachen, da muss PHP ja zu Recht auch viel einstecken. Und ich hatte eben schon noch ein paar andere Beispiele mehr genannt. Und ich würde, da muss ich jetzt live drüber nachdenken, glaube ich, hoffen, dass da ein paar alte Zöpfe abgeschnitten werden.

Also, dass wirklich mal gesagt wird, wir machen jetzt in einem PHP 9, 10, wie auch immer man das Kind da nennt, und sagen, jetzt machen wir eine Sprache, die von vorn bis hinten, also soweit möglich, konsistent ist, Name-Conventions dann tatsächlich mal einhält und Konzepte von vorn bis hinten durchdenkt. Und natürlich wäre das ziemlich breaking. Das heißt, ja, man könnte alte Anwendungen nicht so ohne weiteres fortführen. Ich glaube, man könnte das schon ganz gut portieren, gerade auch heutzutage mit den ganzen AI-Funktionen und so. Aber ich glaube, es geht im Wesentlichen darum, dann zu sagen, wenn man dann neue Anwendungen macht,

dann arbeite ich mit einem PHP, was wirklich sauber und cool ist. Und das wäre für mich eigentlich eine Einladung für PHP 10, das so zu machen. Also, die Versionsnummer schreit ja schon danach. Dann nennt man das PHP X. Das wäre so mein Wunsch. In der Sprache selbst, glaube ich, kann man schon irre viel machen. Und da könnte ich jetzt nicht sagen, dass ich groß was vermisse, auch wenn ich das jetzt vergleiche mit TypeScript oder so, was da möglich ist. Da kann ich jetzt gar nicht sagen, dass mir im PHP was fehlt. Jetzt sind wir natürlich viel im Laravel-Universum unterwegs. Das heißt, da gibt es natürlich hier und da schon mal kleine Helferchen,

die Laravel uns mitbringt. Aber alles in allem wünsche ich mir eigentlich, dass die Sprache einmal wirklich einheitlich gemacht wird und ja, einfach insgesamt dann auch einen besseren Ruf bekommt. Ich finde das ganz spannend. Also, dazu habe ich jetzt tatsächlich nichts vorbereitet. Aber ich glaube, das ist so ein fortlaufender Prozess, eben diese Inkonsistenzen auszuräumen. Ich kann mich nämlich erinnern, immer bei den Major-Updates auf jeden Fall kommt dann immer raus, okay, hier, schau mal, diese Funktionen haben sich jetzt geändert, hier, die sind deprecated und dann nimmt das immer so ein paar Versionszyklen

und dann ist das auch, glaube ich, gerade gezogen. Also, ich glaube, das ist tatsächlich eine Baustelle, die relativ offensichtlich ist und die auch aktiv angegangen wird. Aber immer in so, immer so Nuancen nur, ne? Also, da wird mal hier eine Funktion rausgeschmissen. Also, wie gesagt, kann ich auch total verstehen, weil man hat diese, man will halt nicht diesen harten Cut machen. Und ich glaube aber, dass der irgendwann mal notwendig wäre. Und vielleicht muss man dann PHP sogar an der Stelle auch einfach forken und sagen, ich mache jetzt eine PHPX oder sowas, was dann wirklich sagt, ich mache es jetzt anders als die Vorgänger.

Und wenn ihr damit neu anfangt, alles cool, upgraden, wer da Lust drauf hat, wäre meiner Meinung nach vielleicht der beste Weg. Also, vielleicht muss es einfach selber machen, Felix, weil, also PHP ist in C geschrieben, das ist vielleicht ein kleines Hindernis. Aber ansonsten kann man sich auf GitHub einfach die PHP-Programmiersprache anschauen, also den Compiler, und dort in der Theorie auch den Compiler forken und ändern. Und es gibt sogar, also logischerweise ein offizielles Prozedere und eine offizielle Roadmap, welche Sachen bei PHP gemacht wurden, gemacht werden, vielleicht gemacht werden sollen und sowas.

Und das wird bei PHP über so ein RFC-System gemacht, also Request for Commons. Das heißt, in der Theorie kann jeder, wie der möchte, so einen Vorschlag stellen und dann wird im PHP-Core-Team darüber abgestimmt. Und wenn da genug Stimmen dafür sind, dann wird das umgesetzt. Und auf der offiziellen PHP-Seite gibt es eine Liste von RFCs. Und da kann man genau nachsehen, okay, was ist denn geplant, was ist denn schon approved, was ist denn gerade umgesetzt, bei welcher Versionsnummer kommt das und sowas. Die sagen allerdings auch dabei, die RFC-How-To-Wikipedia-Seite vom PHP.net sagt extra, wenn du das nicht selber implementieren kannst und auch sonst keinen hast, der das implementieren könnte,

dann brauchst du eigentlich gar nicht erst versuchen, so einen RFC zu stellen, weil die wahrscheinlich nicht einfach Leute haben wollen, die blinde Anforderungen stellen und dann sich gar nicht mit der Implementierung beschäftigen. Das ist ja interessant. Hast du Features, die in PHP-Version 9 eventuell kommen? Hast du dir das im Vorhinein angeguckt? Genau. Ich habe mir diese Liste dann tatsächlich mal angeschaut, weil ich mir auch überlegt habe, was will ich denn eigentlich? Wenn ich mir die neuen PHP-Versionen anschaue, so die meiner Versionssprünge, dann scrolle ich da immer so durch und denke, ja, weiß ich nicht, hätte ich jetzt alles nicht gebraucht.

Aber umgekehrt, was will ich denn eigentlich? Und ich habe zwei ganz spannende Sachen gefunden. Das eine ist tatsächlich schon accepted für PHP 8.5. Und das heißt Errors Backtraces V2. Und da wird einfach der Backtrace von so einem Error nochmal sehr viel sprechender gemacht, mit einem genauen File-Verlauf von hier, da, nach da, nach da war der Aufruf. Und das hilft, glaube ich, beim Debuggen nochmal insgesamt ganz gut. Oh, cool. Wir haben uns ja kürzlich Java und Spring Boot mal angeguckt. Und die träumen mir davon, dass sie so einen Stacktrace haben, wie PHP den aktuell schon hat. Aber wenn er noch weiter verbessert wird, habe ich natürlich gar nichts gegen.

Und das Zweite, was konkret an der Discussion ist, das heißt, wird gerade darüber abgestimmt, ist ein Thema Pipe Operator V3 heißt es. Und da geht es darum, so ein bisschen wie bei JavaScript, wo man ja auch mehrere Funktionen hintereinander channelen kann, gibt es hier dann auch so eine Syntax, wo man quasi den Output von der einen Funktion direkt als Input für die nächste Funktion nutzen kann. Und dann kannst du die so hintereinander abarbeiten, auch einfache Funktionen, statt wie man das bei dieser Fluent-Syntax über Klassenregeln muss. Das fand ich auch noch ganz spannend. So ein bisschen, wie das in Shell-Skripten oft gemacht wird?

Ja, genau. Einfach auch Funktionen beliebig hintereinander setzen. Boah, stelle ich mir richtig gut vor. Ist natürlich auch wieder eine Voraussetzung dafür, dass die Funktionen einen ähnlichen Rückgabewert haben. Also die hat jetzt zum Beispiel hier ein Beispiel, wo man die Number of Admins ermittelt und dann hast du erst eine Funktion getUsers und dessen Ergebnis wird dann gepipet in so ein Array-Filter, wo dann rausgecheckt wird, welcher User denn Admin ist. Und das wiederum wird dann weiter gepipet in so eine Count-Funktion. Und die gibt dir dann ein numerisches Ergebnis zurück. Das fand ich auch ganz spannend.

Aber tatsächlich, abgesehen von diesen beiden Punkten, da stehen schon Dinge drin in diesem RFC. Aber das ist jetzt nichts so richtig Bahnbrechendes. Und das bringt mich zu dem letzten Thema, was ich gerne hätte und halb PHP gerne hätte. Und das ist eine bessere Typisierung, insbesondere das Thema Generics. Oh Kay, damit legst du mir seit Jahren in den Ohren. Ja, ja. Es ist aber auch wirklich eine Last. Also insbesondere dieses Generics ist ja so ein Thema. Das kennt man aus TypeScript vielleicht. Aber ganz kurz zur Erklärung. Üblicherweise benutzt man das für Collections, also Fancy Arrays. Und man möchte sagen, okay, welchen Typ haben denn diese einzelnen Array-Items?

Und bei einem Generic könntest du sagen, das ist ein Array vom Typ User zum Beispiel. Und das bedeutet, alle Items in diesem Array sind eine User-Klasse. Und damit kannst du halt total schöne Dinge machen, zum Beispiel durchiterieren. Und du weißt, auch mit Code Completion im Editor und sowas, wenn ich jetzt ein Item aus diesem Array nehme, habe ich genau Code Completion für den Type User, weil ich es vorher gesagt habe. Und das gibt es nicht. Also das ist schon seit der erste RFC, seit 2016 ist das Thema in der PHP-Welt. Aber gibt es bis jetzt nicht. Und da fragt man sich, hä? Ist auch jetzt, also TypeScript hat das noch schon gemacht.

Was ist denn dann so schwer? Und es stellt sich heraus, es ist anscheinend verdammt schwer. Und da bin ich wirklich in einen Rabbit Hole abgestürzt. Ich möchte das vielleicht kurz zusammenfassen. Der Grund, warum es das noch nicht gibt, ist, es ist zu kompliziert und zu performanceintensiv. Also ein faszinierendes Thema. Unfassbar schwierig, da reinzusteigen, weil das hoch mathematische Zusammenhänge sind, die da irgendwie erläutert werden. Aber kurzum, im Moment zu kompliziert, aber man arbeitet dran. Aber es ist schon auf der Agenda. Also es wird uns irgendwann in PHP beschert werden. Das Neueste, was ich gefunden habe, ist ein Blogpost von der PHP Foundation aus Ende 2024.

Kann ich vielleicht verlinken. Da heißt es State of Generics and Collections. Und da wird es eben nochmal aufgezeigt, was denn der aktuelle Stand ist, was die Probleme sind, warum es da nicht weitergeht. Und da wird unter anderem beschrieben, dass es einfach unfassbar kompliziert ist, dieses Thema mit dem Konzept von PHP reinzubringen.

Ja, ich merke schon, du bist da irretief abgestiegen. Und ich würde sagen, wir verlegen die restlichen Details auf eine Folge, die dann heißen wird PHP Generics.

Aber Gott, da muss ich mich dann noch mehr mit beschäftigen. Wir können natürlich unseren Zuhörenden dann noch nicht sagen, wann die rauskommen wird. Ja, aber da musst du dich dann allerdings nur noch damit beschäftigen, wie das umgesetzt wurde und wie man es einsetzt. Ja. Und das dürfte dann ja deutlich weniger umfangreich sein. Vielleicht, um das abzuschließen. Man kann das tatsächlich schon über Bande bekommen, weil verschiedene Tools überlegt haben, wie es funktionieren könnte.

Und das dann einfach als Standard etabliert haben, um PHP herum. Also PHP sagt, wir können das in der Sprache nicht etablieren, weil technisch unmöglich, sage ich mal, für den Moment. Aber alles drumherum kann damit schon arbeiten. Und da ist insbesondere Laravel und PHP Storm sind da Vorreiter, die sagen, okay, wir können es nicht in der Sprache selber programmieren. Aber wir lösen das zum Beispiel über so PHP-Docs. Und bei Laravel kannst du eben schon über diese Collection, über bestimmte Kommentare, die du an die Dateien dransetzt, das so ein bisschen erreichen. Das ist natürlich bei Weitem nicht so geil, wie wenn das die Sprache selber mitbringt.

Aber es funktioniert dann so ein bisschen über Bande, dass du sagst, okay, zumindest halb kann ich es hier umsetzen. Und wenn ich das halbwegs konsequent umsetze, dann habe ich auch eine gute Entwickler-Workflow. Ein anderes Beispiel ist zum Beispiel PHP-Stan. Das ist so ein Static-Analyser, der versucht, so ein bisschen den Compile-Step von PHP vorab nachzuführen. Und auch da kann man über so entsprechende PHP-Docs das schon so ein bisschen erleben, wie schön das wäre, wenn wir Generics hätten.

Ich bin natürlich kein großer Fan von so Frickellösungen. Also dann lebe ich lieber mit den Schwächen der Sprache, als dass ich mir da externe Sachen reinhole, die in zehn Jahren ganz komisch aussehen, rückblickend.

Von daher warte ich dann lieber auf die Features, wenn sie in der Sprache wirklich selbst kommen. Das denke ich auch. Also es ist natürlich einerseits, wenn Laravel und PhpStorm als große Player das schon machen, dann hat das schon ein bisschen Seriosität. Aber ich bin ganz deiner Meinung, die haben sich eine Syntax überlegt, die wahrscheinlich sinnvoll wäre, die sehr an TypeScript angelehnt ist und wahrscheinlich auch andere Sprachen. Aber sagt jetzt niemand, dass wenn PHP auf einmal doch eine Lösung findet und die Syntax ein bisschen anders ist, ist das halt hinfällig.

Was noch eine andere spannende Idee wäre, was auch immer mal wieder versucht wurde, ist, so ein Superset von PHP zu machen. Das ist ja TypeScript zum Beispiel. Das ist ja ein Superset von JavaScript. Das heißt, der fertige Browser kann mit TypeScript nichts anfangen, aber ich programmiere in TypeScript und habe dann nachher einen Compiler, der das in natives JavaScript übersetzt.

Und das ist eben eine andere Idee, die es gibt, dass man sagt, okay, PHP aus nachvollziehbaren Gründen kann das nicht und will das vielleicht auch nicht. Aber wir machen ein PHP-Superset, was diese Features kann und was dann so einen dedizierten Compile-Schritt da drin hat, der es in normales PHP umwandelt und dann wird es ausgespielt.

Aber auch da viele gute Ideen, aber nicht so richtig irgendwas spruchreif. Die Idee finde ich natürlich eigentlich klasse, weil man sieht ja eben genau in TypeScript, wie gut es funktioniert und dass dann die Sprache, die da drunter liegt, viele Sachen auch adaptiert nach und nach, weil sie eben in diesem Superset ausprobiert werden können, finde ich an sich erstmal einen coolen Ansatz.

Gab es da schon so ein paar, insbesondere Privatmenschen, die da mal so interessante Konzepte gemacht haben? Kann man sich alles auf GitHub anschauen? Aber da fehlt halt wirklich so wie Microsoft so ein richtig dicker Player dahinter, der sagt, so wir machen das jetzt vernünftig und ordentlich. Tja, mich würde es nicht wundern, wenn Jetbrain und oder Laravel da auch in der Zukunft auf die Idee kommen, sowas zu machen. Die sind ja relativ dicke Player da im PHP-Business. Ich glaube, wir sind schon relativ weit gekommen jetzt, was PHP angeht. Wir haben alles nur an der Oberfläche angekratzt. Also wenn wir jetzt die Historie uns angucken, da kann man jetzt auf jedes einzelne Jahr, auf jede einzelne Version noch eingehen, auf die Unterversionen.

Man könnte in die Features, die noch kommen, weiter einsteigen. Vor- und Nachteile können wir hier stundenlang ausbreiten. Ich glaube, für so einen groben Überblick reicht das im ersten Moment. Und ich denke, da werden sicherlich noch Folgen kommen, wo wir uns dann spezielle Themen raussuchen, die wir dann nochmal weiter bearbeiten und dann wirklich da auch einsteigen.

Das macht, glaube ich, mehr Sinn als jetzt hier alles versuchen, breitzutreten. Sonst wird die Folge ja auch zu lang. Was mich noch als Rauswerfer interessiert, nachdem wir das jetzt mal grob skizziert haben, Felix, PHP bei Genen-IT-Systeme, ist das ein sinkender Stern oder ein aufsteigender Stern?

Hm, das ist eine coole Frage. Und ich bin mir sicher, dass uns PHP in den nächsten Jahren definitiv begleiten wird, weiterhin. Das heißt nicht, dass wir nicht offen für Alternativen sind, aber ich glaube, für eine ganz breite Basis an Webseiten ist es im Moment auch das richtige Tool.

Gerade wenn ich an Laravel denke, das ist ein super Framework, mit dem wir geniale Anwendungen schreiben können, die super funktionieren.

Und da fällt mir kein Grund ein, warum wir davon Abstand nehmen sollten. Wie gesagt, alles immer mit dem Gedanken, dass man offen für Neues ist und wenn irgendwas sich besser bewährt oder sich besser anfühlt, dann steigen wir gerne darauf um.

Aber für den Moment ist PHP besser als ein Ruf, würde ich behaupten. Ich finde es auch einfach sehr elegant, dass wir damit so ein breites Spektrum an Anforderungen bei uns abdecken können. Nämlich zum einen klassische Webseiten bauen mit WordPress oder sowas, Online-Shops kriegen wir damit hin und eben komplexe, wirklich Backend-Anwendungen mit Laravel.

Und das ist eigentlich so ein Spektrum, was alles abbildet, was wir so machen, in derselben Sprache. Und das ist einfach total charmant. Da kann man auch die Leute zwischen den Themen, also zwischen den Projekten hin- und hertauschen und die kennen sich mit der Sprache aus und alles. Also wirklich genau das, was wir eigentlich brauchen. Ja, und das passt natürlich sehr gut zu unserem USP, zu einem Unique Selling Point, dass wir eben Experten in den Sachen sein wollen, die wir einsetzen, im Speziellen dann in Web-Technologien.

Und das können wir genau dann sein, wenn wir Experten in den Programmiersprachen sind. Und die Programmiersprachen, die wir im Wesentlichen einsetzen, sind dann ja JavaScript, TypeScript und im Backend dann PHP mit Laravel.

Und man kann nur eine Expertise in der Sprache haben, die man tagtäglich benutzt. Und in dem Moment, wo man zwei, drei Sprachen parallel macht, fängt das irgendwann an zu verwässern. Und deswegen ist es für uns genial, wenn wir uns auf wenig Sprachen konzentrieren können und fast alle Entwicklenden auch in diesen Sprachen dann unterwegs sind,

weil wir uns dann natürlich gegenseitig auch pushen können. Und da, genau wie du sagst, ist PHP natürlich mit diesem breiten Spektrum eine super Sprache für uns. Fantastisch, Felix. Es hat mich sehr gefreut, in das Rabbit Hole mal abzusteigen. Das sind ja auch so Sachen, mit denen ich mich sonst nicht so beschäftigt habe, wie es eigentlich hinter den Kulissen von PHP aussieht. Ich habe immer nur gejammert, keine Generics, aber jetzt weiß ich auch mal, warum es das noch nicht gibt. Ja, war auch total spannend für mich. Und lieber Kay, ich würde sagen, damit schließen wir die Folge hier und sehen uns beim nächsten Mal.

Bis zum nächsten Heißgetränk, Felix. Tschüss.