Vue vs React vs Angular

2018/12/21(金) 21:37:36.86

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/02/14(木) 19:21:17.93

新しいフロントフレームワークが出た時に丸ごとすげ替えれるならなんでもいいよ
俺はMVCがベストバランスの正解だと思うがね

2019/02/14(木) 19:22:01.34

backboneを勉強した人は無駄になった。
Angularも1系を勉強した人は無駄になった。
jQueryは登場してから13年使われ続けている。

これが現実やで

2019/02/14(木) 19:25:35.68

wpの保守死ぬほど大変だけどな。てかフレームワークとwpは全く別物だろうよ。ブログのフレームワークと言えない事も無いが。

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/14(木) 19:38:24.66

>>322
ビルトインされてるよ。テーマによってはwpビルトイン版と競合を避けるため他のバージョンを別に導入する場合もある。
そしてwpのシェアはcms中では60%、全Web中では33%
だからwp除くならjQueryは40%程度だなｗ

2019/02/14(木) 19:43:27.31

> だからwp除くならjQueryは40%程度だなｗ

圧倒的シェアじゃないか！

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/14(木) 19:50:59.92

最初からシェア小さいとは言ってないだろｗ
増加してるのはwpのシェア増につられてだろうと予測しただけ。
おそらく合ってるなｗ
jQueryバカが威張るのは滑稽。

2019/02/14(木) 20:14:34.64

jqueryしか使えないバカが多い
バカのくせにバカを賛美している

2019/02/14(木) 20:27:26.21

所で仮想DOMのアプローチって本当に速いのかな？

仮想DOMはDOMを触らないって言うけど、
結局最終的な形にするためにDOMを構築するでしょう？
そのときに要素を作ったり削除したり

そんな事しないで、CSS使って要素を隠したり表示したほうが速いない？
jQueryはDOM操作が得意なわけだけど、DOMを作ったり削除したりするんじゃなくて
classを変更して見た目を変えることで擬似的にDOMが表示されたり消えたりするって
いうのがベストプラクティスだと思ってる。この場合はDOMの構築をやらないので
仮想DOMのアプローチよりも速いんじゃない？

2019/02/14(木) 20:30:52.74

cssのが早いのは当たり前だろ…
お前、こういうスレ来るのは10年早いよ。
真摯に勉強しろやマジで。スレタイ読まずに荒らしてないでさぁ

2019/02/14(木) 21:08:57.94

VuexとReduxって難易度変わらない？

2019/02/14(木) 21:10:34.79

どちらも単に面倒くさいだけじゃないの？

2019/02/14(木) 21:11:54.44

正直Reduxとか使うよりも、カスタムイベントを使ったほうが楽だと思う

2019/02/14(木) 21:25:16.30

マジでお前来るなよ
スレチクソキチガイが
テメーの妄想なんかどうでもいいんだよ
勝手にjqueryスレ立ててそっちでやれバーカ

2019/02/14(木) 21:53:19.44

だが断る

2019/02/15(金) 07:48:37.76

>>304
そういう観点ならNuxtでもいいと思う

2019/02/15(金) 08:12:30.75

Vueが最強なんじゃね？
仕事ならReact

2019/02/15(金) 08:39:56.97

仕事でもnuxtつこてるわ
angularとreactは敷居が高め
他のメンバーが嫌がるのよ

2019/02/15(金) 08:56:20.31

そういやVueでもjsx使えるとかVueの和書の一番厚い本に書いてあったな

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 09:54:44.63

reactのために作ったってだけである種類の関数の入れ子をxml風に記述できるというだけの独立した仕組みだからreact関係なく使えるよ。

2019/02/15(金) 13:09:17.41

>>337
そうなのか。興味湧いてきたのでちょっとNuxt試してみます。

2019/02/15(金) 19:10:03.96

ReactやVueやる奴らは当たり前だがフロントデザインやUXできるんだよな？

