PHP には未来がありますか、それとも 25 年で十分でしょうか?

1995 年 6 月、Rasmus Lerdorf は Usenet グループで発表を行いました。 あなたはまだそれを読むことができます。

25 年が経過した今日、PHP はかつてないほどユビキタスになっています。 この記事の読者の大多数にとって、Web プログラミングへの最初の進出には PHP が関係していたに違いありません。

パーソナル ホームページ ツール (PHP ツール) バージョン 1.0 の発表。

これらのツールは、C で書かれた小さなタイトな CGI バイナリのセットです。

しかし、PHP がどんなに豊かな歴史と幅広いユーザー ベースを持っていたとしても、急速に進化している環境で PHP を使用する正当な理由にはなりません。 PHP は必然的に既存のアプリケーションで今後何年も使用されますが、新しいサイトでの将来性はありますか?

将来に目を向ける前に、まず PHP が過去にどのように進化してきたかを調査する必要があります。

始まり

Rasmus Lerdorf は当初、彼のオンライン CV にアクセスしたユーザーを追跡する方法として PHP を作成しました。 ソース コードがリリースされ、コードベースがかなりの回数ゼロから書き直されると、PHP はある程度の人気を博し、1998 年までに全ドメインの 1% にインストールされたと報告されています。私たちは今日知っています。 それは完全に中に書かれていました 、構文が最新バージョンとは著しく異なります。

PHP を使用してビジネスを構築しようとしたが、機能が不足していることに気付いた Zeev Suraski と Andi Gutmans を入力してください。 Rasmus と協力して、PHP は再び書き直され、PHP 3.0 としてリリースされました。 その時点で推定 10% のドメインに PHP 3 がインストールされています。 これは、PHP の意味が Personal Home Page から、誰もが好む再帰的な頭字語「PHP: Hypertext Preprocessor」に変わったポイントでもあります。 このバージョンと期間は、一般に、PHP が将来の地位を固めた時期と見なされています。 PHP 3 と 4 の間に phpMyAdmin が作成され、Zeev と Andi は名前を組み合わせて PHP サービス会社 Zend を設立し、由緒ある象のロゴが登場しました。

残りは歴史です。PHP 4 が Drupal になった直後です。 2003 年に WordPress を導入しました。 そして2004年、マークというハーバードの学生がやってきた。

フェイスブックとPHP

Facebook が PHP サイトとして始まったことは有名です。 しかし、数千人のユーザーが数百万人になり、数百万人が数十億人のように見え始めたとき、成長する痛みがありました.

特に、PHP は (そして今も) スクリプト言語です。 開発者の生産性には優れていますが、リソース効率にはそれほど優れていません。 そこで 2008 年、Facebook はトランスパイラーである PHP 用の HipHop の開発に着手しました。 簡単に言うと、PHP を解析して C++ にトランスパイルし、結果の C++ を x64 にコンパイルしました。 PHP の型付けが弱く動的であることを考えると、これは並大抵のことではありません。 しかし結果は、CPU 負荷が 50% 減少したことを物語っています。

このプロセスを使用して Facebook で開発者として働くことの恐ろしさを想像していると思います。 PHP コードを変更し、トランスパイラーを実行してからコンパイルし、指を叩き、実行可能ファイルを実行して、戻って修正する必要がある問題を見つけます。 これはかなり長いイテレーション サイクルです。Facebook が HPHPi も開発した理由は、トランスパイラー/コンパイラー (HPHPc) と同じ役割を果たしますが、開発に使用するためだけのインタープリターです。 ご想像のとおり、2 つのプロジェクトの同期を維持することは頭の痛い問題でした。そのため、2011 年に HHVM (HipHop Virtual Machine) が開発されました。

HHVM は PHP ランタイムです。 JIT (ジャストインタイム) コンパイルを使用して、両方の長所を提供します。 これはかなりクールで、興味があれば、Facebook 自身のブログ投稿で詳細を読むことができます。 次の大きなステップは 2014 年に訪れ、HHVM 専用に構築された言語である Hack が発明されました。 PHP のスーパーセットとサブセットの両方であり、オプションの型注釈と非同期アーキテクチャなどの追加機能が追加されています。 また、指定された型ヒントを使用して確実に最適化できるようにすることで、HHVM の JIT をより効率的にするのにも役立ちます。 すぐに、Facebook の新しいコードが Hack で作成され、既存のコードは時間の経過とともに変換されました。 Hack と HHVM はどちらもオープン ソースであり、現在も積極的にメンテナンスされています。

Facebook が PHP をネイティブ形式のままでは大規模に使用できないと判断したという事実は、PHP の設計が不十分な言語であることを意味するのでしょうか? いいえ、そうは思いません。 当時存在していたオプションのどれも、Facebook が必要とする規模や詳細のために作成されたとは思えません。 しかし、それは人々が PHP に対してそれを使用することを止めるものではありません。

憎しみ

より広いソフトウェア コミュニティ内で、PHP が大きくなるにつれて、必然的に皮肉屋のグループから火がつきました。 ただし、客観的に言えば、PHP は他のほとんどの言語よりも嫌われています。 最近の 2020 年 Stack Overflow Developer Survey によると、PHP は 6 番目に恐ろしい言語です。 なんで?

