Reactには組み込みの状態管理機能があるの？

ちょっと懐かしいな、昔Backboneのチュートリアルをたくさん書いてたんだ。 https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet... インポートがない以外は、15年後でも嫌いじゃないよ。LLMのおかげで、コーディングについての考え方がかなり変わった。どのように言語を書けばLLMが最も効果的に書けるかに興味がある。JSX/宣言的なものは結構しっかりしてると思う。useEffect以降のReactコミュニティはちょっとふわふわしてきてる気がする。多分、LLMが「考える」にはあまり良い方法じゃないんじゃないかな。（表現力、明示性、解析可能性について何かある）

MarionetteはBackboneのボイラープレートをかなり減らしてくれたけどね。

1,000コンポーネントが同じページにあるような大規模アプリ もしページに40X25の編集可能なテーブルがあったら、それが1,000コンポーネントになるね。でも、テーブル以外では、1,000以上のコンポーネントを一つのページに持つのはやりすぎに思える。

Reactの本当の革新は「単方向データフロー」だと言えるかもしれない これはDOMの動き方そのものじゃない？ データは属性やプロパティを通じて下に流れ、イベントは上にバブルする？ > でもReactチームはFlowアーキテクチャをフレームワークの中心に据えたんじゃない？ 彼らはFlowではなくFluxと呼んでたよね？

コンポーネント自体が追加の複雑さの一形態なんだ。アイデアは、構成され自己完結したコードの島を提供すること。これを達成するためには、大量のマークアップ、プレゼンテーション、イベント処理、ビジネスロジックの記述、そして前述の抽象化を補うためのセキュリティやアクセシビリティのロジックが必要になる。エディタで見るものはあまり見栄えがしないかもしれないけど、その裏には膨大な無駄が隠れている。なんで人々はこれを好むの？ メンテナンスの速度は上がらないのに。開発者が快適に感じる事前定義されたアーキテクチャスキームに組み込めるから好まれるだけなんだ。それだけ。結局は快適さの問題だけど、複雑さはとんでもないことになってる。シンプルなものはタダじゃない。

双方向データフローがあり、ストアを更新するとUIが変わり、それが状態ストアを変えて、またUIが変わる、という問題がある。Reactでも同じ問題が起こるよ。循環する状態更新。状態変更→useEffectをトリガー→状態を変更。これ、Reactを始めたばかりの頃にぶつかったことがある。

人々は、React/Flux/Reduxの前のフロントエンド開発がどうだったかを思い出さないし、思い出せないこともある。1000行未満のシンプルなページでも、状態管理で問題が起こることが簡単にあったよね。もちろん、対策はできたけど、全然簡単じゃなかった。

私は何年もAngularを使っていて、最近新しいプロジェクトのためにフロントエンドの仕事に戻ってきた。これが私のReactの経験で、完璧ではないし、いくつかのReact特有のことを学ぶ必要があるけど、正しいことをする傾向があるよ。

ここでの著者です。単方向データフローが実際の問題を解決するという点には感謝していますが、実際には一つの複雑さを別の複雑さに置き換えているだけだと思います。確かに、Backbone Storeの状態変更のカスケードはデバッグがフラストレーションでした。でも、Reactの抽象化は同じくらいフラストレーションを引き起こす問題を引き起こします。古い状態を参照するクリックハンドラーの古いクロージャー、依存配列のオブジェクトが毎回再生成されるための無限のuseEffectループ、安定からインデックスベースに変わったために起こる神秘的な入力クリアリング。違いは、Backboneの問題は明示的で可視化されていたことです。何かが壊れたとき、イベントハンドラーを追跡して、何がいつ発火したのかを理解できた。複雑さは目の前にあったから、デバッグ可能だった。Reactの問題は抽象化の背後に隠れている。Reactが問題を解決しないとは言っていませんが、それらの解決策がFacebook規模ではない99%のアプリに適切かどうかを疑問視しています。時には、明示的で冗長なアプローチの方が、長期的には考えやすいこともあるんです。

