こんにちは、テックフィード白石です。
日本のエンジニア界隈をリードするエキスパートに、テクノロジーの最前線を語っていただくYouTube動画連載「Ask the Expert」の新着動画が公開されました！
今回は、フロントエンドのエキスパートmizchiさんに、フロントエンドの最新動向について詳しく伺ってきました。
mizchiさんのアカウントをぜひフォローしましょう！
mizchiさん（フロントエンド兼Node.jsエンジニア）
ついでに白石のもフォロー推奨:
聞き手: テックフィード白石
以下に掲載するのは、インタビュー動画の内容の要約です（正確な書き起こしではありません）。
内容をフルにご覧になりたい方は、ぜひ動画をご視聴ください。
ご質問、ご感想などはYouTubeのコメント、もしくはこの記事のコメント欄でも受け付けております。どしどしお寄せください😊
以下、動画の内容の要約です。
React Server Componentsとは
mizchi:ここしばらくフロントエンドで熱いテーマになっているのは、React Server Components（RSC）です。
これは、今までフロントエンドでだけレンダリングしていたものをサーバーサイドにある程度寄せて、 フロントエンドのパフォーマンスとサーバーサイドの自由度を高めようといったトレンドの先頭を走っているアプローチ ですね。
これはNext.jsとかが先に実験的に実装しつつ、React本体にも手を入れながら開発されているっていう機能です。
mizchi: RSCの一番の特徴はやはり、サーバーが前提になるっていうところですよね。
サーバーとクライアントで同じコンポーネント定義を持っているんだったら、クライアントでも展開できるし、サーバーでも展開できるという発想が先にあります。
白石:サーバーサイドレンダリング（SSR）とは違うんですか？
mizchi: 今までサーバーサイドレンダリングと呼ばれていたものでは、ある画面の中間スナップショットを全部、上から下までページの構成要素すべてをレンダリングしないといけませんでした。
RSCはそうではありません。 サーバーとクライアントで同じコンポーネント定義を持ちつつ、どのコンポーネントをサーバーでレンダリングするのか、クライアントでレンダリングするのかをプログラマーが振り分けていくような作りになっています。
白石:レンダリングされる粒度がコンポーネントごとになった、って感じなんですね
mizchi: はい。それがReactにおいてのサーバーサイドコンポーネントなんですが、いろいろなフレームワークやライブラリが似たような仕組みを持とうとしている状態なので、Server ComponentやServer Function、Server Actionという、一般化した概念として整理されてきています。 いずれ、これがフロントエンドの今後の常識になっていくだろうという見通しです。
白石:なるほど。そこでqwikの話が出てくるわけですか。
mizchi:そうですね。こうした新たなトレンドに対応した、専用のランタイムとかフレームワーク環境を作ってしまおう、というのがqwikの原点です。
Reactの限界がqwikにおいてはスタートライン
mizchi:qwikのコードは、見た目はほぼReactです。
ただ$がつく関数がちょっと特殊な扱いを受けます。それらの関数は、ソースコード上は同じ位置にあるように見えても内部的には別のパーツで、 サーバーとクライアントのどちらでレンダリングされるかはビルド時に決定 されます。
これの何がすごいかというと、 Reactのパフォーマンスの限界がqwikにおいてはスタートラインになる んですよ。コーディング規約などの外部制約を満たせば、ReactやNext.jsにおけるパフォーマンスの限界を突き詰めたようなものがデフォルトで出てくるというのがqwikです。
mizchi:例えば以下のようなコードでは、onClickハンドルを踏んだ瞬間に初めて、ここを展開するロジックがチャンクとして降ってくるんです。最初はJSのないベタなHTMLが降ってきて、クリックしたら初めてこの部分が降ってくる。これはもう、理論上最強です。
<button onClick$=(() => {isFavoriteSignal.value = !isFavoriteSignal.value})>
{isFavoriteSignal.value ? ‘♡’ : ‘♥’}
</button>
mizchi:ReactとかNext.jsみたいな世界観だとここまで多分いけないんですよ。もしかしたら、ものすごく頑張った先にここまで行けるかもしれないけど、qwikはここがスタートラインなんです。最初からこれを前提としているqwikは僕としてはあまりにも強くて、「 KPI上パフォーマンスが最優先だったらqwikを使ってもいいんじゃない？ 」っていろんな人に言ってます。
qwikの欠点は？普及する？
白石:では、そこまですごいqwikの採用を妨げているものがあるとすると何でしょうか？
mizchi:やはり既存のライブラリが使えないことですね。たとえばChakraUIなどのUIコンポーネントライブラリが使えないので、全部自分で最初から書かなきゃいけない。qwik UIなど、UIライブラリは一応存在するんですが、正直足りない。まだ作りかけ、という段階です。
mizchi:なので、マークアップなどを全部自前で行わなきゃいけないことが、結構受け入れ難いんじゃないかなという気がします。ただ、それに関しても後で述べるAIコード生成マークアップの自動生成で補えるんじゃないかなと思っているところはあります。
（その2に続きます）
