created 2023-12-17 updated 2023-12-17 read 3 min

React / jQuery / JavaScript

https://laiso.hatenablog.com/entry/2023/12/14/184602
論争のもととなったサイトが実際にはjQueryをヘビーユーズしていたわけではないことを前提とする。

Cubbit (@cubbit2) on X確かに仮想DOMの説明を間違ってる人は多いですわね 原理的に生DOM直いじりのほうが高速に決まってるのに、「jQueryは生DOM操作なので遅い、仮想DOMは早い」みたいな雑語りはわりと見かけますtwitter.com
PostThis post is from a protected account.twitter.com
音の兔(ねのうさ) (@_SoundRabbit) on X当然と言えば、当然なのですが、究極的には、JQueryとかReactとかを使うより最適化されたVanilla.jsが一番速いです。ただ、Reactの場合、仮想DOMを利用した差分更新により、Vanilla.jsほどの手間をかけずにそこそこ速く、「Vanilla.jsに比べて、開発コストのわりに速い」とは思います。twitter.com
はなだ☆のぶかず@動画編集始めました (@nobkz) on X要は、Reactなどの仮想Domの利点をいえば「UIの機能的な集約で書きつつ」って前提があり、枝刈りしつつ高速化してるという話ということなんだよね。 Reactの場合高速化以上に、タスクスケジューラーも入れてユーザーの関心のあるインタラクションに余計な処理を入れないようになっててそのところとかを、言って欲しいなと。twitter.com

原理的に生DOM直いじりのほうが高速に決まってるのに、「jQueryは生DOM操作なので遅い、仮想DOMは早い」

こういうレベルで論じている人、残念ながら本当によくいる。聞きかじった話をそのまま広めて回っていて、自分の中で論理の筋を通したりしないタイプの人なんだろうなと思えてしまうので、その人への信用は著しく失われる。

mattn (@mattn_jp) on X将来、仮想 DOM より良い技術が出てきた時に今の仮想 DOM 扱うコードはほぼ作り変えになるだろうから、わりとキツいだろうなぁとは思う。twitter.com

良い技術が出てきた時に今の仮想 DOM 扱うコードはほぼ作り変えになるだろう

という点では他のプログラミングパラダイムでも当てはまるものが多くありそう。

https://twitter.com/uhyo_/status/1735136114846117985
https://twitter.com/mizchi/status/1735139833507701050
https://twitter.com/BoufrawFrodo2/status/1735192169147965745
https://twitter.com/uhyo_/status/1735457513460629970
https://twitter.com/mizchi/status/1735518104669843466
https://twitter.com/mizchi/status/1735525082368455106
https://twitter.com/ko1nksm/status/1735528221285011764
https://twitter.com/nobkz/status/1735518705050882059
jQuery書ける人を用意しやすい、という点では確かに優勢なんだろうが、Vanilla JavaScriptで書けないのにjQueryは書けるというレベル感の人を集めて作られたソースコードはメンテにそれなりのコストが掛かりそうだけど、本当に限界効用を達成できているのだろうか?

https://twitter.com/nobkz/status/1735149245920063814
https://twitter.com/yuta0801_/status/1735709669447045523
VDOM vs DOMという意味ではVDOMへの批判として納得できる部分もあるものの、Vanilla JavaScript (+必要なpolyfill) を差し置いてjQueryを選定する擁護としては微妙かなと感じる。

藤秋すばる (@f_subal) on XjQuery、あまり言われない特徴としてこれがあるよなーと思っている https://t.co/ZtdKyP79YDtwitter.com

jQueryは1個の要素と複数個の要素を同じように書かせる

へぇ〜

kmizu (@kmizu) on Xフロントエンド素人の私が言うのもあれなんですけど、現代のWebフロントエンド、実現したいユーザー体験に比べて覚えないといけないこと多すぎ! 開発者に見せるAPIは「これスタンドアロンのアプリのUIライブラリだと考えなくていいよな」みたいなの多いと感じます。twitter.com

実現したいユーザー体験に比べて覚えないといけないこと多すぎ

覚えないといけないことは実際にはそれほど多くないと思う。(技術的トレンドや最新技術の流れの速さに比べて、の意)

https://twitter.com/tanakahisateru/status/1735493626128687545
確かにフロントエンド界隈は語気を強くしたり冷笑的態度をとって議論を優位に進めようとする人が目立つ印象がある。(観測範囲は日本のフロントエンド界隈のみ)

田中ひさてる (@tanakahisateru) on Xフロントエンド文化には、内部実装の問題とモジュール間インターフェースの問題を分けて考える習慣があまりなく、また、黄金の金槌がどれなのかを求める傾向も強い。なぜなら、ほとんどの現場が、ワンマンカウボーイに頼るしかない進化の道筋を辿ったから。もしかしたらこういう理屈なのかもしれないなtwitter.com

ほとんどの現場が、ワンマンカウボーイに頼るしかない進化の道筋を辿った

つらい

https://twitter.com/takehora/status/1735588928391196804
https://twitter.com/uhyo_/status/1735100567989699029
屏風の中の話だけど今からjQuery選択するところはjQueryどころではないパフォーマンスの問題を抱えてそう

ニウム (@namnium_01) on XReact類はフロントエンドという魑魅魍魎に立ち向かうためのElmみたいな「人間のための」ライブラリなので、速い速くないみたいな話に持っていくのが変だと思うんですよね まるでC++とRustの関係のよう…twitter.com

魑魅魍魎に立ち向かうためのElmみたいな「人間のための」ライブラリ

本当にそう思う。jQueryに関わらず、これを使える人間が多いから、みたいなノリで選定されやすい技術については、コストを短期的な人的リソースのみではなく、人間による長期的なメンテナンスコストまで加味してから選定してほしい。まあ問題は長期的なメンテナンスコストというのは定量的に表しづらいことだ...。