Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

JSフレームワークを使ったHTMLテンプレート利用のススメ

Web開発者の悩みを軽減! クライアントサイドでのHTMLテンプレート管理 第2回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2016/12/07 14:00

 前回、Webシステムの運用現場では「HTMLの文言、デザインの修正がすぐにできない」「サーバサイドの技術がわからないとHTMLが修正できない」といった問題が生じていることを紹介しました。そして、それらの問題の原因の一つに、PHPでのSmartyやRubyのERBといったサーバサイドテンプレートがある、これらの問題はクライアントサイドでのHTMLテンプレートを使うと解決しやすくなることを説明しました。もっとも、現在フロントエンドエンジニアがチーム内にいない場合には、具体的にはどのような方法がとれるのかがイメージつきにくいと思います。今回は、クライアントサイドでのHTMLテンプレートを使って具体的な方法を紹介します。

目次

対象読者

  • サーバサイド開発者
  • フロントエンド開発者
  • Webアプリ・システム開発に参加する方全般

クライアント側でのHTML生成することの懸念点について

 前回、サーバサイドHTMLテンプレートでの問題点を指摘しましたが、サーバサイドではなく、クライアント側でHTMLを制御することに対して懸念を持っている方も多くいることだと思います。

 サーバサイドでHTMLを生成する場合には、HTMLのコードをプログラムを使って生成するので、人が記述することの代わりをするということで、理解も簡単でした。一方で、クライアント側でHTMLを生成するとは厳密にはHTMLコードを生成するわけではなく、DOMを構築するということです。この操作は非常に面倒だったのですが、jQueryの普及により非常に簡単になりました。

 しかしながら、jQueryの普及とともに高度なUI/UXが要求され、その結果、複雑な構成の、非常にわかりにくいJavaScriptやHTMLのコードが多く見られるようになったことも事実です。この時のイメージを強く持っていて、このようなクライアント側でHTMLを制御する難しさを経験した方では、クライアント側でHTMLを操作することになると、より一層、フロントエンド側が難しくなるという懸念をいっそう強く持つのも当然です。

 しかし、今ではこれらの問題もかなり解決されていて、もっと簡単にそして直感的にDOMを構築できるようにさまざまなライブラリやフレームワークが充実しています。クライアントサイドでHTMLを効率的に管理するためにはこれらのライブラリ、もしくはフレームワークを使えば比較的に簡単に実現できるようになりました。

 また、これらの懸念はサーバサイドとクライアントサイドでの違いを知ることで、むしろ解決しやすくなるということがわかってもらえるのではないかと思います。

サーバサイドとクライアントサイドでの違いについて

 では、サーバサイド側からクライアント側でHTMLを処理するようになるとどのような違いが生じるでしょうか。サーバサイドでHTMLを生成する場合とクライアントサイドでHTMLを生成する場合の処理の違いと扱うデータを示したのが図1です。

図1 サーバサイドとクライアントサイドでの処理と扱うデータの違い
図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化しやすくなるということでもあります。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • WINGSプロジェクト 小林 昌弘(コバヤシ マサヒロ)

    <WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。個人紹介主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしど...

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XMLD...

バックナンバー

連載:Web開発者の悩みを軽減! クライアントサイドでのHTMLテンプレート管理
All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5