ReactとSolidJSの思想を比較して考える

React

VDOM作ってdiff取ってパッチをいい感じに当てる

コンポーネントは関数

コンポーネント内のステートや某をhooksで管理する

（classコンポーネント時代はもう過ぎたものとします）

Viewはテンプレートエンジンのようにデータをpushせず、必要なものをpullすべき

何らかのバックエンドのデータがviewに依存するのではなく、viewが必要なデータに依存すべき

learn once, write anywhereは最高

仮想DOMを学んでおけば、仮想Hogeを作って同じことが出来る

SolidJSは実DOMでのパフォーマンスを意識してて、そのためにbabel使ったcompileで最適化もしてる

なんで、微妙に方向性は違うしな、という気もする

でも、reactivityもどこでも使える気がするけどどうなんだろう

もうちょっとSolidJSの作者の、コンポーネントに対する反論の記事を読んだほうがいいか

solidjsのコンポーネントのレンダリングの仕組みも把握したほうがいい

SolidJS

reactive programming

これって、何によって値が変わるのかを追跡して更新を書けるだけなので、

任意の問題に対するモデル化を提供することが出来る

特定の解決策ではない

実際、こんなコードでReactのVDOMのスタイルを、reactive な方法で表現ができる

code:js

import { render, diff, patch } from "v-doms-r-us";

import App from "./app"

mountEl = document.getElementById("app");

let prevVDOM = [];

createEffect(() => {

const vdom = render(<App state={state()} />);

const patches = diff(vdom, prevVDOM);

patch(mountEl, patches);

prevVDOM = vdom;

});

setState({ name: "Jake" });

現代にこのスタイルが主流として残らなかったのは、適切な制約をかけてくれるAPIがなかったからではないか

react way, hooks styleを取り込みつつ、直感的に書けたり、書きながら良い感じに抽象、蒸留を促すスタイルが伴えば最強感がある

この、書きながら考えてどんどんいい感じにキレイになる、というのは大事で、かつてreactive programmingが主導権を握れなかたのはここにある？

reactiveに書きまくってるとスパゲッティコードになる

関数として切り出すのと同じ感じで切り出せるようなAPIを持っていることが大事

reactive programingの書き方のスタイルの違いが大きいのでは？

reactiveなstream(observable)に対してメソッドを適用していくスタイル

rxjsとか

これは学習コストが高い

recoilなスタイルは、従来の手続き型をそのまま書ける

solidjsの作者の、パフォーマンスどうよくするのかの認識の仕方は良いなと思う

なので、reactivityだけを取り入れたいなら今でもReactでできる

フロントエンドはサーバサイドからのデータ取ってくれば良くて、フロント側のステートなんてそもそもあんまりない論もある

これはそういうwebアプリケーションならそうで、SWRとかがあればもういいやんという感じになる

複雑なGUIが必要ないならそうだと思う

エコシステム、コミュニティ的な観点から、ReactやNext.jsが強いことに変わりはない

変わりうるとしたら、複数のライブラリを部分的に埋め込めるような仕組み

コンポーネント単位でもできる例が挙げられてる

それで、部分的にメリットが有るところで、ReactまたはSolidJSの中に、他方が入る、というような手法を試みられるかも

それらを可能にするような基盤が、柔軟性とパフォーマンスを両立する形で提供してくれたら、なめらかに移行していきそう

ちょっと違うか

こういう物をやる場合、結局の所どう動いとるん？という疑問がつきまとうはずで、React使うときは仮想DOMの挙動を知っておこう、というのと同じレベルで、なんらかの基盤の問題意識と挙動を把握すべきってなりそう

もうちょっとjsでかすぎ問題についても明るくなっておきたい

デカすぎ分かるという気持ちと、

みんな高性能なスマホ持ってるから富豪的にやっていこうや！ドンという気持ち