Vue vs React vs Angular Part.5
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.4
https://mevius.5ch.net/test/read.cgi/tech/1591869705/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Svelte, Next, Nuxt, Gatsby, VuePress, RedWoodなどはおｋ。 例えば、アロー関数なんて使わなくても
this保存してfunctionつければ同じことができるけど
アロー関数使わなくて良い世界を知ったら元に戻れないだろ？
ほんの数行の違いでもないほうが楽なんだよ まさかjQueryマンセーで愚かな考えを晒すことで周りから袋叩きされる
ということを通してjQueryを貶めるという作戦か そんな願望垂れ流してないで
メリットとデメリットの話をしろよ
jQueryがなくても頑張れるっていうだけで
jQueryをなくすメリットを言わないんだもんなｗ ハァ？jQueryバカはCSSセレクタ丸パクリのクセして自分の手柄にしてんのか。チョンみてーだな(藁 jQueryバカが言ってるメリットはどれも小粒
なくても困らない
なら最初から利用しなければ余計なファイルを削減できる
というのが使わないメリット >>753
もともとJavaScriptでCSSセレクタは使えなかった。
今は単に「セレクタ」というんだが、お前が言ってるように「"CSS"セレクタ」という
言葉があるのは、元々はCSSで使うものだったときの名残ｗ
はるか昔にjQueryがJavaScrpitでCSSセレクタを実装した
その素晴らしい発想を見て、それをあとからDOM APIに
querySelectorとして使えるようにした
パクったのはDOM APIの方。それを知ってて
お前わざと>>753みたいなアホ丸出しのレスしただろ？ｗ
しかしDOM APIがパクったのはセレクタAPIだけで
jQueryオブジェクトはパクらなかったので
DOM APIのループ処理で繰り返すという手続き的なAPIは変わらなかった
宣言的なjQueryの比べれば劣化コピーでしかない 余計なファイルを削減できる？
JavaScript使ってる時点で外部JavaScriptファイルがある
たかだか1ファイル減るだけの話
しかも結合すれば1ファイルですむ jQueryとかメリットなんて微々たるものなのにレガシーブラウザ対応とかで
無駄にサイズがでかいからな
減らす効果はそれなりにあるぞ 余計なファイルを削減できるというメリットは小粒
初回アクセス時に30KB読み込みができるというメリットは小粒
JavaScript処理が僅かに早く終るというメリットは小粒
jQueryをなくしたときのメリットはどれも小粒ではないか
体感上わからない程度の遅延があっても困らない
ならできる限り開発を楽にするほうがいい
というのがメリット >>757
圧縮時30KBはものすごく小さいですが？ 例えばGoogleのシンプルな検索トップページは圧縮状態で65KBでした。 jQueryを利用するメリットがそもそも小粒
ブラウザごとの分岐処理とかが埋め込まれてるから実行時の効率が悪い
ファイルサイズがでかい
つまりいらない jQueryのメリットのうち小粒のものだけを抜き出したら
全部小粒だった
と言ってるのと同じだなｗ >>755
中学校を単に学校というって言ってるみたいなもんだな。バカが。
CSSのセレクタのルールそのままパクっただけの盗人。
盗んだものをもともと自分のだと主張。まさにチョン。 jQueryの価値はjQueryオブジェクトだよ
CSSセレクタなんか、素の使いづらいJavaScriptでもできるじゃんｗ
価値がないところだけを見て価値がないと言っても無意味だよ
もっと広い目でjQueryを見ないとｗｗｗ このjQueryバカは素人レベルのスキルしかなさそう しょぼいWebページをjQueryで作ってご満悦なんだろう いい年こいたおっさんがjQueryにすがりついてるとかダサすぎるんだよ ほらね、もう遠吠えいうことしかできなくなったでしょ？ CSSセレクタパクリがバレたら開き直ったjQueryガイジ。
居直り強盗で駅前一等地を占拠してパチンコで儲けるチョンと同じ。
jQuery関係ないスレで居直り占拠jQueryチョン。 おっと
>>1 に
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
と書いてあったな >>770
なんで無視したの？もう一回同じことを書く羽目になったじゃないか
もともとJavaScriptでCSSセレクタは使えなかった。
今は単に「セレクタ」というんだが、お前が言ってるように「"CSS"セレクタ」という
言葉があるのは、元々はCSSで使うものだったときの名残ｗ
はるか昔にjQueryがJavaScrpitでCSSセレクタを実装した
その素晴らしい発想を見て、それをあとからDOM APIに
querySelectorとして使えるようにした
パクったのはDOM APIの方。それを知ってて
お前わざと>>753みたいなアホ丸出しのレスしただろ？ｗ
しかしDOM APIがパクったのはセレクタAPIだけで
jQueryオブジェクトはパクらなかったので
DOM APIのループ処理で繰り返すという手続き的なAPIは変わらなかった
宣言的なjQueryの比べれば劣化コピーでしかない 言葉で説明されてもメリットわからんな。どうせ議論するならコード書け。 言い出しっぺとして書くけど、これを数文字短くするためにjQuery使うか？
document.querySelectorAll('div.highlighted')
.forEach(ele=> Object.assign(ele.style, {color: 'red', backgroundColor: 'white'})) document.querySelectorAll('div.highlighted').forEach(ele=> Object.assign(ele.style, {color: 'red', backgroundColor: 'white'}))
$('div.highlighted').css({color: 'red', backgroundColor: 'white'});
一行のものはだいたい半分になる。
だがそれよりも重要なのは「宣言的」であるということ
forEachというループが無くなっている 無いとなんかすごいのか？
jQueryが裏で回してるだけじゃん >>776
jQueryが裏で回す（十分テスト済み）＝自分でやらないからバグが減る jQueryとレビューする点を見れば
どちらが大変かなんて明らかなのよ
document
querySelectorAll → $
('div.highlighted') → ('div.highlighted')
forEach(
ele=>
Object
assign(
ele.style, → css
{color: 'red', backgroundColor: 'white'})) → ({color: 'red', backgroundColor: 'white'});
jQueryだと4箇所見るだけですむが、DOM APIだと 9箇所もある コードの意図を隠してまで短くすることか？
その時点で要素があるべきなのか複数なのか何も判らん
エラーが出ない=バグがないってことならいいが >>739
こいつ結局Webサイトの話しかできてねえな
アホだろ
>>750
こいつやはりアホだ
アロー関数がfunctionの代用だと勘違いしてる
その認識でほんの数行変えたらバグるわけ
そもそも仕様がまったく違う >>780
どこにアロー関数がfunctionの代用って書いてある？よく読んでみなよｗ >>779
隠しているのはコードの詳細であって
詳細を隠してるから意図は明確になってる >>739
Web Componentsは流行らんと思うよ正直
こんな移り変わりの激しいWeb技術の世界で3年以上前から話題が上がってるにも関わらず未だに流行りにもなってないっていうのはそういう事だろ
Recoidなんて登場してから殆ど経ってないのにもうReduxを抜きつつある
Web Componentsが本当に良いものならそういう速度感で流行るもんだ
現時点で流行ってないっていうのは結局D言語みたいなものにしかならない WebAssemblyに関してはWebGPUが今後流行ったら多少チャンスはあるかも知れんがそれ以外の用途では望みは薄そうだな Ruby, jQuery は、メソッドチェーンで関数型のように書ける。
a().b().c() みたいに
これを一々、存在チェックしてられない
return if obj = a() == nil
return if obj = obj.b() == nil
obj.c() WebAssemblyはこれからの技術
MS以外がまだまともなframeworkだしてない
JSが好きという人は少ないので必ず流行る
>>786
CPU速くなったらwasmの弱点が消えて長所だけが残るから
wasmはだんだん増えていく > CPU速くなったらwasmの弱点が消えて長所だけが残るから
> wasmはだんだん増えていく
そこに目的がありません
速くなったら使われると思うのはなぜか？
ウェブアプリが作れるようになったら、みんなウェブアプリを作ると思うのはなぜか？
目的がなければ、使うようにも作るようにもならない 劣ってるから使われないって思うのは
技術者のよくある勘違いだよなｗ
そもそも需要がなければ使われないんだよ 不都合な真実、ほとんどの人がwasmを試してすらいない。遅いなんて言ってる人全然いないだろ？ https://classic.minecraft.net/
babylon.js製。
安定して60fpsで動くが、babylon.jsにはWebAssemblyは一切使われていない。 >>789
JSに縛られず開発生産性高い言語を使える
それだけでwasmを使う理由になる × JSに縛られず
○ もとからJS使わない人が使う
だからウェブ系の人は使わないし
JS使わないならネイティブアプリでいいんじゃね？ってなるんだよなｗ >>794
native appだけでいいってのは技術的にはそのとおり
wasmは中途半端な立ち位置だからな
ただApple, Googleで手数料30%取られるだろう？
wasmだとその手数料を回避できるから
そういうビジネスの問題考えたら価値がすごくあるわけ 結局ブラウザから排除されてるJavaAppletやFlashPlayerとWebAssemblyに違いなんとほぼないんだよな >>794
JSについては違う
Blazorのようなのが人気でてくると
JSしかできないフロントエンジニアの存在が不必要になる
C#プログラマーはserver sideとclient sideの両方のコードがかける
JSが必須ではなくなるということは
JSエンジニアが必要なくなる時代ってことだ >>796
まったく違う、わかってない
Sandboxあるからセキュリティが高い
さらにwasmはweb standard Web Components はとても素晴らしいけど、けっこう面倒くさい。でもライブラリとかはバックグラウンドにガリガリ使うようになって間接的に役立つだろうし、なんなら関数でラップしても良い wasmでjsが消えてもDOMは残る。フレームワーク使えば別だけど、DOMから離れようとすれば遅くなり、wasmの速さは失われる wasm＆SPAは業務系の希望になりうると思うが
業務系の複雑なUIはSPAと相性がいい
業務系エンジニアなら誰でも使えるJavaやC#がフロントでも使えたら学習コストが下がる
サーバーとクライアントでロジックを共有すればコストが下がる >>797
> Blazorのようなのが人気でてくると
前提崩れだね。
十年で日本を追い抜く言ってた朝鮮はどうなりましたか？ｗｗｗ
Silverlightｗｗｗｗ なんだよまたjQueryでスレ伸びてるのか。
クライアントがブラウザである以上、jsやcss,domに原則縛られるんだよ。あとは如何に効率よくラップするかの差でしかない。好きなもの選べばいいさ。
ただ未だに生のjsやcssで組んでるやつは流石に時代遅れと自覚して欲しい。 >>803
BrowserはいまだにJSに縛られると思ってるやつは流石に時代遅れと自覚して欲しい
Blazor WebAssembly使い始めたがC#だけで書けるし
Visual Studioで開発できるし最高だわ >>804
期待してるけどツールがまだ追いついてなくて….razorファイルのフォーマットが崩れる問題くらいはさすがに修正してくれないと。
まあ現状はスレチなので。 Blazorはまあまあ悪くないけどソースコード編集してから画面に反映されるまでが遅いのがネックだね >>804
それは違うなだろう。
ラップしてるだけ、意識しないだけで最終的にブラウザが対応してる要素に縛られるのは変わらん。スマホアプリとは全く違う。
フレームワークの進化に対して実行エンジンであるブラウザの進化が遅すぎるんだよな。今でもsafariだけcssの解釈が違うなんてしょっちゅうだし、土台部分の知識が無いと結局対応できん。チグハグで不安定なのがフロントの宿命なんだよ。
だから各フレームワーク、IDEには本当に感謝してる。裏でとんでもない労力かけて俺たちの労力軽減してくれて有り難うだよな。 5GとかiphoneとかRetinaみたいな余計なことして
業界混乱させる前にやるべき事やれや
まずまともなブラウザ提供しろ
さもなくばデフォのブラウザ大人しくchromeにしとけ >>808
自分が読み書きするコードがC#ならそれでいいでしょ
どんな言語も実行前には人間が読めない形になる web componentは流行るかどうかはさておき、必然的に使う場面が出てくると思う。
今後はマイクロサービスと同様にその技術がフロントにも流れてきてマイクロフロントエンドアーキテクチャが主流になると思う。
そうなると、サービス単位で共通なコンポーネントはweb標準であるweb componentで作る必要が出てくる。
どうだろうか jquery別に悪くないけど、今はvanilla jsで十分だし使う場面がない。
モダンフレームワーク（react,vue,etc）vs jqueryという構図をこのスレでは良くみるが意味がわからん。
正しく議論されるべきは
モダンフレーム vs web標準（web componentなど）
だと思う。 オライリーから出てるCSSシークレット著者によるWeb Components評。
ちょっと辛辣。コメント欄で議論盛り上がってるがここChrome翻訳効かないのな…
https://lea.verou.me/2020/09/the-failed-promise-of-web-components/ Web Componentsに対する批判
https://thenewobjective.com/web-development/a-criticism-of-web-components
・CSS疑似セレクターが機能しない
・ネイティブ要素と互換性がない
・Non-trivialな要素はHTMLElementを継承する必要がある
・JavaScriptが必要
・潜在的に指数関数的なフォールバック
・ポリフィルが必要
・Ariaの問題
・SEOの問題
・追加の制限 俺の頭が悪いせいかこの記事の言いたいことがいまいちわからん
plug and playの箇所解説よろ >>815
ｼｨｰｯ! (jqueryバカがよってくるから) >>814
流行らんよ
マイクロサービスはトレードオフ >>817
後で読んでみるけど、
ariaとJavaScript以外は別に問題じゃない気がするけどね web非標準のreactが簡単にssr出来るのにweb標準のweb componentsが事実上無理（初期レンダリングコストはクライアント側で支払うしかない）なのはなんだかなぁ… >>817
templateタグともっと親和性を高めるとかHTMLだけでComponent作れるとやりやすいよなと思う >>825
やろうと思えばできるけどな。shadow domを使わない場合だけど。
でも言いたいことはわかる。そこまでサポートしてから世に放てば良かったのにとは思うけどね。
https://web.dev/declarative-shadow-dom/
↑いま頑張ってやってる途中やで Declarative Shadow DOM か。いいね。
試してみようと思ったらchromeでもまだオリジントライアル中か… やりたいことは理解してるんだけど
英語力がないから何がdeclarativeのニュアンスがわからん。 宣言的だろ？ ようはループを使わないってことだよ
例えばjQueryはループを使わない
$('.selector').css({color: 'red'); このように
これがDOM APIだとループが必要な手続き的になってしまう >>830
絶対に違うわww
宣言的＝ループを使わないが違うということは俺にもわかる 宣言的なweb component
現状のweb componentのどこが非宣言的で、あのリンク先の技術が適用されるとどこが宣言的になるんだろう。イマイチわからん。web componentにおける宣言的ってなんや UI組み立てる系のライブラリは固定乱数でいいから
全てのDOM要素にid振っとけや
色が違うとかアイコンを変えろとかクソみたいな指示飛んでくるんだから 宣言的な書き方に拘っても保守性なんて少しも良くならんわ。 SPAは簡単だったけどCSSがやっぱりわからねえんだわ
SPAで作ってもデザインが古くさくなる デザインなんてとりあえずBootstrapっぽくすればええんやろ？ >>833
乱数のid振ってどうすんだよ？
まさかidで色変えてんのか？
>>835
お前のセンスゼロだしこの先死ぬまでセンスゼロのままだからなあ
>>836
bootstrapっぽくすら不可能じゃん
>>837
センスゼロのやつは死ぬまでセンスゼロ
>>838
Googleが公式にセンスゼロ向けって謳ってるしな
ただしセンスゼロでcssスキルない奴が使うとMaterialUIすらまともに使えない センスゼロでもSPAはできるけど、CSSはそうもいかんからなぁ
センスゼロでも使えるライブラリを使うしかないか
逆に言えばライブラリ使えば、センスゼロでもCSS、SPA両方できるようになるわけだし、こだわり捨てればまあ、いいか
すぐに移り変わる分野だし、気楽にやろう MaterialUIなんて公式のサンプルコピペしてテーマ設定するだけでそんな酷くならんと思うが
これ以上のリッチなもの求めてて自分で勉強できないならデザイナー雇うしかない
色彩センスは今どき色選んでくれるサービスたくさんあるだろ
ttps://yumyumcolor.com/ とか MaterialUIとBootstrapは併用できるの？
混ぜるな危険？ material ui 重い…
軽量でいい感じのが欲しい この手のUIフレームワークは余白が多すぎて、1画面の情報量が少ない
スマホアプリ前提な感じ >>842
やろうと思えばできるが崩れる上にそもそもやるやつはアホでしかない
>>844
余白なんか調整すればいい
キツキツの帳票みたいなUIが好みという日本人が多いが世界中から笑われてんの未だに気づかない連中ばかりだからな 情報をギッシリ詰め込むのは別に構わないと思うが
ダッシュボードとかでよくある
しかしジジイどもは同じ画面で入力もやらせようとするからおかしくなる >>844
Vue もReact もAngular も
全く関係ない話だ スマホ向けのUIとPC向けのUIを同じテーマでやるのは無理ある
サイトリニューアルして昔あった機能や要素を削除して既存ユーザーから大反発食らうのがこのパターン ■ このスレッドは過去ログ倉庫に格納されています
