新しいデザインのプルリクエストの差分ページが公開されたみたいだけど、DOMが膨れ上がったに違いない。

最近、問題に光を当てるブログ記事[1]（HNスレッド[2]）を見つけた。要するに、PRビューは10万以上のDOMノードをレンダリングすることができ、その多くは目に見えないインラインSVGノードで、SPAルーティングがナビゲーションをかなり遅くしているってこと。[1]: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe... [2]: https://news.ycombinator.com/item?id=44799861

それはほぼレビュー不可能だね。もしNDAを破らずに共有できるなら、そんなにファイルが関わるPRってどんなの？

その改善がユーザーに届くまでどれくらいかかるの？OSのアップデートが必要なのかな、それともSafariはFirefoxやChromeみたいに早いアップデートの仕組みを使ってるの？

ありがとう、それは確かに良い兆候だね。Chromeとその派生のレンダリングエンジンの独占状態や、Firefoxの普及があまり進んでないことを考えると、AppleにはSafariをmacOS/iOSでただ生き残らせるだけじゃなく、素晴らしいものにしてほしいな。

ここにいるみんながJSとReactを責めてるのが面白いよね。でも、君がリンクした修正はCSSのパフォーマンスについてだし。

で、問題は「Rails」じゃない。 彼らはRailsを捨ててReactに移行したのが問題だ。古いSSRのGitHub体験はすごく良かった。移行する前は、どんなマシンでも大きなPRをレビューできたのに。

そうそう、まさにその通りだと思ってた！それに、GitHubの検索機能は最悪だし、diffの表示もひどいよね。今のクライアントがBitbucketからGitHubに移ったばかりで、開発者たちが大騒ぎしてるよ。

Gistを埋め込むのに、ダークモードやライトモードを完全に実装してないのがイライラする。テーマは常にライトに設定されてて、値をオーバーライドする方法がないんだ。せめて、自動に設定してほしいな。

じゃあ、いい例って何？

私には、GitLabよりも速いと思う。

それなら、MSに買収される価値があるね。

前の会社で10年間Phabricatorを使ってたけど、GitHubがこんなにひどいとはまだショックだよ。これが業界標準なの？！残念ながらPhabricatorは今やメンテナンス専用だね。https://en.m.wikipedia.org/wiki/Phabricator

フラストレーションが溜まるよ。GitHubは以前はかなりパフォーマンスが良かったのに、今はシングルページアプリになってからダメになった。

「GitHubのウェブサイトはどこでも遅い。」使ってるソフトウェアによるんじゃないかな。例えば、コマンドライン検索やtarball/zipballの取得は、github.comやraw.githubusercontent.com、codeload.github.comからは遅くないし、GitLabよりも遅くはないよ。ブラウザも使ってないし、gitソフトウェアも使ってないけどね。

WindowsのFirefoxではかなりサクサク動いてるよ。問題の人が10秒かかってたページは、こっちではほぼ2秒で読み込まれる。

GCPツールは、私の経験ではChromeとSafariの両方でパフォーマンスがひどい。ログビューアみたいな画面では、時々本当に痛い思いをするよ。

今のテクノロジー業界は、3つのグループがいるんだよね。 - プロジェクトマネージャーが開発者にできるだけ早く成果を出すように常にプレッシャーをかけてる。将来的に速度が落ちるかもしれないとか、会社が顧客を失うかもしれないとか、法律を破るかもしれないなんて関係ない。 - 開発者は、逆効果になることに対して抵抗して、政治的な資本を消耗して常に燃え尽きてる。で、もし逆効果になったら、開発者がそれを許したせいで責められるんだ。 - そして、勝つためには全く気にしないことが一番だと学んだ開発者たちがいて、あまり考えずにタスクをこなしていく。これってすごく皮肉に聞こえるかもしれないけど、残念ながらこれが現実なんだ。開発者は最終結果からあまりにも孤立していて、PMが開発者を結果から隔離しているせいで責任感がまったくない。「開発者を隔離する」ことが彼らの唯一の仕事だと思われてる。追記：これは個々の貢献者や中間管理職が騒がずに解決できる文化的な問題じゃない。Cレベルが強制的に文化を変えない限り、変わらないけど、これはほとんどのCEOやCTOの利益にはならないんだよね。