2019/02/15(金) 19:14:19.75

>>330
仮想domのメリットは最終的にはリアクティブ。その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、リアクティブでは単に変数をfalseするだけになる。
複雑な入力フォームも恐ろしく作りやすくなるから、一度vueの公式見るといい。

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 19:47:12.24

勉強しなくていい言い訳探しに来てる奴に何言ってもムダ

2019/02/15(金) 21:10:18.28

>>344
> その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、
あー、それがお前の根本的な間違いなんだよ。
お前っていうか、世間一般？使い方間違えてるんだよね。
そういうDOM操作なんてしません。

jQueryでは単にHTMLのclassの（例えば）activeをdeactiveにするだけになる。
複雑な入力フォームも作れるし、classを変えるだけで全く違った表示にすることができる
そのフォームを使ってる間JavaScriptは全く使用しない。
デザイナが自由に好きなデザインで作ることができる。
そしてjQueryではclassの値を変えるだけになる。

2019/02/15(金) 21:28:10.41

>>343
むしろそっちのが専門や

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 21:31:08.33

jQueryのhideはdisplay: noneだろ。
active、deactive（笑）に至っては意味不明。
jQueryではそういうときはactiveクラスをtoggleClassで付けたりはずしたりするんであって、active外してdeactive（笑）つける、deactive（笑）外してactive付ける、なんてマヌケなことはしません。
やっぱりね、自分が勉強したくないもんだから他人の足を引っ張ろうとするような女の腐ったような童貞は自分が上げてるライブラリもまともに使いこなせないｗｗミジメ過ぎｗｗｗｗｗ

2019/02/15(金) 21:33:20.85

jQueryからreactならそこまで乗り換えコストかからんと思うけどな。

2019/02/15(金) 21:46:27.22

>>347
合格

2019/02/15(金) 21:48:11.36

>>348
ん？お前俺が言ったことと大差ないよな？

activeクラスを付けるor 外すことで表示の切り替えを行うから
そんなことでDOM操作なんてしないってことだろ？

でそれが>>330で書いたことにつながるんだよ。
仮想DOMは最終的にDOM操作をするから遅くなるが、
jQueryではCSSによって見た目を切り替えるだけだから速いってこと

2019/02/15(金) 21:51:50.27

いやDOM APIを通じて操作するんでしょ

2019/02/15(金) 22:06:11.07

>>352
そりゃVueやReactだって最終的にはDOM APIを通じて操作するよ
ただしその操作の内容を、DOM要素の削除や追加じゃなくて
クラス名を変えて表示を切り替えるだけにすると速いってこと

2019/02/15(金) 22:07:28.91

Angularの方が難しいの？　Reactの方が自由に構成決めたりコーディングしたり出来る分、
自分で決めなきゃいけない事が多くなって逆に難易度高いって聞いたけど。

Angularの方が環境構築も規約も全部世話してくれるから楽だって聞いたからAngularから入ったんだけど。もしかして騙された？

2019/02/15(金) 22:10:09.24

>>354
英語などの単語の暗記が得意だったならangular
数学が得意だったならreact

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:14:49.66

さすがjQueryバカ。伊達に名前にバカって付いてないな。
クラスの付け外しも厳然たるDOM操作。
そんなことも分からないとは…使われるjQueryもかわいそうだ。

2019/02/15(金) 22:20:03.31

そもそもjQueryのコア機能はDOM操作なんだが…
DOM操作しないならjQuery要らねーよ。
贔屓のライブラリの存在理由否定してどうする。

2019/02/15(金) 22:22:45.45

>>357
DOM操作のうち、class属性を変えるだけにするということ
そしてCSSでブラウザにネイティブ処理させるから速いんだよ
要素の追加や削除は必要最小限にするのが鉄則

2019/02/15(金) 22:29:21.05

>>354
自分がやりたいことと、フレームワークが提供してくれる機能とのバランスだよ

