Vue vs React vs Angular Part.3

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/06/12(水) 19:04:55.46ID:x67noP4p
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.2
https://mevius.5ch.net/test/read.cgi/tech/1552136553/
※前前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
2020/05/31(日) 02:36:06.59ID:e5GrMoxK
vueはリアルdomを作る前に
仮想domを作って効率よく差分するから
早いんだっけ。だからjqueryを使うとその効果が失われる。

だからvueの中に
jqueryを混ぜると仮想domの特性を
活かせないから辞めた方がいい。しかし参考書の多くは
リアルdom 構築後のソリューションが多く掲載してる。

結果、真面目に教本に
沿って学習すると多くのロスが生まれる。悪循環が
生まれて半年どころの学習時間では済まなくなる。
2020/05/31(日) 02:37:27.64ID:e5GrMoxK
>>372
文章の組み立てが下手でスマソ
2020/05/31(日) 05:04:14.93ID:JRHRMyge
>>372
> vueはリアルdomを作る前に
> 仮想domを作って効率よく差分するから
> 早いんだっけ。だからjqueryを使うとその効果が失われる。

それは論点をすり替えている。実際の所jQueryの方が速い。
なぜかと言うと仮想DOMを作って差分をだして、
結局その差分をリアルDOMに適用するわけだから、速くなるわけがない。

仮想DOMが速いというのは

1. まずページ全体のDOMを書き換えることとする。（jQueryで普通はしない）
2. ページ全体のDOMを書き方たら遅いではないか！（自分にツッコミかよ）
3. ページ全体のDOMを書き換えるけどそれは実は仮想DOMで速いんだ
4. そうやって差分で必要なとこだけDOMを書き換えるから速いんだ。

ページ全体のDOMを書き換えるなどという愚かな発想をし
その愚かな発想よりも速いと言っているだけ。つまりマッチポンプ

jQueryを使って普通に作るなら、最初から必要なところだけ
DOMを書き換えるので最初から速い。差分計算処理も不要。

このページ全体を書き換えるという発想は、もともとデスクトップアプリケーションや
ゲームの発想。デスクトップアプリケーションやゲームでも全体を書き換えると
遅くなるから必要なところだけ書き換えるというのはよく行われてきた
それをウェブに持ち込んだからこんな物ができてしまった。

もともとウェブでは必要なところしか書き換えないし、デザインはCSSで
制御するのが普通だからDOM操作も最小限になる。

それをやらずにDOM操作でデザインを実装しようとしたから
遅くなる方法を打ち消す仮想DOMなんてのが必要になった
2020/05/31(日) 05:26:17.06ID:OM55fPsS
そもそも速度のためにこれらのフレームワークができたわけじゃないし…
規模が大きくなってジェイ・クエリーとかで直接DOM操作するのが管理しきれなくなったからでしょ
2020/05/31(日) 07:42:19.68ID:TFlNfav4
未だにＣＯＢＯＬ最高って言ってるおっさんみたいだな
2020/05/31(日) 09:42:21.10ID:o76pWhWL
jqueryも仮想DOMも、ページ全体の構築後は一部だけ書き換え
どこから全体が出てくるんだ？
全体書き換えってことはページ遷移ってことだよな？
それならReactやvueのほうが圧倒的に速いんだけど？
2020/05/31(日) 10:10:06.97ID:FFfnQQzy
速度の為ってより構造化の為に使うもんなんやない？
2020/05/31(日) 11:40:21.71ID:PGtiFJnl
>>374
結局、vueにjQueryを混ぜると遅くなるの？
2020/05/31(日) 11:43:49.13ID:JRHRMyge
>>379
ならない

下手なコードを書けば遅くなるのは
プログラマの問題でしかない
2020/05/31(日) 11:47:50.50ID:JRHRMyge
>>375
そういうこと。なのに仮想DOMはリアルDOM "を全画面書き換える" より速いが
仮想DOMはリアルDOMより速いとかよく勘違いされてる

