Vue vs React vs Angular
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん?
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 逆って今WebComponentがないのに
今WebComponentを使ってるわけ無いだろ 結局ピュアjavascriptを真面目に身につければOK? どうせwpだろwww
railsが使われてるからrubyが死にきれないのと似たようなもんwww だから「本当にやりたいこと=WordPressでできる範囲のこと」なんだから
フレームワークもいらんし、どうせjQuery使われてるからjQueryでいいってことなんだよ 需要と供給
いくらすごいことができるようになっても
求められてないんだよ。 間違ってないと思うがなぜwpのスレに籠らずこんなスレ来て啓蒙活動してるのかw
他人が勉強するのが不安で怖いんだろ?ww
そんな女の腐ったようなセコい性格だからいつまでたっても童貞なんだよwww 論理に破綻はないが?wp圧倒してるの事実だし。現状に安穏としたいならしてれば?俺らは勉強するから、ってこと。図星刺されて恥ずかしくなっちゃったのかなw
お前のやってることってテストの前に勉強してるやつをガリ勉・ダサいとレッテルはって集団でみんなで堕落しようとセコい行動する女みたいなんだよw
男でそれじゃダメだよ。 angularは勧めんな。railsもそうだがああいう丸ごと全部なものになれると
それ以外なんもできなくなる。 wpしか使えない底辺カスは死ぬまでjquery使ってろ >>319
> 論理に破綻はないが?wp圧倒してるの事実だし。
wp圧倒してるの事実である根拠は?
事実だとしてそれがjQueryにどれだけ影響してるの?
wpのシェアなんてウェブ全体からすればたいしたことないじゃない 新しいフロントフレームワークが出た時に丸ごとすげ替えれるならなんでもいいよ
俺はMVCがベストバランスの正解だと思うがね backboneを勉強した人は無駄になった。
Angularも1系を勉強した人は無駄になった。
jQueryは登場してから13年使われ続けている。
これが現実やで wpの保守死ぬほど大変だけどな。てかフレームワークとwpは全く別物だろうよ。ブログのフレームワークと言えない事も無いが。 >>322
ビルトインされてるよ。テーマによってはwpビルトイン版と競合を避けるため他のバージョンを別に導入する場合もある。
そしてwpのシェアはcms中では60%、全Web中では33%
だからwp除くならjQueryは40%程度だなw > だからwp除くならjQueryは40%程度だなw
圧倒的シェアじゃないか! 最初からシェア小さいとは言ってないだろw
増加してるのはwpのシェア増につられてだろうと予測しただけ。
おそらく合ってるなw
jQueryバカが威張るのは滑稽。 jqueryしか使えないバカが多い
バカのくせにバカを賛美している 所で仮想DOMのアプローチって本当に速いのかな?
仮想DOMはDOMを触らないって言うけど、
結局最終的な形にするためにDOMを構築するでしょう?
そのときに要素を作ったり削除したり
そんな事しないで、CSS使って要素を隠したり表示したほうが速いない?
jQueryはDOM操作が得意なわけだけど、DOMを作ったり削除したりするんじゃなくて
classを変更して見た目を変えることで擬似的にDOMが表示されたり消えたりするって
いうのがベストプラクティスだと思ってる。この場合はDOMの構築をやらないので
仮想DOMのアプローチよりも速いんじゃない? cssのが早いのは当たり前だろ…
お前、こういうスレ来るのは10年早いよ。
真摯に勉強しろやマジで。スレタイ読まずに荒らしてないでさぁ 正直Reduxとか使うよりも、カスタムイベントを使ったほうが楽だと思う マジでお前来るなよ
スレチクソキチガイが
テメーの妄想なんかどうでもいいんだよ
勝手にjqueryスレ立ててそっちでやれバーカ >>304
そういう観点ならNuxtでもいいと思う 仕事でもnuxtつこてるわ
angularとreactは敷居が高め
他のメンバーが嫌がるのよ そういやVueでもjsx使えるとかVueの和書の一番厚い本に書いてあったな reactのために作ったってだけである種類の関数の入れ子をxml風に記述できるというだけの独立した仕組みだからreact関係なく使えるよ。 >>337
そうなのか。興味湧いてきたのでちょっとNuxt試してみます。 ReactやVueやる奴らは当たり前だがフロントデザインやUXできるんだよな? >>330
仮想domのメリットは最終的にはリアクティブ。その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、リアクティブでは単に変数をfalseするだけになる。
複雑な入力フォームも恐ろしく作りやすくなるから、一度vueの公式見るといい。 勉強しなくていい言い訳探しに来てる奴に何言ってもムダ >>344
> その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、
あー、それがお前の根本的な間違いなんだよ。
お前っていうか、世間一般?使い方間違えてるんだよね。
そういうDOM操作なんてしません。
jQueryでは単にHTMLのclassの(例えば)activeをdeactiveにするだけになる。
複雑な入力フォームも作れるし、classを変えるだけで全く違った表示にすることができる
そのフォームを使ってる間JavaScriptは全く使用しない。
デザイナが自由に好きなデザインで作ることができる。
そしてjQueryではclassの値を変えるだけになる。 jQueryのhideはdisplay: noneだろ。
active、deactive(笑)に至っては意味不明。
jQueryではそういうときはactiveクラスをtoggleClassで付けたりはずしたりするんであって、active外してdeactive(笑)つける、deactive(笑)外してactive付ける、なんてマヌケなことはしません。
やっぱりね、自分が勉強したくないもんだから他人の足を引っ張ろうとするような女の腐ったような童貞は自分が上げてるライブラリもまともに使いこなせないwwミジメ過ぎwwwww jQueryからreactならそこまで乗り換えコストかからんと思うけどな。 >>348
ん?お前俺が言ったことと大差ないよな?
activeクラスを 付けるor 外す ことで表示の切り替えを行うから
そんなことでDOM操作なんてしないってことだろ?
でそれが>>330で書いたことにつながるんだよ。
仮想DOMは最終的にDOM操作をするから遅くなるが、
jQueryではCSSによって見た目を切り替えるだけだから速いってこと >>352
そりゃVueやReactだって最終的にはDOM APIを通じて操作するよ
ただしその操作の内容を、DOM要素の削除や追加じゃなくて
クラス名を変えて表示を切り替えるだけにすると速いってこと Angularの方が難しいの? Reactの方が自由に構成決めたりコーディングしたり出来る分、
自分で決めなきゃいけない事が多くなって逆に難易度高いって聞いたけど。
Angularの方が環境構築も規約も全部世話してくれるから楽だって聞いたからAngularから入ったんだけど。もしかして騙された? >>354
英語などの単語の暗記が得意だったならangular
数学が得意だったならreact さすがjQueryバカ。伊達に名前にバカって付いてないな。
クラスの付け外しも厳然たるDOM操作。
そんなことも分からないとは…使われるjQueryもかわいそうだ。 そもそもjQueryのコア機能はDOM操作なんだが…
DOM操作しないならjQuery要らねーよ。
贔屓のライブラリの存在理由否定してどうする。 >>357
DOM操作のうち、class属性を変えるだけにするということ
そしてCSSでブラウザにネイティブ処理させるから速いんだよ
要素の追加や削除は必要最小限にするのが鉄則 >>354
自分がやりたいことと、フレームワークが提供してくれる機能とのバランスだよ
業務アプリみたいに複雑なインターフェースのアプリをガッツリと大量(=画面数が多い)に
作らなきゃいけないならAngularがいいだろうけど、そうでもないなら
Reactで適当にデータ管理してやれば楽ってこと
Angularはいろんなことを面倒見てるけど、そこまでやることないじゃん?って思うならReact
更に言うならウェブサイトみたいなものはjQueryで十分ってこと > ネイティブ処理させるから速いんだよ
だったらネイティブのDOM API使うわw
You Don't Need jQuery!
https://blog.garstasio.com/you-dont-need-jquery/dom-manipulation/ >>360
それもバランスの問題だな。
そこ見ても分かるだろ?いずれの例もjQueryの方が短く書けている
開発効率の高さがあるからjQueryのほうが良い訳 フレームワークの欠点は単純なウェブサイトでは
生産性を落とすという大きな問題があるってこと ついでだから、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';
} DOMにノードを追加すると、DOM APIと直接対話するVanillaを1回呼び出すだけで済みますが、jQueryは多くの操作を実行します(スタックが長すぎて画像に収まりません)。違いは明らかです。
Vanilla:4ミリ秒
jQuery:95.3ミリ秒
Vanilla Javascriptは、追加時のjQueryよりも約25倍高速です。 >>367
いや、だからそんなことをしないで、クラスの書き換えだけを
やることで高速化できるって言ってるんだよ
話ついてきてね >>359
使い分けって言いながらフレームワーク要らないって言うから意味不明になるんだよ
「自分の仕事では」要らないって話だろ? 削除はともかく、追加がクラスの書き換えだけの訳ないわな。その書き換える対象がまだ無いんだから。 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倍もコード容量かけて何やってんのwwwww ボコボコでワロタw
我が物顔でスレチ荒らしするからこうなるww >>372
じゃあnano使えば良いんじゃないですか?
フレームワークよりも大幅に小さいし ウェブサイトではフレームワークは重すぎで生産性を下げるという
大きな問題があるが、jQueryやnanoはDOM APIの冗長性を省くだけだから
生産性は上がるしか無いというのが大きなメリットなんだよ まあjQueryがいらないのは確かだね。
要素のstyle操作程度ならなおさらね。
「DOM操作しない方がいい」って言ってたし、じゃあDOM操作ライブラリのjQueryはいらないねw
え、やっぱりDOM操作したい?そして短く書きたいって?
100倍軽いnanoがあるよw そういやzeptoとかもあったけど、
今までの経験上、軽いだけの代替ライブラリは
結局本家を超えることって無いんだよな
nanoが普及すると良いね すまん、ガチで話についていけてないんだが、>>351でjQueryは速いって書いてあるからjQueryは速いのか!って思ってたんだけど結局遅いの? GitHubがjQuery辞めたので https://ushirock.hateblo.jp/entry/2018/07/28/013507
jQuery が DOM 操作の際に eval() を多用しているため CSP を safe モードで使えないらしい
これは jQuery の核になる部分の仕様らしく、 .html() はどんな時でも任意のコードを実行する可能性があると
やっぱり jQuery といえば Sizzle でのセレクタ解析が遅いとか(querySelectorが使える場合優先されるらしい)ネイティブへの置き換えとかに目が行きがちだけどもこういう深い話でのデメリットもあるんだなと >>379
jQueryが速いなんて言ってないんだが?
ファイルサイズではフレームワークよりも小さいから
初回ダウンロードは速いだろうけど。
速いって言う話はDOM操作で要素を消したり作ったりするよりも
classを変更するだけにしてCSSで表示したり見えなくしたりするほうが
速いだろうってこと。 jQuery。それは、
・遅い
・重い
・アンセキュア
なDOM操作ライブラリ。 jQueryを使うのって、速さ云々より一つのコードがどんな環境でも同じ様に動くって所なんじゃないの?
ブラウザの種類やバージョンでJavascriptの挙動の違いがあるから、それを吸収する為にjQueryを使うんじゃない? >>381
はっきり言ってjQueryが遅いとは思わない
熟練した人が地道に管理すれば十分速い
それが手間じゃねぇの?ってのがフレームワークの意義 >>384
jQueryってDOM APIを使ってるだけなのに
なんでアンセキュアになるの? >>383
そうか、なんかすまん。
>仮想DOMは最終的にDOM操作をするから遅くなるが、
>jQueryではCSSによって見た目を切り替えるだけだから速いってこと
この部分読んで仮想DOMは遅くてjQueryは速いのか!って解釈しちゃったんだが仮想DOMに比べて速いだけでjQueryも速くないんだな。 >>387
>>367の結果だけ見ると遅すぎ(10回やると1秒!?)って思っちゃったんだが……
webは基本的には静的コンテンツだから気にならない世界なのかな。
とりあえず俺にはこのスレの会話を理解する能力が足りないっぽい。 まあ1つの処理に4ミリ秒って時点で衝撃的な遅さだしweb開発の世界はそんなもんなのか。 vue.jsが
やたらめってら、もてハヤサれる昨今だけど
ぶっちゃ毛v-forが仕様としてオワッテると思うわ。
それとuidの生成パターンをC言語なら「ポインターが理解でないワケ」や
「ポインター徹底攻略」、、、JAVAならデザイパターン本みたいな
分厚い本で説明しなきゃ
いけないのに、それを全くやってないよな。
俺が考えるvue.jsが広まらないワケだよ。コンポーネントをどうユーザーが
受けとるべきかも、簡単な再帰などを使ってイラストレートしなきゃいけないのに
これも全くやってない。細々としたシステムは売り込んでるけど
vueの長所が全くされてない 早い遅いじゃなくて開発効率の話だろ。domを直接指定して操作云々はもう止める、最小限にするて事。今後確実にそうなるのは皆分かってると思うが。 実行速度の話をしてる人たちに、いきなり開発効率の話をしだすのは草。なんの関係もないじゃんw 実行速度については、DOM要素を作成したり削除したりするよりも
CSSで表示したり隠したりしたほうが速いんじゃないかってだけのこと
それをやるにはVue/React/AngularよりもjQueryの方が楽ってこと
DOM操作がネイティブよりも速いなんて話はしてない。
CSSによる表示切り替えの方が速いって話をしてる。
そのCSSによる表示切り替えを楽にやる(開発効率が良い)のは
jQueryってだけのこと DOM要素の追加削除とCSSの表示切り替えって役割が違わね? CSSの表示切り替えは既に存在する要素に対して行うのに対してDOM要素の追加は動的に要素を追加するためにやるもんだと思うんだが。
この2つは比べるべきものなの? スレタイの3つとかはSPAのような高性能なブラウザアプリを作成するものでしょ。例えばofficeとかslackとか。CSSの切り替えだけでいけるの? >>354
難しいというより学習コストが高い=最低限として覚えなきゃいけない事が多い
その反面必要な機能をサードパーティーから探してくる必要性がかなり低い >>379
普通にUIとして使う分にはそんなに気になるほどの事でもないけど
Canvasに連続的に描画とか行う場合はダイレクトにその遅さが目立つってくらいかな 早いからじゃなくて便利だからjQueryを使うんだろ。なんで今更速度の話になってんの? 最近ブラウザでWebRTCとかやるのもわりとあるケースだし遅いってのは無視できない問題でもあるよ >>403
jQueryは仮想DOM操作より早いと信者が言い出したから。 >>405
デマ乙
>>330を見れば分かるが仮想DOMよりも
classの変更で表示・非表示の切り替えをしたほうが速いって言ってる もう一度聞くけど、classの変更でできることって限られてるでしょ?見た目の操作だけかな?
それが仮想DOMより速くてもどうしようもなくないか?役割が違うんだから。
なんか自分の間違いを認めたくないから無理やり話をすり替えようとしてるようにしか見えないんだが… スレタイから逸脱しすぎてると思ったらjQueryと比較してる奴がいるのか。。もう何年も前に通り過ぎた話題だぞ。前見ようぜ。 ■ このスレッドは過去ログ倉庫に格納されています