Vue vs React vs Angular Part.3

**デフォルトの名無しさん** · 2019/06/12(水) 19:04:55.46

実際どうなん？
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/04/02(木) 21:48:52.20

>>317では依頼する側の口ぶりだったが

**デフォルトの名無しさん** · 2020/04/03(金) 00:25:10.75

>>319
じゃあ自分の職場でほざいてりゃいいじゃん。
おまえのまわりではマジで無能が仕事すること自体迷惑なんだろうし。
んでもってその分をお前がやりゃすむ話だろ。

**デフォルトの名無しさん** · 2020/04/03(金) 00:31:29.04

職場の状況も人間関係も何もわからず話も噛み合わないのにケンカすんなや

**デフォルトの名無しさん** · 2020/04/03(金) 23:50:22.99

大体もうなんか作るんなら一人でやるのが一番気楽なんだよな
なんで分業するのが正しいみたいな風潮になってんのかねぇ…

**デフォルトの名無しさん** · 2020/04/04(土) 01:54:10.26

>>323
一人で作れる規模なら一人で作ればいいと思う。markdownエディタであるinkdropは作者は1人で開発されてるし。
ただたくさんのお金を産もうとするとアプリケーションのデザインやパフォーマンスなど様々な要素が重要になるのでチーム開発せざるを得なくなる

**デフォルトの名無しさん** · 2020/04/04(土) 23:28:18.77

>>324
まぁそうなんだろうけど
足手纏い入れて不具合原因探しする手間考えたら多分一人でやるよりも時間掛かるんだよね体感的に

**デフォルトの名無しさん** · 2020/04/08(水) 01:25:50.15

VueのUIフレームワーク、TypeScriptと一緒に使うなら何がおすすめ？
Quasarっていうのが気になって試してみたけど、TSXをうまくトランスパイルできる設定方法がわからず。。

**デフォルトの名無しさん** · 2020/04/09(木) 05:03:32.21

https://github.com/dotnet/aspnetcore/issues/15997
↑
Blazorは、デスクトップのC#の200倍遅いらしい。
サイズも大きすぎるようで、
機能の限定されたプログラムで最小で2MB、標準では16MBくらいが最小なので
はないか。

**デフォルトの名無しさん** · 2020/04/09(木) 05:06:50.72

同じくWasmを使っている Uno Platformも JS よりも遅いらしい。
JSを使いたくないC#プログラマには便利ではあろうが、現実的に
使えるアプリを作るのは難しそうだ。
Blazorの場合は、HTMLも使う必要があるようだからもっと存在意義が疑問視
される。

**デフォルトの名無しさん** · 2020/04/11(土) 02:54:20.42

vue.jsでnew演算子を
使うとバグが出る前例て
あったけ？

**デフォルトの名無しさん** · 2020/04/11(土) 19:13:15.99

ここで聞いていいかわからないけど…

Webpackのloaderって、
・js を babel-loaderでトランスパイルするルール
・ts を ts-loaderでトランスパイルするルール
を設定したとき、tsはts-loaderによってｊｓになると思うけど、
このloaderによって生成されたｊｓはbabel-loaderの処理対象にはならない？

**デフォルトの名無しさん** · 2020/04/11(土) 19:52:52.40

なるぞ

**デフォルトの名無しさん** · 2020/04/11(土) 20:29:13.86

loaderの処理順による
先だか後だかに書いた順に適用されてく
どっちだったかは忘れたから調べて

**デフォルトの名無しさん** · 2020/05/23(土) 17:25:41.30

angular使い始めたけどいいなコレ。管理しやすさ◎

**デフォルトの名無しさん** · 2020/05/23(土) 21:49:01.48

今から始めるなら Angular はちょっと…

**デフォルトの名無しさん** · 2020/05/23(土) 22:53:11.76

Vueって書いてあるのにな

**デフォルトの名無しさん** · 2020/05/24(日) 07:29:28.60

>>334
VueもReactも使えるよ！

**デフォルトの名無しさん** · 2020/05/24(日) 07:51:13.57

>>333
Reactと比較してどう？

**デフォルトの名無しさん** · 2020/05/24(日) 13:57:54.47

Reactを使い慣れたならAngularってめっちゃ使いにくいと思うよ
コンポーネント1個作る旅に4ファイルずつ増えるのが発狂しそう

**デフォルトの名無しさん** · 2020/05/24(日) 14:48:48.68

jQueryが一番ラクじゃね？ｗ