仮想DOMだけ書き換えても、リアルDOMには反映されない
仮想DOMからリアルDOMを書き換えるのと
jQueryでリアルDOMを書き換えるのは同じ
2020/05/31(日) 11:55:31.24ID:o76pWhWL
>>381
お前相当バカだろ
そこにSPAの概念がまったく入ってねーじゃねえか
実際の通信や運用を考えてからモノを言え
jqueryジジイは脳みそ停止してんだろ

あと同じなわけないじゃん
無知すぎる
2020/05/31(日) 11:58:01.25ID:JRHRMyge
>>377
> jqueryも仮想DOMも、ページ全体の構築後は一部だけ書き換え
> どこから全体が出てくるんだ？

ブラウザが持ってるリアルDOMとは別に
JavaScriptのメモリ内に同じ情報を仮想DOMとして持っている

そして仮想DOM伝導師いわく
「仮想DOMの情報をリアルDOMに完全に同期させるんです。
遅いと思った？思ったでしょう？でも差分をとってそこだけ反映させるから
遅くならないんです。仮想DOMの書き換えはリアルDOMより速いんです」

と言葉巧みに、仮想DOMからリアルDOMへ反映のコストを隠しつつ
仮想DOMの書き換えのみが速いと誤解させるようなことを言っている。

> 全体書き換えってことはページ遷移ってことだよな？
> それならReactやvueのほうが圧倒的に速いんだけど？

ページ遷移するな。History APIを使ってページ遷移してるように見せかけて
jQueryで一部分だけ書き換えればReactやvueよりも速い。
Railsに標準で組み込まれてるturbolinks(+jQuery)がこの仕組み
2020/05/31(日) 11:59:50.32ID:JRHRMyge
>>382
> そこにSPAの概念がまったく入ってねーじゃねえか

お前のレスを見る前に>>383を書いた。
SPAの概念はReactやvueの専売特許ではない
昔から Rails + turbolinks+ jQuery で同じことをしている
お前が無知なだけだ。過大広告に騙されやがってｗ
2020/05/31(日) 12:41:37.02ID:k/fS2Kff
Ruby 君かな
2020/05/31(日) 12:43:35.72ID:JRHRMyge
>>385
ちげーよ
2020/05/31(日) 12:47:08.02ID:o76pWhWL
>>384
お前相当なにもわかってないじゃん
コイツに説明するだけ無駄すぎた
jqueryクソジジイは一生jquery使ってろ
ただただ気持ちわりい
2020/05/31(日) 12:50:05.93ID:JRHRMyge
なぜかJavaScriptの話ではなく「俺」の話にすり替わってるｗ
2020/05/31(日) 12:50:33.12ID:pH0zoOzG
turbolinksがSPAって初めて聞いた
2020/05/31(日) 12:56:44.85ID:FFfnQQzy
>>379
大体速度を気にしなきゃいけない様なシビアな案件なんて殆どないしな

大レコード数のテーブルを生成するのだってその処理部分に関してはほぼ混ぜ様がないだろうし
2020/05/31(日) 12:59:27.17ID:FFfnQQzy
単純に言って混ぜるとソースが汚くなるのと
タイミング問題が起こった時に分け分からんくなるってくらいだろ
2020/05/31(日) 13:05:49.62ID:5WJ7AaAn
判った。jqueryは
あんま良くないけど、vue.jsと一緒に
使うと爆速になるってことね。
2020/05/31(日) 13:11:27.49ID:JRHRMyge
>>389
あれ使い方間違ってる人多いからね。
JavaScriptが発動しないといかって無効にする人

turbolinksはjQueryとの相性が良くて
最初にサイトを表示したときに全てのJavaScriptコードを読み込んで
あとはすべての要素が動的に増減する（無くなることもある）という前提で使うもの
jQueryはすべての要素を0以上の要素郡として操作するので非常に相性がいい
2020/05/31(日) 14:22:35.36ID:lymCwRQ/
あれだ、「コンパイラの最適化がどんなに賢くなってもアセンブラには敵わない」とかいうのと同じ。
2020/05/31(日) 14:31:17.31ID:JRHRMyge
>>394
それはコンピュータの最適化 vs 人間の最適化 という話なので
まったく関係ない話ですね
2020/05/31(日) 15:01:48.16ID:PGtiFJnl
無知ですまんのだが、リアルDOMでも仮想DOMでも最終的にはひとつのテキストファイル(html)になってブラウザが読み込んでレンダリングするってのは変わらないわけだよね。
リアルDOMと仮想DOMではその最終処理に向かう途中のどこに違いが生じるの？
2020/05/31(日) 15:11:00.06ID:JRHRMyge
>>396
その通り。テキストファイルになるわけじゃないけど
仮想DOMは速いとかいうビジネストークを無視すれば話は簡単