それに、Reactが他のレンダリングライブラリより「複雑」だと見せかけるのはやめようよ。() => Hello, Worldよりシンプルなものはないよ。

こういう批判は、業界標準の批判的な検証が不足している反応だと思う。Reactが単純に悪いとは思わないけど、必要ない場面で無思考に選ばれていることはあると思う。それに、Preactはどうなの？3KBのライブラリ（Reactは100KB以上）で、90%以上のReactサイトの代替として使えるんだよね。この無駄さは、細部への注意が欠けていることを示してる。こういう記事は、真剣な提案というよりは、もっと注意を払うように促す挑発だと見てる。

ブラブパラドックスは本当に存在するし、どこにでも見られるよ。

まさにその通り。Reactに関するスレッドでは、いつも人が集まってきて、どれだけ複雑かを語るよね。「愚かさ」みたいな言葉を使って、何百万ものプロが使ってるツールを批判するのは、他のコメントを真剣に受け取るのが難しい。特有の傲慢さと無知さが漂ってる。Reactが良いか悪いかは別として、使われる理由があるんだ。完全に無視するのは、ちょっとチェスタートンのフェンスみたいだね。

React（あとTailwindも）って、雇用や採用においてはすごく便利だよ。プロジェクトにパラシュートで飛び込んだときに、誰かが失敗する可能性や、最初の週や月に迷子になる可能性はかなり低い。正しい抽象化や問題に対する最適な技術的解決策とはあまり関係ない。ウェブにはデフォルトのデザインパターンがないから、良くも悪くも西部開拓時代みたいなもんだ。これを理解してから、現代のウェブスタックと和解したよ。

人は人気のある悪い技術を使って、いつも間違いを犯してるよね。MongoDBが必要だった時代、アプリはみんなNoSQLじゃないとダメだって言われてたの覚えてる？Kafkaを使って、すべてがイベント駆動型だった時もあったよね。左パッドがそれぞれマイクロサービスを持つ必要があった時期も。大企業（Facebook、Google、LinkedIn、Amazon）がそれを推し始めて、人気のある開発者がブログで紹介して、大きなカンファレンスで講演が行われて、広告収入やVCマネーで資金が投入されたマーケティングが「すごい」技術として押し出されると、CTOたちがそれを採用し始めて、採用基準になって、急に誰もそれがクソだとは認めたくなくなるんだよね。だって、みんなのキャリアがそれに依存してるから… あるいは、もっと寛大に考えれば、まだ生産環境で痛い目に遭ってないから、他のアーキテクチャの選択肢がどれだけシンプルかを知らないだけかもしれない。人気があるからって、必ずしも一般的なユースケースに合ってるわけじゃない。実際、そうじゃないことが多いんだよね。

... 有名で広く採用されているフレームワークや技術が、単純に悪いとか昨日の技術よりも改善されていないと大胆に主張する人たちには、無邪気な傲慢さがある。よく採用されているフレームワークや技術が、当時の外部要因ではなく、ポジティブな美徳によって有名になったと考える人たちには、無邪気な無知がある。Reactは、FacebookがGoogleのAngularに反応して作ったもので、Angularは当時のBackboneや他の技術に反応したものだった。その時点で、開発者のマインドシェアを巡る企業間の競争になり、企業自体がその技術を使っていないのに、開発者をハイプトレンドに巻き込んだ。ブートキャンプがその技術を教え始めて、企業はそのスキルを持つ人材を求めるようになった。なぜなら、当時のブートキャンプの大規模な推進によって、すべての「新しい」開発者がそのスキルを持っていたから（MOOCやブートキャンプの急増）。「採用の懸念」や「開発者が望んでいるから」や「友達のXYZが使っているから」などの理由で技術選択をした創業者に何人も会ったことがある。「Xは古いやり方だから使えない」とかね。これらの技術について「傲慢」に語らず、「大多数の開発者」が使っていることを軽視せずに議論する余地は確かにある。もしかしたら、大多数が間違っているかもしれない。