**デフォルトの名無しさん** · 2020/05/24(日) 15:05:42.13

は、hyperapp...

**デフォルトの名無しさん** · 2020/05/24(日) 15:06:04.29

>>338
どっちも使いにくいとは思わないかな。というかそんなの慣れの問題だから気にならなくなってしまったってのが正解かな。

**デフォルトの名無しさん** · 2020/05/26(火) 11:48:31.01

angularでサービスを作成してDIして使うことは、普通にクラスを作成してnewして使うことに比べて何かメリットがあるのでしょうか？

**デフォルトの名無しさん** · 2020/05/26(火) 14:46:33.17

JavaScriptコードだけで数万行を超えるような規模になったらメリットあるよ

**デフォルトの名無しさん** · 2020/05/29(金) 19:17:47.54

jqueryは単純に
生javascriptが書けない人が
利用してるだけだと思う。vue.jsは

教本で全部
済ませようとすると100%身に付かない。
塾の先生でもそう知っている人はいない。

**デフォルトの名無しさん** · 2020/05/29(金) 19:52:39.01

typescript じゃないと書けなくてゴメン

**デフォルトの名無しさん** · 2020/05/29(金) 20:25:45.60

>>344
https://w3techs.com/technologies/history_overview/javascript_library/all/y
jQueryはウェブサイトの74.9%で使われてる
5年前に比べて13%も増えている
これだけの人が生JavaScriptをかけないとは思えない。

**デフォルトの名無しさん** · 2020/05/29(金) 22:59:47.61

趣味ならともかく仕事でjQueryを使えば簡単なところを自力で書いてるやついたら嫌だろw

**デフォルトの名無しさん** · 2020/05/29(金) 23:00:55.14

というか塾の先生ってなんや？

**デフォルトの名無しさん** · 2020/05/30(土) 08:47:54.68

>>346
WordPressには必ずjqueryがついているが、WordPress自体が全サイトの35％
ということは残り40％くらいが非WordPressサイトなわけでそれらがjqueryを使っている

まあでもjqueryは便利だしよくできているよな

**デフォルトの名無しさん** · 2020/05/30(土) 08:50:12.11

つまりWordPressがあれば、VueとかReactとかAngularはいらんわけや

**デフォルトの名無しさん** · 2020/05/30(土) 08:54:02.70

>>349
もしWordpressがvueを採用してjQueryを排除すれば、、WordPress自体が全サイトの35％
ということは残り40％くらいが非WordPressサイトなわけでそれらがjqueryを使っている

となるのかな？

jQueryが使われていてもWordPressに含まれているものは省くっていうのなら
vueが使われていてもWordPressに含まれているなら同じように省くよね？

**デフォルトの名無しさん** · 2020/05/30(土) 09:07:51.68

まあ俺としてはjQueryのシェアの高さより
Vue、React、Angularの1%未満という低いシェアのまま
数年もの間、伸び悩んでる方に危機感を持ったほうが良いと思うけどね

逆にjQueryの方がシェアが伸びてるという皮肉
脱jQueryが叫ばれた頃よりも10%もシェアが増えているからね
一方同じ期間で、Vue、React、Angular全部合わせて1%にしかなっていない
JavaScriptLibraryを使わないサイトも同じぐらい減って、jQueryを使い始めていることが想像できる

**デフォルトの名無しさん** · 2020/05/30(土) 09:54:10.71

>>351
すまん
日本語がわからん

ちなみにjqueryが伸びているというのはそもそもReactやvueとか単純にこれらのフレームワークを使える奴が圧倒的に少ないから
エンジニアの中でも使える奴が少ないからな
Webサイト制作している奴らには使えるはずもない

せいぜいjqueryしか使えないんだよ
あとはWebサイトの数 >>>>>>>> SPAアプリの数

**デフォルトの名無しさん** · 2020/05/30(土) 12:18:55.92

GoogleのCore Web Vitalsで表示速度・インタラクティブ性・読み込みの安定性を重視して検索順位を決める方針、
これは明らかにWordPressのクソみたいな重くて表示バラバラで途中で広告ロードされて間違ってクリックする低品質なサイトをぶっ潰す方針ってことだよな

もちろんReactとかであってもきちんとレンダリング処理をコントロールしないと同じことが言えるわけだが
さらにGoogleはレベルの低いこのWebフロントをなんとかしたいのだろう
いつまでもゴミのようなWordPressに頼っている現状ではWebの未来は暗い

