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などはおｋ。 >>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を同じテーマでやるのは無理ある
サイトリニューアルして昔あった機能や要素を削除して既存ユーザーから大反発食らうのがこのパターン >>850
結局SPAって1つか2つの問題を解決するために他の多くの問題を呼び込んでるんだよな >>850
vue.js で CRUD アプリを造りたいとか
発想そのものがあほやん
https://qiita.com/koduki/items/9ce6ad8787b32caa38ff
CRUD にしたいなら vue.js 使わなければ良いだけの話だろ >>852
だから
（殆どの用途には）vue.js 使わなければ良いだけの話だろ
と最初から言ってるだろｗ https://w3techs.com/technologies/history_overview/javascript_library/all/y
2020年10月15日 76.5%
2020年10月23日 76.6%
2020年10月25日 76.7%
な？だからjQueryが使われてるんだって
少なくとも10日で0.1%以上増えてるからな シンプルなアプリは開発者、利用者の両方の視点でMVCフレームワークの圧勝だろ
複雑なアプリになると開発者としてはSPAのほうが作りやすいが、、、
しかし利用者からすれば複雑なアプリの需要なんてのはほとんど無い等しい
例えばpgadminは複雑なアプリだがぶっちゃけシンプルなadminerのほうが使いやすいのだ
結論
SPAはゴミ 「脱jQuery」を目的にするとたいてい失敗する
なにか問題があって、それを解決するためにVue、React、Angularなどを採用すべきという
当たり前の前の話であって、良い選択肢の１つであるjQueryを廃止して
特定の用途専用のものを導入するのは愚かである
特定の用途専用のものは、特定の用途の場合に使うもので
「○○の用途のために○○を導入しました」という言い方にするべきだ ようするにUX設計ができない人のためのフレームワークがSPA 今までSPAのやり方でスマホアプリとか作ってきた人たちが
今までと同じやり方で作るためのものSPAだろう
ウェブにはウェブのやり方があるんだが
そういう（アプリ作ってひた人たちにとっては）"新しいやり方"を
学ぶ能力がなくて、今までと同じやり方でやりたいっていうのがSPA
これからはSPAだ〜とか言ってるやつは、jQueryどころかCSSも嫌いなはず
なぜならどちらも宣言的だから。SPAは手続き的に作る。
セレクタに対して処理や属性を宣言的に適用するjQueryやCSSは
考え方が根本的に違っていて、頭が凝り固まってる人には理解ができない 良い加減スレチ
くだらん話でスレ埋めるな
よそのスレか板いってくれ jQueryが増えてるってのは事実として
それ以上に増えれば、シェアはjQueryよりも増えるんだよ
結局増えてねーじゃんと jQueryとReactじゃ根本的に作るべき対象が違う うん。だから最初から根本的に作るべき対象が違うので
「脱jQuery」ありきは間違いだって言ってるわけ
作るべき対処がjQuery向きじゃない場合に使えば良いわけで
今までjQueryで問題なくやってきたところが脱jQueryするのは
意味がないどころか、デメリットになってるわけ
作るべき対象がjQuery向きなのに、脱jQueryしてどうするんだと フレームワークなんて概念がなかった時代にjQueryで無理やり作ったシステムとかならフレームワーク置き換えって結構意義はあるけどね
段階的な置き換えか一から再構成かは都度都度によるけど Ruby on Rails では、React, Bootstrap が多い。
Material-UI を使った場合は、レスポンシブ対応になるのかな？
react-bootstrap という、BootstrapをReactコンポーネントとして再構築した、UI フレームワークもある。
jQuery など不要な依存関係がない Rails, React, Bootstrap で、
Bootstrap 4 が、jQuery に依存しているから、使っているだけ
react-bootstrap など、jQueryに依存していない場合は、axios が多い >>854のシェアって公開されてない社内サイト/アプリやログイン必須アプリも含まれてるの？ ブラウザ毎に仕様が違った時代に重宝されたjqueryを未だに崇めてる奴は脳みそがそこで止まっているわけだ 脳みそが若いままプリプリってことだ。物覚えもいい。 >>872
脳が止まってるのはお前やで
未だにjQeryの便利さをブラウザの仕様の違いを
吸収するためのものだって思ってるんだろ？
jQueryすげー、DOM APIが簡潔に書けるーってみんなが思ってる中
ブラウザの違いを〜とか言ってて恥ずかしくないのか？ 未だにDOM直接イジってんのかｗ
おっさん哀れだなぁｗｗｗ ■ このスレッドは過去ログ倉庫に格納されています
