Architecture no one needs is server side templating (HN)を読んで。
昨今では猫も杓子もJavaScriptが大好きなようで、「Reactを使っていない」などと言おうものならバッシングを受ける時代ではありますが、そんな2018年も終わろうとしている今、どうしてテンプレートエンジン(笑)などというダサいソリューションを使わなければならないのでしょうか?
テンプレートエンジンは遅い
Templating language is basically string interpolation which builds the presentational layer at load time.
"load time"とはいつを指すのでしょうか? どうやら元記事の著者は、テンプレートエンジンが「ユーザーがリクエストを読み込むとき」、文字列を連結していると考えているようです。これは明らかに、大抵のテンプレートエンジンの動作ではありません。
- テンプレートエンジンはテンプレート文字列を読み込み、コンパイルする
- 入力されたモデルを使い、コンパイルされたテンプレートがストリームに対して出力を行う
- 必要なら出力をキャッシュする
第一に、テンプレートはコンパイルされるので単なる文字列の結合より高速です。第二に、出力は結合された文字列として生成されるのではなく、出力ストリームに直接出力を行います。その場合、文字列結合にかかわるオーバーヘッドはありません。
一般的に言って、SPAよりもテンプレートエンジンのほうがずっと高速です。
時々、「SPAはリンク先をプリフェッチするから速い」などという人がいますが、これはユーザーの観点からすれば最低最悪なので絶対にすべきではないです。
SSR
サーバーサイドレンダリングは本当にいいところが何一つないソリューションで、遅く、複雑で、必要性のない依存関係と必要のないレイヤーをシステムに持ち込む、何故使われているのか理解に苦しむものです。
テンプレートエンジンの学習コストが高い
テンプレートエンジンの学習コストがJavaScriptの学習コストより高いというのは相当無理のある主張ではないでしょうか? それともJavaScriptはできて当然ということなのでしょうか? テンプレートエンジンの構文は大抵どれも似通っていて、それほど負担になるとは思えません。必要な時にリファレンスを見れば十分ではないでしょうか。
エラーハンドリング
元記事の著者はなぜか、テンプレートエンジンはエラー発生時に500を返すことしかできないと思い込んでいるようですが、全くそんなことはありません。
クライアントサイドのコードが別々になってしまう
これは確かに問題であり、テンプレートエンジンにうまい解決策はありません。ただ言えることがあるとすれば、テンプレートエンジンを使うときは「その流儀」に合わせて設計を行うべきであり、例えばAJAXリクエストを極力減らして作るべきです。
コンポーネント志向
多くのテンプレートエンジンがコンポーネント志向でないというのは本当に問題なのですが、これは単に多くのテンプレートエンジンがそういう設計になっているということであり、コンポーネント志向のテンプレートエンジンがないわけではありません。
SPA: Good parts
SPAは動的なWebアプリケーションを作るのに適した唯一のソリューションで、テンプレートエンジンにはできないことです。
まとめ
Summary of the article: "Why do we need screwdrivers? I have a hammer, and everything looks like a nail to me!"
HNのこのコメントが、完璧な要約です。SPAが必要ならSPAを使えばいいし、テンプレートエンジンが上手いソリューションならテンプレートエンジンを使えばいいのです。