業務アプリみたいに複雑なインターフェースのアプリをガッツリと大量（＝画面数が多い）に
作らなきゃいけないならAngularがいいだろうけど、そうでもないなら
Reactで適当にデータ管理してやれば楽ってこと
Angularはいろんなことを面倒見てるけど、そこまでやることないじゃん？って思うならReact

更に言うならウェブサイトみたいなものはjQueryで十分ってこと

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:30:21.14

> ネイティブ処理させるから速いんだよ

だったらネイティブのDOM API使うわｗ
You Don't Need jQuery!
https://blog.garstasio.com/you-dont-need-jquery/dom-manipulation/

2019/02/15(金) 22:33:24.44

>>360
それもバランスの問題だな。
そこ見ても分かるだろ？いずれの例もjQueryの方が短く書けている
開発効率の高さがあるからjQueryのほうが良い訳

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:34:33.79

せっかくだから日本語版
jQueryは必要ない（You Don't Need jQuery）
https://github.com/nefe/You-Dont-Need-jQuery/blob/master/README-ja.md

2019/02/15(金) 22:37:44.38

フレームワークの欠点は単純なウェブサイトでは
生産性を落とすという大きな問題があるってこと

2019/02/15(金) 22:38:05.96

https://i.imgur.com/obAeeP9.png

2019/02/15(金) 22:38:49.90

ついでだから、jQueryは必要ない（？）から一例を抜粋

8.7 slideToggle

スライドを伴って、エレメントの表示・非表示を切り替えます。

// jQuery
$el.slideToggle();

// Native
let originHeight = '100px';
el.style.transition = 'height 3s';
let { height } = el.ownerDocument.defaultView.getComputedStyle(el, null);
if (parseInt(height, 10) === 0) {
el.style.height = originHeight;
}
else {
el.style.height = '0px';
}

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:41:31.02

css tricksのYou Might Not Need jQuery
https://css-tricks.com/now-ever-might-not-need-jquery/

その翻訳
https://coliss.com/articles/build-websites/operation/javascript/now-ever-might-not-need-jquery.html

2019/02/15(金) 22:43:21.30

DOMにノードを追加すると、DOM APIと直接対話するVanillaを1回呼び出すだけで済みますが、jQueryは多くの操作を実行します（スタックが長すぎて画像に収まりません）。違いは明らかです。

Vanilla：4ミリ秒
jQuery：95.3ミリ秒
Vanilla Javascriptは、追加時のjQueryよりも約25倍高速です。

2019/02/15(金) 22:44:41.61

>>367
いや、だからそんなことをしないで、クラスの書き換えだけを
やることで高速化できるって言ってるんだよ
話ついてきてね

2019/02/15(金) 22:48:19.07

>>359
使い分けって言いながらフレームワーク要らないって言うから意味不明になるんだよ
「自分の仕事では」要らないって話だろ？

2019/02/15(金) 22:51:08.66

>>368
class追加するだけでもjqueryより10倍速いんですが？
https://i.imgur.com/nEJCnHz.png

2019/02/15(金) 22:51:38.93

削除はともかく、追加がクラスの書き換えだけの訳ないわな。その書き換える対象がまだ無いんだから。

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:51:58.45

jQueryはネイティブに比べて遅い上にサイズも大きすぎる。
画像でもないのに数十kBとかアホか。
短く書けりゃいいのならnanoなど代替ライブラリもある。
nanoのコード例：
$(".someClass").css("background-color:green;").html("Hello World");
$('#c').animate('2.3', '1.2','0','1','1','0','0', '0','0','1').css('background-color:red').text('Hello');

$("#a").on("click", function(){

$("#someDiv").css("background-color:green;color:#fff;");

})

nanoは0.6kB。
jQueryは100倍もコード容量かけて何やってんのｗｗｗｗｗ

2019/02/15(金) 22:54:11.02

ボコボコでワロタｗ
我が物顔でスレチ荒らしするからこうなるｗｗ