ここでは技術的な詳細には立ち入りたくありませんが、もしそうなら、PHP: a fractal of bad design は、PHP 嫌悪者のためのバイブル ブログ投稿です。 2012 年に書かれ、言及されているいくつかの問題はその後修正されましたが、多くはまだ修正されていません。 (例: 2020 年にネイティブの非同期サポートがないのはなぜですか?)

最も恐ろしい言語に関する Stack Overflow 2020 調査

より一般的な問題は、言語の哲学にあると思います。 これは、複雑な方法で実装された、かなり狭いドメイン向けのツールです。 理想的な世界では、アプリケーションが複雑でなければならない場合、その複雑さは、言語自体ではなく、ユーザー コードで開発者に表示される必要があります。 複雑なプロジェクトを作成するのに複雑なツールは必要ありません。 私が PHP が複雑であると言うとき、初心者が使いにくいと言っているわけではありません (実際にはまったく逆です)。一貫性のない命名規則と多くの非常に特殊な関数があり、どちらもエラーを作成しやすいと言っています。実行時までキャッチされません。 しかし、これらは単純に PHP の時代の特性なのでしょうか? おそらく要因ではありますが、それが憎しみの理由ではないことは確かです. 結局のところ、Python は PHP より 6 年前の 1989 年に作成され、Stack Overflow 調査で 3 番目に人気のある言語であり、今日最も急速に成長している言語の 1 つでもあります。

セキュリティに関して言えば、PHP サイトに平均以上の数の脆弱性があるのは、言語のせいなのか、それともサイト開発者のせいなのかについて、いくつかの議論があります。 一方では、数十年前のチュートリアルからハッキングされたコードでサイトを作成する非プログラマーを含む幅広い人々にアピールするように設計されたコーディング言語は、言語自体のメリットに関係なく、常に問題を抱えています。 一方、PHP は、基本的なセキュリティの問題を疑わしい複雑な方法で修正しようとしました。たとえば、最初に SQL インジェクションを修正する escape_string()、次に追加して脆弱性を修正します real_escape_string()、次に追加 addslashes()mysql_escape_string()pg_escape_string() 等々。 これを複雑なエラー/例外処理に追加してください (そうです、エラーと例外は異なります)。言語のニュアンスに精通していない場合は、間違いを犯しやすくなります。 サポートされていない古いバージョンの PHP を実行しているサイトの数は、サポートが終了した後も驚くほど多くあり続けているため、PHP サイトは今後何年にもわたってハッカーにとって簡単に手に入る成果物であり続けるでしょう。

とはいえ、この言語が抱えている問題が多くの人が考えているほど大きいとは思えません。 PHP についての不満には合理的な理由がありますが、汚名の多くは、個人が理由付けするのではなく、ファッショナブルであるため吸収されているように私には思えます。

未来

この著者は、言語の批評をページに入力することの皮肉をよく知っています。 post.php アドレスバーに。 しかし、これは既存のサイトに関するものではありません。 最も熱心なピッチ フォークの暴徒でさえ、PHP で作成された既存のサイトをすべて書き直すことを提案するとは思いません。 問題は、2020 年 6 月に新しい Web サイトを作成したい場合、PHP を検討するオプションにする必要があるかどうかです。

現在の Web 開発のトレンドがシングル ページ アプリケーションのコースを設定していることは疑いの余地がありません。ブラウザーは決してリロードしませんが、ナビゲーションは Javascript から発生し、非常に高速な API 呼び出し (例: GitHub や Google の閲覧) からのデータを使用してページを再レンダリングします。ドライブ)。 ブラウザでリアクティブでパフォーマンスの高いアプリケーションを構築するための Javascript ライブラリ、フレームワーク、およびツールのエコシステムは成長を続けており、React と Vue が最も人気があります。

最終的に、PHP はサーバー側のレンダリング用です。 これは、ほとんどのサイトで問題なく、多くのサイトにとって最適なオプションです。 しかし、2020 年に何か新しいものを構築している場合は、これが制限をもたらすことを受け入れる必要があります。 そして、PHP スタイルのサーバー側レンダリングが死んでいるわけではありませんが (誰もが SEO を忘れていませんか?)、最新のサイトは同形である可能性があります。つまり、Next などのフレームワークを使用して、サーバーとクライアントで同じ Javascript をレンダリングできます。 js (React の場合) または Nuxt.js (Vue の場合) を使用して、PHP をサーバー上で使用できなくします。

しかし、PHP も進化しているという事実を無視することはできません。 「Web 職人のための PHP フレームワーク」として自称する Laravel は、PHP アプリケーションを安全かつ迅速に作成するための MVC アーキテクチャを提供します。 コミュニティから高く評価されており、積極的かつ急速な発展を遂げています。 さらに、PHP 8 は今年後半にリリースされ、JIT、Union 型、改善されたエラーなど、多数の新機能 (その多くは Facebook セクションでおなじみのように見えます) を備えています。

PHP さん、25 歳の誕生日おめでとうございます。 あなたは多くの人々に力を与え、ウェブの台頭において重要な役割を果たしてきました。 しかし、人々が将来を別の場所に探しているとしても、あまり動揺しないでください。結局のところ、それは 2020 年です。

Leave a Comment

Your email address will not be published. Required fields are marked *