まあWebもPWAとかに変化するからついてこいよっていう意味も含んでいるのかもな

とにかくjqueryゴミカスサイトは淘汰されていく方針になってきたってわけだが大量のゴミ処理はそう簡単に消えないからうまくいくのかもわかんねえ

**デフォルトの名無しさん** · 2020/05/30(土) 12:39:52.72

>>353
WordPressに35%含まれてるから実質40%とかいう言い訳しないで
普通にjQueryは74.9%で使われてると言えばいいって話

そうしないとWordPressのjQueryがvueに変わった時に
vueのシェアが35%になっても
WordPressに35%含まれてるから実質0%ということになる

**デフォルトの名無しさん** · 2020/05/30(土) 12:42:46.15

>>353
> ちなみにjqueryが伸びているというのはそもそもReactやvueとか単純にこれらのフレームワークを使える奴が圧倒的に少ないから

違う。フレームワークを使う "必要性が圧倒的に少ない" から。
jQueryの代替じゃないんだから、脱jQueryなんて意味がない言葉だったんだよ。

「ウェブサイトはオワコン。これからはウェブアプリの時代だ！」というふうに
"正しく言っていれば" みんなから冷ややかな目で見られていただろうねw

**デフォルトの名無しさん** · 2020/05/30(土) 12:45:07.75

>>354
JavaScriptフレームワークを使ったサイトは重い
jQueryを使うのが一番軽い。

なにせ素のHTMLが最初に表示され（この段階でページとして認識される）
そこにJavaScriptを適用する方式だから。

これと真逆のJavaScriptを全部読み込んで実行しないと中身が出力されない
フレームワークよりも圧倒的に軽くなるんだよ

**デフォルトの名無しさん** · 2020/05/30(土) 12:55:05.10

prototype.js、jQueryはCSSのセレクタがそのまま使えるのが革命的だった

**デフォルトの名無しさん** · 2020/05/30(土) 13:04:50.05

>>358
prototype.jsは使えません

jQueryのCSSセレクタは後にJavaScriptにquerySelectorAllとして導入されたが
jQueryと違って返すのは単なるDOM要素の配列でループが必要なので
結局劣化版にしかならなかった

**デフォルトの名無しさん** · 2020/05/30(土) 14:04:43.55

>>359
え、そうだっけ？っと思って今調べたら$内の記述が確かに違うね

**デフォルトの名無しさん** · 2020/05/30(土) 15:20:36.38

prototype.jsの$はDOM APIの単なる省略でしかないんだよ
prototype.jsのメインはプロトタイプ（つまり基底クラス）の拡張

それにたいして関数型のスタイルを取り入れたjQueryはセンスがいいよな
CSSが関数型の思想なのでウェブの標準にうまくマッチしている

対してVue、React、Angularなどのフレームワークは
単なるオブジェクト指向のアプリケーションフレームワークでしかない
jQueryの代替になんてなりようがなかったんだよ

**デフォルトの名無しさん** · 2020/05/30(土) 17:16:32.62

正直、WebサイトごときにReactとか使う気にはなれない
だがGoogleが求めているのはReactとかの方向性ではないか？と思うのだが
もちろんいずれReact連中は無くなる予定だし

**デフォルトの名無しさん** · 2020/05/30(土) 17:40:52.11

recoil実戦投入はさすがにまだ早い？

**デフォルトの名無しさん** · 2020/05/30(土) 19:45:54.00

機能たくさんあるサービスでVue使ったらコンポーネント増えすぎて管理大変だったという思い出
Reactとか使うべきなかね

**デフォルトの名無しさん** · 2020/05/30(土) 20:28:00.60

そういやWebサイトはComponentに分けるとか無理だ
あの長ったらしいLPとかComponentというよりごちゃごちゃした感じで情報詰め込んで見る奴の思考を停止させるわけだから
むしろまとまりがあるComponentなんか使ったらむしろ作るほうが大変だな

**デフォルトの名無しさん** · 2020/05/30(土) 21:49:42.17

>>362
Googleが求めてるのは、利用者が欲しい情報に正しくアクセスできること
だからサイトの作り方でランクを変えるべきではないし、
新しい技術を使っているからといってランクを上げたりはしない

ランクを変えるとしたらページがどれだけ早く（快適に）表示できるかだが
単純なHTMLページの速さに勝るものはない