仮想DOMはJavaScriptのオブジェクトでしかないので
ブラウザを使わなくてもユニットテストがしやすいというのがメリット

リアルDOMの状態は気にせずJavaScriptオブジェクトをテストするだけ
そしてユニットテストがブラウザに依存しなくなる
（ただしJavaScriptのオブジェクトからリアルDOMへの変換は
フレームワークがしっかりとテストしているはずという前提を受け入れる必要がある）

ユニットテストの場合に限ればリアルDOMを使わない仮想DOMの方が速いが
実際の製品では仮想DOMを使うので速くはならない

速度うんぬんではなく、テストをしやすくするためにリアルDOMから仮想DOMへデータを分離している
2020/05/31(日) 15:14:27.24ID:JRHRMyge
大規模なものを作るときは、小さいパーツに分けないとテストが困難になる。
大規模なものを大規模なままテストするのは難しい

その結果フレームワークでは、小さいパーツがたくさんできる。
それは素晴らしいことだと思うかもしれないが、
どんなものでも小さいパーツを作ればいいって話ではない
小さいパーツを作れば作るほどパーツを組み合わせるための処理、
インターフェースが増えてコードが膨れ上がる

ウェブサイトのような小さいシステムでは
逆にコストが掛かることになるんだよ。
そういう見極めができない人が、脱jQueryなどと叫んで
小さいシステムなのにフレームワークを採用して逆にコストを増大させている
2020/05/31(日) 15:17:00.98ID:JRHRMyge
作るものによって使う技術を変えるべきなのに
それができないエセ技術者が多い
新しい技術を知ったら何でもそれでやろうとする。
2020/05/31(日) 15:34:07.62ID:lymCwRQ/
>>395
ああすまん、あんたにレスしたつもりはなかった。
>>394はリアルDOMの操作を直接コーディングするのと仮想DOMの差分からDOM操作を生成するのとの
速度比較の話ね。
2020/05/31(日) 15:34:50.72ID:PGtiFJnl
>>397
ありがとうございます、すごくわかりやすくて腑に落ちました。
2020/05/31(日) 16:02:47.28ID:o76pWhWL
こいつは昔からいるゴミカスjqueryジジイでどこでも仮想DOMに噛み付く気持ちわりい粘着野郎
2020/05/31(日) 16:12:18.94ID:JRHRMyge
JavaScriptの話ができないやつは「俺」の話をしてしまうｗ
2020/05/31(日) 16:23:27.31ID:FFfnQQzy
>>396
tar zxvfで解凍するかtar zxfで解凍するかの違いとか想像してみるのはどうだい？
2020/05/31(日) 16:26:37.16ID:FFfnQQzy
>>395
よっぽどの職人とかじゃない限り凡人がコンパイラの最適化を超えるとかいい加減無理だろ
2020/05/31(日) 16:50:56.70ID:PGtiFJnl
>>404
「v」のある無しで展開時に詳細を出力するかどうかの違いということですよね？
これをjavascriptの話とした場合、展開時の詳細にあたるものは具体的にはなんなのでしょうか？
2020/05/31(日) 17:05:12.54ID:iwS1y3tF
初心者向けにはこの記事がわかりやすいと思う
↓
https://www.google.com/amp/s/employment.en-japan.com/engineerhub/entry/2020/02/18/103000%3famp=1