企業が品質やパフォーマンスにどれだけ無関心か、全然説明しきれないよ。機能重視の企業は本当に存在するから。

大きな組織で働いたことがある者として、もっと良い質問は「なんでこれがいつも起こるの？」だと思う。大企業では、製品やコードの「所有権」が流動的になって、短期的な目標に焦点を当てるせいで曖昧になる。そういう考え方で製品に勢いをつけると、技術的負債に機能が積み重なっていく。前のチームがやったことだから、誰もそれを返済することに熱意を持たないし、経営陣が求めるのはボーナスを得るための新機能だから邪魔になる。これについて声を上げると、反対されてパフォーマンス改善プランに入れられるから、資本主義の支配者たちと合わないって理由で。

テックスタックを決めるときの主な目標は、組織がコードを書く人をどれだけ簡単に雇ったり解雇したりできるかってことだよ。組織が大きくなるほど、これが真実になる。Reactを書いてる開発者はRailsより多いし、コードを書く開発者の意見を聞くべきじゃない。テックスタックの決定をしている人たちの意見を聞くべきなんだ。他のことは二の次で、だからパフォーマンスが悪くて、測定できない開発者が出てくるんだよね。これが、開発者にこのことを聞くと奇妙な認知的複雑さの答えが返ってくる理由でもある。ほとんどの場合、開発者は雇われるために何をするべきかは分かっているけど、その枠を超えて働けないし、同時に自分たちがリリースするもののさまざまな制限についても認識している。結果が遅くて、アクセシビリティの問題があって、スケーラビリティも悪いってことは分かってるけど、彼らの主な関心は雇用を維持することなんだ。

昔は「IBMを買ったことでクビになった人はいない」って言われてたけど、今のバージョンは「Reactを使わないとクビになる」って感じだね。だから、どのサイトもReactを使ってる。結果が遅いGitHubになっても関係ない。悪い開発者は「みんな何を使ってる？」って見るけど、良い開発者は「これにとって一番良くてシンプルな（KISS）ツールは何？」って考えるんだよね。

Googleに関しては少し経験があるよ。短く言うと、彼らはそういうことはしない。Google Cloudは、たまたまFirefoxを使っているGoogleの人たちに依存してた。UIをテストするために、関連するOSやブラウザのバージョンを動かしている「マシンファーム」は持ってなかった（それはGoogleの一部のチームやプロジェクトにはあるけど、全プロジェクトが持つべきリソースではない）。ある時、私のチームが担当していたUIで、Firefoxだけに重大なパフォーマンスの後退が起きた時、チケットが提出されたけど、それは優先度が低すぎるものでした。解決策？Mozillaが二つのマイナーバージョン後にレンダリングエンジンをパッチして、その問題は解決した。修正にゼロ以上の努力はしたけど、要するに、問題を追いかけるのにブラウザのレンダリングエンジン自体をデバッグするところまで行かなきゃいけなかった。しかも、チームのためにそれをセットアップした人がいなかったし、私が初めてやることだったから、あまり進まなかった。Googleの社内セキュリティが関連コンポーネントのインストールを妨げたし、そもそもFirefoxをソースからビルドする方法を理解しなきゃいけなかった。私の個人用マシンもその作業には遅すぎた（Googleのビルドはほとんどファームベースで、コンパイルはサーバー上で行われてキャッシュされるから、ローカルマシンではない）。単に時間が足りなかった。Mozillaが問題を修正する前に、私は間に合わなかった。そして、確かに、私が問題を追いかけたからといって昇進に繋がるとは思わない（特に「他社が修正するまで待つ」という解決策は会社にとって0エンジニア時間のコストだったから）。GitHubやMicrosoftのことは分からないけど、Googleは名目上、Safari、Edge、Chrome、Firefoxの最新のN（N=2だと思う）バージョンをサポートしてるけど、「サポートする」というのは、実際には「FirefoxがUIを壊す変更を押し込んだら…まあ、他に使えるブラウザが3つあるからね」ってことだよね。もちろん、Chromeのパフォーマンスの問題は、社内の開発者体験に干渉するから優先度が高くなるんだ。

答えは「en **** ification」だよね。https://news.ycombinator.com/item?id=41277484

最近、Chromeでも問題が出てきてるよ。どのブラウザもダメになってきてる。PRが大きくないのにね。

