フロントエンドフレームワーク戦国時代
もはやデファクトスタンダード
新進気鋭
server / client model
not SSG
react
react routerの作者関わってたっけ
shopifyが買収
fly.ioと仲が良さそうだけど、中の人繋がりあったっけ？
MPA (server rendering)
SSG
hybrid rendering
SSR, SGをpageごとに分けられる
islands
SSR
resumable
クリック時点で必要なJSを落としてきて動かす
UIにおける遅延評価と言えるなmiyamonz.icon
ただし、prefetchとかもOK
builderIO
reactivity
イケてる感と抽象度の高さを感じるmiyamonz.icon
でもちょっと、早くないスカ…？という気持ちもある
react componentは受け取れるんだが
コンポーネントまたぐステートとかどうするかな。
これはqwik wayでいくしかなく、signalなんだな
react内外の意識したくねーーー
軽くドキュメント読んだが、実際のところresumableとか、スピードがいいところはかなり納得ができる
miyamonz.icon
Jamstack的な構成ならAstroが好まれそう
消去法でremixかなあ
qwik
スピードにフォーカスする点は良いが、
Reactがオプショナル
アプリ全体で一貫した状態管理や諸々をする際、React wayが取れず、Qwikあるいは自分で頑張る必要がある
そこで合理的選択があったり、ピンとくる設計があればこれにしてもいいかも
Astro
これも似た理由
あとMPAへの戻しが実際どのくらい現実的かわからん
静的サイト中心なら全然あり。
動的, SSRならRemix, 静的ならAstro
外側を眺めてるならこんな基準で良さそう
あとはもうちょっと実際の素振りを交えて判断
複数のコンポーネントをまたいだ状態管理ができるかどうかが、特にmiyamonz.iconが気になるところ
feature単位での実装が大事
ステートはコンポーネント外に記述できないといけない
feature間の依存は、明示的にimportで記述されるべき
なぜ大事かと言うと、
すばやく欲しい機能を作り、
メンテナビリティも維持する
最も堅実で、デメリットもほぼない方法だから
RSCあたりのメモ
Naming is hard.
SSR is actually client component (one-shot) rendering on server.
And, we can probably run server components on client.
Feels like "stateful components" / "stateless (and async) components" mean better. But, that's way too confusing because of historical reasons.
SSRは、実際は、サーバ上で一回client componentをレンダリングしてるだけ
この人のwakuworkってのは実装見ておくと勉強になりそう
キーワード、概念
エッジコンピューティング
アイランドアーキテクチャ
これ、一見良さそうだけど、どうなんだろ
エッジコンピューティングとは概念的には直交っぽい（同時に成立させられそう）なんだけど
エッジコンピューティングやれば、パフォーマンス的な面でアイランドアーキテクチャの必要性が薄って結果的に択一になりそう
エッジコンピューティングは、単に分散環境を学んで、そこで動かす（基本的には、使うライブラリを減らしたり小さく頑張るだけ）のをやればいいだけ
エッジで動くなら、Nodeでも動かしやすいはず
アイランドアーキテクチャの場合は、JSのフレームワークを一段上の抽象を見出して、フレームワークの履き替えがいる
大変よお、そういうのは
シェアという観点でも
あー、でもsignalsとreact側のjotaiとかのintegrateするなんかがあれば、割と気にせず使っていいかもな
かなり大事だった
動的か静的か、あたりってキャッシュ戦略あたりと同じ構造になってそうなので、キャッシュ戦略を勉強しておこう
react以外
SolidJS
Ryan Carniato
Netlify
solidjsは、主張は分かるが、仮想DOM捨てて、お前がいうreactivityでどうやってこのコンポーネントの世界を統治していくんだ？というビジョンが無いのでしんどそう
野党みたい