Vue vs React vs Angular vs Svelte Part.8
レス数が950を超えています。1000を超えると書き込みができなくなります。
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Svelte Part.7
https://mevius.5ch.net/test/read.cgi/tech/1610901677/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 >>850
Svelteがいいか悪いかは別として高々数十行数の例題の行数の増減に拘るヤツは無能やろ >>848
jQueryの恩恵は生産性の向上
DOM APIで書くよりも数倍シンプルに書くことが出来る >>850
$('.class').on('click', function() { alert("ok"); })
これをSvelteで書いてみて >>851
うっわｗｗｗ
Promiseって、jQuerryの方が先にDeferredとして採用した機能で
その後にPromiseが標準化された後はDeferredはPromise互換になってるんやで
調べてみたらjQuery 1.5でリリースされた機能だから2011年、もう10年以上も前から使ってる機能
お前はそんなことも知らんのや。最近Promise知って自慢気にでもなってんのか？ >>857
jQuery自体はまだまだ現役だけど
jQuery〜って派生モノが結構終わってきてる jQueryの派生物って結局デザインの部分で
そこはCSSを使えばいいだけなんだよね
jQueryはクラスとか属性を操作するもの
で、そのデザインは変わりやすいもので
Reactとかは結局CSSのアップデートで不要になっていく なんでjqueryの話になってんの？
専用スレでやればいいっていうかそっちいけ >>856
実質されてないみたいなもん
進化も退化もないからメンテは要らんと思うけどね
オリジナルの作者がもう違うことやってるし投げ出した
今思えば酷いコードだ
彼とは昔shibuya.jsってところで会ったことがあるのだけど jQueryの作者についてググったら、2016年にはもうReactに乗り換えてるじゃん >>855
それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それを取り入れた >>864
そういうのって結構多いんよね
Pythonの作者もPythonコミュニティ抜けたし
Delphiの作者もMicrosoft行ったし >>864
本人に取っても黒歴史だろうね
こんなきちがい信者まで産んじゃってw >>866
Pythonの作者は「ヲタク君たち見てる〜？ 次のリリースはMSのみんなのおかげでぇ、超早くなりま〜す♡」とかMicrosoftからNTRビデオレターみたいなの出してたぜw IT分野は言語でもフレームワークでも何でも同じだけど
出来る人たちはある程度の期間が経ったら新しいものへちゃんと乗り換える
細かく見ればそれぞれの期間でも適材適所で複数を使い分ける
一方でダメな人たちは一つのものに依存 >>854
短さにこだわる割にfunction使うのか…… そもそもReact/Vue/Svelteのどれもイベントハンドラの為にわざわざセレクタなんか使わないからね
jQueryに囚われすぎて思考が狭くなってるよ
もう少し勉強した方がいい
それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど
他のライブラリは管理不要になってるからね
半端な欠陥コードの真似をしろと言われても困るよw 小規模では、jQuery は圧倒的
これを素のJS で書いたら、コードが数倍になって、バグだらけで使えない。
生産性が悪く、長時間労働になるから、
コストが高くなって、時給が減る
Deferred, Promise もある。
Ajax も皆、jQuery を使っていた。
それを最近は、axios に分離した
LoDash も良い >>874
jQueryは地味に罠が多いし、独特だし、インターフェース設計古いし、ネット上の解説コードの品質が低いし、なんでも文字列だし、 バグ増える印象ある。
歴史が長いし、作られた当時は何もなかったから仕方ないんだけども。 >>870
thisが使えるから、こっちのほうが短くなりやすい
>>871
DOM APIとの互換性 >>875
何もしないでokって出せるのか凄いなｗ
いいから動くもの出せよ >>877
自分が無能なものをライブラリのせいにするな >>872
> それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど
なんでいちいちボロを出すんだｗｗｗ
最初からリークしないように設計されたんだが
歴史の話をしてやろうか？
古くかIEでattachEventでハンドラを登録した時ページ移動しなければ
メモリリークしてしまう問題をjQueryは解決したのが売りの一つだった
DOM APIの先はJavaScriptの領域外のブラウザのAPI（ActiveX？）だったため
JavaScriptの参照ポインタが機能しないのが根本的な原因
だからそれを解決するため、俺の記憶が間違っていなければ
オブジェクト（イベントハンドラ）を直接参照するのではなくIDを使った
ウィークポインタのような仕組みを使ってハンドラを管理した
DOM APIに直接登録するのはjQuery自身のイベントハンドラ一つで
いくつ登録しても、内部のハンドラマネージャーがうまいこと
転送するという仕組みで実装されたからメモリリークしないのがjQuery >>865
ちゃんと書けよ
それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それをjQueryは取り入れた
だからPromiseと同等のものにJavaScriptプログラマ触れたのはjQueryが先で
jQuery使ってるプログラマがPromiseを知らないとかありえないだろ
お前が知らんだけじゃんかｗｗｗ
って話の流れだろ jqueryジジイさんは会社や開発でjqueryすごい！Reactクソ！って言ってjqueryのみで仕事してんの？
それともWebサイトしか作れない底辺？ >>878
たった4行でここまで無能を晒せるとか凄い奴だな >>883
DOM APIは互換性が高くなった。だから
DOM APIでやればいいって言ってるやつがいるだろ？
DOM APIだけでやってるよ。ただしjQueryという便利なライブラリでラップして。
わざわざ自分でDOM APIを簡単に使えるラッパーを自作するなんてアホでしょう？ >>881
それIE固有のリーク回避処理でしょ
IEサポート外した時にIE対処コードは除去されてるよ
しかも上位ノードでイベントバブリングを捕捉した後のコールバック管理の話とごちゃ混ぜになってるし
記憶の整理もできてないのにどうしてそんなに自信満々なんだろうか >>887
は？jQueryがリークするって言ったのお前じゃん
じゃあIEのリーク以外にイベントハンドラでリークするっていう
デマ（笑）はどこから持ってきたのか言えよ
まず最初にお前が記憶（捏造）をはっきりと書き出せ
IEの時点でリークが回避されてるっていうのに
on使うだけでリークするわけがないって、少し考えればわかるやろ しかも上位ノードのイベントバブリングとか
全く話に出てきてないことを言い出すし
な？こういうことだよ。jQueryをわかってないで批判してる > IEサポート外した時にIE対処コードは除去されてるよ
IEサポート外なら、メモリリークしないということになるだろｗ
IE以外ではメモリリークしないんだろ？ >>882
いやだからお前が無知って話なんだが？
本当の起源を知らないでjQueryが起源だ！と言ってる無知なあなたを咎めてる 「jQueryが起源だ」でこのスレを検索しても何も見付からない
自分で嘘つきであることを証明した瞬間ｗ jQueryおじさんはどんなアプリ作ってるか（仕事してるか）とか、大きいアプリ作った事ない疑惑に関してはきっちりスルーするね JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
それにムカついてるのか？
起源なんて書いてないがｗ >>895
誰もが知ってる超大規模ウェブサイトだな >>893
メモリリークするIEが死んだんだから
jQueryもメモリリークしないで終わる話
お前がいい出したんだぞ >>896
それを起源って言うんだよw
日本語もわからないの？ >>898
いやそれは俺じゃないぞw
お前みたいに自演などしない >>899
なるほど
JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
「jQueryが起源」という意味に勘違いして
あらしてたのかｗｗｗ
な？こういうやつなんだよ >>902
起源に論点ずらしてるがまずその認識が間違ってるのよ
jQueryのはtwistedを参考に作られたの
それを知らなかったよね？と言う話
あなたが無知を論点にしてたからそれを咎めたの
わかる？
起源の話はしてない
jQueryは凄くないと言う話をしてる >>888
うーん文意読み取れない？
onのリークとIE固有のリークは別物だよ
さらにその2つとも関係ないjQueryの実装の話も混じってるよ
と補足したらわかるかな？
リークはonとremoveChild繰り返しで簡単に確認できるよ 891 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:21:35.79 ID:P6YErMSE [3/7]
> >>882
> いやだからお前が無知って話なんだが？
> 本当の起源を知らないでjQueryが起源だ！と言ってる無知なあなたを咎めてる
899 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:28:28.28 ID:P6YErMSE [5/7]
> それを起源って言うんだよw
903 返信：デフォルトの名無しさん[sage] 投稿日：2022/01/11(火) 12:36:39.36 ID:P6YErMSE [7/7]
> 起源の話はしてない
わろたｗｗｗ >>904
> リークはonとremoveChild繰り返しで簡単に確認できるよ
reactとDOM APIを混ぜて使って
reactはメモリリークするって話をしてるんですね
「お前がアホ」で終わるよねｗｗｗ 恣意的な編集して論破とか言ってる恥ずかしい人がいる…… いつもの勝利宣言だから、もう書き込まないでしょうｗ あ、間違えた。論破してる人と恣意的編集してる人は別だわ。
論破は確かにしてるわ >>910
IDを見ずに内容から、こいつキチガイだって判断したんだろ？ｗ
それが事実だよ >>911
恣意的な編集してる方が普通にキチガイだよ >>912
自分の判断に素直になれよｗ
誰も起源なんて言ってないのに
「恣意的な編集して起源って言ったニダ！論破したニダ！」
って言ったほうがキチガイに決まってるじゃんかｗ ここのスレタイとテンプレみて居座る奴がまずキチガイ >>913
突然ニダニダ言い出してどうしたの？
もうすぐ超大規模ウェブサイトの端っこで惨めに数行減らす作業の時間だよ？ >>915
jQuery使ってるから、すでに最小の労力で
プロジェクトは完遂してるぞｗ >>916
jQuery以外には何使ってるの？ jQuery以外の部分は触らせてもらえないんだろうけどさ >>917
それに答えたらなにかいいことでもあるのか？
GCP使ってるけど？ >>918
執拗に回答を避けてるからなんでかなと思って。GCPとか全然回答になってない事言うし はぁ？やってることってプログラミング環境全てじゃん
RubyとかPythonとか言えばいいのか？ >>920
普通GCPの〜を使ってるって言い方するでしょ。GCPって言い方は変だよ、明らかに reactその他と良し悪しを比較するなら意味があるだろうが、じぇーくえりーしか知らん奴のゴリ押しは無価値なんだよなぁ jQueryくんはなんかそっち系のスレ出来てるからそっちいって Ruby on Rails 6 でも、Bootstrap 4 を使うと、jQuery が自動的にインクルードされている。
React, Vue.js, Bootstrap 4 で、jQueryも使う
Bootstrap 5 で、jQueryは削除されたけど、まだpopper.js は使っている
Rails 7 では、外人のYouTuber のRailsのすべての学校・サロンは、
ここ3か月で、脱webpack のesbuild の動画を一斉に上げた！
すごい。全員が最先端を攻めている Railsはどうでもいけどesbuild使うとビルド速くなる以外にメリットあるのかな？ ★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 Rails7がもつフロントエンドへの「答え」、2021/9
https://zenn.dev/kenzan100/articles/0f9b100655a4bf
Rails 7 をちょこっと試す（さらば、Webpacker 編）、2021/9
https://qiita.com/suketa/items/837eb97bdb48dd8c4688
規約だけのフレームワーク・Stimulus が入った。
React, Vue,js, Stimulus の選択
Foreman が入った。
JavaScript のbundle には、esbuild, rollup.js, webpack の選択
Bootstrap, Bulma, Tailwind, PostCSS, Dart Sass をサポート。
DartSass 以外の、Ruby Sass, node-sass(LibSass)は滅んだ
SASSでは、グローバルスコープの@import を廃止して、
ファイルスコープの@use へ変わる NextとFirebaseでSNSっぽいの作ってみて思ったんやが、NextとかNuxtとかのフロントエンドのフレームワークって、フロントエンドの技術メインで全部やろうとしたら有用やなとは思ったが、バックエンドちゃんと書けたり書ける人おるんやったら、いらんかもと思ったんやがどう思うよ
古い感覚なんかもしれんがロジックは基本バックエンドで書いて隠蔽して、フロントはjson要求したりjsonの色付けだけの方が、構成として綺麗かなーとは思ったんや
フロントでゴリゴリとロジック書いてて、これええんか…？って思ってまう
Railsみたいなフルスタックから、フロントやバックとかを分離する方向に時代は向かっとるとは思うが、Nextもフルスタックになりつつあるし
フロントがSPAとかSSGになってんのは体感速度爆上がるからそこはええと思うんやがな ユーザーが何でも変更可能なクライアントのコードで
全部やったら不正しまくりだろ
フロントエンドで重要なことをしたらだめに決まってる Nextは別にフロントバックエンドがゴッチャにはならんでしょ、シームレスにも出来るってだけで。バックエンド好きなもの使えるし。
FirebaseというかFirestoreはたしかにそんな傾向あるけど、そこは考え方を転換すればセキュリティを担保できるし、必要なとこはFunctionsでやればいいのだ。 >>931
要らんと思う
フロントはあくまでAPIクライアント フロントしか開発したことない人が使うには良いんだろうね
バックエンドも触ってる人からみれば分離した方が開発も運用も楽っての当たり前に理解しているし jQuery時代の人なら普通にバックエンドも
プログラミングしてたんだけどね
派手なものを簡単に作れるから
基礎技術ができてない人が多い 別にReactとかじゃなくてもフロント改変なんていくらでもできる
なんならパケット直いじりツール使えばどんなシステムでも変更できるし ちょこちょこNext.jsやFirebaseやった事ないのかズレた事言ってる奴が居るな…… >>931自体がNextを要らないと言っているのかSPAを要らないと言っているのかポイントが絞れてないからじゃね？ ついにnext.jsを使うプロジェクトを開始したぞ
ちな俺はサーバーサイドもフロントもガッツリやったことがある
その俺が評価してやんよ
ミスったら俺の首が飛ぶ 利用者の体感利便性を考えたら
まずはページ再送出をしないCSR/SPA化が今では必須でしょう
更に最初のアクセスページのためにCSRだけではダメで最低限SSR併用か可能ならSSGが必要
バックエンド開発者もこの変化についてこれない人は
CSRのためのAPI対応しか出来なかったり
もっと古い人はCSR未対応の古きSSRオンリーしか出来なかったりで
なぜ「CSRとほぼ同じコードをSSR/SSGする必要があるのか」さえも理解できていないようです SPAで利便性がよくなるか？という問題は場合によるとしか言えんからなー
シンプルなMPAのほうが使いやすいと感じるケースは未だに多い
SPAが必須と考えるのは開発側の独りよがりだよ まあでもSPAのほうが余分なもの読み込まないぶん若干ページ遷移早いよな
そこだけは褒めてやるべきだとおもうわ
まあ作り手の面倒は増えてるし回線速度が速い現在に本当に必要なのかは疑問だけど >>942
SPAは毎回ページまるごと送出しなおしのMPAよりも以下の利点がある
・サーバーの負荷減少
・トラフィックの減少
・ブラウザ側での表示書き換え減少
・ユーザーの待ち時間減少 (体感の向上)
つまり全てにおいてエコで優れている
もちろんSPAに加えて前述のように最初のページアクセス待ち時間減少のためにSSR/SSG併用
デメリットは「技術の低い人たちは提供できない」 ユーザー目線で言うと非SPAはリロード時、遷移時に画面がしっかりリセットされる安心感があるんだよな
なんか動きが変な気がしたらとりあえずリロード、戻る、適当にハイパーリンククリック
それでまあまあ具合がよくなると経験的にわかってる
これは非常に重要なんじゃないかな
たぶん何も知らんユーザーからするとSPAは巨大でミュータブルなオブジェクトに見えてるんじゃないかとおれは考えてる
逆に非SPAはほとんどイミュータブルな関数に見えてる
もちろんプログラミングの素人であるユーザーがイミュータブルとミュータブルの違いを認識してるはずは無いんだが
ぼんやりと感覚的にその違いを使い勝手という形で体感してるんじゃないかな >シンプルなMPAのほうが使いやすいと感じるケースは未だに多い
MPAの方がシンプルってそれこそ開発側の視点じゃね？
ユーザーから見てシンプルだというなら仕様が違うものを作っていることになるわけで、そもそも比較にならない。 場合によってはSPAのほうが想定すること少なくて楽。
それはそれとしてSPAが適するかどうかは用途次第。なんだけど、最近MPAはSSGとSPAのハイブリッドばかりでSSR作って無いなぁ >>945
一般ユーザーはそこまで考えてないと思うし、そう思わせるならUIが悪いと思うな。個人的な意見だけども >>944
・サーバーの負荷減少はユーザーでなく運用側のメリットで今はユーザー視点のメリットについて議論しているのでは？
・トラフィックも同様
・表示書き換えは、、、SPAのほうが増えてないか？
・ユーザーの待ち時間は減る傾向が見られるね
・技術力が低い人に提供できないのはユーザーにとってはデメリットだね
つまりそれだけ利便性の高いサイトが少ないということだから
こうして一個一個深堀していくとやっぱりユーザー目線ではデメリットのほうが大きい気がするなー
ウェブIDE、オフィス文書編集、BPMエディタ、、、この手の従来デスクトップでしかできなかった超複雑なツールをブラウザで提供出来るようになったのは凄い発明だけど
何でもかんでもSPAってのは典型的なミステイクだね
未だに世の中のほとんどのサイトは従来の非SPAがマッチしてるよ >>946
ユーザー目線でも開発者目線でもどっちもシンプルということだね レス数が950を超えています。1000を超えると書き込みができなくなります。
