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/03/14(土) 10:36:53.78

その手のことを補うのが型チェックだろ。
reactでもvueでも問題はそこじゃない。

**デフォルトの名無しさん** · 2020/03/14(土) 12:53:11.03

>>273
Vueやってるヤツでもその内のどれくらいがビルドして組んでんだかな…

**デフォルトの名無しさん** · 2020/03/14(土) 15:48:52.29

vue流行りはマジで日本だけだからな
cakePHPと同じ

世界からは失笑されている

**デフォルトの名無しさん** · 2020/03/14(土) 16:32:02.87

vueのほうが手軽なのに、日本で特異的にvueが流行ってる理由というより世界の潮流としてreact優勢なのはなんか理由があるのかな？

**デフォルトの名無しさん** · 2020/03/14(土) 16:45:14.14

なんでだろう(´・ω・｀)

**デフォルトの名無しさん** · 2020/03/14(土) 17:42:50.06

一部だけ入れ替えとかならvueよりもreactのがやりやすいんでねーの。

**デフォルトの名無しさん** · 2020/03/14(土) 19:11:23.63

>>281
Vueが流行ってるのは東アジアとか東南アジアだろ
日本ではなんだかんだReactが優勢というかそこに行けない大多数の奴らは結局jQuery使ってる感じだろ

**デフォルトの名無しさん** · 2020/03/14(土) 20:42:39.46

Typescriptとの親和性が一番でかいっしょ

**デフォルトの名無しさん** · 2020/03/14(土) 21:01:49.64

>>285
きもい

**デフォルトの名無しさん** · 2020/03/14(土) 21:49:58.26

適材適所でいいじゃん

**デフォルトの名無しさん** · 2020/03/16(月) 17:15:30.62

vue.jsは、github 全体の中でプログラム部門ではTOPのSTAR数を誇る最大人気のプロジェクトだ。

**デフォルトの名無しさん** · 2020/03/16(月) 17:19:16.28

ドキュメント部門を除外した場合の github starranking :
vuejs/vue
3 vuejs/vue
JavaScript 159352🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
facebook/react
4 facebook/react
JavaScript 145286A declarative, efficient, and flexible JavaScript library for building user interfaces.
tensorflow/tensorflow
5 tensorflow/tensorflow
C++ 142031An Open Source Machine Learning Framework for Everyone
twbs/bootstrap
6 twbs/bootstrap
JavaScript 139254The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.

**デフォルトの名無しさん** · 2020/03/16(月) 17:21:28.81

上位4つの内、3つは、JavaScriptを使ったWebFrameWork(HTML+CSS+JS)らしい。
残りの1つは、機械学習用の数学(?)ライブラリ。

**デフォルトの名無しさん** · 2020/03/17(火) 01:37:00.55

人気は、二系統に分けて書いてみれば、
・vue>Angular>React>>Razor>>>Blazor
・Unity>Qt>>>Flutter

**デフォルトの名無しさん** · 2020/03/17(火) 02:04:41.32

vueの人気は、分かり易さ以外にランタイムの小ささがもう一つの主因になっているかもしれない。
簡単なWebにAngularの500KBやBlazorの2.0MBでは困るから：

DownloadSize(RuntimeSize) :
vue:91KB
React:116KB
Angular:500KB
Blazor:2.0MB (将来は1.5MBを目指している)

**デフォルトの名無しさん** · 2020/03/17(火) 19:27:45.14

俺は大雑把な
vueの文法が嫌いだが、ランキングが高いので
仕方なく使っている。ランキングが高いと世の中に出廻る

ソースの数や解説本の数なんかも違ってくる。

速いのも魅力的だし

**デフォルトの名無しさん** · 2020/03/17(火) 21:03:20.21

普通にreactでいいじゃん
reactで何か問題あるのか？

**デフォルトの名無しさん** · 2020/03/18(水) 20:05:07.33