簡単に言えば
・DOMの操作はきちんとやらないとレンダリングの負荷が大きくなる
・仮想DOMはDOMの操作を上手いことやってくれるので速い
・とは言え仮想DOMを使うこと自体がオーバーヘッドなのでDOMの直接操作を無駄なく行った場合よりは遅い
2020/05/31(日) 17:51:15.80ID:x+1l8ufV
https://i.imgur.com/IFVxEh2.jpg
2020/05/31(日) 18:21:47.85ID:87/vy3Ai
コンパイルした時点で仮想DOMなんてものは無くなるので、理論的には仮想DOMを使うことによるオーバーヘッドも消せるということか。
そして>>408を見る限りはコンパイラが優秀なので実際にオーバーヘッドを消せているということかな。
まあこの実験のデータセットがリアクトコンパイラにとって有利なものだったという可能性もあるのでもう少しデータの詳細が知りたいが。
2020/05/31(日) 19:07:31.06ID:5WJ7AaAn
Domが読み込まれる前の
createdの段階で実行するから
早くなるんだろう。この段階はelもrefも

起きてないフェーズなんだから
jquery なんて使ったらモトメこうもない

台無しだろう。
2020/05/31(日) 19:12:25.04ID:5WJ7AaAn
>>410
モトメじゃなくて元もwww
2020/05/31(日) 22:15:08.01ID:JRHRMyge
>>407
> ・DOMの操作はきちんとやらないとレンダリングの負荷が大きくなる

そのとおりだが「きちんとやってないコード」っていうのがどういうものかって話なんだよな

ぶっちゃけ、どんなバカならそんなコードを書くんだよ？って
いいたくなるような話なんだよねこれ

現実にやりそうな「きちんとやってないコード」の例を
出せる人がいるなら見てみたい
そしたら（jQueryは）普通どうやるのかを俺は言えると思うね
2020/05/31(日) 22:15:41.30ID:JRHRMyge
>>409
> コンパイルした時点で仮想DOMなんてものは無くなるので、
誰がそんな話してるんだ？
無くなるわけないぞ
2020/05/31(日) 22:20:45.56ID:JRHRMyge
>>410
> Domが読み込まれる前の
> createdの段階で実行するから

もうJavaScriptの常識を忘れたのか？
DOMが読み込まれる前にJavaScriptを実行すると遅くなるだろ

jQueryの特徴の一つはDOMContentLoadedで処理をするというところ
レンダリングをブロックせずにDOMが読み込まれた直後に実行されるから速い

さらに最適化をするならば、</body>の直前でJavaScriptを読み込む
JavaScriptの実行はなるべく後で行うことで
すばやくレンダリングさせることができる。

というのは常識的な知識だったはずなんだがなぁ
2020/05/31(日) 22:22:33.40ID:JRHRMyge
結局仮想DOMのアイデアっていうのは

1. すげー遅くなるアイデアを最初に言って
2. それを改善するアイデアで相殺することで
3. 遅くならないということを、（遅いアイデアより）速くなる

と言ってるだけ
2020/05/31(日) 22:26:16.77ID:DRV8bcqm
>>415
お前が作ったわけでもねーしお前がweb準拠を策定しているわけでもねえのに何偉そうに吠えてんだよゴミカス
2020/05/31(日) 22:35:34.04ID:JRHRMyge
>>416
お前が世界を作った訳でもねーのに何偉そうに吠えてんだよゴミカス
2020/05/31(日) 22:37:06.99ID:lLPzLHf4
常識かもしれんが
バッドノウハウの類いに聞こえるな
2020/05/31(日) 23:01:44.07ID:DRV8bcqm
ゴミカスはDOM構築後にjqueryを読み込むから速いとかゴミ説明して勝ち誇ってるが
それは読み込んだだけでjqueryを何も実行しない（＝jqueryを使っていない）だけだろ
これで速いとかアホかこいつ
2020/05/31(日) 23:14:07.26ID:lymCwRQ/
>>415
これは、DOMの直接操作なら常に最適な操作ができるという前提の発想だな。
最適操作が自明な範囲しか念頭に無いんだろうな。
2020/05/31(日) 23:16:48.38ID:JRHRMyge
>>418
うん。だから俺は<head>で読み込むようにしてるよ
ファイルサイズは80KB、gzip圧縮時でわずか30KBしかない

>>419
イミフｗ
HTMLはそのまま表示するのが一番早い。デザインはもちろんCSS。
ページの初回表示時はJavaScriptを使わず単にページを表示するだだけ
静的なHTML+CSSが早いのは誰にも否定できない

