fast-checkを使ったプロップテストは、小さな変更があるときにすごく役立つって感じた。

使わなくてもいいよ！私の会社（ほぼ私が開発した）でこの10年間に開発したフレームワークについてどう思う？MITライセンスでオープンソースにするよ：https://github.com/Qbix/Q.js

基本的にReactがやってることを、もっと良くやってる。SolidJSにはまだいくつかの大きな痛点があるけど、私が見つけたのは、propがシグナルなのか、シグナルになるべきなのかがわからないこと。型システムがあまり役に立たない。Reactでは、参照が変わったら、その参照をpropとして読むコンポーネントが再レンダリングされるって確信できるけど、Solidでは更新が観察されるかどうかがあまり明確じゃない。

なのに、業界全体の慣性のせいで、いくつかのコンテキストでは仕方なくReactを使わなきゃいけないのが本当に残念。多くの人が仕方なく働いていて、ほんとにそうじゃなければいいのにって思ってると思うよ。それは、彼らが知ってるものを使うことを意味するし、それがReactになる。私もその気持ち、めっちゃわかる。人々は子供や趣味に時間を使いたいし、最悪の場合、年老いた親の世話をしてるかもしれない。

問題の一因は、ブラウザが本来の目的を果たしていないことだと思う。GoogleはChromeを通じてほぼ独占的な立場を持っていて、やりたいことは何でもできるし、やりたくないことはやらなくてもいい。だから、基準がGoogleが開発に時間をかけたいと思うこと以外にはほとんど機能しない。彼らは独占的すぎないから、ブラウザを完全にロックダウンされた製品にすることもできない。SafariやFirefox（この順番で…ちょっと残念だけど）がそれを阻んでいる。だからブラウザはあまり進化せず、ドキュメントビューアからアプリケーションランタイムに変わるという強い技術的な力があるのに、結局あまり動いていない。SilverlightやJavaアプレット/JNLPの夢を実現するチャンスがあるのに、誰もそれをコントロールできないならやりたくないと思っている。FirefoxもOSSの精神で一人で先駆けるだけの開発力はないしね。だから、JSの人たちは、ブラウザやプラットフォームレベルでより良いものを提供されないから、アプリランタイム版のNANDチップで頑張るしかないんだよね。

確かに最近、ブラウザやCSSは通常はJSに頼るような多くのユースケースを解決してきてる。これをさらに進めていくべきだね。

正直、これらのフレームワークがこんなにすごいことを成し遂げてるのは、狂ったプラットフォームで作業してるからだと思う。HTML、CSS、JSは、ウェブが主にテキストと簡単なフォームだった頃には意味があったけど、今はインタラクティブなアプリを作るにはクソみたいな基盤だよ。全部捨てて、再構築する必要がある。

もっと言うと、ブラウザは5つか6つ必要だと思う。ショッピング用、バンキング用、ソーシャル用…こういうプラットフォーム同士はバックエンドで競争して、フロントエンドでは一貫した体験を提供すればいいんだ。そうすれば、私たちのデバイスで動くコードを書いてる人たちがユーザーを裏切るような利害の対立がなくなる。使いやすさも向上するし、一つの銀行の構造や流れ、ホットキーを覚えれば、他の銀行のインターフェースも簡単にナビゲートできるようになる。各ビジネスが別々のフロントエンドを作るのは無駄だよね。結局、競合とほぼ同じものになるんだから。サンドイッチ屋は、アプリを8%の顧客にインストールさせるためにどう動くかで競争するんじゃなくて、より良いサンドイッチを作ることで競争すべきだよ。

Reactは複雑な問題を解決するのが得意だよね。でも、すべての問題が最初から複雑なわけじゃないし、デフォルトで複雑なツールを使うとプロジェクトに複雑さを加えちゃって、迅速に反復する柔軟性も失われる。これは、過去の機能や未来の機能から比較的もろいエコシステムを維持する必要があることに加えて、JavaScriptや他の技術の複数の領域で当てはまることもある。現在のウェブアプリ構築の世代から次のカーブが出てくるのを探してる。

いろんな会社やスタートアップで結構な数の技術スタックの決定に関わってきたけど、Reactのメリットを含む議論を聞いたことがないんだ。決定はいつも、慣れやエンジニアの採用のしやすさ、エコシステムの組み合わせに基づいてたね。

