- 「PHPはダメだ（PHP Sucks）」という批判の多くは、2012年以降のPHPを見ていないことに起因している
- PHP 5.4以降で多くの変化があり、それ以降の言語の変化を見ていく必要がある
PHP 5.4以降の主な変化
- Traits (PHP 5.4)
- 継承の代わりにコンポジションを使えるようにする
- すべてのクラスに含められるtraitを持てる
- 短縮配列表記
- 配列の分割代入
- 可変長引数
- ジェネレーター
- 無名クラス
- 新しいファイルを作らずに新しいクラスを作成できる
- 他のクラスと同様にインターフェースを実装できる
PHP 7以降の主な変化
- 末尾カンマ
- 関数呼び出しやメソッド呼び出しで末尾カンマを使える
- アロー関数
- JavaScriptとは少し異なるが、言語への良い追加機能
- Null合体演算子
- Null合体代入演算子 (PHP 7.4)
- WeakMap (PHP 7.4)
- 配列よりもメモリ効率がはるかに良い
- オブジェクトをキーとして使える
PHP 8以降の変化
- Null安全演算子
- メソッドを呼ぶ前にnullチェックをする必要がない
- 名前付き引数
- オプション引数を飛ばすためにnullを使う必要がない
- 属性（アノテーション）
- クラス、メソッド、引数、プロパティにアノテーションを追加するのに使える
- 改善されたエラー処理
- match式
- 長いswitch文の代わりに、より簡潔で読みやすい方法
- Enum (PHP 8.1)
- 値とメソッドを持つenumクラスを作成できる
- 型ヒントとしても使える
- 型安全性
- 型付き引数、戻り値の型、union型、intersection型などを備える
- enumに対する型ヒントも使える
- コンストラクタプロパティ昇格 (PHP 8.0)
- 冗長なコンストラクタはもう不要
- ボイラープレートコード削減に役立つ
- 読み取り専用プロパティ (PHP 8.1)
- プロパティを読み取り専用として宣言できるキーワードがある
パフォーマンス
- PHP 5.6から7への移行で400%の性能向上
- PHP 7から8への移行で20%の性能向上
- ほとんどのWeb開発用途には十分な性能を提供し、それ以上に特殊な用途であれば専用言語の使用を推奨
結論
- PHPは死んでおらず、もはや最悪でもない。2012年以降、言語は大きく変化しており、この点について見方を改める時期に来ている。
- traits、短縮配列表記、配列の分割代入など多様な機能の導入により、PHPはより効率的で、読みやすく、保守しやすい言語になった。
- さらに、エラー処理の改善、属性の導入、長らく待たれていたenumの登場などを加味すれば、PHPがWeb開発のための堅実で信頼できる選択肢へと進化したことは明らかだ。
- したがって、誰かがPHPは最悪だと言うなら、その人は過去にとどまっているだけだと自信を持って言える。
GN⁺の見解
- PHPの言語的変化を見ると、もはや過去のPHPではないことが分かる。それでも多くの開発者が昔の認識にとどまっているようだ。
- trait、short array構文、分割代入など、コードをより簡潔で読みやすくする機能が多く追加された。これは保守性向上にも寄与しそうだ。
- ジェネレーターやWeakMapなど、メモリ効率を改善する機能も目立つ。大規模データ処理時に有用そうだ。
- Enumや型安全性の改善など、言語としての完成度を高める変化もあった。クリーンコードを書きやすくなることが期待される。
- 何よりPHP 8での性能改善が印象的だ。実際のベンチマークではNodeJSやGoに匹敵する性能を示すという。
- ただし、レガシーなPHPプロジェクトをモダナイズするのは簡単な課題ではない。コード移行に多くのリソースがかかる可能性がある。
- PHPは今なおWordPressなど多くのオープンソースエコシステムを支える基盤言語だ。単に言語的特徴だけを見てPHPの価値を過小評価するのは難しい。
40件のコメント
phpがなぜいまだにクソなのかがよく分かるコメントですね。
臭わないクソになったことをお祝いします。
機会があれば、クソ以外のものも食べてみることをおすすめします : )
意見がものすごくたくさん上がっていますね。私はPHP開発者ではありません。コミュニティがあおったPHP嫌悪論を見て、ジュニアの方々にそうした感情が生まれ、悪循環が繰り返されているように思います。職人は決して道具のせいにはしません。PHP開発者の皆さん、いつもファイトです。
PHP開発者として……他の言語を使う人たちの傲慢さには本当に悪態をつきたくなるほどです。
なぜああも他人が使う言語をけなさずにはいられないのか理解できません。
自分もPHPをやってからJavaに転向してみたり、Pythonもやってみたり、nodejsもやってみましたが……
言語ごとに理解しがたい思想や不便さはそれぞれあるのに、なぜPHPだけは叩かずにいられないのか理解できません……
ほんとに、なんであんなことをするのか。
PHPのバグと呼ばれるような状況も、実際に開発していると
それを知らなくてもほとんど使われない構文や構造だったりするし、
そういうレガシーは他の言語にもどれもある程度はあるわけで。
うんざりしますね。
自分が生業としている技術について論じたことをお詫びします。私の意図とは関係なく、結果的に koxel さんの気分を害してしまったのであれば、それは私の責任です。
ただ、私は場当たり的なコーディングがすべてだと思っている PHP 開発者たちの中でジュニアとして揉まれながら感じたことを書いただけです。PHP 開発者の中には、そのベストプラクティスが変化することさえ認めず拒む人もいます。その点がもどかしかったのです。私は現在の状況では主にフロントエンド業界の仕事をしていますが、JavaScript の開発手法についてもいくらでも批判すべき点はあると思っています。どの言語が絶対的に優位だとは考えておらず、状況に応じて異なる基準が適用されるべきだと考えています
言われてみれば、初心者の開発者でもまずいプログラムを書けてしまうような構造が問題だということなんだろうけど、
そういうのは他の言語でもみんな同じじゃないか。
言語ごとにベストプラクティスというものがあるのは、まさにそういう理由なのに..
WordPress基準では、PHP 5.6以下のバージョンの使用率は5%未満です。
https://wordpress.org/about/stats/
それでも2023年にWordPressは、PHPインストールの最低要件を7.0に引き上げました
個人的には、PHPが嫌いな度合いとJavaScriptが嫌いな度合いはほとんど同じですね。
この2つに比べれば、Pythonはまだかなりマシに見えるくらいです
キャリアのスタートは php で、キャリアのハイライトも php を通じて築いたように思います。
今は別の言語で生計を立てていますが、
今でもサイドプロジェクトや趣味では、ときどき php を取り出して使っています。
同じように、やはり魅力のあるやつだと思います。
もちろん最近はいろいろな代替も出てきていて少し残念ではありますが、
laravel vapor は悪くないです
今はWeb開発をしているわけではありませんが……昔を思い出しました。
PHPを嫌う方は多いですね。私もPHPを3年ほど使ってみて、言語として本当に魅力に欠けるとずっと思っていましたし、RoRに触れてRubyという言語の優雅さにすっかり惚れ込むようになったのも、ある意味ではPHPのおかげだったのかもしれません。
でも、PHPが最初に出てきた頃は本当にすごかったんです！ 当時はCGIで掲示板を作っていた時代でしたからね。そのときPHPがもたらした機敏さはセンセーショナルでした。PHPがWeb開発に大きな地平を切り開いたのは事実だと思います。 :)
とはいえ、新しい酒は新しい革袋に……
言語としてのPHPは依然として最悪ですが、
プラットフォーム（適切な表現が見つかりにくいのですが）としてのPHPは、思ったより悪くないと思います。
特にMVP〜成長初期のプロジェクトで、いずれ別の言語／プラットフォーム／フレームワーク（一般的にはSpring）へ移行すると最初から決めてしまえば、
その後は言語の欠点はそれほど重要ではなくなり、PHPの長所だけが目に入ってきます。
停止せずにファイルを修正するだけでデプロイできるので、ユーザーのフィードバックをより素早く反映でき、
PHP(-FPM)が他よりも特に得意な、こまやかなリクエストキュー処理は、予想外の大量トラフィック（短期間の成長）にもよく耐えられます。
バグがあってもアプリ全体が落ちず、メモリリークにもある程度強いぶん、ビジネスロジック+aに集中できますし、
PHPを一度も使ったことがない、他言語を主に使う開発者でも、1週間ほど見ればそれなりに扱えるほど難易度が低いです。
こうした点は、規模が大きくなれば（深刻かもしれない）欠点に変わるのでしょうが……
少なくともMVP規模で、ユーザーのフィードバックを受けて素早く反映し、急成長しなければならない状況で、PHPほど適した選択肢があるでしょうか。
しかもPHP導入を決める時点で「規模が大きくなったら別の言語へ移行する」とすでに腹を決めているわけですから、真面目な話…… Why not?
少し考えが違います。一人でMVPを作り上げるには、DBスキーマ、WAS、UIの3つを最小限のコーディングで実装できるツールが必要だと思います。そして、PHPの代替としては、Ruby on RailsとDjangoという優れた選択肢があると思います。
Djangoの場合、Active Recordパターン（ずいぶん古い言葉ですね）でモデルクラスだけ定義すれば、DBスキーマとそれなりに使えるバックオフィス向けのCRUD UIが出てきます。認証、アクセス制御、フォーム検証、DBマイグレーションツール、テストツールなど、最低限のWebサービス開発のための道具が提供されます。個人的には、2000年代後半にWebプログラミングを始めて以来、Djangoほどの生産性を経験したことはありません。SPA方式が流行し、フロントエンドとバックエンドの職種が分かれて以降は、むしろ生産性が下がったようにさえ感じます。少なくとも2人の作業者がユーザーフローを理解し、プロトコルをすり合わせた状態で作業してはじめて、並列に作業を進められるからです。
PHPがWebアプリ向けテンプレート言語を標榜したかったのなら、言語レベルでWeb脆弱性を防御する手段を提供すべきだったと思います。モダンPHPスタイルがフレームワークによる開発方式を採用したことが、その証拠だと言える気がします.
そして、phpは汎用スクリプト言語を標榜してからすでに長い時間が経っています。
なぜ言語とフレームワークを比較しているのか分かりません。
Ruby on Rails や Django のコンセプトを取り入れた Laravel があります。
モダンPHPがもはやモダンではなくなり、PHPの標準的な開発手法として定着し、さらにWordPressを含むCMSがモダンPHPを採用したとき、PHPは安全な汎用言語として人々に認識されるようになると思います。信頼を回復することは、一般的に信頼を壊すことよりも多くの努力を要します。
後方互換性の維持という名目で、初心者が PHP の基本機能だけを使って安全でないウェブサービスを作れてしまうことを許しているからです。
PHP tutorialで検索して上位 5 サイトのうち、XSS を防ぐためにスーパーグローバル変数 (superglobal) の内容を出力するときは HTML エスケープを適用すべきだという説明を含んでいた例は、PHP 公式サイト 以外にはありません。彼らが公式に提供しているガイドがウェブ開発の内容を含んでいるのですから、PHP は言語とフレームワークという 2 つの役割を果たしているのではないでしょうか?スーパーグローバル変数の名前として HTTP のさまざまな要素が標準で提供 されている点については、どう思われますか。私は、言語が表現している内容によって汎用性の範囲と用途が決まると考えています.
たとえば挙げられていた
$_GETや$_POSTのようなスーパーグローバル変数は、PHP を CGI、SAPI モードで使用したときに公開される値です。PHP を CLI で使用する場合、それらの値は公開されません。そのようなスーパーグローバル変数は、PHP を実行するランタイムである PHP-CGI や PHP-FPM などが公開する API の一種であって、言語としての PHP の仕様ではありません。
先に言及されていた「テンプレート言語を標榜する PHP」も、厳密に言えば PHP ではなく、PHP のランタイムの一つである CGI がそのように活用されることを意図している、ということです。
同様に、脆弱性として語られていた数多くの PHP 組み込み関数も、PHP のエクステンションが公開している関数であって、PHP という「言語」が持つ機能ではありません。
おっしゃる通りだとすると、
JavaScript はブラウザとやり取りするためにブラウザが公開する API を使う、しかもそもそもその目的で設計された言語でありフレームワークだということになり、
Java は言語ではあるものの、実際には JDK の数多くの API を活用するために使われるフレームワークだということになり、
そのほかのあらゆる言語も、言語そのものの仕様とは関係なく、標準ライブラリや API を提供するならすべてフレームワークだと見なさなければならなくなるでしょう。
もちろん切っても切り離せない関係であるのは確かですが、こうした点をもって PHP がフレームワークだと主張するのは、説得力にかなり欠けると思います。
そして2024年5月現在でも、WordPressコアプロジェクトでXSSのパッチが当てられていることを見ると、PHPの構文レベルでの改善だけではXSSを防げないようです。
フロントエンドフレームワークやサーバーサイドテンプレートエンジンなどは、データとしてレンダリングできるあらゆる内容に対して一律にHTMLエスケープを適用し、明示的にエスケープを解除したときにのみ安全でない形の出力を生成します。PHPには、そのような処理を一律に適用できる合意された方法がありません。
echoやprint文がデフォルトでエスケープをサポートしていれば、当面は動かないコードが続出したでしょうが、長期的には多くの人がエスケープを漏らすミスを減らせたはずです。はい、私は言語と実行環境を切り離して見るという見方には賛成しておらず、何らかの形で実行環境が言語に影響を与えると考えています。JavaScript の場合は Node.js とブラウザという 2 つの実行環境があり、Python には多くの実装がありますが、CPython が優勢だと理解していただければよいでしょう。
元記事の主題は文法的な改善に限られていますが、私はこのフレームよりもう少し広い範囲の話をしたかったのです
> さらに、Laravel はオープンソースのコントリビューターではなく、Rasmus や Zend のようなところによって、2011年ではなく2007年ごろに、個別プロジェクトではなく公式の言語機能として出てくるべきものだったと思います。Python 3 は後方互換性を一部捨てたために導入でつまずきましたが、PHP も 5 系のころに大規模な後方互換性の整理をしておくべきだったと思います。PHP の変化は、いつも時代の流れより一歩遅れているようにも感じます。
上のコメントへの返答も兼ねます。
おっしゃる観点で見ると、PHP を一種の Web フレームワークとして扱えるという考え方はあると思います。
ただし、例に挙げられていた XSS フィルタやエスケープなどを含むさまざまな機能を、PHP が標準で提供すべきだとは思いません。
最も一般的な PHP-FPM と Django、RoR は同じポジションではありません。Flask、Sinatra、Express に近いです。
PHP-FPM は、ルーティング（ディレクトリベース）、リクエストの解釈（$_GET, $_POST, $_FILE, $_COOKIE）、レスポンス送信（echo, print）、セッション管理（$_SESSION）以上の機能は担当していません。
では Flask は違うのでしょうか？
Flask で HTML エスケープされたレスポンスを返すには、単純に return するだけでは済みません。
https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
では Sinatra は違うのでしょうか？
同様に、別途エスケープ用ライブラリを使う必要があります。
https://sinatrarb.com/faq.html#escape_html
では Express は違うのでしょうか？
これも同様に、別途エスケープ用ライブラリを使う必要があります。
https://expressjs.com/en/resources/middleware.html
例に挙げられていたライブラリは、どれもそのフレームワークが公式に提供しているライブラリではありません。
それなのに、なぜ PHP だけは必ず PHP 公式としてそうした機能を提供しなければならないのでしょうか？
「どんな狂ったフレームワークがリクエストデータをスーパーグローバル変数で露出させるんだ。たとえセキュリティ上の問題がなくても、これはユーザーに対する礼儀ではない！」のような、
すでに多くの人が語っている理由で PHP はダメだと主張するならまだ分かりますが、
おっしゃっていた「PHP の基本機能がフルスタックフレームワークの提供するものほど十分ではない」という理由については……少なくとも私は賛同しにくいです。
Express をよりモダンかつ体系的に使うために Nestjs という存在が生まれたように、PHP をよりモダンかつ体系的に使うために Laravel という存在が生まれた、と考えれば……
他のフレームワーク（言語）と比べたときの短所よりも、私の元コメントで述べたような PHP（-FPM）特有の長所のほうが、より実感しやすいのではないでしょうか？
記憶をたどってみると、少なくとも slim と twig の組み合わせだけでも一般化していれば、プロジェクトでやらかした PHP のミスを減らせたのではないかと思います。もちろん、ほかの PHP 開発者たちが PHP のベタ書きに慣れていたため、当時は導入できませんでした。
幸い、PDO は標準ライブラリに入っていたので、SQL インジェクションへの対策はできました。
元コメントで言及されていたバグの影響範囲の限定や処理性能については、特に否定も肯定もありません。あれば良い機能だとは思いますが、スループットの急増やメモリ使用量の問題は成長段階で最低一度は考えなければならない課題なので、そうした問題が明示的な形でできるだけ早く表面化するほうが良いとも思います
> もちろん、ほかのPHP開発者たちがPHPの雑なコーディングに慣れていたので、当時は導入できませんでした。
> PHPで開発できる人たちが変わるのがいちばん時間がかかるし難しいので
個人的には、PHPそのものには問題がないか、十分に対処できる手段があるか、あるいは他の言語と同じように納得できる理由から生まれた違い程度しかないと思うのですが、おっしゃる人材の問題……これが実質的にいちばん大きな問題ではないかと思いますね。
PHPを本気で使える開発者たちは、もうずっと前に昔のPHPに愛想を尽かしてPHPから脱出して久しく、
残っている大半のユーザーは、PHPがどれだけ進化してもまともに評価してくれない、あるいはまともに評価する余力すらない人たち……
PHPが適していると思うMVP+aのプロジェクトには前者の経験者たちが参加する理由がなく、
たとえ参加したとしても、PHPを選ばないか、PHPを選んだとしても後者のユーザーが1人2人混じった瞬間にめちゃくちゃになるだろうと……（笑）
少なくとも韓国国内では、満足のいくPHP開発が可能な人材を確保すること自体が簡単ではありません。
そうしてまたPHPは選択肢から外され、ますます平均的な人材レベルが下がり、それが無限に繰り返されて悪循環を生み出している気がします。
~~こうしてでも引き続き売り込んで、小規模な1〜3人プロジェクトだけでも~~ ちゃんとしたPHPプロジェクトを試みるケースが増えないと、この悪循環は断ち切れないのではないかと思います。
そんな自分も、実のところPHPが生み出してくれる収益はそれほど大きくありません。満足のいく人材確保があまりにも難しいので、PHPをメインスタックにしたくてもできないのが現実です……
汎用言語とPHPの間には、HTMLページを生成する方法の違いがあるからです。Flaskは少なくとも1.0 バージョンをリリースした時から、人々がテンプレートエンジンを使うことを推奨しており、テンプレートエンジンに依存するよう設計されていました。HTMLページとサーバーサイドデータを意図的に分離し、テンプレート単位の作業を支援してきました。解決しようとする問題の特徴と人々の利用習慣が考慮されているのだと思います。
一方でPHPは、標準出力がそのままページの一部になり、サーバーサイドデータとHTMLページの間の境界が曖昧です。
printしたものが結果のページにそのまま入り、エスケープは開発者が明示的に行わなければなりません。すべての外部データにhtmlcharacterescapes関数を付けなければならないという設計は、人々には受け入れられませんでした。人々は無意識にテンプレートを求めていたのに、PHPにはHTMLページを生成するというユーザーの目的が考慮されていなかったように見えます。その機能が標準ライブラリ、あるいは言語自体に入るべき理由は、PHPの環境構成とコード配布方式を考えたとき、それが最も効果的な方法だからです。LAMPスタックによって開発環境が、Webホスティング方式によって運用環境が定型化されており、FTPでファイルを放り込むやり方に慣れているため、追加パッケージを提供できる可能性は汎用言語に比べて低くなります。モジュールのインストールを入門者に求めることもできません。残る選択肢は標準ライブラリと標準ドキュメントしかありません。
> 人々は無意識のうちにテンプレートを求めていたのに、PHP には HTML ページを生成するというユーザーの目的が考慮されていなかったように見えます。
あまり強く共感できる内容ではないように思います。
単に C API を CGI として簡単に公開できる程度だった PHP3 の時代であれば、おっしゃる通りテンプレート用途で使われていたと言えるでしょうが……
PHP4.2 の時点で、すでに十分に汎用的に活用できるレベルの環境は整っていました。
コードが CLI 経由で実行されることを期待できる環境になっていましたし、前のコメントで触れられていた「Laravel は 2007 年ごろに個別プロジェクトではなく公式の言語機能として出るべきだった」という話は、当時の PHP の方向性とはまったく合っていません。
2004 年に公開された PHP 向けテンプレートエンジンの Smarty、2006 年に公開された PHP 向け MVC フレームワークの CodeIgniter といった存在は、PHP そのものがテンプレート言語ではないことの反証であり、またそのようには使わないという PHP コミュニティの社会的コンセンサスがすでに形成されていたと判断できるでしょう。
> フロントエンドフレームワークやサーバーサイドテンプレートエンジンなどは、データからレンダリングできるあらゆる内容に一律で HTML エスケープを適用し、明示的にエスケープを解除したときにだけ安全でない方法の出力を生成します。
前のコメントにあったこの話も、PHP の時代背景と比べると、特に正しい話ではないと思います。
django が最初に公開された 2005 年から、その後しばらくの数年間は HTML エスケープはデフォルト設定ではありませんでした。開発者が意図的にエスケープフィルタを設定してやる必要があったのです。今でも Python で使われている jinja の場合、いまだに HTML エスケープを自動では処理しません。
自動でエスケープしてくれることが一般的だと見なされるようになった時期には、PHP はすでにテンプレート言語というアイデンティティをとっくに脱ぎ捨てています。（当時 PHP を無思考に使っていたユーザーはそれを望まなかったかもしれませんが、別の見方をすれば、PHP はすでにそうしたユーザーを少しずつ排除していくと決めていた、とも言えるでしょう。）
PHP はもはやそのような用途のための言語ではないので、PHP の標準ライブラリや言語にそのような機能をデフォルト値として適用する理由はまったくありませんし、汎用言語として動作したい PHP の立場からすれば、言及されていた
htmlcharacterescapes関数で十分に役割を果たしていたと考えます。> Web ホスティング方式で運用環境が定型化されており、FTP でファイルを投げ込むやり方に慣れているので、追加パッケージを提供できる可能性は汎用言語に比べて低いです。
この点についても、あまり強く共感できません。10 数年以上前から git などは十分に活用されていました。Docker が公開された直後から Docker を使ったデプロイもかなり試されていましたし、今でもそのように使われています。
挙げられている内容の大半は、PHP そのものというより PHP で開発された CMS の上で触っているときにだけ意味のある話なのではないかと思います。
こういう表現は好きではありませんが、PHP 開発者から見ても開発者扱いされないような、そういうケース……
Jinjaの自動エスケープ機能については、私の主張が誤っていて、ご指摘の内容が正しいです。
> 上の内容にもあまり大きく共感はできません。十数年以上も前から
gitなどを非常にうまく活用していました。Docker が公開された直後から Docker を使ったデプロイも十分に多く試されていましたし、今もそのように使っています。私の PHP の経験は 2014 年で止まっていて、当時は Docker がありませんでした。
gitも働き方自体を変えなければならなかったので導入できませんでした。実際の業務環境でそうしたものを導入しようとするなら共通認識が必要ですが、私の状況では不可能でした。> こういう表現は好きではありませんが、PHP 開発者たちも開発者として扱ってもらえない、そういうケース……
振り返ってみると、開発者として扱ってもらえない人たちの中で、私が仕事をしていたのかもしれません。
例に挙げられたDjangoの認証、アクセス制御、フォーム検証、DBマイグレーションツール、テストツールは、PHPのLaravelでもすべて提供されています。
認証: https://laravel.com/docs/11.x/authentication
アクセス制御: https://laravel.com/docs/11.x/authorization
フォーム検証: https://laravel.com/docs/11.x/validation
DBマイグレーション: https://laravel.com/docs/11.x/migrations
テスト: https://laravel.com/docs/11.x/testing
また、外部ライブラリや有料ライブラリではありますが、
既存のDBスキーマをモデルとマイグレーションコードとしてエクスポートしたり、その逆方向にも動作するものも存在しますし、
CRUD UIを含む洗練されたバックオフィスを提供する https://nova.laravel.com/ も存在します。
Djangoが持つ機能のほとんどはLaravelにも存在します。
（そもそも両者ともRoRのコンセプトを受け継いでいるだけに、提供される機能自体は似通わざるを得ないと思います。）
それでもDjango-Pythonと違って、Laravel-PHPには私が元のコメントで述べた利点がさらに存在します。
PHPがWebアプリ向けテンプレート言語を標榜して設計された言語であることは否定できない事実ですが、
モダンPHPスタイルが定着してからもう10年近くになるこの時期に、単なるテンプレート言語としてしか見ないのは厳しすぎるのではないかと思います。
Nova をリンクしてくださったので見てみましたが、これも有料ライセンスなんですね。プロジェクトのチュートリアルで明示されていてすぐ使える Django Admin と、機能は似ているとしても、アクセスしやすさの面では差があるように見えます。
また、Laravel はオープンソースの貢献者たちによってではなく、ラスムスや Zend のような企業によって、2011年ではなく 2007年ごろに、個別プロジェクトではなく公式な言語機能として登場しているべきものだったと思います。Python 3 は下位互換性を一部捨てたことで導入に支障がありましたが、PHP も 5 系のころに大規模な下位互換性の整理をしておくべきだったと思います。PHP の変化は、時代の流れに対していつも少し遅れているようにも感じます。
今では個人的に Web 開発に入門する立場ではないので、PHP を選ぶことはないでしょう。
言語とフレームワークをしきりに混同していますね
同じ内容のコメントをあちこちに投稿する必要はないと思います。注意を引きたいのですか？
もちろん以前より良くなってはいるのでしょうが、今あえてPHPを使うくらいなら、汎用的に使える場面が多そうなNode.jsやPythonを使うほうがよいように思えます。
PHPブームはやってきます
この10年間でPHPのエコシステム、デプロイ方式、実行モデル、デバッグのやり方などがどれほど改善されたかへの言及がありません。しかも、PHPで開発できる人たちの認識が変わるのがいちばん時間がかかって難しいため、特に良くなっていくという期待すらしていません。特にリンクされた投稿はPHPフリーランサーのマーケティング用ブログなので、なおさら選別して受け取るべきだと思います。
この10年間、Composerパッケージ（Nodeのnpmのような配布）を基準にしたPHPの利用統計では、PHP 5以下はほぼ完全に姿を消しており、PHPエコシステムがComposer中心へ移行してからもすでに長い時間が経っています。
一部のCMS、WordPressやGnuBoardなどは完全に切り離されています。
CMSを除いたエコシステムは上記のような状況です。
PHPを使う立場からすると、今でもPHPは最悪の言語です。
他の言語のほうがもっと良くなったからです。
Hacker Newsの意見
要約:
fopen()でエラーコードを取得できないような根本的な課題にあったPHP: 悪い設計のフラクタル（韓国語）
12年前の文書（笑）
2012年に書かれた文書をいまだに……
phpが進歩もなく2012年当時のままだとでも思っているのでしょうか……？
ああ、もちろん、根拠もなく始まった言語だというのは否定できませんけどね。笑
言及されている英語文書の翻訳版へのリンクです..
PHPがどれだけひどくても、まさかあの時代の問題をいまだに抱えたままではないでしょう。
保守していても問題です。これほどのレベルで設計からして間違っているのに、バージョンアップして品質が良くなった？ それは下位互換性を深刻に壊しているという意味で問題です。比較演算子からしておかしいのに、どうしようもないでしょう。
単にハッカーニュース要約の4番目のリンクの韓国語翻訳版を提供しただけのようです（笑）