一方で、ここで話しているのはウェブのことだからね。技術的負債、いわゆる「ハンマーしか持っていない」マインドセット、NIH、履歴書重視の開発が悪名高いドメインだよ…

これは傲慢なのか、それとも経験と異なる視点の組み合わせなのか？ある開発者は、コンポーネントエコシステムや人材プールのおかげでReactが大好きかもしれないし、別の開発者は、カスタムHTML/CSSを書いているからReactが必要以上に多くのJSを書くことを要求するのが嫌かもしれない。Backboneを選ぶことはある？ないね。でも、現代のウェブアプリを作るのに必要なバニラJSの少なさに驚く開発者も多いかもしれない。これまで以上に、異なるフロントエンドスタックのトレードオフをプロジェクトごとに評価する必要があるね。

ここに作者がいます。「パレオインフルエンサー」との比較は面白いけど、実際には両方の側面があると思う。確かに、過去を美化したり、現代のツールを軽視したりする誘惑はあるよね。でも、新しいものや人気のあるものが自動的に良いって考える傾向も同じくらい強い。Reactは純粋な技術的なメリットだけで勝ったわけじゃない。Facebookのマーケティング力が後ろ盾になっていて、採用時のチェックボックスにもなっているし、みんなが使うからみんなが学ぶという自己強化的なエコシステムを作り出した。この記事は「世界中の最も才能あるエンジニアたちが騙された」とは言ってない。もっと微妙な質問を投げかけているんだ。「その努力は本当に前進させたのか、それともただ別の複雑さに横移動しただけなのか？」記事にある二つの実装を見てみて。どちらも同じことをしてるし、だいたい同じ長さなんだ。15年のReact開発、数えきれない開発者の時間、そして巨大なエコシステムがあるのに、劇的に少ないコードを書いたり、問題をもっと優雅に解決したりしているわけじゃない。ただ違う方法で解決しているだけで、異なるトレードオフがある。時には過去を振り返ることが「レトロ理想主義者」であることではなく、比例した利益なしに複雑さを加えたのかを疑問視することなんだ。パレオダイエットの人たちが、私たちが食べ物を過剰に設計したと指摘しているのは、何かの真実かもしれない。もしかしたら、私たちのフレームワークも過剰に設計されているのかも。

マクドナルドを食べるのが完全に悪いとか、「本物の食べ物」から明らかに劣ると言い切る人たちには、無邪気な傲慢さがあると思う。人気が質を保証するわけじゃないし、メニューの変更が進歩とは限らないし、批判すべき点もたくさんあるけど、こういう記事の著者は時々、レトロ理想主義者のトロープを利用して反体制的になることで大きな影響を受けることがあると思う。栄養的にはパレオインフルエンサーのような存在だね。そういう主張は、世界中の経験豊富な食べ手たちが根本的に不健康な食の選択に騙されていることを示唆していて、ちょっと面白い。

簡単なことにReactを使う理由は、複雑なことにもReactを使うからで… 地元の店に18輪のトラックで行く理由は、全国を貨物運ぶときにも18輪のトラックを使うからで、複数の車両を使いたくないからだ。/s 誤謬は両方向に存在することがある。「仕事に適した道具を使う」というのは良いアドバイスだね。

今、React以外にもその機能を持った選択肢がたくさんあるよ。Reactだけがそれを持っているとは思えない。

それは全部本当だけど、この記事のポイントはまだ成立してると思う。Reactは一つの妥協を別の妥協と交換しているし、使われるツールに関わらず、そのツールを使うソフトウェアエンジニアたちは、そのツールを機能させるために多くの努力をしなきゃいけない。ReactがBackboneより良いかどうかの問題じゃなくて、私たちソフトウェアエンジニアが、グループとして正しい妥協を強調しているのか、今日の人気ツールの妥協を検証することで何を学べるのかが問題なんだ。

記事はほとんど書かれてなくて、ただクロードにブログを書かせただけなんだよね。

君のコメント、実際には何も言ってないように見えるんだけど。