サーバサイドHTMLテンプレートからの脱却のススメ

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

サーバサイドHTMLテンプレートから脱却してみよう

　ここまでの問題を読んでいれば、「サーバサイドHTMLテンプレート」をやめればいいだろうと思うでしょう。

　しかし、簡単にはそのようにならないようです。その理由の一つは、現在ではなんとか、多少の不都合はあっても運用を回し切れていることや、フロントエンジニアと言えるほどの専門人員を配置できるないなどがあります。

　現在、何とかなっているということは、たいていのケースではサーバサイドエンジニアが最終的にはHTMLをHTMLテンプレートなどの形式に変換する作業を行っているということです。

　しかし、今後の流れとしてはUI／UXも重要視され、今後、規模が大きくなればフロントエンドエンジニアもプロジェクトに参加するフェーズが来ることでしょう。そのときに高度なサーバサイドHTMLテンプレートを用いていると、フロントエンドもバックエンドもわかるエンジニアを確保しなければならず、それは非常に難しいことだと思います。

　一方、フロントエンドエンジニアが活躍する場としてJavaScriptだけでの画面遷移をするなどのSPAのようなWebアプリがありますが、そちらでは、クライアントサイドでのHTMLテンプレート技術というも一般になってきています。

　SPAというと特にサーバサイドエンジニアにとっては非常に難しいように感じてしまうようですが、現在のサーバサイドHTMLテンプレートで問題ない範囲のWebアプリであれば、クライアントサイドのHTMLテンプレートの導入もそれほど難しくないのではと思っています。

　筆者も今まではサーバサイドHTMLテンプレートでHTMLを記述していましたが、クライアントサイドでのHTMLテンプレートを利用してみると、単にHTMLが管理しやすいだけでなく、以下のようなメリットがあることに気付きました。

• 機能を画面単位で作る必要がなくなり、サーバサイド側の処理をよりシンプルにできる。
• サーバサイドのアウトプットにデザイン要素など処理に関係がないものを含めないので、テストが行いやすくなった。
• DBなどの状態により変わってしまう画面の確認、テストが行いやすくなった。
• 画面の部品化がすすみ、画面の変更にも柔軟に対応できるようになった。

　このようにクライアントHTMLテンプレートを導入することで、フロントエンドエンジニアだけでなく、サーバサイドエンジニアにとってもメリットがあります。

　次回はサーバサイドHTMLを使っている人も、また、フロントエンドエンジニアでも双方負担が少ない形でのクライアントサイドでのHTMLテンプレートの利用方法を紹介します。

最後に

　JavaScriptでフレームワークの導入をしようとすると、最先端のトレンドについて行かなければならないなど、なにやら必要以上に難しいことと思ってしまう方も多いようです。

　筆者はサーバサイドエンジニアとして開発することも、フロントエンジニアとして開発することもありますが、技術レイヤーが異なるエンジニア同士で作業しやすい環境を作ることは、非常に難しいと感じています。その大きな原因としてはお互いの状況についての理解不足にあると思っています。

　今回、記述した内容がすべての状況において当てはまるとは限りませんが、皆様にとって少しでもご参考になる部分があれば幸いです。

参考資料

• Smarty
• Blade
• Slim
• Jade