jQueryを使う場合はJavaScriptオフでも、HTMLの文章自体は見れるわけで
Googleの求めているものに一番理想的
むしろSPAの方が本当に検索できるか？を常に意識しないといけない。URL設計は特に大事
JavaScriptで表示するページでも検索できるようになっているとされているが保証はない
だから検索されたいページ（ブログの記事など）にJavaScriptのフレームワークを使うのは推奨しない

**デフォルトの名無しさん** · 2020/05/30(土) 21:52:11.19

>>365
そういうこと。ウェブページは全体で一つのものを構成してるのだから
小さいコンポーネントに分けるのが難しい。

ここだけでしか使わないようなものがたくさん生まれる。
どんなに事前に設計しても、あとからあいてるこの空間に入れればいいと
その時の都合で当初の設計にないものが追加される

**デフォルトの名無しさん** · 2020/05/30(土) 21:55:32.30

俺は最初から言ってるんだが、脱jQueryなんてありえなかったんだよ
脱jQueryを目的とするな。今問題が起きてないならjQueryから変えるのは新たな問題を発生させるだけ。
jQueryで困ってる場合（通常ウェブアプリ）はもともとjQueryを使うという方針が間違っていただけ。
それは"脱"jQueryという今まで使っていたjQueryはもう古いからやめましょうではなく
目的に応じた適切な技術を使いましょうという話でしかなかった

**デフォルトの名無しさん** · 2020/05/30(土) 22:33:41.92

bootstrap5楽しみだね

**デフォルトの名無しさん** · 2020/05/30(土) 22:47:55.31

>>369
せやね。bootstrap5はjQueryを使ってないけど、vueもreactもangularも使ってない
だからフレームワークのシェアが増えることはないけど
もしかしたらjQueryのシェアが減ってライブラリ使用なしが増えるかもしれないね

まあそんなことはなかった。jQuery使ってたとわかるのが楽しみだｗ

**デフォルトの名無しさん** · 2020/05/30(土) 22:50:51.02

個人的にはjQuery、Vue.js→Webサイト向け
React、Angular→Webシステム向け

だと勝手に思ってる

**デフォルトの名無しさん** · 2020/05/31(日) 02:36:06.59

vueはリアルdomを作る前に
仮想domを作って効率よく差分するから
早いんだっけ。だからjqueryを使うとその効果が失われる。

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

結果、真面目に教本に
沿って学習すると多くのロスが生まれる。悪循環が
生まれて半年どころの学習時間では済まなくなる。

**デフォルトの名無しさん** · 2020/05/31(日) 02:37:27.64

>>372
文章の組み立てが下手でスマソ

**デフォルトの名無しさん** · 2020/05/31(日) 05:04:14.93

>>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.06

そもそも速度のためにこれらのフレームワークができたわけじゃないし…
規模が大きくなってジェイ・クエリーとかで直接DOM操作するのが管理しきれなくなったからでしょ

**デフォルトの名無しさん** · 2020/05/31(日) 07:42:19.68

未だにＣＯＢＯＬ最高って言ってるおっさんみたいだな

**デフォルトの名無しさん** · 2020/05/31(日) 09:42:21.10

jqueryも仮想DOMも、ページ全体の構築後は一部だけ書き換え
どこから全体が出てくるんだ？
全体書き換えってことはページ遷移ってことだよな？
それならReactやvueのほうが圧倒的に速いんだけど？

**デフォルトの名無しさん** · 2020/05/31(日) 10:10:06.97

速度の為ってより構造化の為に使うもんなんやない？

**デフォルトの名無しさん** · 2020/05/31(日) 11:40:21.71

>>374
結局、vueにjQueryを混ぜると遅くなるの？

**デフォルトの名無しさん** · 2020/05/31(日) 11:43:49.13

>>379
ならない

下手なコードを書けば遅くなるのは
プログラマの問題でしかない

**デフォルトの名無しさん** · 2020/05/31(日) 11:47:50.50

>>375
そういうこと。なのに仮想DOMはリアルDOM "を全画面書き換える" より速いが
仮想DOMはリアルDOMより速いとかよく勘違いされてる

仮想DOMだけ書き換えても、リアルDOMには反映されない
仮想DOMからリアルDOMを書き換えるのと
jQueryでリアルDOMを書き換えるのは同じ

**デフォルトの名無しさん** · 2020/05/31(日) 11:55:31.24

>>381
お前相当バカだろ
そこにSPAの概念がまったく入ってねーじゃねえか
実際の通信や運用を考えてからモノを言え
jqueryジジイは脳みそ停止してんだろ