チューリング完全性が嘘っぽく感じるのはどうして？計画的陳腐化が一因だし、抽象化が進んで多くの人がソフトウェアを作りやすくなった（その分、計算資源をかなり使うけど）。ムーアの法則がその抽象化レイヤーを支えているからね。もしすべてのソフトウェアがCで書かれなきゃいけなかったら、世界は全然違ってたと思う。抽象化が進みすぎた感はあるけど、今はそういう状況だから戻ることはないだろうね。チューリング完全性は、これらの話の中ではほとんど無関係な概念だと思うし、むしろ完全性が高いメモリや計算リソースの要求を生んでるんじゃないかな。

2011年のMac Miniで、AppleがmacOS 10.13以降のアップグレードを許可しなくなった。Appleがこの点で攻撃的だと感じる人もいるけど、それは8年前のブラウザのバージョンだよ。家の鍵を全部外して、ドアや窓を開けっぱなしにして、招かれざる客が来ないことを期待してるようなもんだ。

チューリング完全性はパフォーマンスについて何も言ってないよ。仮に、今のコンピュータで新しいコンピュータをエミュレートすることはできるかもしれないけど。

ChromeかFirefoxをインストールできないの？

https://front.com は、ちゃんと作られたReactアプリの例だよ。

嫌われてるのは一般的にSPA全体だけど、よくできたReactやAngularのアプリが素晴らしいUXを持っている例もあるよね。Clockifyがその一つ。問題のあるアプリがサーバーでレンダリングされていたとしても、UXが大幅に良くなるとは思わない。これらの問題は、開発者が品質を無視して新機能を急いでリリースするようにプレッシャーをかけられることが原因だから。

React開発者を嫌ってるわけじゃないよ。消費者向けソフトウェアを作って、最高のハードウェアやネットワークでテストしてる開発者が嫌いなんだ。大半のユーザーが8年以上前の消費者向けハードウェアで、スパイシーな3G回線を使ってるってことを無視してるから。

ここでも誤解されてるね。むしろ、WebKitの変更から見ると、問題はDOMの変更ロジックやCSSとの詳細な相互作用にあるみたいで、JavaScriptじゃないと思う。JavaScriptが問題を引き起こすこともあるけど、それはボタンに高コストの操作が付いてるのをクリックできるマウスを責めるようなもんだよ。ほとんどJavaScriptを使わずに、フレックスボックスでテーブルを作っただけで、Firefoxではめちゃくちゃ遅いページを作ったことがある（Mozillaがレンダリングエンジンを更新するまで）。ブラウザが複雑な標準に従って動作する中で、詰まったり遅くなったりする場所はたくさんあるよ。

Reactは悪いアイデアじゃなかった。SPAは悪いアイデアになりがちだけど、ReactはSPAを簡単に書けるツールに過ぎない。

よくできたシングルのReactアプリ じゃあ、Slackはどう？ディスコード？SoundCloud？Trello？Bandcamp？Spotify？続けていくと、実際には何百、何千ものよくできたReactアプリがあるよ。

そうだね、SPA（シングルページアプリ）は本来すごくニッチな概念なのに、間違った理由でいろんなものに使われすぎてる気がする。Reactに関しては、フロントエンドがめっちゃ重要なサイトは、一般的なフレームワークから離れて、カスタムなものを作って最適化する傾向があるよね。NotionとかGoogle Sheets、Figmaみたいに、ウェブインターフェースが全てで、早い段階から業界で一般的に使われてるフロントエンドスタックをバイパスしちゃってる。

TredictはReactで書かれたウェブアプリで、何年も使ってるけど、速くて安定してて便利だよ。問題はReactじゃなくて、KPIや非現実的なタイムラインなんだよね。結局、いつも同じことだし、Reactのせいじゃないよ。

Reactは初めて使った時、特にJSXの経験がないと、魔法みたいに感じるよね。でも、プロップドリルをしなきゃいけなくなって、すべてを後悔することになる。主な問題は、ビュー・モデル層をなくそうとするところで、データを取得してコンポーネント内で直接レンダリングできるようにしてるけど、それが複数のコンポーネントを高い視点から管理するのを文字通り不可能にしちゃうんだよね。一つのビュー・モデルの代わりに、同じ結果を得るために50個のReact風ユーティリティを使う羽目になる。