ランタイム・サイズの大きさはダウンロード時間だけでなく、JSの実行時コンパイルの時間にも関係してきて、特にモバイルの場合にはダウンロード完了後の起動速度にも関係すると思う。
vueが速い理由の一つにはその影響もあるのかもしれない。
また、blazorは、.netのVMがブラウザ内で確かWasmを使って動作しなければならない。
Wasmも仮想マシンで、.netも仮想マシン。全体の遅さは両方の遅さの掛け算となるので特にモバイルではだいぶ遅く感じるのではないかと思われる。

**デフォルトの名無しさん** · 2020/03/18(水) 20:25:33.91

重くてリッチなのはreactでいいじゃん

**デフォルトの名無しさん** · 2020/03/20(金) 21:43:18.11

WikipediaはVueを選んだ
Reactはオワコン

Watching you, with a Vue to a Kill: Wikimedia developers dismiss React for JavaScript makeover despite complaints
https://www.theregister.co.uk/2020/03/20/wikimedia_react_javascript/

・WebpackやBabelなどのフロントエンド用ビルドツールサポートが優れていて、依存するライブラリが少なく、安定して進化している
・Reactは、2014年から2017年まで特許条項付きBSDライセンスを採用していた
・Vueの開発はReactのように一つの組織によって運営されていない
・前にHHVMを捨てたせいでPHPに移行を余儀なくされたので、Facebookを信用してない
・Wikimedia Deutschlandは既にVueを試してる

**デフォルトの名無しさん** · 2020/03/20(金) 23:44:09.86

wikipedia ってそんなに権威があるのか？

**デフォルトの名無しさん** · 2020/03/20(金) 23:59:20.63

　　　　　　　　　　　　　　　　　　　＼､,,)rﾞ''"''ｰ弋辷_,,..ィ
　　　　　　　　　　　　　　　　　　=､..,,,ﾆ;ヲ_　　　　　ヾ彡r''"
　　　　　　　　　　　　　　　　　　｀`ミミ,　　 i'⌒!　　ﾐミ＝-
＿＿＿＿＿＿＿＿＿＿＿＿=　-三t　　 fﾞ'ｰ'l　　 ,三＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
|　　　　　　　　　　　　　　　　　　　,シ彡､　lﾄ　 l!　 ,:ﾐ...　 {:::}　　　　　　　　__,,,,,､　',::::ヽ.　　　　　　|
|　　　　　　　　　　　　　　　　／　^'''7　 ├''ヾ!　　 }:::ﾉ　,,,==ｪｪゝ '彡o,ゝ=　Ｙ）　　　　　　　 |
|　以下　　　　　　　　　　　　／　　　　l　　ト､　＼　ヽ::', "_ｨ.o`> 　 `二´-｀`　',ﾉ　　　　　　.　|
|　ウィキペディア創設者　　　　　〃ﾐ　,r''f!　　l!　ヽ.　　　　ﾊ｀彡ィ　 , 　　､　　　　.|　　　　　　　.|
|　ジミー・ウェールズからの　ノ , 　 ,ｲ,: l! ,　,j! ,　ﾄ、　　　ヽ,　　　/　_　,r'ハ　　　.|　　　　　　　.　|
|　メッセージをお読みください　/ ｨ,/ :'　　　　　':. l ヽ.　　　　ﾍ　　ｲ:::::::::__,:＿､::: }:::/　　　　　　　　|
|　　　　　　　　　　　　　　　　 / :: ,ll　　　　　　　　ﾞ': ﾞi　　　　ヽ::::（:ィ─=彡　ヾl::/|､　　　　　　.　|
|　　　　　　　　　　　　　　　 /　 /ll　　　　　　　　 'ﾞ　!　　　　ﾊ',::＼:::::::"":: : ::／　ﾊ､.　　　　　　|
|　　　　　　　　　　　　　　 /' ヽ.　　　　　　　ﾘ　　,､-'´　|＼`ヾ::::::::::::ィ　　/　|　｀`ヽ─-､.|
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

**デフォルトの名無しさん** · 2020/03/21(土) 09:43:46.28

Wikipediaがvueを使ったからreactが終わってるは飛躍しすぎてる気がするけどな

**デフォルトの名無しさん** · 2020/03/21(土) 10:29:31.96