あと同じなわけないじゃん
無知すぎる

**デフォルトの名無しさん** · 2020/05/31(日) 11:58:01.25

>>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.32

>>382
> そこにSPAの概念がまったく入ってねーじゃねえか

お前のレスを見る前に>>383を書いた。
SPAの概念はReactやvueの専売特許ではない
昔から Rails + turbolinks+ jQuery で同じことをしている
お前が無知なだけだ。過大広告に騙されやがってｗ

**デフォルトの名無しさん** · 2020/05/31(日) 12:41:37.02

Ruby 君かな

**デフォルトの名無しさん** · 2020/05/31(日) 12:43:35.72

>>385
ちげーよ

**デフォルトの名無しさん** · 2020/05/31(日) 12:47:08.02

>>384
お前相当なにもわかってないじゃん
コイツに説明するだけ無駄すぎた
jqueryクソジジイは一生jquery使ってろ
ただただ気持ちわりい

**デフォルトの名無しさん** · 2020/05/31(日) 12:50:05.93

なぜかJavaScriptの話ではなく「俺」の話にすり替わってるｗ

**デフォルトの名無しさん** · 2020/05/31(日) 12:50:33.12

turbolinksがSPAって初めて聞いた

**デフォルトの名無しさん** · 2020/05/31(日) 12:56:44.85

>>379
大体速度を気にしなきゃいけない様なシビアな案件なんて殆どないしな

大レコード数のテーブルを生成するのだってその処理部分に関してはほぼ混ぜ様がないだろうし

**デフォルトの名無しさん** · 2020/05/31(日) 12:59:27.17

単純に言って混ぜるとソースが汚くなるのと
タイミング問題が起こった時に分け分からんくなるってくらいだろ

**デフォルトの名無しさん** · 2020/05/31(日) 13:05:49.62

判った。jqueryは
あんま良くないけど、vue.jsと一緒に
使うと爆速になるってことね。

**デフォルトの名無しさん** · 2020/05/31(日) 13:11:27.49

>>389
あれ使い方間違ってる人多いからね。
JavaScriptが発動しないといかって無効にする人

turbolinksはjQueryとの相性が良くて
最初にサイトを表示したときに全てのJavaScriptコードを読み込んで
あとはすべての要素が動的に増減する（無くなることもある）という前提で使うもの
jQueryはすべての要素を0以上の要素郡として操作するので非常に相性がいい

**デフォルトの名無しさん** · 2020/05/31(日) 14:22:35.36

あれだ、「コンパイラの最適化がどんなに賢くなってもアセンブラには敵わない」とかいうのと同じ。

**デフォルトの名無しさん** · 2020/05/31(日) 14:31:17.31

>>394
それはコンピュータの最適化 vs 人間の最適化という話なので
まったく関係ない話ですね

**デフォルトの名無しさん** · 2020/05/31(日) 15:01:48.16

無知ですまんのだが、リアルDOMでも仮想DOMでも最終的にはひとつのテキストファイル(html)になってブラウザが読み込んでレンダリングするってのは変わらないわけだよね。
リアルDOMと仮想DOMではその最終処理に向かう途中のどこに違いが生じるの？

**デフォルトの名無しさん** · 2020/05/31(日) 15:11:00.06

>>396
その通り。テキストファイルになるわけじゃないけど
仮想DOMは速いとかいうビジネストークを無視すれば話は簡単

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

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

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

速度うんぬんではなく、テストをしやすくするためにリアルDOMから仮想DOMへデータを分離している

**デフォルトの名無しさん** · 2020/05/31(日) 15:14:27.24

大規模なものを作るときは、小さいパーツに分けないとテストが困難になる。
大規模なものを大規模なままテストするのは難しい

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

ウェブサイトのような小さいシステムでは
逆にコストが掛かることになるんだよ。
そういう見極めができない人が、脱jQueryなどと叫んで
小さいシステムなのにフレームワークを採用して逆にコストを増大させている

**デフォルトの名無しさん** · 2020/05/31(日) 15:17:00.98

作るものによって使う技術を変えるべきなのに
それができないエセ技術者が多い
新しい技術を知ったら何でもそれでやろうとする。

**デフォルトの名無しさん** · 2020/05/31(日) 15:34:07.62

>>395
ああすまん、あんたにレスしたつもりはなかった。
>>394はリアルDOMの操作を直接コーディングするのと仮想DOMの差分からDOM操作を生成するのとの
速度比較の話ね。