2019/02/15(金) 22:54:50.30

>>372
じゃあnano使えば良いんじゃないですか？
フレームワークよりも大幅に小さいし

2019/02/15(金) 22:56:00.99

ウェブサイトではフレームワークは重すぎで生産性を下げるという
大きな問題があるが、jQueryやnanoはDOM APIの冗長性を省くだけだから
生産性は上がるしか無いというのが大きなメリットなんだよ

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 22:59:32.27

まあjQueryがいらないのは確かだね。
要素のstyle操作程度ならなおさらね。
「DOM操作しない方がいい」って言ってたし、じゃあDOM操作ライブラリのjQueryはいらないねｗ
え、やっぱりDOM操作したい？そして短く書きたいって？
100倍軽いnanoがあるよｗ

2019/02/15(金) 23:04:02.60

nano信者か・・・

2019/02/15(金) 23:05:15.16

そういやzeptoとかもあったけど、
今までの経験上、軽いだけの代替ライブラリは
結局本家を超えることって無いんだよな
nanoが普及すると良いね

2019/02/15(金) 23:09:04.09

すまん、ガチで話についていけてないんだが、>>351でjQueryは速いって書いてあるからjQueryは速いのか！って思ってたんだけど結局遅いの？

2019/02/15(金) 23:11:01.96

何をもって速いとするかに依る

2019/02/15(金) 23:11:48.08

>>380
速さを求めるときに使うもの？

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 23:12:36.21

GitHubがjQuery辞めたので https://ushirock.hateblo.jp/entry/2018/07/28/013507

jQuery が DOM 操作の際に eval() を多用しているため CSP を safe モードで使えないらしい

これは jQuery の核になる部分の仕様らしく、 .html() はどんな時でも任意のコードを実行する可能性があると

やっぱり jQuery といえば Sizzle でのセレクタ解析が遅いとか（querySelectorが使える場合優先されるらしい）ネイティブへの置き換えとかに目が行きがちだけどもこういう深い話でのデメリットもあるんだなと

2019/02/15(金) 23:14:27.13

>>379
jQueryが速いなんて言ってないんだが？
ファイルサイズではフレームワークよりも小さいから
初回ダウンロードは速いだろうけど。

速いって言う話はDOM操作で要素を消したり作ったりするよりも
classを変更するだけにしてCSSで表示したり見えなくしたりするほうが
速いだろうってこと。

**デフォルトの名無しさん** (ｱﾒ MM6b-QWHq) · 2019/02/15(金) 23:15:42.26

jQuery。それは、

・遅い

・重い

・アンセキュア

なDOM操作ライブラリ。

2019/02/15(金) 23:16:58.62

>>382
ソースコードざっと見たけど、evalが見当たらないんだけど何行目にある？
https://code.jquery.com/jquery-3.3.1.js

2019/02/15(金) 23:17:08.57

jQueryを使うのって、速さ云々より一つのコードがどんな環境でも同じ様に動くって所なんじゃないの？

ブラウザの種類やバージョンでJavascriptの挙動の違いがあるから、それを吸収する為にjQueryを使うんじゃない？

2019/02/15(金) 23:17:55.89

>>381
はっきり言ってjQueryが遅いとは思わない
熟練した人が地道に管理すれば十分速い

それが手間じゃねぇの？ってのがフレームワークの意義

2019/02/15(金) 23:21:18.07

>>384
jQueryってDOM APIを使ってるだけなのに
なんでアンセキュアになるの？

2019/02/15(金) 23:21:36.55

>>383
そうか、なんかすまん。

>仮想DOMは最終的にDOM操作をするから遅くなるが、
>jQueryではCSSによって見た目を切り替えるだけだから速いってこと

この部分読んで仮想DOMは遅くてjQueryは速いのか！って解釈しちゃったんだが仮想DOMに比べて速いだけでjQueryも速くないんだな。