「React最高！」って聞いたことないな。いつも「もっと簡単に人を雇える」って話だよね。残念ながら。

ウェブ開発者が合理的な生き物だと思ってるのは間違いだよ。実際には「社会的証明」や「権威」みたいな人間のバイアスに簡単に引っかかるから。

+1 ReactのDXは本当に素晴らしい。最初はすごく良かったけど、変な感じになって膨れ上がった。でも、JSの地獄に対してはまだまだ素晴らしいと思う。ただ、確かに面倒くさくて、必要な悪って感じもある。改善の余地はあるよね。Next.jsは地獄そのもの。皮肉なことに、AIのおかげでかなり耐えられるようになって、実際には結構良い。だけど、それがアーキテクチャデザインにとって良いこととは言えないよね？今は変な時代だ。もちろん、傍観者として批判するのは簡単だよね。私もそうだし。Next.jsは自分たちの独自のやり方でやりすぎてる気がする。use-clientとserverの使い分けは、最初からおかしいよね。でも、実際のところ「アイソモーフィック環境が欲しいなら、他にどうするつもりなの？」って質問があると思う。私の答えは「やりたくない！」だけど、Vercelや権力者たちはプロダクトの人たちの心をつかんでるみたい。少なくとも今はね。

ViteのReactについて言及するなんて面白いね。3年前にウェブアプリをそのセットアップに移行して、もう振り返ることすら考えなかった。Reactはまだ信頼できる作業馬で、物事を進めるのに助けてくれるし、エコシステムも豊かだ（この規模のものに対して質のバラつきは仕方ないと思ってる）。数年前にNextをいじってみたけど、開発を追ってみた結果、自分が必要としていることをやっていないと判断した。アイソメトリックレンダリングは、実際よりもずっと良さそうに聞こえる。痛みはフロントエンドとバックエンドの異なるプログラミング言語から来るんじゃなくて、クライアントの状態、サーバーの状態、セキュリティなどを調整するのが難しいからなんだ。各側に専門的な言語がある方が、どのコードがサーバーで動くべきか、ブラウザで動くべきかを考えなくて済むから、実際には助かると思ってる。

もしかしたらバックエンドの私たちが助けになるかも。フロントエンドをやる必要があるときは、できるだけ少しだけ学ぶようにしてる。Reactがその役割を果たしてくれる。もしAngularが退屈な王座に座っていたら、ただAngularを使えって言ってたかもしれない。世界が使っているものを使えばいいんだよ！

Reactがひどいアーキテクチャの決定で崩壊したら、Viteはフォークすべきだよ。Vueのコミュニティプロジェクトを通じて、最高のReactの開発体験が提供されてるのはおかしい。

もしコストがレンダー時間が数ミリ秒増えることと、開発時間が数時間増えることなら、それはかなり楽観的だね。ほとんどのReactプロジェクトは最適化の段階に到達せず、レンダリングや遷移の遅延が数秒に達してUXに大きな影響を与えることが多い。フックや再レンダリング、互換性の問題に対処するのにかかる時間は、中規模プロジェクトで何百時間、大企業では何千時間にもなるよ。

Reactが余分なレンダー時間や開発時間を追加するなら、何を節約してるんだ？

Reactに対する主な不満は、周辺ライブラリの質がイマイチなことだね。「また新しいリライトとメジャーバージョンアップをやってる」って感じの人たちが多い。APIの安定性を維持するのはそんなに難しくないんだから、もうちょっと頑張ってほしい！

Remix 3はReactをベースにしてないみたいだね。React RouterやRemixの人たちは素晴らしいライブラリを作るけど、問題は次の素晴らしいライブラリを追いかけ続けてることなんだ。彼らの最新作を使う頃には、もう新しいライブラリを作り始めてて、ツイートしてるからね。

すごく鋭い指摘だね。同じ気持ちを言葉にできなかったから、感謝！Nextが自滅しても、人々は多分Vite上のReactに戻るだろうね…この状況については私も同じように感じてる。短期的や中期的にReactの支配に影響を与えるようなことは、悪い選択が積み重なっても難しいと思う。

