昔ながらのフロントエンド開発はもう終わりつつある
はじめに
SPAが現れる前は、ウェブアプリケーションは典型的にはマルチページだったんです。このことは、ユーザーがアプリと相互作用するたびに、サーバーから新しいページが丸ごと送られ、ブラウザーがそれを再度読み込んでいたということを意味しています。ユーザーがページ間を移動するたびに、完全なページが再読み込まれ、速度が遅くなったりユーザー体験があまりスムーズでなかったりしました。似たようなアプリケーションは、PHPやRuby on Rails、ASP.NETなどのサーバーサイドの技術を用いて構築されていて、HTMLコードをサーバーサイドで生成し、それをブラウザーに送信していました。
ウェブ開発者は万能の専門家でした。彼らはフロントエンド部分とバックエンド部分を同時に担当していました。ウェブ技術の発展と利用者の要求に応えるために、問題や待ち時間なくインタラクティブなインターフェイスで作業できる新しい解決策が必要でした。
そうして最初のSPAの解決策が、BackboneJsやAngularJsを使って現れました。これらの技術はサーバーの負荷を減らす（当時、そのリソースは限られていたので）と同時に、サーバーからの新しいページでの更新を待つ必要がなくなり、JSを介してウェブページとインタラクティブに作業できるようにしました。
これによって、フロントエンドとバックエンドの役割の分離が実現しました。純粋なフロントエンドの開発者の役割はより求められるようになり、多様化しました。彼らはユーザーインターフェイスを作成し、HTML、CSS、JavaScriptを使いこなし、APIやサーバーとの対話に特化し始めました。一方、バックエンドの開発者たちは、データ処理、アプリケーションのビジネスロジック、データベースとの作業、サーバーAPIの作成により集中するようになりました。
そして、React、Angular2、Vueなどのウェブアプリケーション開発ツールの時代に入りました。単純なフォームやリストを作る代わりに、今ではjs-routing、ステート管理、ブラウザAPI、リクエストへの認証トークンのバインディング、データマッピングなどがあります。
シンプルだったものを複雑にし始めました
このアプローチの結果として以下の問題が生じました：
-
コミュニケーションと調整の困難さ。API契約、通信方法 - HTTP 1.1、WebSocket、GraphQL。JSONのパースとバリデーション。
-
理解と知識の乖離。たとえば、沢山のクエリを投げるフロントエンドアプリケーションを開発し、それを普通で最適化されたSPAだと考えるかもしれません。しかしバックエンドにとってはとても危険な状況であり、なぜなら、多くのデータベースアクセスとこのデータの適切な集約が必要で、それがパフォーマンスとメンテナンスに影響を及ぼすからです。
-
作業の重複。バックエンドで行われるほとんどのCRUD操作は、フロントエンドでも同様の振る舞いがありました。私たちはサーバーからリストをただ取得するだけでなく、それをstore()に入れ、ユーザーアクションはdispatch()を介して処理され、実行されるリクエストを待ちます。その後結果に応じてstoreをreducer()を介して更新します — バックエンドがデータベースに行うことの全てを、フロントエンドで繰り返しています。（ページのリロードやSPAをサーバーからの現在の状態に復元することも言及に値します — 一時的な痛みになりました）
-
デバッグとテストの難しさ。今では統合の問題を考慮し、両方のアプリケーションサイドの文脈でそれらをテストする必要があります。はい、フロントエンドアプリケーションのために孤立したe2eテストを作成できますが、それらは本番での信頼性を保証するものではありません。サーバーのレスポンスを検証するためのZoDがありますが、それの使用率はどのくらいでしょうか。
-
開発時間とコストの増加。API契約に対する変更は同時に2人の人を要求します。昔のように直接サーバーのテンプレートを変えることはできません。変更をスムーズに行えるように、それを別々のタスクに分割し、ビジネスアナリストといった専門家を必要とします。
-
SEO。私たちのアプリは完全にJSを介して形成されているため、検索エンジンはアプリのコンテンツやそのナビゲーションをきちんと取得し、インデックス化することができませんでした。そのためSSRやSSGのソリューションが必要になりました。
-
セキュリティ。ページ上で入力されたあらゆる重要なデータは、サーバーに渡される前に隠す必要があります。また、アプリケーションのためにサーバーから多くの個人情報を要求する必要があります。それらはアクセストークンを露呈します。
それで、なぜ昔ながらのフロントエンドが終わりつつあるのか
どんなリソースに行っても、いくつもの求人がオープンしているのが見られます。
- Python + Django
- PHP + Laravel
- NextJs + React
- Nuxt + Vue
これらは全て、サーバーベースのウェブアプリケーション開発のための組み合わせです。HydrationとResumabilityアプローチのおかげで、サーバーはページの修正された部分だけをレンダリングし、それを再読み込みしなくても済むようになりました。
これらが提供するもの：
-
サーバーアプリケーションは今や複雑なHTTPやWS契約を持ち、それを両側でサポートする必要はなく、gRPCのような他のサービスと情報をやり取りするようなより良い方法を利用できます。
-
仲介承認の欠如のおかげで変更プロセスは速いです。1人のユーザーに直接結果がすぐに変わります。
-
テストはアプリケーションを全体的にチェックできるため、統合テストの必要がなくなり、エラーが減る。
-
HTMLマークアップだけを交換するため、すべての「リクエスト-レスポンス」ロジックはユーザーに隠されます。
-
なぜ大量のJSONデータをやり取りしてSPAを正しい状態に復元する必要があるのでしょうか？準備されたテンプレートを送ることができるのです。
-
ブラウザの互換性やbabelや他のツールの使用について心配する必要はもはやありません。なぜならページ上のJSコードは最小限です。
No-Codeソリューション、AIによるテンプレート生成、巨大なサーバーリソース、SEO要件の出現により — 現在はフロントエンド開発者やツールがこれほど多くは必要とされていないことがわかります。
ビジネスオーナーにとって正当な疑問があります — 「単純なアプリケーションを開発するために、なぜ純粋なフロントエンド開発者と純粋なバックエンド開発者を雇う必要があるのですか？」
Full-stack開発者は管理上の一時流行ではありません。スタッフの節約という観点から、今は必須です。純粋なフロントエンド開発者は必要ありません。データベースとの直接の単純な操作や他のサービスとの作業により、結果を表示できる開発者が必要です。
おそらく複雑または「ヘッドレス」なアプリケーションが残るでしょう。それらはフロントエンドとバックエンドの分離を必要としていますが、ほとんどのアプリケーションはSPAから離れて、既にあった道を進むことになります。しかし、今ではその問題への解決策があります。HTMXの到来により、どんなバックエンド開発者も基礎的な知識でウェブアプリケーションを作成できます。今や少しのロジックがあるシングルページアプリを作成するためにJSを知る必要すらありません。
あなたは尋ねるかもしれません、「フロントエンド開発者はJSのロジックだけでなく、CSSや適切なセレクタ、HTMLとそのセマンティクスなども担当していましたが、バックエンド開発者も今それを知らなければならないのでしょうか？」 — いいえ、今ではAIや「HTMLレイアウトデザイナー」がFigmaからのレイアウトに基づいてテンプレート生成を行えます。サーバーで定義されたHTMLテンプレートのロジックとインタラクティビティです。
まとめ
今は、これらの洗練されたフロントエンド開発ツールが本当に必要なのかどうか、そして純粋なフロントエンド開発者であり続けるべきかどうかを考える良い時期です。
現在のフロントエンド開発者が60%フロントエンド、40%バックエンドの割合でFullstack資格に移行して、関連性のある専門家でい続けるであろうことが期待されます。HTMXはただの始まりで、NextJsやNuxtのようなツールへのベクトルは増え続けるでしょう。Angularのようなフレームワークは、新しい実装に適応できなければ消えるでしょう。AngularエコシステムにもすでにAnalogJsのようなプロトタイプがあります。