そしてjQueryはそこにユーザーのアクションに対して動きをつける。
つまりユーザーが操作するまではjQueryは何もしない。だから軽い。
JavaScriptを実行しなければページが表示されないフレームワークでは太刀打ちできない
2020/05/31(日) 23:21:06.36ID:JRHRMyge
>>420
> これは、DOMの直接操作なら常に最適な操作ができるという前提の発想だな。

重要なのはそこ。最初から最適な操作ができるという前提の話をしている。

最適な操作でなければ遅くなる。理屈上はそのとおり。
では「最適な操作ができていない」というのはどういうときか？

そんなコードを書くやつがいるのか？という話をしている


仮想DOMというのは
1. 最適な操作にならない、奇抜なアイデアを持ち出す
2. 奇抜なアイデアを改善するアイデアを出す
3. （最適じゃない奇抜なアイデアを）改善したと言っている
2020/05/31(日) 23:35:08.81ID:pA4LVr9r
>>421
イミフじゃねえよ
jqueryが何もしないなら何もしねえだろが
それなら読み込みすらするなアホが
バカかコイツ
2020/05/31(日) 23:59:38.84ID:JRHRMyge
ああ、DOM構築後に何もせず、ユーザーが操作して初めて
JavaScriptの処理が走るって意味がわからんのかｗ
2020/06/01(月) 00:08:08.77ID:0Y4JhCWi
てめえが散々書いてることを自分でわかってねえだろがゴミ
jquery実行した途端におっせーじゃん
2020/06/01(月) 00:08:56.41ID:ZvU3LrYi
>>424
ユーザーが操作する前にハンドラーをアタッチするよね
現時点で存在しない動的エレメントの場合は監視もするね

まあそんなの揚げ足取りかな
2020/06/01(月) 00:18:03.32ID:Y6C/Hhni
>>425
じゃあJavaScriptオフにすれば？
なんでjQuery実行した遅くなるんだかｗ

> ユーザーが操作する前にハンドラーをアタッチするよね
> 現時点で存在しない動的エレメントの場合は監視もするね

存在しない動的エレメント（例 A要素）の監視をするならこれだけ
$(document).on('click', 'a', function() { .. })

内部的にはdocument要素に一つイベントハンドラをアタッチするだけ
さらに直接document要素にアタッチしているのではなくjQuery内部で
複数のイベントハンドラをまとめてるので、複数実行しても
DOM要素への操作は一回しか行われない。
2020/06/01(月) 01:04:02.53ID:ZvU3LrYi
jQueryは基本CSSセレクタで指定した要素に対して処理を指示するものだから、コードの簡潔化を図ろうとして極めて行くとCSSに詳しくなる
CSSのセレクタはhtmlの構造で決まるものだから、きれいなhtmlを意識する様になる
結果的にhtml、CSS、JavaScriptの3つの基本に詳しくなる

WebAssemblyは別にしてReactとかのWebフレームワークも最終的にはその3つが生成されるんだけど、見えづらいせいか少し基本を軽んじるきらいはあるんじゃないかな

ただ自分はVue使いなんだけど当然ながら素晴らしい
特にVueテンプレートファイルのhtml、CSS、JavaScriptを1つのファイルにまとめられるのは素敵
特にCSSのスコープ定義で局所化したりできるのは痺れる
WebPackの功績が大きいのかも知れないけど
Wpfのデータバインドを意識したモデル、ビュー構造も最高に好き
2020/06/01(月) 01:13:40.91ID:RpkIRyj6
WPFだと…？
2020/06/01(月) 01:21:29.25ID:Y6C/Hhni
まああれだ。雑誌編集者に対して
ボタンやらInputBoxやらアプリのUIについて
語っても殆ど意味がないのと一緒