2019/02/15(金) 23:25:42.00

>>387

>>367の結果だけ見ると遅すぎ(10回やると1秒！？)って思っちゃったんだが……

webは基本的には静的コンテンツだから気にならない世界なのかな。

とりあえず俺にはこのスレの会話を理解する能力が足りないっぽい。

2019/02/15(金) 23:28:54.96

まあ1つの処理に4ミリ秒って時点で衝撃的な遅さだしweb開発の世界はそんなもんなのか。

2019/02/15(金) 23:31:51.99

jQuery使うと100ミリ秒になるけどなｗ

2019/02/16(土) 00:34:30.68

vue.jsが
やたらめってら、もてハヤサれる昨今だけど
ぶっちゃ毛v-forが仕様としてオワッテると思うわ。
それとuidの生成パターンをC言語なら「ポインターが理解でないワケ」や
「ポインター徹底攻略」、、、JAVAならデザイパターン本みたいな
分厚い本で説明しなきゃ
いけないのに、それを全くやってないよな。
俺が考えるvue.jsが広まらないワケだよ。コンポーネントをどうユーザーが
受けとるべきかも、簡単な再帰などを使ってイラストレートしなきゃいけないのに
これも全くやってない。細々としたシステムは売り込んでるけど
vueの長所が全くされてない

2019/02/16(土) 00:34:57.77

早い遅いじゃなくて開発効率の話だろ。domを直接指定して操作云々はもう止める、最小限にするて事。今後確実にそうなるのは皆分かってると思うが。

2019/02/16(土) 00:44:30.53

実行速度の話をしてる人たちに、いきなり開発効率の話をしだすのは草。なんの関係もないじゃんw

2019/02/16(土) 01:34:13.23

実行速度については、DOM要素を作成したり削除したりするよりも
CSSで表示したり隠したりしたほうが速いんじゃないかってだけのこと
それをやるにはVue/React/AngularよりもjQueryの方が楽ってこと

DOM操作がネイティブよりも速いなんて話はしてない。
CSSによる表示切り替えの方が速いって話をしてる。

そのCSSによる表示切り替えを楽にやる（開発効率が良い）のは
jQueryってだけのこと

2019/02/16(土) 01:47:37.10

DOM要素の追加削除とCSSの表示切り替えって役割が違わね？

2019/02/16(土) 01:49:25.92

CSSの表示切り替えは既に存在する要素に対して行うのに対してDOM要素の追加は動的に要素を追加するためにやるもんだと思うんだが。
この2つは比べるべきものなの？

2019/02/16(土) 01:59:26.44

スレタイの3つとかはSPAのような高性能なブラウザアプリを作成するものでしょ。例えばofficeとかslackとか。CSSの切り替えだけでいけるの？

2019/02/16(土) 02:11:14.67

相手せんでええよキチガイだから。

2019/02/16(土) 04:00:16.99

>>354
難しいというより学習コストが高い＝最低限として覚えなきゃいけない事が多い
その反面必要な機能をサードパーティーから探してくる必要性がかなり低い

2019/02/16(土) 04:05:31.34

>>379
普通にUIとして使う分にはそんなに気になるほどの事でもないけど
Canvasに連続的に描画とか行う場合はダイレクトにその遅さが目立つってくらいかな

2019/02/16(土) 06:51:31.57

早いからじゃなくて便利だからjQueryを使うんだろ。なんで今更速度の話になってんの？

2019/02/16(土) 07:10:24.28

最近ブラウザでWebRTCとかやるのもわりとあるケースだし遅いってのは無視できない問題でもあるよ

2019/02/16(土) 07:20:20.26

>>403
jQueryは仮想DOM操作より早いと信者が言い出したから。

2019/02/16(土) 08:04:12.49

>>405
デマ乙

>>330を見れば分かるが仮想DOMよりも
classの変更で表示・非表示の切り替えをしたほうが速いって言ってる

