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

**デフォルトの名無しさん** (ｱﾒ 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

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

2019/02/16(土) 12:43:59.75

>>411
具体例をお伝えした方がいいのだろうか？
例えばサーバーのDBに対して検索かけてとってきた要素を並べてコンテンツだすとかclassだけでなんとかなるの？
そもそも要素を出したし消したりでなんとかなるような簡単なものにReactとか使わないものじゃね？

2019/02/16(土) 12:47:43.95

サービス提供する側としてはネイティブよりSPAの方がよいケースはままあるでしょ。
例えばインストーラーが不要、そもそも技術者がいない、今までの資産をそのまま流用できる、とかとか。
ハードを限定しないソフトウェアの提供形態って殆どの場合は都合できまるもんだと思う。

2019/02/16(土) 12:50:25.75

ネイティブはストアにリリースすんのがイチイチめんどくさい

2019/02/16(土) 13:05:39.77

jqueryしか使えない無能の自己紹介はいらん
消えろカスジジイ

2019/02/16(土) 13:13:23.51

Angular習得した後にjQueryで書かれたコード見たら吐き気がしてくるわ。

「こんなコードわざわざ書かなくても取ってきたデータバインディングすりゃ良いのに」って思う箇所が多々ある…。

まぁ、古いブラウザでも動くようにしなきゃならないからjQuery使ってんだけどね。

2019/02/16(土) 13:19:34.25

>>427
Windows7のサポートが切れればなぁ

2019/02/16(土) 14:02:04.13

>>427
お前が書くコードがクソなだけｗ

2019/02/16(土) 16:10:27.79

>>428
サポート切れてても「壊れてないから」とか「投資できる余裕がない」とか「基幹システムが新しいOSに対応していないから」って理由で
古いOSと機械を使い続ける客もいるんだよなぁ。あんまりよろしくは無いんだけど。

>>429
jQueryベースでデータバインディングみたいなコード書けるん？
書けるなら書き方教えてくれや。こちとら嫌々でもjQueryとは付き合っていかなきゃなんねーんだよ。

2019/02/16(土) 16:16:01.06

イベント使え

2019/02/16(土) 17:30:33.50

>>430
使ったことないが、backboneやKnockoutやらのIE7でも動くライブラリ使ってみれば？ただ今更勉強する意義を考えると辛いなあ。。

2019/02/16(土) 18:08:11.34

旧ブラウザサポートはお高くなりますよ？
これでほとんどの客が黙る

2019/02/16(土) 19:11:18.01

やっすい案件ほどクソ要求してきやがる。

2019/02/16(土) 19:38:01.61

>>430
少なくともイントラではなグローバルサイトではサポート切れたOSの対応は打ち切っていいだろ

2019/02/16(土) 19:40:47.09

Androidだとサポート切れといっていいOSはどれ？

2019/02/16(土) 20:08:25.91

>>433
最新バージョンのreact使ってるけどIE11で問題なく動作しとる

2019/02/16(土) 21:03:12.87

正直互換性の点ではIE11よりもEdgeの方が癖があるんだよね
まぁEdgeもChromiumベースになる計画があるらしいしEdgeのChromium化とWindows7のサポート打ち切りが来ればパブリックサイトは随分シンプルになるんじゃないかと思う

2019/02/16(土) 22:09:54.11

chromiumになってもなんかしらイレギュラーがありそう
信用できない

2019/02/17(日) 08:20:58.26

フロントエンドなんてそんなもんだとしか言いようがない。

2019/02/17(日) 09:26:47.38

逆に言えば進化の余地ありありと言うこと。でもフレームワーク競争もひと段落して数年は安定じゃないかな。ブラウザもChromiumとSafariに収束されつつあるし。あとはiOS safariにpush通知実装されればなあ。

2019/02/17(日) 09:30:51.46

プログラマには、Apple機がなくなった方が楽になると思われている。
IEが消滅して言ったのと同じ状況がApple機に対しても起きつつあると思う。
iPhoneは売れなくなった。

2019/02/17(日) 09:44:50.06

フロントエンドは端末とブラウザの進化の影響をもろに受けるからねぇ…。

クロスプラットフォームの分野でも、SPAが技術的に枯れる前にどんどん新しいフレームワーク出て来るからな。最近だとFlutterとか。

SPAだけでも選択肢多いのに、xamarinだのcordovaだのFlutterだのと。
こっちとしては「クロスプラットフォームアプリ開発するなら結局どれ選べばいいんだよ」的な状態だわ。

2019/02/17(日) 09:48:46.68

結局、大きい組織が作ったものを使っていくようになるんだろう。

2019/02/17(日) 09:49:49.70

Apple機さえ無視すれば、プログラミングが色々便利になる。

2019/02/17(日) 10:25:00.47

>>443
どれでもいい
フロントは使い捨て
簡単に乗り換えできるようにビジネスロジックと疎結合に作る
そこだけ死守すればなにを使ってもいい

2019/02/17(日) 10:44:59.94

cordova使うならIonicでいいんじゃない？
最近はAngularだけじゃなくVueにも対応したらしいし
そういやReactNativeにもVue版出てたな