最近のフロントエンドフレームワークに対する認識とお気持ちの整理
久しぶりに、いわゆるポエムを。
新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。
この先、また技術選定する際なんかにも参考になるかと思ったので。
React
「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。
Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。
一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし）
原初の時代からReactな案件をそれなりにこなしてきたけど、今でもReact-wayですべてを考えるのはやっぱり小難しいな〜って思うし、このEasyではなくSimpleに極振りしたAPIセットを使いこなすのまじムズいな〜って思う。
いつだってMobXだったり、Reactとは直接的に接するのを避けてた身としては、HooksもSuspenseもRSCも、React大好きマンが集まったチームじゃないとワークするの無理では？とすら思ってる。（なので「ゆくゆくは内製で開発できるようにしたいので、Reactでお願いします！」って本当によく言われるけど、まぁお察しですよね）
あとは、ことWeb開発において、`react-dom`がなぜ必要なのかが本当にわからない、とずっと思ってる。サイズも許容したくないくらいデカイし、税金にしては高すぎる。
`react-native`や`react-three-fiber`や`ink`みたく、レンダラーが拡張できるのは素敵かもって思うけど、それはほんまにReact（JSXとかHooksとか）なコードである必要あるんか？（メンタルモデルが本当にマッチしてるの？っていうところ）っていうのはわからない。少なくとも`wrangler`とか見てる分には、CLIに関しては懐疑的。
まぁそういうわけなので、自らすすんでReactを選定することは、この先ないだろうなと思ってる。
変わらずの方向性で元気にやってほしいなとは思ってるけど、個人的Tier1ではなくなったという話。（そういう意味で`useEvent()`のRFCには少し複雑な気持ちだったので流れてよかった）
そういえば、`Suspense` for data fetchingはいったいいつまでexperimentalなんやろね。
Next.js, Remix
となるとやはりReact単体というより、Nextが本体っていうか。Reactは単体でも使える・・みたいなマーケティングを今でもたまに見るけど、エンド開発者から見た場合に、Reactだけを単体で採用したいケースってある？いや、ない。
じゃあNextをやるべきか？って話になるけど、これについてもReact同様で、もはや第一党として選ぶ理由はないかなーと。
ファイルベースのルーティング、SSRもシームレスにできる、APIもサクッと生やせてオールインワン！なんならVercelにデプロイして即完了！この体験すげー！っていうのは、もはやNextだけのお株ではないし。
Nextの`v13`に対する世間の反応と同じように、ReactはNextの中で行き永らえながら、どんどん高機能でどんどん複雑化していって、特定のケースでだけ抜擢されるアベンジャーズみたいな存在になっていくんかなーって夢想してる。相対すべき驚異がこの世に存在するのかどうかは知らんけど。
好き嫌いはさておき、RSCもReact+Nextらしい方向性と打ち出し方やなって思いました。（なんでそうなんでもかんでも難しく解決しようとするん・・）あと、Turbopackの過度なマーケティングには関心しない。
他のReact用フレームワークでいうと、RemixはShopifyにジョインしたことで存在感がまた出てきて、Nextの対抗馬〜みたいになったりするんだろうか？
https://shopify.engineering/remix-joins-shopify
https://remix.run/blog/remixing-shopify
個人的にピックするかでいうと、クラサバ分離な哲学には同意するけど、それをReactでやる必要はない・・って感じ。`react-dom`もやっぱいらんよな〜。
当初からCDNエッジファーストで考えられてたりとか、そういうところはNextより先を行ってるとは思うけど、`react-router`の影がやっぱちらついてな・・。
Preact
Reactみたくランタイム同梱系のライブラリでいくと、Vueよりもサイズが小さいというところで、今もなおそのアイデンティティは健在か。サイズは小さくまとめたいが、VDOMは欲しい場合の択として。（まぁそもそもWebでVDOMが欲しい場合が思いつかんのやけど）
Signalsが使えるようになって、多少は書き味のReact離れを成し遂げはしたけど、やっぱりもう、`useEffect()`書きたくね〜思考停止でメモ化したくね〜っていう気持ちが強いんよな・・。
あとは周辺機器が結局Reactしか見てなくて、そのあたりの対応がいつまでもイマイチだったり、立ち位置がずっとインディーズバンドみたいなところがあると思ってて、そこが煮え切らない。少なくとも、React互換ですっていう見方はもうやめたほうがいい気はしてる。
Shopifyつながりで、RemixのコアとしてPreactが採用された！みたいな未来はないかしら？あったらよくない？
Vue
（あまり出会う機会がないので大したお気持ちがあるわけではない）
`petite-vue`みたく、`script`タグからも独立してほぼフル機能で使えるルートが残されてるのがとてもユニークだなと思ってて、Reactよりよっぽど取っつきやすいなって思ってる。
SFCのスタイルはVueの発明やったと思うし、そういうDX特化みたいなポジションをこれからも取り続けていってほしい。
そういう意味では、`v3`のComposition系のAPIは、やっぱ世の流れへの対応なんかなー。当時はVueでそれやるんや？って思ったけど、まあファンがいるのはいいことよね。
Compiler-InformedなVDOMってやつの中身は気になるところではある。
https://vuejs.org/guide/extras/rendering-mechanism.html#templates-vs-render-functions
Nuxt3もRCになって、立派になったなあ・・って思いつつ、Contentの機能とかを見るに、アプリよりもサイト方面に舵を切っていくんかな？
そのほかだと、Nitroの汎用さはどっかでなんかに使えんかなーって見てる。
Svelte
「いまフロントエンドやるなら最初に覚えるべき！」は、個人的にはこっち。
書くべきコードが少ないってのが、本当に良い。もちろん最初は、魔法が効きすぎてて心配・・・って印象は正直あったけど。
でもライブラリってのは、本来達成したい機能をガイドするために存在するのであって、ライブラリのAPIを使いこなすので手一杯になってたら本末転倒なので。リアルワールドには、他にも考えるべきこと、やるべきことがいっぱいあるので。
ストアにCSSにアニメーションにって、最初から全てが揃ってる状態からはじめられるのも敷居が下がってていいし、コンパイルして最適化されたコードだけが配信されるっていう発明は、今後の主流になるよなーと思ってる。
少し前まではエディタまわりのサポートやらDXが弱かったイメージあるけど、最近は落ち着いてきてると思うし、何ら不満はないです。
SvelteKit
後発なのもあってか、本当にバランスがいいAPIセットやなって思う。
CDNエッジにももちろんデプロイできるし、ページごとにSSR/SSGを切り替えられたりと、「顧客が本当に欲しかったもの」さん！って勝手に呼んでる。
`+page.js`みたいなルーティングにおけるファイル名の縛りは、最初はちょっとOpinionated過ぎでは〜？って思ってたけど、フレームワークはOpinionatedであるべしって最近は思う。もちろんそれがコスパや審美眼的に許容できるならではあるけど、悩む余地は少なければ少ないほうがよい。なんかそういうラインのギリギリを攻めてくるのが上手いな・・・って。
`load()`やらForm action系のRemix感あふれるAPIたちについては、それなりに挙動の理解が必要なので、そこだけは時間が必要そう。でもこれはSvelteKitの問題っていうより、モダンなSSRへの回帰みたいな大きなテーマへの慣れみたいな話かなーとも。
https://kit.svelte.dev/docs/load
https://kit.svelte.dev/docs/form-actions
RCが取れるのも時間の問題というところで、投資しておいて損はないかと。
Solid
Svelteと同じく、VDOMではなくコンパイル時に最適化される系のライブラリ。
Svelteとの違いはその内部の最適化と程度と、やはりはそのシンタックスか。こちらはJSXとHooksライクなAPIで書けるので、SvelteよりもEverything in JSっていう書き味が好みっていう人もいるかもしれない。
ポストReact枠として個人的には期待しつつも、Svelte(Kit)で対応できない案件ってあるんかな？っていうのが目下の関心事って感じで、そこを検証していきたい気持ち。
Signalsはもちろん、`createResource()`とか`Suspense`コンポーネントまで同梱されてるけど、CSSまわりが不在なのよな〜。もちろんCSSinJSはできるけど、それだと結局あとで最適化するのが手間でな〜、って。結局JSXである限り、この悩みはつきまとうのだなあ。
SolidStart
まだまだベータ。
昨今のフレームワークはだいたいViteに載ってるので、CSS Modulesなんかはそのまま使えるようになる。（しかし別ファイルな書き味が好きくない・・かといってCSSinJSは・・Tailwindは・・ウッ・・）同様にVite側からアプローチできるものとして、`vanilla-extract`とかは気になるけど、別ファイルってのがな〜。
SvelteKitの`load()`相当としては、`routeData()`ってのがあったりと、まあAPIセットに関してはだいたい一緒な感じに落ち着く気がしてる。
Solidの本体で、Partial Hydrationを直接的にサポートするコンポーネントが実装されたりもしたので、そのあたり踏まえて一味違う感じのフレームワークになったりせんかなーって見守ってるところ。それこそMarkoみたいに、自動でRSCライクな挙動をいい感じにしてくれるやつみたいにならんかな。
そういう意味でも、まだ少しアーリーなステージかなーという見立て。
メタフレームワーク
特定のライブラリにとらわれないフレームワークたち。
Astro
今季のイチオシ！
SSRとPartial Hydration（以下PH）さえあれば、だいたいのWebページは作れるとさえ思ってるし、Nextがこれをやってくれてればな〜とまで思ってた。
そういう意味では、各フレームワーク側で、PHやそれに準ずるアイデアが追加されたりすることもあるんでは？って思ったりも。Svelteくらい小さいならば、JSの遅延ロードはさておくとしても、遅延実行なプリミティブはどこでも便利なはずやし。
ともあれ、メジャーバージョンも出たところなので、SSGで攻めたい場面では安心して場に出せる手札かと。
Qwik
自分の中でも評価が揺れてる期待の新星ポジ。
着想は理解できるし同意もするけど、これは人類に扱いきれるのか？！みたいな難しさを孕んでるというかなんというか。（こういうとこにAngularの面影を感じｒ）あとは実用に値するのかの検証がまだまだ必要なフェーズでありつつ、検証するのも大変ね？ってところで、まあ静観かなーということにしてる。
PHでは不十分なほどに、ダイナミックな枝があるようなページ構造ってどういうUIなんやろう？っていうのがパッと出てこないのと、そこまでカリカリにLazinessを追求せざるを得ない場面に遭遇したことがないからかな・・。
こういう振り切ったアプローチ、嫌いじゃないけど。（ただRustで書かれたOptimizerのコードリーディングは挫折した）
まとめ
無秩序データフローの神Hooks feat. 十二単衣ばりContextみたいなReact案件たちに疲弊し、かといって自分で書いててもなんだかしっくりこない、そんな2022年。
どんなライブラリでもフレームワークでも、結局カオスになってしまうのなら、Write less codeこそがやはり真理なんや・・って気持ちの高まりによるポエムでした。（無闇矢鱈と追加したライブラリのAPIを覚える前に、捨てやすいコード分割や関心の分離やWeb標準に脳内リソースを割くことを学んでくれ頼む）
React+Next以外の選択肢もあるとはいえ、
- やっぱりまだRCなりベータなりと微妙なラインで手が出しづらく、なんだかんだ消去法で・・・
- 不安なのでとりあえず・・・
ってな感じで、しばらくも結局Nextになっちゃうのが現実なんやろうとは思いつつ。
未来のために、自分の頭で考えて己の審美眼を信じて、意志ある技術選定をしていかねばならぬ。
（なんか今年の振り返りみたいになってしまった）