ウェブの多くはウェブサイトで雑誌編集者が担当するような仕事
jQueryはそこに足りない動きや機能をちょっと追加するだけ
ReactやVueはアプリUIを作るためのもの
目的が全然違っている
2020/06/01(月) 02:00:33.56ID:8MAPJOWk
とりあえずこのスレ民のレベルはわかった
2020/06/01(月) 02:02:35.23ID:0Y4JhCWi
そもそもこのスレに来てわざわざjqueryスゲーを長文で連投しやがるガイジは今すぐ消えろ
構ってほしいんだろうがきしょいわ
テメーの好きな巣で一生吠えてろ
2020/06/01(月) 02:08:26.36ID:Y6C/Hhni
嫌なら見るな
2020/06/01(月) 02:12:34.25ID:0Y4JhCWi
お前が消えろボケが
スレがちがうんだよ
毎回毎回気持ち悪い
リアルでも粘着質なんだろ
早くあっち行け
2020/06/01(月) 02:41:08.49ID:Y6C/Hhni
あっちいけって言われていくわけ無いじゃんｗ
2020/06/01(月) 08:05:37.75ID:M7ivFsPk
>>422
例えば A B C という内容のリストを得たい場合、その前の状態が A B ならCを追加するのが
最適だけど A B C D だったらDを削除することになる。
生のDOM操作を最適化するというのはそういった場合分けを全部自分でやるということだからねぇ。
前の状態にかかわらず全部消してから A B C を入れなおす方が簡単だからそうする人もいるだろう。
そこはDOM操作を最適化することのメリットとデメリットのトレードオフだしな。
2020/06/01(月) 09:32:10.16ID:Y6C/Hhni
>>436
もう少し実際にありそうな例で具体的に
言ってくれないと簡単に反論できるかなぁｗ

例えば A B C という内容のリストを得たい場合
その前（現在の状態）がA Bなら以下の通りで

<ul id="list" class="a b">
<li class="a">A</li>
<li class="b">B</li>
<li class="c">C</li>
<li class="d">D</li>
</ul>

#list > li { display: none; }
#list.a > li.a { display: block; }
#list.b > li.b { display: block; }
#list.c > li.c { display: block; }
#list.d > li.d { display: block; }

$('#list').attr('class', 'a b c'); を実行すれば望んだ状態が得られる

クラスを書き換えるだけでDOMツリーは変更しないから速いことが想定できるし
CSSを変えてるだけだからブラウザが必要最小限のレンダリングを行うだろうと期待できる

DOM操作は必要最小限にしよう。これはたった一行で処理も速い。
2020/06/01(月) 11:54:00.62ID:LV1YXxu/
もうエンジニアらしくパフォーマンス計測して説明してくれよw
2020/06/01(月) 12:20:47.92ID:ELGuH/q/
フレームワーク使ってるやつが、コード書かないんだからどうしようもない
jQueryのコードはいっぱい書いてきた
しかし同等のコードをフレームワークで書き直すやつはいない
2020/06/01(月) 12:37:47.62ID:0Y4JhCWi
さすがにWebサイトごときにReact使う気にはなれんからゴミjqueryでもいいけどさぁ
まさかこのゴミ推奨委員の人はWebアプリにもjqueryでの構築を勧めんの？
2020/06/01(月) 12:52:51.61ID:SacmN/TG
>>440
逆だろ。何でもかんでも「脱jQuery」とか言い出すアホに
俺は警告してるだけ。警告っていうかお前らが「脱jQuery」とかいい始めた5年で
jQueryは更に10%以上も使われてるようになったという事実を言ってるだけだが
一方フレームワークの利用者はいまだ1%未満
2020/06/01(月) 12:58:57.44ID:0Y4JhCWi
>>441
アプリ自体がゴミ量産Webサイトより圧倒的に少ないんだから当たり前じゃん
でお前はアプリ開発もjqueryでやるの？
2020/06/01(月) 13:57:23.29ID:LV1YXxu/
もしかしてjQueryとフレームワーク両方でパフォーマンス計測するということすらできない人々が議論してたのか？
そりゃ決着つかないわ。
2020/06/01(月) 14:01:06.77ID:LV1YXxu/
みんなエンジニアなんだろ？>>408みたいな測定結果を持ってきて相手を黙らせればいいじゃん。
このデータは詳細不明なので役に立たないが。
2020/06/01(月) 17:11:11.56ID:SacmN/TG
>>442
だーかーらー、「ウェブアプリではjQueryよりもフレームワークを使おう」って
言ってれば何の問題もなかったの
「jQueryは古いから脱jQueryしようキャンペーン」がクソだっていってんの

