Windows上のPHPの行の終わり

PHPはしばらく前から存在しているかもしれませんが、それでも重要なWeb開発ツールです。プログラミングの宣言型モデルに基づいて構築されたPHPは、使い慣れたHTML構文を追加のコマンドと関数で拡張し、インラインプログラミングと拡張機能をWebコンテンツに追加します。このモデルは、多くのコンテンツ管理システムの重要な部分であり、データベースで配信されるコンテンツを管理し、動的テンプレートを使用してページをフォーマットするためのフレームワークを提供します。

WindowsでのPHPの未来

これらのCMSの多くは、企業のファイアウォール内で実行され、イントラネットと内部コラボレーションツールをホストしています。したがって、PHPの公式Windowsビルドが、最も長く実行されているオープンソースプロジェクトの1つであるMicrosoftから提供されているのは当然のことです。

しかし、すべての良いことが終わり、Microsoftは最近、Windows用のPHP8の公式ビルドを作成しないことを発表しました。これまで、IISおよびその他のWindowsWebサーバー用のwindows.php.netでバイナリおよびソースコードとしてWindowsリリースを配信してきました。ただし、PHP 7がサポートライフサイクルを通過するにつれて、Windows PHPビルドを提供するチームが他のプロジェクトに移行するため、これは将来的に停止します。

このポリシーの変更は、Windows上のPHPの将来に何を示唆していますか?そして、もっと重要なことに、あなたが仕事のやり方を変える機会を利用したいのであれば、どのような選択肢がありますか?

はい、未来があります

まず、そして最も重要なのは、PHP forWindowsが消えることはないということです。PHP 7を超えてWindowsバージョンのPHPをビルドおよび配布し続けるには、十分な需要があることは明らかです。マイクロソフトは、ビルド用のリソースとサーバーを直接提供しませんが、ライセンスとサーバーをに寄付する可能性があります。少なくとも、Windowsビルドが自動化されたPHP CI / CD(継続的インテグレーション/継続的デリバリー)プロセスから出てくることを保証するPHPプロジェクト。

Visual Studioで適切なビルド設定が使用されるようにすることで、適切なテストが実行され、コードが正しく最適化されるようにするための一連のWindowsスキルを開発するのはPHPチームの責任です。それはそれほど難しいことではありませんが、世界最大のソフトウェア会社の1つから専用のリソースを持っていることと同じではありません。

あるいは、独自のPHPツールを備えたサードパーティ企業とオープンソースコードベースから構築したボランティアによって構築された、他のWindowsバージョンのPHPがあります。サポートが必要な場合は、おそらく商用のPHPバージョンを選択する必要がありますが、オープンビルドはWindowsPHP開発環境をまとめるのに理想的です。

PHP開発にWSLを使用する

代替手段を探している場合は、Microsoft独自のAzure App ServiceクラウドホストアプリケーションプラットフォームがPHPをサポートしていますが、ここではWindowsではなくLinuxで実行されています。このためのコードを作成する場合は、開発プロセスの中心にLinuxバージョンのPHPが必要であり、Visual StudioCodeのリモートワークスペースツールを使用してターゲットを設定する必要があります。IntelliSenseサポートからデバッグおよびコードフォーマットツールまで、コードにはさまざまなPHP拡張機能があります。

PHPをWSL(Windows Subsystem for Linux)にインストールするのは簡単で、必要なすべての依存関係を選択したパッケージマネージャーを介してインストールできます。 UbuntuWSLインスタンスにPHPをインストールするとApacheWebサーバーがインストールおよび構成されるため、コードの記述とテストから本番Webサーバーでの実行にすばやく移行できます。インストールには数分かかります。すべてがWindowsターミナル内で実行できるようになり、Windows内で実行されているVisual StudioCodeからアクセスできます。 WSL1とWSL2のどちらを使用しているかは関係ありませんが、どちらのバージョンでもほぼ同じエクスペリエンスが得られます。

