最初はプンスコしてたんですが、週末を挟んで寝かせていたら、割とどうでも良くなってきたので、もうそこまで怒ってないです。
ただ、どうしてこういう用語が誕生するのかには興味があるので、調査結果とお気持ちをしたためておきます。
引っかかるポイント
先に疑問に思うポイントをまとめておきます。
- あるレイヤーの最終出力を"レンダリング"と呼ぶのは良しとしても、すぐ隣のレイヤーでブラウザが HTML のレンダリングを頑張ってるのに、何で被せるようなネーミングにしたのか
- 従来の CGI や PHP、JSP、ASP.NET でやってきたことと何が違うのか
- 違うとしたら JavaScript フレームワークから出力することを特別視する理由は何か
クラウドゲーミングなどにおけるレンダリングとも混同しがちなんですが、それは私が CG・ゲーム寄りの立ち位置にいるせいだと思うので、とりあえず気にしないことにします。
きっかけ
きっかけはこのツイートでした。
なるほどなーと流し読みしてたんですが、脳内で「サーバー上でラスター画像にしてそれをストリーミングする技術」という解釈が生まれた瞬間にギャップが生じてしまい、
このツイートが生まれました。直後はそうでもなかったんですが、一晩寝かせたらバズってしまったようで、様々な方からご意見・知見を頂戴しました。ありがとうございました。
RT よりは Fav の方が多かったので、何となく共感してくださる方も多かったのかなぁ、という印象です。
render の意味の多様性
私は CG・ゲーム 業界寄りの人間なので、レンダリングと言われると「グラフィックの描画」がどうしても最初に出てきます。それが固定観念に囚われていると指摘されたら、否定できません。
しかし「サウンドレンダリング」や「テキストレンダリング」など、様々なレイヤーにおけるレンダリングが存在していることは理解しているつもりです。
https://talking-english.net/render/
- 〜の状態にする
- 製造する
- レンダリング
- 与える、提供する
- 壁などを塗る
今回調べて知りましたが、他にも「脂抜きをする」「肉骨粉にする」なんて意味もあるそうです。
なので、多くのフレームワークで HTML 出力の関数が render になっていること自体は、ごく自然で適切なネーミングなのだろうと理解しました。
HTML レンダリング is 何
とはいえ、ちょっと前まで Web の世界で「レンダリング」と言ったら、ブラウザが HTML を画面に描画することを指していたはずです。
https://qiita.com/umashiba/items/8cb47825624c5cb043d6
この記事にまとめられているように、
- KHTML
- WebKit
- Blink
- Gecko
- Servo
- Trident
- EdgeHTML
- Presto
こういったものがレンダリングエンジンである、と認識していました。
しかし、Server-Side Rendering に関する記事を見ていると、HTML を出力する JavaScript フレームワークを「レンダリングエンジン」と呼称している方が見られました。
https://www.publickey1.jp/blog/17/server_side_renderingserver_side_rendering_ng-japan_2017.html
だいたいブラウザでのレンダリングエンジンはAngularやReactなどJavaScriptで動いていることが多いので、それをサーバで動かそうとするとNode.jsを使うことになります。
ブラウザが持つレンダリングエンジンが JavaScript で実装されている事例は聞いたことがないので、恐らく「HTML を出力(rendering)するフレームワークをレンダリングエンジンと呼んでいる」と解釈しました。
https://www.publickey1.jp/blog/20/jamjavascriptapimarkupcms_pr.html
JAMスタックでは、サーバサイドでのHTMLレンダリングはデプロイ時などにあらかじめ済ませることで、可能な限り静的HTMLを生成しておくことが大事な要素となっています。
ここでもしれっと「HTML レンダリング」と述べられていますが、文脈からして HTML の生成のことであろうと解釈できます。
文脈依存で意味が変わる用語は多数ありますし、他の業界で使われている言葉との被りまで配慮して欲しいとは言いません。でも、同じ分野の近しいレイヤーとの用語被りは避けようよというのが率直なお気持ちです。
そもそも JavaScript フレームワークのお仕事は HTML を render するのに留まらない、ViewModel 的な立ち位置のものであると認識しています。テンプレートエンジンじゃダメなんです？
(追記)何か別物っぽそうだったのでこの部分は取り下げます。
CGI とかと何が違うのさ問題
これは色々調べているうちに分かってきました。
広義の SSR には、恐らく CGI や PHP などによる HTML 生成も含まれると思われます。
しかし、JavaScript フレームワーク界隈における狭義の SSR では アイソモーフィック JavaScript という概念が重要そうです。
アイソモーフィック(Isomorphic) とは、「同型の」という意味で、同じJavaScriptのコードがサーバー(Node.js)とクライアント(ブラウザ)両方で実行されることを意味します。
これはとても分かりやすいですね。サーバーとクライアントで同じコードが動作するのであれば、HTML 生成を状況に応じて分担するのも容易にできそうな気がします。
自分なりにまとめてみます。
- クライアント側に偏りがちな HTML 生成をサーバー側にも分担するという目的のもとサーバーサイドレンダリングという言葉が掲げられた
- それを効率的に行うために JavaScript フレームワークでサポート、ないし実践されるようになった手段がアイソモーフィック JavaScript
- JavaScript 利用者の間ではサーバーサイドレンダリングを目的とした場合、手段としてアイソモーフィック JavaScript を用いることが暗黙的な前提として存在する
これなら JavaScript からの出力に話が限定される理由も納得いきます。
でもそれなら、もっと前提が分かりやすい名前を掲げて欲しいというのも同時に湧き上がってくるお気持ちです。他のレイヤーを担う人たちと話す際にも混乱しそうなものですが。
恐らくポイントは、サーバーとクライアントで同一言語が使えることにあるのだと思います。クライアント側が JavaScript で動作する関係上、サーバ側でも JavaScript でアイソモーフィックに書かれることで、レンダリングの分担を行いやすい、みたいな説明ならストンと腑に落ちます。
それを表すには、サーバーサイドレンダリングという言葉はスコープが広すぎるのでしょうね。
まとめ
- HTML 出力を render と呼ぶのはおかしくない
- でも「レンダリングエンジン」とか言い出すとブラウザのお仕事と被るからやめてほしい
- 狭義の SSR とは、同一言語でサーバー・クライアント間で処理を分担できるのがポイントっぽい
- でも広義の意味だとスコープが広すぎるので、ちゃんと前提を含んだ言葉をバズらせてほしい
以上です。単なるお気持ち表明のつもりで書き始めた文章ですが、アイソモーフィックという概念に触れられたのは良かったです。