圧倒的に多いウェブサイトで使うのはjQueryが一番適してる
今からでも遅くないんだから、俺はそう主張して回ってんのｗ
2020/06/01(月) 17:21:13.58ID:SacmN/TG
>>408
なんでいちいちサイトを隠すかね？そんなのすぐ見つけられるというのに

Comparing React.js performance vs. native DOM
https://objectpartners.com/2015/11/19/comparing-react-js-performance-vs-native-dom/

Reactを利用したいくつかの個人的な実験に取り組んでいる間に、意外にもパフォーマンスのボトルネックに遭遇しました。
さて、これは私にとってパフォーマンスの恩恵のようには感じられませんでした。インターウェブをサーフィンした後、
Reactに関する同様のパフォーマンスの懸念の事例証拠を見つけたようです。それを念頭に置いて、
私はJSを介してネイティブDOM操作で実装した代替アプローチに取り組み始めましたが、
Reactバージョンよりもパフォーマンスが優れていることがわかりましたが、実際には1対1の比較ではありませんでした。

実行時間

2000要素では、DOMバージョンはデスクトップの時間に匹敵しますが、12秒のリードで、NexusのReactより先を進みます。
4000行までに、Reactバージョンは2.25分でレンダリングするのに苦労しており、DOMバージョンの2倍以上遅いです。
なぜそうなのかをお話ししたいと思いますが、Reactバージョンでは2倍の作業を行う必要があると推測できます。
仮想DOMと実際のDOMの両方を操作してコンポーネントをレンダリングしているためです。

メモリ消費

したがって、モバイル環境でReactを検討する場合、メモリ消費は最適化するか、少なくとも認識しておく必要があるようです。
これは、環境がディスクなどに対して何らかの仮想メモリページのスワッピングを開始する必要がある場合に、
アプリ全体でReactアプリに見られる速度低下の一部である可能性があります。

概要

React.jsは、ブラウザーアプリケーションのビューレイヤーで状態を管理するための優れたアプローチであることは間違いありません。
しかし、私自身の限られた経験から、レンダリングに費やされた時間から消費されたメモリの量をそのまま比較するだけでなく、
Reactのようなライブラリから得られる便利さに対して支払うべき明確な代償があります。
純粋なパフォーマンスの観点からは、特定の問題に対する純粋なJS DOMアプローチを評価することにはいくつかのメリットがあるように思われます。
2020/06/01(月) 17:28:38.28ID:GTAzkg2N
こんなくだらない論争してないでRecoilの展望について語れよ
2020/06/01(月) 17:31:25.34ID:RpkIRyj6
5年前の変な日本語ｗｗｗ
2020/06/01(月) 17:33:30.63ID:SacmN/TG
>>448
Google先生に文句言うな！
2020/06/01(月) 17:35:01.23ID:SacmN/TG
>>447
あと3つぐらい似たようなものが登場するんじゃね？
んで、1年後ぐらいにRecoilはもうオワコンとか言われる
普及する前にオワコンｗｗｗ
2020/06/01(月) 18:42:27.73ID:0Y4JhCWi
Webサイトしか作れないコーダーって悲しいよな
わざわざWebアプリ用のフレームワークに噛み付いて勝ち誇って何がしたいんだか

シェア74％？
へーすごいね
一生使ってろ
2020/06/01(月) 18:43:29.19ID:1M1uJIUJ
このように技術の話を、人の話にすり替えるのが流行ってるのか？
2020/06/01(月) 18:46:20.43ID:1M1uJIUJ
jQueryは〜、 Vueは〜

↓

お前はコーダーだ、お前はjQuery使ってろ、お前は！お前は！