開発マシンで実行されているLinuxPHPインスタンスを使用すると、PHPアプリケーションを構築してテストしてから、Azure AppServicesまたはホストされているWebサーバーにデプロイできます。WSL 2を使用している場合、この新しい開発モデルは最新リリースのDockerコンテナで使用でき、開発PCを使用してWSLでコードをビルドし、それをコンテナとしてパッケージ化して、ネットワーク内のサーバーに簡単にデプロイできます。ホスティングサービス、またはパブリッククラウド。

WSLを介してLinuxでPHPを使用することは、WindowsでのPHP開発にとって最も混乱の少ないオプションである可能性がありますが、別のアプローチとして、より最新のWeb開発モデルを使用することもできます。ASP.NETを使用してMicrosoftエコシステムにとどまるか、Jamstackなどのアプローチを使用して静的サイト開発に基づくクロスプラットフォームモデルに移行するか、多くの選択肢があります。

新しい開発モデル:.NETBlazorおよびAzureStatic Web Apps

1つ明らかなことは、PHPで使用されている宣言型Webアプリケーション開発モデルがなくなることはないということです。PHPに対するMicrosoftの公式サポートが終了したことについてのもっともらしい議論は、新しいMicrosoftテクノロジは、より少ないリソースを使用し、クロスプラットフォームで機能し、新しいWebテクノロジをサポートするロードマップを使用して同様の開発オプションを提供できるというものです。

ASP.NET Coreは、サーバー側の.NETコードを使用してHTMLおよびJavaScriptコンポーネントを配信するクロスプラットフォーム環境です。ポータブルな.NETCoreランタイム上に構築された、ASP.NET CoreのRazor構文は、PHPと同様の宣言型プログラミング手法を提供します。ただし、サーバー側のBlazorプログラミングモデルと組み合わせて使用​​すると、大きな違いが生じます。

Blazor Serverは、単一ページのWebアプリケーションに重点を置いて、Webサーバー上でASP.NETコードを実行し、ブラウザーコンテンツとバックエンドサービス間のSignal R接続を使用して、コンテンツを事前にレンダリングされたWebコンポーネントにコンパイルします。このアプローチには、必要な帯域幅が比較的少ないという利点がありますが、各対話に必要なサーバーとブラウザー間のラウンドトリップ接続で遅延が発生します。この方法でコンテンツを事前レンダリングすると、ユーザーは、UIコンポーネントを更新するインタラクションにより、アプリケーションの応答性が向上したと感じることができます。

Azure AppServicesの一部としてのAzureStatic Web Appsの最近のリリースにより、Webコンテンツを作成して使用する新しい方法がAzureとWindowsにもたらされました。Visual Studio Codeを使用してローカルにサイトを構築し、GitHubでコンテンツをホストすることにより、カスタムGitHubアクションは更新されたコンテンツをAzureにデプロイします。サイトは、HTML、クライアント側のJavaScript、およびデータベースやその他のサービスへのAPI接続を使用して構築されます。

BlazorやPHPと同様に、Jamstackはサイトデザインにテンプレート駆動型のアプローチを採用していますが、従来のCMSにはあまり適しておらず、コンテンツ配信ネットワークを介して配信できるファイルベースのコンテンツには適しておらず、ユーザーの近くにコンテンツをキャッシュするために使用しています。Jamstackの手法を使用してコンテンツベースのAzure静的Webアプリサイトを構築できますが、新しいコンテンツを公開するたびにサイト全体を再構築する準備をする必要があります。

マイクロソフトが独自のPHPビルドをサポートしなくなったことは、大惨事ではありません。これは、レドモンドの優先順位が変わったことを示しています。WSLやAzureでホストされるLinuxなどのテクノロジーは、PHPコードを構築して実行するための代替パスを提供します。

また、Webアプリケーション開発に対する他のより現代的なアプローチが、.NETおよび最新のアプリケーション開発技術に基づいて構築されたMicrosoftの現在のクラウド中心のパスとより密接に連携している可能性があることも示しています。何をするにしても、たくさんの選択肢があります。