**デフォルトの名無しさん** · 2020/05/31(日) 15:34:50.72

>>397
ありがとうございます、すごくわかりやすくて腑に落ちました。

**デフォルトの名無しさん** · 2020/05/31(日) 16:02:47.28

こいつは昔からいるゴミカスjqueryジジイでどこでも仮想DOMに噛み付く気持ちわりい粘着野郎

**デフォルトの名無しさん** · 2020/05/31(日) 16:12:18.94

JavaScriptの話ができないやつは「俺」の話をしてしまうｗ

**デフォルトの名無しさん** · 2020/05/31(日) 16:23:27.31

>>396
tar zxvfで解凍するかtar zxfで解凍するかの違いとか想像してみるのはどうだい？

**デフォルトの名無しさん** · 2020/05/31(日) 16:26:37.16

>>395
よっぽどの職人とかじゃない限り凡人がコンパイラの最適化を超えるとかいい加減無理だろ

**デフォルトの名無しさん** · 2020/05/31(日) 16:50:56.70

>>404
「v」のある無しで展開時に詳細を出力するかどうかの違いということですよね？
これをjavascriptの話とした場合、展開時の詳細にあたるものは具体的にはなんなのでしょうか？

**デフォルトの名無しさん** · 2020/05/31(日) 17:05:12.54

初心者向けにはこの記事がわかりやすいと思う
↓
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.80

https://i.imgur.com/IFVxEh2.jpg

**デフォルトの名無しさん** · 2020/05/31(日) 18:21:47.85

コンパイルした時点で仮想DOMなんてものは無くなるので、理論的には仮想DOMを使うことによるオーバーヘッドも消せるということか。
そして>>408を見る限りはコンパイラが優秀なので実際にオーバーヘッドを消せているということかな。
まあこの実験のデータセットがリアクトコンパイラにとって有利なものだったという可能性もあるのでもう少しデータの詳細が知りたいが。

**デフォルトの名無しさん** · 2020/05/31(日) 19:07:31.06

Domが読み込まれる前の
createdの段階で実行するから
早くなるんだろう。この段階はelもrefも

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

台無しだろう。

**デフォルトの名無しさん** · 2020/05/31(日) 19:12:25.04

>>410
モトメじゃなくて元もwww

**デフォルトの名無しさん** · 2020/05/31(日) 22:15:08.01

>>407
> ・DOMの操作はきちんとやらないとレンダリングの負荷が大きくなる

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

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

現実にやりそうな「きちんとやってないコード」の例を
出せる人がいるなら見てみたい
そしたら（jQueryは）普通どうやるのかを俺は言えると思うね

**デフォルトの名無しさん** · 2020/05/31(日) 22:15:41.30

>>409
> コンパイルした時点で仮想DOMなんてものは無くなるので、
誰がそんな話してるんだ？
無くなるわけないぞ

**デフォルトの名無しさん** · 2020/05/31(日) 22:20:45.56

>>410
> Domが読み込まれる前の
> createdの段階で実行するから

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

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

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

というのは常識的な知識だったはずなんだがなぁ

**デフォルトの名無しさん** · 2020/05/31(日) 22:22:33.40

結局仮想DOMのアイデアっていうのは

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

と言ってるだけ

**デフォルトの名無しさん** · 2020/05/31(日) 22:26:16.77

>>415
お前が作ったわけでもねーしお前がweb準拠を策定しているわけでもねえのに何偉そうに吠えてんだよゴミカス

**デフォルトの名無しさん** · 2020/05/31(日) 22:35:34.04

>>416
お前が世界を作った訳でもねーのに何偉そうに吠えてんだよゴミカス

**デフォルトの名無しさん** · 2020/05/31(日) 22:37:06.99

常識かもしれんが
バッドノウハウの類いに聞こえるな

**デフォルトの名無しさん** · 2020/05/31(日) 23:01:44.07

ゴミカスはDOM構築後にjqueryを読み込むから速いとかゴミ説明して勝ち誇ってるが
それは読み込んだだけでjqueryを何も実行しない（＝jqueryを使っていない）だけだろ
これで速いとかアホかこいつ

**デフォルトの名無しさん** · 2020/05/31(日) 23:14:07.26

>>415
これは、DOMの直接操作なら常に最適な操作ができるという前提の発想だな。
最適操作が自明な範囲しか念頭に無いんだろうな。