こんな感じｗ
2020/06/01(月) 19:00:51.83ID:YLFWVkAE
だって人の話だから
jQueryじゃなくてスレタイも読めないキチガイに怒ってるだけ
2020/06/01(月) 20:39:10.04ID:wdhscBPR
>>451
そんな奴このスレにいないよ。
みんな大学で情報理論についてみっちり学び、研究室ではpythonでMLの研究に携わって、その傍らアルバイトでwebサービスの開発をして小遣い稼ぎ、その後メーカーに就職してC言語で組み込みに励んだあとにIT企業に転職してマネージャーになってコーディング卒業してるから。
webサイト作成は趣味兼副業のアフィblogのためにやってるだけだろう。
2020/06/01(月) 20:48:13.50ID:l4HIPpsU
実際ReactはWebアセンブリで消える可能性ある
jQueryは素人とかWebサイト用に残る
俺はjQueryよりReactの方が好きだけど
2020/06/01(月) 20:52:59.65ID:M7ivFsPk
>>437
隠してるだけじゃんｗ
データが刻々変化するWebアプリみたいなものは全然念頭に無いんだろうな。
2020/06/01(月) 21:31:57.98ID:0Y4JhCWi
>>455
底辺組み込みをそこまで自慢しなくてもw
2020/06/01(月) 21:33:22.10ID:0Y4JhCWi
>>456
そう
それは俺が前からここで言ってる
いまWebComponentを策定中だからあくまでもそれまでの繋ぎでしかない
2020/06/01(月) 21:33:28.89ID:xlNGyQiU
>>457
だから具体例を言えと言ってる
データが刻々変化する？だからなんだ？
CSSでグラフでも作ってwidthの%で表現すればいいんか？

って簡単に俺に反論されるやろ？
だからできないような具体的な例を考えてこいと言ってる
2020/06/01(月) 21:35:46.98ID:xlNGyQiU
>>459
WebComponent登場でVue、React、Angularの設計が大きく変わって
また覚え直しになるのが目に見えてるんだよなｗ

WebComponentだと配布の容易性からフレームワークを
使わないで実装するのが流行るだろう

jQueryはそのコンポーネント同士を繋ぐ役目をするものだから
WebComponentの時代でも生き残る
2020/06/01(月) 21:42:45.19ID:M7ivFsPk
>>460
具体例って、

<ul>
<li>A</li>
<li>B</li>
<li>C</li>
</ul>

を

<ul>
<li>A</li>
<li>B</li>
<li>C</li>
<li>D</li>
</ul>

にするとかそういうレベルで言わないと理解できないんだろうか。
2020/06/01(月) 21:48:41.87ID:xlNGyQiU
>>462
そうそう。そんなんでいい。それをVueとか好きなフレームワークで書いてみ
2020/06/01(月) 21:49:22.79ID:xlNGyQiU
っていうか、最初の例じゃねーかｗ
それ要素を非表示にするだけでいいだろ
なんでそんな事しねぇといけなんだ。
そこからちゃんと説明しろって
2020/06/01(月) 22:14:07.76ID:M7ivFsPk
スタイルで非表示にすればいいじゃんてのは結局直接DOM操作するのが大変だからだよなぁ。
UNIXのtopコマンドみたいなのはただ隠すだけじゃ無理があるし。
2020/06/01(月) 22:23:29.85ID:lf51+gry
>>406
寧ろコンソールへの表示の有無で解凍速度変わるって知らんの？
画面表示って結構オーバーヘッドなんやけど
2020/06/01(月) 22:39:38.12ID:80Xi+K8a
場末のスナック＝コボル＝jQuery
2020/06/01(月) 22:41:03.24ID:0Y4JhCWi
>>461
覚え直しなわけねーじゃん
jqueryごときで脳みそ固定されてっからお前には苦痛だろうが新しく出たって1日で覚えられるわい
2020/06/01(月) 23:11:58.91ID:betc8EO5
jquery先生マジでwebアプリ知らんのなｗ
2020/06/01(月) 23:15:49.58ID:xZL8Ap71
>>466
いや、だからjavascriptでそれにあたるものはなんなんでしょうか？という質問なんですけど…
2020/06/01(月) 23:23:52.92ID:xZL8Ap71
正直なところリアルDOMと仮想DOMの関係をtarコマンドに例えられたのが理解できず混乱してしまったんですが、この例えって適切なんでしょうか？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況