2019/02/16(土) 08:58:01.91

もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？
それが仮想DOMより速くてもどうしようもなくないか？役割が違うんだから。
なんか自分の間違いを認めたくないから無理やり話をすり替えようとしてるようにしか見えないんだが…

2019/02/16(土) 09:01:46.50

>>406
仮想DOMだって属性の値にしか差分がないことがわかったらそれだけ反映するようにはできるだろ。
これなんかわかりやすい。
https://kuroeveryday.blogspot.com/2018/11/how-to-create-virtual-dom-framework.html

2019/02/16(土) 11:06:01.11

スレタイから逸脱しすぎてると思ったらjQueryと比較してる奴がいるのか。。もう何年も前に通り過ぎた話題だぞ。前見ようぜ。

2019/02/16(土) 11:13:52.65

ReactとかVueすら使えない超低レベルなクソジジイが騒いでるだけだから

2019/02/16(土) 11:14:50.85

>>407
> もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？

要素の追加削除の代わりに見た目を変更するっていうのは、
単に要素を追加削除するコストだけではなく
イベントハンドラの設定のコストも減らせる

もともとjQueryはデリゲートが簡単にできるから、要素が増えたり減ったりしても
イベントハンドラは最初に一回だけ設定すれば良いんだが、
それを使わなくても例えば要素のonclick属性とかに直接やる場合でも
要素が追加したときに新たにイベントハンドラを設定しなくてすむ

仮想DOMではDOM操作を最適化して必要な場合だけ実行するが
速度の話をするならそもそもDOM操作自体を減らそうという発想にしたほうが良いと思う
要素ごとにイベントハンドラを設定するよりも、
要素の親に一つだけイベントハンドラ設定したほうがいいわけだし

2019/02/16(土) 11:35:47.92

こっちでやったら？

Webフロントエンドで脱jQueryを目指すスレ
https://mevius.5ch.net/test/read.cgi/tech/1547896353/

2019/02/16(土) 11:38:28.40

使える使えないと使う使わないは別のこと
jQueryが殆どの場合最適解でSPAが勝てる領域はかなり狭いという事実を見失っちゃいかん

2019/02/16(土) 11:41:22.10

SPA、シングルページアプリケーションであって
シングルページウェブサイトじゃないからな

アプリケーションの時点で、ならネイティブアプリにしろよって
言われる時代

2019/02/16(土) 11:52:58.50

勝手にそんな時代を作るな

2019/02/16(土) 11:56:31.80

まぁ正直フレームワークは知らなくてもいいかも知れんがNodeを知らないと確実に困る時代にはなってくると思う

2019/02/16(土) 12:00:35.69

ネイティヴアプリは環境差異とデプロイメントがめんどくさいんだよね
dockerがGUIをサポートしてくれたら乗り気になるかもしれんがな

2019/02/16(土) 12:09:05.56

>>417
それはウェブでも変わらん。カメラ使おうと思ったら
ブラウザごとに使うAPIは違うし、端末ごとに対応してる
解像度も違うし散々だったぞ

dockerってLinuxの話してる？それならSnapsやFlatpakなどが登場してる。
Dockerはあくまで開発者向けで自分で作ったアプリをデプロイするときに使うもの。

一般ユーザー向けにアプリを配布するならSnapsなどを使う
GUI対応でディストリ非依存のパッケージ管理システム

2019/02/16(土) 12:16:07.61

>>417
ネイティブの面倒なところはそこよりも
OSの差異で動かなくなったりするところだな特にiOSとか

2019/02/16(土) 12:19:58.87

>>418
Snapsってdockerのように依存関係や実行時の環境もカプセル化してくれんの？

2019/02/16(土) 12:34:18.62

>>419
その差異をブラウザは吸収できないんだよね
だからみんなネイティブアプリにする

2019/02/16(土) 12:41:53.08

みんなって誰だよ
勝手に決めるな