- Die meisten Kritiken wie „PHP sucks“ beruhen darauf, dass sie PHP seit 2012 nicht mehr angesehen haben
- Seit PHP 5.4 hat sich viel verändert, und es lohnt sich, die Sprachentwicklung seitdem zu betrachten
Wichtige Änderungen seit PHP 5.4
- Traits (PHP 5.4)
- Ermöglichen Komposition statt Vererbung
- Man kann Traits haben, die in jede Klasse eingebunden werden können
- Kurze Array-Syntax
- Statt
array() können eckige Klammern verwendet werden
- Array-Destrukturierung
- Arrays können direkt Variablen zugewiesen werden, ohne sie zuerst temporären Variablen zuzuweisen
- Variadische Funktionen erster Klasse
- Mit der
...-Syntax kann eine beliebige Anzahl von Argumenten an eine Funktion übergeben werden
- Generatoren
- Speicherintensive Aufgaben lassen sich speichereffizient ausführen
- Anonyme Klassen
- Neue Klassen können erstellt werden, ohne neue Dateien anzulegen
- Sie können wie andere Klassen auch Interfaces implementieren
Wichtige Änderungen seit PHP 7
- Nachgestellte Kommas
- Bei Funktions- oder Methodenaufrufen muss man sich nicht mehr darum kümmern, ob ein nachgestelltes Komma verwendet wird
- Arrow Functions
- Etwas anders als in JavaScript, aber eine sinnvolle Ergänzung der Sprache
- Null-Koaleszenzoperator
- Vor der Zuweisung eines Werts ist kein Null-Check mehr nötig
- Null-Koaleszenz-Zuweisungsoperator (PHP 7.4)
- Es gibt auch einen verkürzten Zuweisungsoperator für den Null-Koaleszenzoperator
- Weak Maps (PHP 7.4)
- Deutlich speicherschonender als Arrays
- Objekte können als Schlüssel verwendet werden
Änderungen seit PHP 8
- Nullsafe-Operator
- Vor dem Aufruf einer Methode ist kein Null-Check mehr nötig
- Benannte Argumente
- Es ist nicht mehr nötig,
null zu verwenden, um optionale Argumente zu überspringen
- Attribute (Annotationen)
- Können verwendet werden, um Annotationen zu Klassen, Methoden, Argumenten oder Eigenschaften hinzuzufügen
- Verbesserte Fehlerbehandlung
- Es sind keine Ausnahmevariablen mehr nötig, um
false zurückzugeben
- Match-Ausdruck
- Eine kompaktere und besser lesbare Alternative zu langen
switch-Anweisungen
- Enums (PHP 8.1)
- Enum-Klassen mit Werten und Methoden können erstellt werden
- Sie können auch als Type Hints verwendet werden
- Typsicherheit
- Mit typisierten Argumenten, Rückgabetypen, Union Types, Intersection Types usw.
- Auch für Enums lassen sich Type Hints verwenden
- Constructor Property Promotion (PHP 8.0)
- Schluss mit ausufernden Konstruktoren
- Hilft, Boilerplate-Code zu reduzieren
- Readonly-Eigenschaften (PHP 8.1)
- Eigenschaften können per Keyword als schreibgeschützt markiert werden
Performance
- Beim Wechsel von PHP 5.6 auf 7 gab es eine Performance-Steigerung von 400 %
- Beim Wechsel von PHP 7 auf 8 gab es eine Performance-Steigerung von 20 %
- Für die meisten Webentwicklungszwecke bietet PHP ausreichend Performance; für speziellere Anwendungsfälle empfiehlt sich eine spezialisierte Sprache
Fazit
- PHP ist nicht tot und auch nicht mehr das Schlechteste. Seit 2012 hat sich die Sprache erheblich verändert, und es ist Zeit, die eigene Meinung dazu zu aktualisieren.
- Durch die Einführung verschiedener Funktionen wie Traits, kurzer Array-Syntax und Array-Destrukturierung ist PHP effizienter, lesbarer und wartungsfreundlicher geworden.
- Nimmt man noch die verbesserte Fehlerbehandlung, die Einführung von Attributen und das lange erwartete Erscheinen von Enums hinzu, ist klar, dass sich PHP zu einer soliden und zuverlässigen Wahl für die Webentwicklung entwickelt hat.
- Wenn also jemand sagt, PHP sei das Schlechteste, kann man selbstbewusst sagen, dass diese Person einfach in der Vergangenheit feststeckt.
Meinung von GN⁺
- Betrachtet man die sprachlichen Veränderungen in PHP, sieht man klar, dass es nicht mehr das PHP von früher ist. Dennoch scheinen viele Entwickler noch immer an alten Wahrnehmungen festzuhalten.
- Traits, kurze Array-Syntax und Destrukturierungszuweisungen sowie viele weitere Funktionen machen Code kompakter und besser lesbar. Das dürfte auch die Wartbarkeit verbessern.
- Auch Funktionen wie Generatoren oder Weak Maps, die die Speichereffizienz verbessern, fallen auf. Sie dürften bei der Verarbeitung großer Datenmengen nützlich sein.
- Es gab zudem Veränderungen wie Enums oder Verbesserungen bei der Typsicherheit, die die sprachliche Reife erhöhen. Das dürfte das Schreiben von Clean Code erleichtern.
- Besonders beeindruckend ist die Performance-Verbesserung in PHP 8. Laut tatsächlichen Benchmark-Ergebnissen soll sie mit NodeJS und Go vergleichbar sein.
- Die Modernisierung von Legacy-PHP-Projekten bleibt jedoch keine einfache Aufgabe. Die Code-Migration kann viele Ressourcen erfordern.
- PHP ist weiterhin die Basissprache vieler Open-Source-Ökosysteme wie WordPress. Es ist daher schwer, den Wert von PHP allein anhand sprachlicher Eigenschaften abzutun.
40 Kommentare
Das sind Kommentare, an denen man gut erkennen kann, warum PHP immer noch mies ist.
Glückwunsch dazu, aus Scheiße Scheiße zu machen, die nicht stinkt.
Wenn sich die Gelegenheit ergibt, probiert bitte auch mal etwas anderes als Scheiße zu essen : )
Es gibt wirklich sehr viele Meinungen dazu. Ich bin kein PHP-Entwickler. Wenn ich sehe, wie in der Community eine Abneigung gegen PHP geschürt wird, habe ich das Gefühl, dass bei Juniors genau solche Emotionen entstehen und sich dieser Teufelskreis wiederholt. Ein echter Handwerker gibt niemals seinem Werkzeug die Schuld. An alle PHP-Entwickler: Weiter so, ihr schafft das!
Als PHP-Entwickler … die Arroganz von Leuten, die andere Sprachen benutzen, ist wirklich zum Fluchen.
Ich kann absolut nicht verstehen, warum manche unbedingt die Sprache anderer schlechtmachen müssen.
Auch ich habe nach PHP mal auf Java umgesattelt, auch Python ausprobiert und auch Node.js verwendet, aber …
jede Sprache hat ihre eigene Philosophie oder Unbequemlichkeiten, die man nicht nachvollziehen kann – warum also ausgerechnet PHP ständig niedergemacht werden muss, ist mir unbegreiflich.
Verdammt, warum verhalten sie sich so?
Die Situationen, die als Bugs von PHP bezeichnet werden, sind in der Praxis beim Entwickeln
oft Syntax oder Strukturen, die man kaum benutzt, selbst wenn man sie nicht kennt,
und so ein Legacy-Gepäck gibt es auch in anderen Sprachen bis zu einem gewissen Grad.
Ich habe es wirklich satt.
Es tut mir leid, dass ich über die Technik gesprochen habe, mit der Sie Ihren Lebensunterhalt verdienen. Unabhängig von meiner Absicht habe ich letztlich die Gefühle von koxel verletzt, und dafür trage ich die Verantwortung.
Ich habe allerdings nur das aufgeschrieben, was ich als Junior unter PHP-Entwicklern empfunden habe, die meinten, improvisiertes Coding sei alles. Manche PHP-Entwickler erkennen nicht einmal an, dass sich Best Practices ändern, und weigern sich, das zu akzeptieren. Das fand ich frustrierend. Derzeit arbeite ich vor allem im Frontend-Bereich, aber ich denke, man kann auch die Art und Weise, wie JavaScript entwickelt wird, durchaus kritisieren. Ich glaube nicht, dass irgendeine Sprache einen absoluten Vorrang hat; je nach Situation sollten unterschiedliche Maßstäbe gelten.
Wenn ich das so sehe, scheint das Problem eher die Struktur zu sein, die Anfängern erlaubt, fehlerhafte Programme zu schreiben.
Aber ist das nicht in anderen Sprachen genauso?
Genau deshalb gibt es doch in jeder Sprache so etwas wie Best Practices..
Bei WordPress liegt der Anteil der Nutzung von PHP-Versionen 5.6 oder älter bei unter 5%.
https://wordpress.org/about/stats/
Trotzdem hat WordPress 2023 die minimale Anforderung für PHP-Installationen auf 7.0 angehoben.
Persönlich ist meine Abneigung gegen PHP fast genauso groß wie meine Abneigung gegen JavaScript.
Im Vergleich zu den beiden wirkt selbst Python noch wie ein Engel.
Ich habe meine Karriere mit php begonnen und meinen Karrierehöhepunkt wohl ebenfalls mit php erreicht.
Heute verdiene ich meinen Lebensunterhalt zwar mit einer anderen Sprache,
aber für Side Projects oder als Hobby hole ich php immer noch gelegentlich hervor.
Ich finde, es ist nach wie vor ein reizvoller Kandidat.
Natürlich ist es etwas schade, dass es inzwischen viele Alternativen gibt,
aber
laravel vaporist gut.Ich arbeite zwar gerade nicht im Webdevelopment, aber da kommen Erinnerungen hoch.
Viele scheinen PHP nicht zu mögen. Ich habe PHP selbst etwa drei Jahre lang benutzt und durchgehend gedacht, dass die Sprache an sich wirklich wenig Reiz hat. Man könnte fast sagen, dass PHP der Grund war, warum ich, als ich mit RoR in Kontakt kam, völlig von der Eleganz der Sprache Ruby begeistert war.
Aber als PHP zum ersten Mal aufkam, war es gewaltig! Damals war es die Zeit, in der man Foren mit CGI schrieb oder baute. Die Agilität, die PHP damals bot, war sensationell. Es scheint tatsächlich so zu sein, dass PHP dem Webdevelopment große neue Horizonte eröffnet hat. :)
Aber neuer Wein gehört in neue Schläuche...
PHP ist als Sprache zwar immer noch die schlechteste überhaupt,
aber als Plattform (mir fällt schwer, dafür den passenden Begriff zu finden) ist PHP meiner Meinung nach besser, als man denkt.
Gerade bei Projekten von MVP bis frühe Wachstumsphase: Wenn man von vornherein festlegt, dass man später auf eine andere Sprache/Plattform/ein anderes Framework (meistens Spring) wechseln wird,
sind die Schwächen der Sprache danach nicht mehr so wichtig, und man sieht nur noch die Vorteile von PHP.
Weil man allein durch das Ändern von Dateien ohne Unterbrechung deployen kann, lässt sich Nutzerfeedback schneller umsetzen,
und die sparsame, effiziente Request-Queue-Verarbeitung, die PHP(-FPM) besser beherrscht als anderes, hilft dabei, unerwartet hohen Traffic (schnelles Wachstum in kurzer Zeit) gut auszuhalten.
Selbst wenn es Bugs gibt, fällt nicht gleich die ganze App aus, und weil man auch einigermaßen vor Memory Leaks geschützt ist, kann man sich auf Business-Logik + a konzentrieren.
Dazu kommt noch die niedrige Einstiegshürde: Selbst Entwickler, deren Hauptsprache etwas anderes ist und die PHP noch nie benutzt haben, können nach einer Woche Einarbeitung schon ganz gut damit arbeiten ...
All das wird mit zunehmender Größe zwar wieder zu Nachteilen werden (vielleicht sogar zu gravierenden) ...
Aber zumindest im MVP-Maßstab, wenn man Nutzerfeedback einsammeln, es blitzschnell umsetzen und schnell wachsen muss: Gibt es wirklich eine passendere Wahl als PHP?
Und wenn man sich bei der Einführung von PHP ohnehin schon sagt: „Wenn es größer wird, migrieren wir auf eine andere Sprache“, dann ganz ehrlich ... Why not?
Ich sehe das etwas anders: Wenn man allein ein MVP bauen will, braucht man ein Werkzeug, mit dem sich die drei Dinge DB-Schema, WAS und UI mit minimalem Coding umsetzen lassen. Und ich denke, dass es mit Ruby on Rails und Django hervorragende Alternativen zu PHP gibt.
Bei Django gilt: Definiert man per Active-Record-Pattern (wirklich ein altmodischer Begriff) nur die Modellklassen, bekommt man das DB-Schema und ein einigermaßen brauchbares CRUD-UI für das Backoffice gleich mit dazu. Es werden Werkzeuge für die Mindestanforderungen der Webservice-Entwicklung bereitgestellt, etwa Authentifizierung, Zugriffskontrolle, Formularvalidierung, DB-Migrations-Tools und Testwerkzeuge. Persönlich habe ich, seit ich Ende der 2000er mit Webprogrammierung angefangen habe, nie wieder eine Produktivität wie mit Django erlebt. Seit sich der SPA-Ansatz verbreitet hat und Frontend- und Backend-Rollen getrennt wurden, habe ich sogar eher das Gefühl, dass die Produktivität gesunken ist. Denn damit parallel gearbeitet werden kann, müssen mindestens zwei Beteiligte den User Flow verstehen und auf ein gemeinsames Protokoll abgestimmt arbeiten.
Wenn PHP den Anspruch hatte, eine Template-Sprache für Web-Apps zu sein, dann hätte die Sprache meiner Meinung nach auf Sprachebene Mittel zur Abwehr von Web-Sicherheitslücken bereitstellen müssen. Dass der moderne PHP-Stil auf ein Framework-basiertes Entwicklungsmodell setzt, kann man wohl als Beleg dafür sehen.
Und PHP wird schon seit Langem nicht mehr als universelle Skriptsprache propagiert.
Ich verstehe nicht, warum Sie eine Sprache mit einem Framework vergleichen.
Es gibt doch Laravel mit Konzepten von Ruby on Rails und Django.
Ich denke, PHP wird dann als sichere Allzwecksprache wahrgenommen werden, wenn Modern PHP nicht mehr als „modern“ gilt, sondern sich als Standard-Entwicklungsmethode für PHP etabliert hat und CMS einschließlich WordPress Modern PHP übernommen haben. Vertrauen wiederherzustellen erfordert im Allgemeinen mehr Aufwand, als es zu zerstören.
Das liegt daran, dass aus Gründen der Wahrung der Abwärtskompatibilität zugelassen wird, dass Einsteiger allein mit den Grundfunktionen von PHP unsichere Webservices erstellen können. Unter den ersten fünf Websites, die bei der Suche nach einem PHP-Tutorial erscheinen, gibt es außer der offiziellen PHP-Website kein Beispiel, das darauf hinweist, dass beim Ausgeben des Inhalts von Superglobalen zum Schutz vor XSS HTML-Escaping angewendet werden muss. Wenn die von ihnen offiziell bereitgestellten Guides Inhalte der Webentwicklung abdecken, übernimmt PHP dann nicht zwei Rollen zugleich: Sprache und Framework?
Was halten Sie davon, dass unter den Namen der Superglobalen verschiedene Elemente von HTTP standardmäßig bereitgestellt werden? Ich denke, dass der Umfang der Allgemeinverwendbarkeit und die Einsatzbereiche dadurch bestimmt werden, welche Inhalte eine Sprache ausdrückt.
Die von Ihnen als Beispiel genannten Superglobals wie
$_GETund$_POSTsind Werte, die offengelegt werden, wenn PHP im CGI- oder SAPI-Modus verwendet wird. Wenn PHP als CLI genutzt wird, werden diese Werte nicht bereitgestellt.Solche Superglobals sind eine Art API, die von Laufzeitumgebungen für die Ausführung von PHP wie PHP-CGI oder PHP-FPM bereitgestellt wird, und nicht Teil der PHP-Spezifikation als Sprache.
Auch das zuvor erwähnte „PHP, das sich als Template-Sprache versteht“, ist streng genommen nicht PHP selbst, sondern eher CGI als eine der PHP-Laufzeitumgebungen, die auf diese Weise genutzt werden soll.
Genauso sind auch die zahlreichen eingebauten PHP-Funktionen, die als Schwachstellen bezeichnet wurden, Funktionen, die von PHP-Erweiterungen bereitgestellt werden, und keine Fähigkeiten, die die „Sprache“ PHP selbst besitzt.
Wenn man Ihrer Argumentation folgt,
wäre JavaScript eine Sprache und zugleich ein Framework, das APIs nutzt, die vom Browser für die Kommunikation mit dem Browser bereitgestellt werden, und das von vornherein genau zu diesem Zweck entworfen wurde,
Java wäre zwar eine Sprache, aber faktisch ein Framework, das verwendet wird, um die zahllosen APIs des JDK zu nutzen,
und auch alle anderen Sprachen müsste man unabhängig von der Spezifikation der Sprache selbst als Framework betrachten, sobald sie Standardbibliotheken oder APIs bereitstellen.
Natürlich besteht hier eine untrennbare Beziehung, aber mit solchen Punkten zu behaupten, PHP sei ein Framework, ist wenig überzeugend.
Und selbst bis zum Stand von Mai 2024 scheint sich XSS nicht allein durch Verbesserungen auf Ebene der PHP-Syntax verhindern zu lassen, wenn man sieht, dass im WordPress-Core-Projekt weiterhin XSS gepatcht wird.
Frontend-Frameworks, serverseitige Template-Engines und Ähnliches wenden auf alle Inhalte, die aus Daten gerendert werden können, pauschal HTML-Escaping an und erzeugen nur dann auf ausdrücklich unsichere Weise Ausgabe, wenn das Escaping explizit deaktiviert wird. In PHP gibt es keinen allgemein anerkannten Weg, eine solche Verarbeitung pauschal anzuwenden. Hätten
echooderprintstandardmäßig Escaping unterstützt, hätte das zwar kurzfristig zu einer Flut nicht mehr funktionierenden Codes geführt, langfristig hätten aber viele Menschen wohl seltener den Fehler gemacht, Escaping zu vergessen.Ja, ich stimme der Sichtweise nicht zu, Sprache und Laufzeitumgebung getrennt zu betrachten, und ich denke, dass die Laufzeitumgebung die Sprache auf die eine oder andere Weise beeinflusst. Bei JavaScript gibt es mit Node.js und dem Browser zwei Laufzeitumgebungen, und bei Python gibt es viele Implementierungen, wobei Sie es so verstehen können, dass CPython dominiert.
Das Thema des Originalbeitrags ist auf syntaktische Verbesserungen beschränkt, aber ich wollte etwas in einem etwas breiteren Rahmen darüber sprechen als in diesem Framing.
> Außerdem denke ich, dass Laravel etwas ist, das nicht von Open-Source-Beitragenden, sondern von Unternehmen wie Rasmus oder Zend hätte kommen sollen, und zwar nicht 2011, sondern eher um 2007 herum – nicht als Einzelprojekt, sondern als offizielles Sprachfeature. Weil Python 3 einen Teil der Abwärtskompatibilität aufgegeben hat, gab es zwar Probleme bei der Einführung, aber ich finde, auch PHP hätte ungefähr zur Version 5 einmal gründlich bei der Abwärtskompatibilität aufräumen sollen. Es wirkt auch so, als kämen die Veränderungen bei PHP der Zeit immer mit etwas Verzögerung hinterher.
Das ist zugleich auch eine Antwort auf den obigen Kommentar.
Aus der von Ihnen genannten Perspektive betrachtet, kann ich schon nachvollziehen, dass man PHP gewissermaßen als eine Art Web-Framework auffassen könnte.
Trotzdem denke ich nicht, dass PHP Funktionen wie den beispielhaft genannten XSS-Filter, Escaping und Ähnliches von Haus aus bereitstellen muss.
Das am weitesten verbreitete PHP-FPM sowie Django und RoR befinden sich nicht auf derselben Ebene. Eher vergleichbar sind Flask, Sinatra und Express.
PHP-FPM übernimmt nicht mehr als Routing (verzeichnisbasiert), Request-Auswertung (
$_GET,$_POST,$_FILE,$_COOKIE), Response-Ausgabe (echo,print) und Session-Management ($_SESSION).Ist Flask denn anders?
Wenn man in Flask eine HTML-escapte Response zurückgeben will, reicht ein simples return nicht aus.
https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
Ist Sinatra denn anders?
Auch dort muss man entsprechend eine separate Escaping-Bibliothek verwenden.
https://sinatrarb.com/faq.html#escape_html
Ist Express denn anders?
Auch hier gilt dasselbe: Man braucht eine separate Escaping-Bibliothek.
https://expressjs.com/en/resources/middleware.html
Alle als Beispiel genannten Bibliotheken werden von dem jeweiligen Framework nicht offiziell bereitgestellt.
Warum also sollte PHP solche Funktionen unbedingt offiziell selbst bereitstellen müssen?
Wenn man mit den Gründen argumentiert, die ohnehin schon viele nennen, etwa:
„Welches verrückte Framework legt Request-Daten als Superglobals offen? Selbst wenn das sicherheitstechnisch kein Problem wäre, ist das gegenüber den Nutzern einfach unhöflich!“
und daraus ableitet, PHP sei Müll, dann meinetwegen.
Aber dem von Ihnen genannten Grund, dass „die Grundfunktionen von PHP nicht ausreichend genug sind wie das, was ein Full-Stack-Framework bereitstellt“, kann ich ... zumindest nur schwer zustimmen.
So wie mit Nestjs ein Werkzeug entstanden ist, um Express moderner und systematischer zu verwenden, könnte man sagen, dass mit Laravel ein Werkzeug entstanden ist, um PHP moderner und systematischer zu verwenden ...
Fallen dann nicht eher – wie ich in meinem ursprünglichen Kommentar schrieb – die spezifischen Vorteile von PHP(-FPM) ins Gewicht als die Nachteile, die im Vergleich zu anderen Frameworks (Sprachen) genannt werden?
Wenn ich mich an alte Zeiten zurückerinnere, denke ich, dass wir zumindest einige der PHP-Fehler im Projekt hätten vermeiden können, wenn sich wenigstens die Kombination aus Slim und Twig allgemein durchgesetzt hätte. Natürlich ließ sich das damals nicht einführen, weil andere PHP-Entwickler an nacktes PHP-Coding gewöhnt waren. Glücklicherweise gehörte PDO zur Standardbibliothek, sodass wir uns immerhin gegen SQL-Injection absichern konnten.
Zu der im ursprünglichen Kommentar erwähnten Begrenzung der Auswirkungen von Bugs oder zur Verarbeitungsleistung habe ich weder eine klar negative noch positive Meinung. Ich finde, dass solche Funktionen durchaus nützlich sind, aber Probleme wie ein sprunghafter Anstieg des Durchsatzes oder des Speicherverbrauchs sind Themen, über die man in einer Wachstumsphase mindestens einmal nachdenken muss. Deshalb halte ich es für gut, wenn solche Probleme möglichst früh in einer expliziten Form sichtbar werden.
> Natürlich ließ sich das damals nicht einführen, weil andere PHP-Entwickler an chaotisches PHP-Coding gewöhnt waren.
> Weil es am meisten Zeit kostet und am schwierigsten ist, die Leute zu verändern, die mit PHP entwickeln können,
Ich persönlich finde, dass mit PHP selbst entweder nichts Grundlegendes falsch ist, dass es ausreichende Gegenmittel gibt oder dass die Unterschiede höchstens in einem Rahmen liegen, der – wie bei anderen Sprachen auch – nachvollziehbare Gründe hat. Aber das von Ihnen angesprochene Personalproblem … das ist in Wirklichkeit vielleicht das größte Problem.
Entwickler, die PHP ernsthaft einsetzen könnten, haben sich schon vor langer Zeit vom alten PHP angewidert abgewandt und PHP längst verlassen,
und die meisten derjenigen, die geblieben sind, sind Leute, die PHP selbst dann nicht wirklich richtig betrachten würden, wenn es sich noch so sehr weiterentwickelt – oder die gar nicht die Mittel haben, es angemessen zu beurteilen …
Bei Projekten vom Typ MVP+a, für die PHP meiner Meinung nach geeignet ist, haben die erfahrenen Leute aus der ersten Gruppe keinen Grund, sich zu beteiligen,
und selbst wenn sie mitmachen würden, würden sie entweder kein PHP wählen, oder, falls doch, würde das Ganze in dem Moment im Chaos enden, in dem ein oder zwei Nutzer aus der zweiten Gruppe dazukommen würden … haha
Zumindest hierzulande ist es nicht leicht, überhaupt Leute zu finden, die zufriedenstellend PHP entwickeln können.
So fällt PHP wieder aus der Auswahl, das durchschnittliche Niveau der verfügbaren Leute sinkt immer weiter, und das wiederholt sich endlos in einem Teufelskreis.
~~Wenn man schon so weiter dafür trommelt, müsste es zumindest mehr Fälle geben, in denen selbst in kleinen 1- bis 3-Personen-Projekten~~ ernsthaft versucht wird, ein ordentliches PHP-Projekt aufzusetzen, damit dieser Teufelskreis durchbrochen wird.
Auch ich verdiene mit PHP ehrlich gesagt nicht besonders viel. Die Beschaffung geeigneter Leute ist einfach zu schwierig, deshalb ist die Realität so, dass man PHP gar nicht als Main-Stack einsetzen kann, selbst wenn man es gern tun würde …
Das liegt an den Unterschieden zwischen allgemeinen Programmiersprachen und PHP in der Art, wie HTML-Seiten erzeugt werden. Flask hat die Nutzung einer Template-Engine zumindest seit der Veröffentlichung von Version 1.0 empfohlen und wurde so entworfen, dass es auf eine Template-Engine angewiesen ist. Es trennt HTML-Seiten und serverseitige Daten bewusst voneinander und unterstützt die Arbeit auf Template-Ebene. Ich denke, dabei wurden die Eigenschaften des zu lösenden Problems und die Nutzungsgewohnheiten der Menschen berücksichtigt.
Im Gegensatz dazu wird bei PHP die Standardausgabe direkt zu einem Teil der Seite, und die Grenze zwischen serverseitigen Daten und der HTML-Seite ist unscharf. Was per
printausgegeben wird, landet unverändert in der resultierenden Seite, und das Escaping muss der Entwickler explizit selbst vornehmen. Ein Design, bei dem manhtmlcharacterescapesan alle externen Daten anhängen muss, wurde von den Menschen nicht gut angenommen. Eigentlich wollten die Leute unbewusst Templates, aber bei PHP wirkt es so, als sei das Ziel der Nutzer, nämlich HTML-Seiten zu erzeugen, nicht berücksichtigt worden.Der Grund, warum diese Funktionalität in die Standardbibliothek oder sogar in die Sprache selbst gehört, ist, dass dies unter Berücksichtigung von PHPs Umgebungsaufbau und Code-Bereitstellungsweise die effektivste Methode ist. Entwicklungsumgebungen waren durch den LAMP-Stack, Betriebsumgebungen durch Webhosting standardisiert, und da man an das einfache Hochladen per FTP gewöhnt war, war die Möglichkeit, zusätzliche Pakete bereitzustellen, geringer als bei allgemeinen Programmiersprachen. Man kann Einsteigern auch nicht verlangen, Module zu installieren. Als verbleibende Optionen bleiben nur die Standardbibliothek und die offizielle Dokumentation.
> Die Leute wollten unbewusst Templates, aber bei PHP scheint der Zweck der Nutzer, nämlich HTML-Seiten zu erzeugen, nicht berücksichtigt worden zu sein.
Dem kann ich nicht besonders zustimmen.
Allenfalls in der Zeit von PHP3, als es im Grunde nur darum ging, eine C-API leicht über CGI verfügbar zu machen, könnte man wie von Ihnen gesagt behaupten, dass es als Template-Zweck verwendet wurde, aber ...
Spätestens ab PHP 4.2 war die Umgebung bereits auf einem Niveau, das eine hinreichend allgemeine Nutzung ermöglichte.
Es war zu einer Umgebung geworden, in der man erwarten konnte, dass Code über die CLI ausgeführt wird, und wie Sie im vorherigen Kommentar erwähnt hatten, passt die Aussage „Laravel hätte etwa 2007 nicht als einzelnes Projekt, sondern als offizielles Sprachfeature erscheinen sollen“ überhaupt nicht zur damaligen Ausrichtung von PHP.
Die Existenz von Smarty, einer 2004 veröffentlichten Template-Engine für PHP, und CodeIgniter, einem 2006 veröffentlichten MVC-Framework für PHP, widerlegt schon, dass PHP selbst eine Template-Sprache sei; zugleich kann man daraus schließen, dass sich in der PHP-Community bereits ein Konsens gebildet hatte, es gerade nicht so zu verwenden.
> Frontend-Frameworks, serverseitige Template-Engines usw. wenden auf alle Inhalte, die aus Daten gerendert werden können, pauschal HTML-Escaping an und erzeugen nur dann auf explizite Anweisung hin unsichere Ausgabe, wenn das Escaping bewusst aufgehoben wird.
Auch dieser Teil des vorherigen Kommentars ist, verglichen mit der damaligen Entwicklung von PHP, meiner Meinung nach nicht wirklich korrekt.
Seit der ersten Veröffentlichung von django im Jahr 2005 war HTML-Escaping zunächst mehrere Jahre lang keine Standardeinstellung. Entwickler mussten den Escape-Filter bewusst selbst setzen. Selbst jinja, das in Python bis heute verwendet wird, führt HTML-Escaping noch immer nicht automatisch durch.
Zu dem Zeitpunkt, als automatisches Escaping allgemein als üblich galt, hatte PHP seine Identität als Template-Sprache schon lange hinter sich gelassen. (Auch wenn die Nutzer, die PHP damals gedankenlos verwendeten, das vielleicht nicht wollten, kann man umgekehrt auch sagen, dass PHP sich da bereits entschieden hatte, solche Nutzer nach und nach auszuschließen.)
PHP ist längst keine Sprache mehr für einen solchen Zweck, daher gibt es keinen besonderen Grund, solche Funktionen in der Standardbibliothek oder der Sprache standardmäßig zu aktivieren; aus Sicht von PHP, das als allgemeine Sprache funktionieren will, hat die von Ihnen erwähnte Funktion
htmlcharacterescapesihre Rolle bereits ausreichend erfüllt.> Da die Betriebsumgebung beim Webhosting standardisiert ist und man an das Hochladen per FTP gewöhnt ist, ist die Möglichkeit, zusätzliche Pakete bereitzustellen, im Vergleich zu allgemeinen Programmiersprachen geringer.
Auch dem kann ich nur schwer zustimmen. Schon seit weit mehr als einem Jahrzehnt wurde etwa
gitsehr aktiv genutzt. Sogar unmittelbar nach der Veröffentlichung von Docker wurde Deployment mit Docker bereits in erheblichem Umfang ausprobiert, und auch heute wird es noch so eingesetzt.Vieles von dem, was Sie ansprechen, scheint mir eher dann relevant zu sein, wenn man nicht mit PHP selbst, sondern auf einem mit PHP entwickelten CMS arbeitet.
Ich mag diese Formulierung zwar nicht, aber das sind wohl eher solche Fälle, in denen selbst PHP-Entwickler einen nicht wirklich als Entwickler betrachten ...
Die Auto-Escaping-Funktion von jinja zeigt, dass meine Behauptung falsch war und das, was Sie erwähnt haben, stimmt.
> Auch dem oben Gesagten kann ich nur schwer zustimmen. Schon seit weit mehr als einem Jahrzehnt wurden git und Ähnliches sehr gut genutzt. Sogar kurz nach der Veröffentlichung von Docker wurde Deployment mit Docker bereits vielfach ausprobiert, und auch heute wird es noch so verwendet.
Meine PHP-Erfahrung ist auf 2014 stehengeblieben, und damals gab es Docker noch nicht. Git konnte ich auch nicht einführen, weil dafür die Arbeitsweise hätte geändert werden müssen. Wenn man so etwas im tatsächlichen Arbeitsumfeld einführen will, braucht es einen gemeinsamen Konsens, und in meiner Situation war das nicht möglich.
> Ich mag solche Formulierungen nicht, aber so ein Fall, in dem selbst PHP-Entwickler nicht als richtige Entwickler behandelt werden ...
Rückblickend habe ich wohl unter Leuten gearbeitet, die selbst nicht als Entwickler behandelt wurden.
Die von Ihnen als Beispiel genannten Funktionen von Django – Authentifizierung, Zugriffskontrolle, Formularvalidierung, DB-Migrations-Tools und Testwerkzeuge – werden in PHPs Laravel ebenfalls vollständig bereitgestellt.
Authentifizierung: https://laravel.com/docs/11.x/authentication
Zugriffskontrolle: https://laravel.com/docs/11.x/authorization
Formularvalidierung: https://laravel.com/docs/11.x/validation
DB-Migrationen: https://laravel.com/docs/11.x/migrations
Tests: https://laravel.com/docs/11.x/testing
Außerdem gibt es – teils als externe, teils als kostenpflichtige Bibliotheken – auch Lösungen, die ein bestehendes DB-Schema in Modelle und Migrationscode exportieren oder umgekehrt arbeiten können; ebenso existiert mit https://nova.laravel.com/ eine Lösung, die ein sauberes Backoffice inklusive CRUD-UI bereitstellt.
Nahezu alle Funktionen, die Django hat, existieren auch in Laravel.
(Schon allein deshalb, weil beide letztlich das Konzept von RoR übernommen haben, ist es nur natürlich, dass die bereitgestellten Funktionen ähnlich sind.)
Trotzdem bietet Laravel-PHP im Gegensatz zu Django-Python zusätzlich die Vorteile, die ich in meinem ursprünglichen Kommentar erwähnt habe.
Dass PHP als Sprache für Web-App-Templates konzipiert wurde, ist eine unbestreitbare Tatsache,
aber es erscheint mir inzwischen etwas unfair, sie auch heute – fast zehn Jahre nachdem sich ein moderner PHP-Stil etabliert hat – nur noch als reine Template-Sprache zu betrachten.
Ich habe mir Nova angesehen, weil es verlinkt wurde, aber auch das ist offenbar eine kostenpflichtige Lizenz. Auch wenn es funktional dem Django-Admin ähnelt, der in Projekt-Tutorials klar genannt wird und sofort einsetzbar ist, scheint es bei der Zugänglichkeit Unterschiede zu geben.
Außerdem denke ich, dass Laravel nicht von Open-Source-Mitwirkenden, sondern von Rasmus oder Unternehmen wie Zend nicht 2011, sondern eher um 2007 nicht als einzelnes Projekt, sondern als offizielle Sprachfunktion hätte erscheinen sollen. Zwar gab es bei Python 3 wegen des teilweisen Verzichts auf Abwärtskompatibilität Probleme bei der Einführung, aber ich finde, dass auch PHP ungefähr zur Version 5 eine große Bereinigung der Abwärtskompatibilität hätte durchführen sollen. Es wirkt auch so, als kämen die Veränderungen bei PHP dem Zeitgeist immer mit einer gewissen Verzögerung hinterher.
Da ich inzwischen persönlich nicht mehr in der Position bin, in die Webentwicklung einzusteigen, werde ich mich wohl nicht für PHP entscheiden.
Sie verwechseln ständig die Sprache mit dem Framework.
Ich glaube nicht, dass es nötig ist, denselben Inhalt an mehreren Stellen als Kommentar zu posten. Möchten Sie Aufmerksamkeit erregen?
Natürlich wird es im Vergleich zu früher besser, aber wenn man jetzt noch PHP verwenden will, scheint Node.js oder Python vielseitiger einsetzbar zu sein.
Der PHP-Boom kommt.
Es wird mit keinem Wort erwähnt, wie sehr sich das PHP-Ökosystem, die Deployment-Methoden, das Ausführungsmodell und die Art des Debuggings in den letzten zehn Jahren verbessert haben. Da es am meisten Zeit braucht und am schwierigsten ist, die Menschen zu verändern, die wissen, wie man mit PHP entwickelt, erwarte ich ehrlich gesagt auch keine große Besserung. Vor allem, weil der verlinkte Beitrag ein Marketing-Blog eines PHP-Freelancers ist, sollte man ihn besonders selektiv aufnehmen.
In den letzten 10 Jahren sind laut den PHP-Nutzungsstatistiken auf Basis von Composer-Paketen (vergleichbar mit der Verbreitung über npm bei Node) PHP-Versionen unter PHP 5 praktisch vollständig verschwunden, und das PHP-Ökosystem ist schon seit Langem auf Composer zentriert.
Einige CMS wie WordPress, Gnuboard usw. stehen davon völlig losgelöst.
Abgesehen von CMS ist das Ökosystem in der oben beschriebenen Lage.
Aus Sicht von jemandem, der PHP benutzt, ist PHP immer noch die schlimmste Sprache.
Andere Sprachen sind nämlich besser geworden.
Hacker-News-Kommentar
Zusammenfassung:
fopen()keinen Fehlercode erhalten konntePHP: ein Fraktal schlechten Designs (auf Koreanisch)
Ein 12 Jahre altes Dokument, lol
Ein 2012 verfasstes Dokument immer noch....
Denken Sie, dass PHP sich ohne Weiterentwicklung immer noch genau auf dem Stand von 2012 befindet..?
Nun ja, dass es als Sprache ohne wirkliches Fundament begonnen hat, lässt sich natürlich nicht leugnen. Haha
Hier ist der Link zur Übersetzung des erwähnten englischen Dokuments..
So schlecht PHP auch gewesen sein mag, es wäre doch kaum vorstellbar, dass die Probleme von damals heute noch unverändert bestehen.
Schon die Wartung ist ein Problem. Wenn schon das Design auf diesem Niveau von Grund auf falsch ist, soll dann ein Versionsupgrade die Qualität verbessert haben? Das ist nur deshalb ein Problem, weil dabei die Abwärtskompatibilität massiv zerstört wurde. Schon die Vergleichsoperatoren sind seltsam – was soll man da noch machen?
Es scheint, als hätte man einfach die koreanische Übersetzung des 4. Links aus der Hacker-News-Zusammenfassung bereitgestellt, haha.