Reactが今人気なのは、単に人気だからだよね。開発者は企業が使ってるから使ってるし、企業は開発者が使ってるから使ってる。全ての代替案より優れてるから人気なわけじゃなくて、単にクリティカルマスに達しちゃったから「大きすぎて潰せない」状態になってる。Reactの多くの足元をすくうものを避けるには常に努力が必要だよ。支持者はこれを「スキルの問題」って呼ぶけど、たとえそうだとしても、同じことをより少ないコードで、早く、精神的な負担も少なくできるフレームワークの方がいいと思わない？

同意だよ、Webコンポーネントはフレームワークを必要としないし、Reactでできることは全部できる（attributeChangedCallbackを通じたリアクティビティも含めて）。ゼロから始める人の視点で見ると、Webコンポーネントの学習曲線は実際にはReactよりもずっと緩やかだよ。さらに、Webコンポーネントは良いパターンを強制する。属性として文字列しか渡せないのは実際に天才的で、シンプルでミニマリストなコンポーネントインターフェースを促進し、Reactコミュニティが防ぐために全く新しいパラダイムを発明しなければならなかった参照渡しの問題を避けることができる。皮肉なことに、今でもReactを推してるトップの人たちの多くは、Facebookの株で裕福になって、もう働かなくてもいい人たちだよ。実際、彼らはこの技術を若い人たちに押し付けていて、彼ら自身はもう使う必要もないし、コーディングもしなくていい。そんな中で、業界を離れたい（または離れた）開発者がたくさんいるのは、状況がひどくて、自分たちが決定できることが少ないから。サイドプロジェクトで使っている良いツールがあるのに、劣悪なツールで働くのは士気が下がるよ…こういう状況を見ると、「会社が自分のツール選びを非効率にさせるなら、他の方法でも非効率でいる権利がある」と思ってしまう。個人的には、もうコーディングはしてない（サイドプロジェクトだけ）。クリーンでミニマリストなコードを書くのが得意なのに、それが残念だ。日常の仕事では、n8nやFlowise（AI用）のドラッグアンドドロップUIプラットフォームを使ってる。コンパイルステップなしで、実際にお金がもらえるプロジェクトでバニラJSを使えるのは爽快だ。これらのUIプラットフォームは、Reactよりもずっと予測可能に扱える。Reactを使ってた頃（ほぼ10年）、奇妙なグリッチや状態管理の問題を常にデバッグしてたけど、Webコンポーネントやn8nのようなプラットフォームではそんなことは一度もなかった。

Reactから完全にビジネスを移したから、Metaの tinkererたちが2年ごとにReactを再発明して、名前を何度も使い回すことを心配しなくて済む。Webコンポーネントは素晴らしい。これが本当の未来だ。

大企業では、内部アプリ用に中央集権的なReactライブラリを使うことが求められてる。だから「デフォルトでReact」じゃなくて、「Reactが唯一の選択肢」って感じ。中央ライブラリをWebコンポーネントとして再実装することで、好きなフレームワークを使えるようにするのが私たちの道だと100%同意するよ。

誰か、ReactのUIライブラリの中でウェブコンポーネントを使って成功したことってある？オリジナルのデザインシステムでコンポーネントライブラリを作るとき、RACみたいなヘッドレスライブラリに頼れるのがすごく嬉しいんだ。基本的なコンポーネントの実装がアクセシブルで、タッチデバイスでもうまく動くからね。理論的にはウェブコンポーネントが補完的なツールになり得ると思うけど、実際にはどこで使うのがベストかは分からないな。

「多くの人がウェブコンポーネントをフレームワークの競合と見なしているけど、実際にはそうである必要はない。ウェブコンポーネントはコンポーネント実装とブラウザの間のインターフェースを定義するだけで、相互運用性と信頼性のある構成を可能にする。」 私はフレームワークを避けてる。プレーンJS、ウェブコンポーネント、いくつかの良いドメイン特化ライブラリがあれば、私のニーズは十分に満たされるよ。

強く反対だね。Web Componentsは、違う服を着たReactに過ぎない。ブラウザ用のアプリを書くのに、コンポーネントベースのフレームワークスタイルのアーキテクチャは必要ないよ。ブラウザ用のアプリを書くのは全然難しくないから。大きなフレームワークや同じようなコンポーネントの狂気は必要ないんだ。