対象読者
- サーバサイド開発者
- フロントエンド開発者
- Webアプリ・システム開発に参加する方全般
クライアント側でのHTML生成することの懸念点について
前回、サーバサイドHTMLテンプレートでの問題点を指摘しましたが、サーバサイドではなく、クライアント側でHTMLを制御することに対して懸念を持っている方も多くいることだと思います。
サーバサイドでHTMLを生成する場合には、HTMLのコードをプログラムを使って生成するので、人が記述することの代わりをするということで、理解も簡単でした。一方で、クライアント側でHTMLを生成するとは厳密にはHTMLコードを生成するわけではなく、DOMを構築するということです。この操作は非常に面倒だったのですが、jQueryの普及により非常に簡単になりました。
しかしながら、jQueryの普及とともに高度なUI/UXが要求され、その結果、複雑な構成の、非常にわかりにくいJavaScriptやHTMLのコードが多く見られるようになったことも事実です。この時のイメージを強く持っていて、このようなクライアント側でHTMLを制御する難しさを経験した方では、クライアント側でHTMLを操作することになると、より一層、フロントエンド側が難しくなるという懸念をいっそう強く持つのも当然です。
しかし、今ではこれらの問題もかなり解決されていて、もっと簡単にそして直感的にDOMを構築できるようにさまざまなライブラリやフレームワークが充実しています。クライアントサイドでHTMLを効率的に管理するためにはこれらのライブラリ、もしくはフレームワークを使えば比較的に簡単に実現できるようになりました。
また、これらの懸念はサーバサイドとクライアントサイドでの違いを知ることで、むしろ解決しやすくなるということがわかってもらえるのではないかと思います。
サーバサイドとクライアントサイドでの違いについて
では、サーバサイド側からクライアント側でHTMLを処理するようになるとどのような違いが生じるでしょうか。サーバサイドでHTMLを生成する場合とクライアントサイドでHTMLを生成する場合の処理の違いと扱うデータを示したのが図1です。
サーバサイドHTMLテンプレートを使っている場合は、より実際に表示する画面に近いHTMLを作成していました。そして、JavaScriptやCSSがそのフォーマットに対して見栄えを調整するという役目です。そのため、サービスの利用者側で問題が生じても、ブラウザの問題なのか、もしくはWebシステム側の問題なのかなどがわかりやすいという特徴を持っていました。
しかし、より高度なUI/UXが求められるようになると、実際の画面のイメージとは違い、より制御しやすいHTMLというのが求められてきています。実際、図1(左)を見てもわかるように、サーバ側で使用するHTMLテンプレートはロジック結果を表示するためのフォーマットともいえます。このフォーマット変換が複雑になってしまったのが、先に説明したクライアント側のJavaScriptが複雑化する原因です。または、このHTMLでのUI/UXを求める形として維持しようとして作業面で難しくなっているというのが、前回説明した大きな問題点の一つということです。
一方、クライアント側でHTMLテンプレートを使う場合には、図2(右)のようにクライアント側にJavaScriptでのテンプレートエンジンが必要になり、そこで「ロジック結果」と「JavaScriptやCSS」、そして「HTMLテンプレート」の3つが合成されます。
つまり、よりUI/UXに近い場所で求める形のHTMLを編集することができるので、複雑なDOM操作を無くすことができるのです。つまり、JavaScript側もよりシンプルになるということです。
ただし、クライアント側にデータ(ロジック結果)、コントロール(JavaScript)、ビュー(HTMLテンプレート)の要素がそろったことにより、MVC構造が管理として必要になってきます。
このMVCというキーワードがフロントエンド側ではなじみがなかったので多少不安があるかもしれませんが、これらは難しかったことをより簡単にするためのノウハウでもあり、定型化のパターンに乗せやすくもなったということです。
そして、JavaScript側でもMVCフレームワークというのが普及し、その結果、より効率的な開発フローを構築することにも容易になってきているのです。
また、サーバ側に目を向けると、ロジックの処理部分だけに集約していくことにもなるので、再利用しやすい処理を作りやすくなり、それはREST API化しやすくなるということでもあります。