そもそも最終候補に残らなかった
Angular、Ember、Svelte、Inferno、Preact、Web Components
とかのことも
時々でいいから思い出してください

**デフォルトの名無しさん** · 2020/03/21(土) 10:58:31.90

Reactは動画サイト系では結構使われてるよね
あとWordPress5にも組み込まれたんだっけ？

**デフォルトの名無しさん** · 2020/03/21(土) 13:20:16.16

そもそもReactくらいWebやる奴なら誰でも使えるくらい簡単だからこんな低レベルな争い自体が滑稽
たいした技術でも何でもないだろ

どちらかというとReactは初心者向け

**デフォルトの名無しさん** · 2020/03/21(土) 22:48:44.19

>>304
アプリケーションを簡単に作れるなら良いライブラリでしょ
君の指摘は本質を全く捉えられてないよ

**デフォルトの名無しさん** · 2020/03/22(日) 20:57:52.32

びっくりするほどフロントできるプログラマーっていないよな
デザインすらゴミレベル
ゴミレベルだからデザイン指定しても再現出来ない

**デフォルトの名無しさん** · 2020/03/22(日) 22:42:59.73

それ君の周りにゴミPGしか居ないだけでは

**デフォルトの名無しさん** · 2020/03/22(日) 23:10:42.69

海外の採用担当者がまともなフロントエンジニアがいないと嘆いている
フロントエンジニアでデザインできない奴はマジでクソ
バックエンドやってろって思うわ

**デフォルトの名無しさん** · 2020/03/23(月) 00:48:43.54

サーバーサイドしかできないエンジニアなんか何の役にも立たないな
田舎に帰って畑仕事してる方がまだ世のためになる

**デフォルトの名無しさん** · 2020/03/23(月) 08:16:51.48

自演乙

**デフォルトの名無しさん** · 2020/03/23(月) 10:41:43.30

vueがそもそも簡単という
理由もないし、jqueryがvue.js内部で使えるって
だけでjqueryの代用になるとは誰も云ってないwww

中学生の問題が、高校で出題されるレベル

**デフォルトの名無しさん** · 2020/03/28(土) 00:18:22.26

>>306
最近デザインはMaterial-UI頼りのスマホアプリライクだけど別段評判は悪くない

**デフォルトの名無しさん** · 2020/03/28(土) 07:54:09.66

フロントは細かい要求されるわりに金出ねーじゃん。
そんなんやるやつ減るに決まってるわ。

**デフォルトの名無しさん** · 2020/03/28(土) 09:17:09.13

>>312
Material UIの説明にデザインてきない奴ら向けって書いてる
独自性もないし、そもそもMaterial UIすらまともに使えず、使えてるつもりでバランスバラバラ

クソ使えないエンジニアが「Material UIで作りました！」とかほざくことほど滑稽なことはない
自分は無能です！と言ってるようなもの

無能に金出すわけねえだろ

**デフォルトの名無しさん** · 2020/03/30(月) 10:36:56.62

それじゃ糞ださいフロントでも我慢してくれとしか言いようがない。
まあフロントのデザインにこだわらんというのもありだと思うけどね。

**デフォルトの名無しさん** · 2020/04/02(木) 01:18:38.12

メインでやってるのはホームページの延長じゃなく
業務システムのWeb化だからそんなに外観とか求められんのよな

**デフォルトの名無しさん** · 2020/04/02(木) 06:26:17.20

外観求められんとか以前に商品として終わってるレベルしか作れない能力の無さになんで勝ち誇れるんだ？
少しはデザイン勉強してからフロントやってくれ
マジで無能が仕事すること自体迷惑
それでフロントできますとかほざくな

**デフォルトの名無しさん** · 2020/04/02(木) 08:38:21.23

>>317
そのレベルでいいなら自分でやれや。
それもできんからしょーもない詐欺師に引っかかるんだよ。

**デフォルトの名無しさん** · 2020/04/02(木) 18:08:22.20

>>318
おまえバカ？
こっちは作る側だ
依頼する奴がこんなところに来るかよ

**デフォルトの名無しさん** · 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を混ぜると遅くなるの？