フロントエンドエンジニアが抱える問題
簡単なHTMLであれば、多少面倒であってもサーバサイドエンジニアが修正を行うことはできました。
しかし、フロントエンドエンジニアがプロジェクトに参加するようになると、少々事情が代わり、また新たな問題も生じます。
フロントエンドエンジニアがプロジェクトに参加する場合には、UI／UXもこれまで以上に重視されるプロジェクトであるはずです。
UI／UXを確認する上では、HTMLやJavaScriptなどを作成しながら実際のブラウザを使って確認していきます。そして、サーバサイドHTMLテンプレートを使う場合には、問題なく動作ができるようになったところで、サーバ側の機能をそのHTMLに組み込んでいくなど、図4のような作業工程を経る必要があります。
すでにHTMLそのものを作ってしまっているので、テンプレート機能が持つさまざまなメリットが、逆にデメリットになってしまっています。このため、HTMLを修正する時に2つの大きな課題が発生します。
- HTMLからHTMLテンプレートへの変換能力
- サーバ側でデバッグする能力
これら2つは、どちらも本来は必要なものではなく、作業ルールによって生まれてしまった作業とスキルということです。これらは簡単な修正であれば、それほど難しくないかもしれません。しかし、複雑なUI／UXの修正まで行うとすると、テンプレートの記述ミスにより想定したHTMLではない結果になる、または、サーバ側で動作する制御文の間違いによるサーバ側での処理エラーなど、考慮しなければいけないことはより多くなります。
また、HTMLテンプレートへの変換をサーバサイドエンジニアが担当すると、サーバサイドエンジニアがフロントでの動作を確認する必要が生じてしまうなど、どちらか一方を立てると、もう一方には大きな負担が生まれてしまうという問題が発生します。
フロントエンドエンジニアが抱えるもう一つの問題
まだ、あまり声として上がっているところは少ないですが、フロントエンジニアはもう一つ大きな問題を抱えています。ここまでの記述を読んでいれば、気がついている方もいるかもしれません。
それは、複数のプロジェクトに参加する場合には、複数のHTMLテンプレートの使い方を覚える必要があるということです。
図5のように、HTMLを生成するためのHTMLテンプレート言語は非常にたくさんの種類が存在します。
サーバサイドテクノロジーは、言語やフレームワークによって、できることとできないことがあり、また、たとえできても得意、不得意があります。そのため、プロジェクトによって、言語やフレームワークの選択が変わってしまうこともよくあるケースです。
その結果、HTMLテンプレートも変えなければならないことがあります。
HTMLテンプレートを言語やフレームワークなどから分離させ、どの言語、どのフレームワークなどでも使える共通のHTMLテンプレート言語があればと思う方もいるでしょう。
しかし、HTMLテンプレートは、その言語、そのフレームワークを使うエンジニアにとって効率的であり、利便性が高いように進化した経緯があります。そのため、そのようなHTMLテンプレートが存在することは難しいのです。もちろん、非常に似た形式のものはありますが、言語が異なれば全く同じようにはいきません。
このように同じようなことをするために、多少異なるということを覚える必要があり、そして、そのスキルはあまり市場で評価されるものではありません。そのため、フロントエンドエンジニアがサーバサイドのHTMLテンプレートを覚えるというモチベーションはどうしても低くなってしまうのです。
