Vue vs React vs Angular vs Svelte Part.8

**デフォルトの名無しさん** · 2021/05/23(日) 13:42:32.51

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などはおｋ。

**デフォルトの名無しさん** · 2022/01/10(月) 19:07:28.51

多分jQueryおじさんはPromise使えない

**デフォルトの名無しさん** · 2022/01/10(月) 19:51:27.59

>>850
Svelteがいいか悪いかは別として高々数十行数の例題の行数の増減に拘るヤツは無能やろ

**デフォルトの名無しさん** · 2022/01/10(月) 20:31:39.36

>>848
jQueryの恩恵は生産性の向上
DOM APIで書くよりも数倍シンプルに書くことが出来る

**デフォルトの名無しさん** · 2022/01/10(月) 20:32:38.96

>>850
$('.class').on('click', function() { alert("ok"); })

これをSvelteで書いてみて

**デフォルトの名無しさん** · 2022/01/10(月) 20:37:40.39

>>851
うっわｗｗｗ
Promiseって、jQuerryの方が先にDeferredとして採用した機能で
その後にPromiseが標準化された後はDeferredはPromise互換になってるんやで
調べてみたらjQuery 1.5でリリースされた機能だから2011年、もう10年以上も前から使ってる機能
お前はそんなことも知らんのや。最近Promise知って自慢気にでもなってんのか？

**デフォルトの名無しさん** · 2022/01/10(月) 20:39:32.89

そもそもjQueryってまだメンテされてんの？

**デフォルトの名無しさん** · 2022/01/10(月) 20:39:54.23

それぐらい調べろよ

**デフォルトの名無しさん** · 2022/01/10(月) 20:44:39.86

>>857
jQuery自体はまだまだ現役だけど
jQuery～って派生モノが結構終わってきてる

**デフォルトの名無しさん** · 2022/01/10(月) 20:45:03.96

アンカ間違えた>>856

**デフォルトの名無しさん** · 2022/01/10(月) 20:47:11.64

jQueryの派生物って結局デザインの部分で
そこはCSSを使えばいいだけなんだよね
jQueryはクラスとか属性を操作するもの

で、そのデザインは変わりやすいもので
Reactとかは結局CSSのアップデートで不要になっていく

**デフォルトの名無しさん** · 2022/01/10(月) 20:54:46.19

なんでjqueryの話になってんの？
専用スレでやればいいっていうかそっちいけ

**デフォルトの名無しさん** · 2022/01/10(月) 21:00:00.22

>>856
実質されてないみたいなもん
進化も退化もないからメンテは要らんと思うけどね
オリジナルの作者がもう違うことやってるし投げ出した
今思えば酷いコードだ
彼とは昔shibuya.jsってところで会ったことがあるのだけど

**デフォルトの名無しさん** · 2022/01/10(月) 21:10:12.17

>>855
自慢げに語ってて草

**デフォルトの名無しさん** · 2022/01/10(月) 21:23:01.34

jQueryの作者についてググったら、2016年にはもうReactに乗り換えてるじゃん

**デフォルトの名無しさん** · 2022/01/10(月) 21:25:46.83

>>855
それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それを取り入れた

**デフォルトの名無しさん** · 2022/01/10(月) 21:25:58.06

>>864
そういうのって結構多いんよね
Pythonの作者もPythonコミュニティ抜けたし
Delphiの作者もMicrosoft行ったし

**デフォルトの名無しさん** · 2022/01/10(月) 21:43:05.79

>>864
本人に取っても黒歴史だろうね
こんなきちがい信者まで産んじゃってw

**デフォルトの名無しさん** · 2022/01/10(月) 22:07:00.68

>>866
Pythonの作者は「ヲタク君たち見てる～？次のリリースはMSのみんなのおかげでぇ、超早くなりま～す♡」とかMicrosoftからNTRビデオレターみたいなの出してたぜw

**デフォルトの名無しさん** · 2022/01/10(月) 22:48:04.17

IT分野は言語でもフレームワークでも何でも同じだけど
出来る人たちはある程度の期間が経ったら新しいものへちゃんと乗り換える
細かく見ればそれぞれの期間でも適材適所で複数を使い分ける
一方でダメな人たちは一つのものに依存

**デフォルトの名無しさん** · 2022/01/10(月) 23:37:01.84

>>854
短さにこだわる割にfunction使うのか……

**デフォルトの名無しさん** · 2022/01/11(火) 00:17:35.94

>>854
なんでアロー使わんの？

**デフォルトの名無しさん** · 2022/01/11(火) 01:17:39.85

そもそもReact/Vue/Svelteのどれもイベントハンドラの為にわざわざセレクタなんか使わないからね
jQueryに囚われすぎて思考が狭くなってるよ
もう少し勉強した方がいい

それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど
他のライブラリは管理不要になってるからね
半端な欠陥コードの真似をしろと言われても困るよw

**デフォルトの名無しさん** · 2022/01/11(火) 01:23:25.82

>>872
たしかに馬鹿げてるなw

**デフォルトの名無しさん** · 2022/01/11(火) 02:14:14.47

小規模では、jQuery は圧倒的

これを素のJS で書いたら、コードが数倍になって、バグだらけで使えない。
生産性が悪く、長時間労働になるから、
コストが高くなって、時給が減る

Deferred, Promise もある。
Ajax も皆、jQuery を使っていた。
それを最近は、axios に分離した

LoDash も良い

**デフォルトの名無しさん** · 2022/01/11(火) 02:33:45.09

>>854
書く必要がない

**デフォルトの名無しさん** · 2022/01/11(火) 02:38:32.89

>>874
時給なん？

**デフォルトの名無しさん** · 2022/01/11(火) 07:27:25.35

>>874
jQueryは地味に罠が多いし、独特だし、インターフェース設計古いし、ネット上の解説コードの品質が低いし、なんでも文字列だし、バグ増える印象ある。
歴史が長いし、作られた当時は何もなかったから仕方ないんだけども。

**デフォルトの名無しさん** · 2022/01/11(火) 08:52:19.62

>>870
thisが使えるから、こっちのほうが短くなりやすい

>>871
DOM APIとの互換性

**デフォルトの名無しさん** · 2022/01/11(火) 08:52:52.31

>>875
何もしないでokって出せるのか凄いなｗ

いいから動くもの出せよ

**デフォルトの名無しさん** · 2022/01/11(火) 08:53:15.82

>>877
自分が無能なものをライブラリのせいにするな

**デフォルトの名無しさん** · 2022/01/11(火) 08:59:20.14

>>872
> それにjQueryのonで登録したハンドラはoffで開放しないとリークするけど

なんでいちいちボロを出すんだｗｗｗ
最初からリークしないように設計されたんだが

歴史の話をしてやろうか？
古くかIEでattachEventでハンドラを登録した時ページ移動しなければ
メモリリークしてしまう問題をjQueryは解決したのが売りの一つだった
DOM APIの先はJavaScriptの領域外のブラウザのAPI（ActiveX？）だったため
JavaScriptの参照ポインタが機能しないのが根本的な原因

だからそれを解決するため、俺の記憶が間違っていなければ
オブジェクト（イベントハンドラ）を直接参照するのではなくIDを使った
ウィークポインタのような仕組みを使ってハンドラを管理した

DOM APIに直接登録するのはjQuery自身のイベントハンドラ一つで
いくつ登録しても、内部のハンドラマネージャーがうまいこと
転送するという仕組みで実装されたからメモリリークしないのがjQuery

**デフォルトの名無しさん** · 2022/01/11(火) 09:01:52.24

>>865
ちゃんと書けよ

それを言えば元々はpythonのイベント駆動のフレームワークが起源だよ
それをjQueryは取り入れた
だからPromiseと同等のものにJavaScriptプログラマ触れたのはjQueryが先で
jQuery使ってるプログラマがPromiseを知らないとかありえないだろ
お前が知らんだけじゃんかｗｗｗ

って話の流れだろ

**デフォルトの名無しさん** · 2022/01/11(火) 09:18:40.61

jqueryジジイさんは会社や開発でjqueryすごい！Reactクソ！って言ってjqueryのみで仕事してんの？
それともWebサイトしか作れない底辺？

**デフォルトの名無しさん** · 2022/01/11(火) 09:28:15.89

>>878
たった4行でここまで無能を晒せるとか凄い奴だな

**デフォルトの名無しさん** · 2022/01/11(火) 10:35:17.70

>>883
DOM APIは互換性が高くなった。だから
DOM APIでやればいいって言ってるやつがいるだろ？

DOM APIだけでやってるよ。ただしjQueryという便利なライブラリでラップして。
わざわざ自分でDOM APIを簡単に使えるラッパーを自作するなんてアホでしょう？

**デフォルトの名無しさん** · 2022/01/11(火) 10:35:33.69

>>884
反論は？

**デフォルトの名無しさん** · 2022/01/11(火) 11:41:38.20

>>881
それIE固有のリーク回避処理でしょ
IEサポート外した時にIE対処コードは除去されてるよ
しかも上位ノードでイベントバブリングを捕捉した後のコールバック管理の話とごちゃ混ぜになってるし
記憶の整理もできてないのにどうしてそんなに自信満々なんだろうか

**デフォルトの名無しさん** · 2022/01/11(火) 12:07:20.77

>>887
は？jQueryがリークするって言ったのお前じゃん
じゃあIEのリーク以外にイベントハンドラでリークするっていう
デマ（笑）はどこから持ってきたのか言えよ
まず最初にお前が記憶（捏造）をはっきりと書き出せ

IEの時点でリークが回避されてるっていうのに
on使うだけでリークするわけがないって、少し考えればわかるやろ

**デフォルトの名無しさん** · 2022/01/11(火) 12:08:07.72

しかも上位ノードのイベントバブリングとか
全く話に出てきてないことを言い出すし
な？こういうことだよ。jQueryをわかってないで批判してる

**デフォルトの名無しさん** · 2022/01/11(火) 12:16:30.78

> IEサポート外した時にIE対処コードは除去されてるよ

IEサポート外なら、メモリリークしないということになるだろｗ
IE以外ではメモリリークしないんだろ？

**デフォルトの名無しさん** · 2022/01/11(火) 12:21:35.79

>>882
いやだからお前が無知って話なんだが？
本当の起源を知らないでjQueryが起源だ！と言ってる無知なあなたを咎めてる

**デフォルトの名無しさん** · 2022/01/11(火) 12:22:19.44

>>885
答えになってない

**デフォルトの名無しさん** · 2022/01/11(火) 12:23:03.67

>>881
もうIE死んだんだからどうでもいいよ

**デフォルトの名無しさん** · 2022/01/11(火) 12:23:06.68

「jQueryが起源だ」でこのスレを検索しても何も見付からない
自分で嘘つきであることを証明した瞬間ｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:23:30.40

jQueryおじさんはどんなアプリ作ってるか（仕事してるか）とか、大きいアプリ作った事ない疑惑に関してはきっちりスルーするね

**デフォルトの名無しさん** · 2022/01/11(火) 12:24:49.74

JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
それにムカついてるのか？

起源なんて書いてないがｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:25:49.86

>>895
誰もが知ってる超大規模ウェブサイトだな

**デフォルトの名無しさん** · 2022/01/11(火) 12:27:16.03

>>893
メモリリークするIEが死んだんだから
jQueryもメモリリークしないで終わる話
お前がいい出したんだぞ

**デフォルトの名無しさん** · 2022/01/11(火) 12:28:28.28

>>896
それを起源って言うんだよw
日本語もわからないの？

**デフォルトの名無しさん** · 2022/01/11(火) 12:28:56.54

>>898
いやそれは俺じゃないぞw
お前みたいに自演などしない

**デフォルトの名無しさん** · 2022/01/11(火) 12:29:22.45

>>897
答えてなくて草

**デフォルトの名無しさん** · 2022/01/11(火) 12:29:49.05

>>899
なるほど

JavaScriptよりも先にjQueryの方が
Promise（Deferred）を採用したって俺が言ったから、
「jQueryが起源」という意味に勘違いして
あらしてたのかｗｗｗ

な？こういうやつなんだよ

**デフォルトの名無しさん** · 2022/01/11(火) 12:36:39.36

>>902
起源に論点ずらしてるがまずその認識が間違ってるのよ
jQueryのはtwistedを参考に作られたの
それを知らなかったよね？と言う話
あなたが無知を論点にしてたからそれを咎めたの
わかる？
起源の話はしてない
jQueryは凄くないと言う話をしてる

**デフォルトの名無しさん** · 2022/01/11(火) 12:37:23.27

>>888
うーん文意読み取れない？
onのリークとIE固有のリークは別物だよ
さらにその2つとも関係ないjQueryの実装の話も混じってるよ
と補足したらわかるかな？

リークはonとremoveChild繰り返しで簡単に確認できるよ

**デフォルトの名無しさん** · 2022/01/11(火) 12:39:48.98

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]
> 起源の話はしてない

わろたｗｗｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:40:53.24

どうやら完璧に論破したみたいだな
気持ちいいぜ

**デフォルトの名無しさん** · 2022/01/11(火) 12:41:05.16

>>904
> リークはonとremoveChild繰り返しで簡単に確認できるよ

reactとDOM APIを混ぜて使って
reactはメモリリークするって話をしてるんですね

「お前がアホ」で終わるよねｗｗｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:42:42.26

恣意的な編集して論破とか言ってる恥ずかしい人がいる……

**デフォルトの名無しさん** · 2022/01/11(火) 12:45:51.77

いつもの勝利宣言だから、もう書き込まないでしょうｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:48:06.76

あ、間違えた。論破してる人と恣意的編集してる人は別だわ。
論破は確かにしてるわ

**デフォルトの名無しさん** · 2022/01/11(火) 12:49:25.14

>>910
IDを見ずに内容から、こいつキチガイだって判断したんだろ？ｗ
それが事実だよ

**デフォルトの名無しさん** · 2022/01/11(火) 12:50:46.87

>>911
恣意的な編集してる方が普通にキチガイだよ

**デフォルトの名無しさん** · 2022/01/11(火) 12:52:13.82

>>912
自分の判断に素直になれよｗ
誰も起源なんて言ってないのに
「恣意的な編集して起源って言ったニダ！論破したニダ！」
って言ったほうがキチガイに決まってるじゃんかｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:55:00.59

ここのスレタイとテンプレみて居座る奴がまずキチガイ

**デフォルトの名無しさん** · 2022/01/11(火) 12:55:18.35

>>913
突然ニダニダ言い出してどうしたの？
もうすぐ超大規模ウェブサイトの端っこで惨めに数行減らす作業の時間だよ？

**デフォルトの名無しさん** · 2022/01/11(火) 12:55:59.22

>>915
jQuery使ってるから、すでに最小の労力で
プロジェクトは完遂してるぞｗ

**デフォルトの名無しさん** · 2022/01/11(火) 12:58:05.23

>>916
jQuery以外には何使ってるの？ jQuery以外の部分は触らせてもらえないんだろうけどさ

**デフォルトの名無しさん** · 2022/01/11(火) 12:59:24.44

>>917
それに答えたらなにかいいことでもあるのか？

GCP使ってるけど？

**デフォルトの名無しさん** · 2022/01/11(火) 13:02:09.73

>>918
執拗に回答を避けてるからなんでかなと思って。GCPとか全然回答になってない事言うし

**デフォルトの名無しさん** · 2022/01/11(火) 13:04:01.96

はぁ？やってることってプログラミング環境全てじゃん
RubyとかPythonとか言えばいいのか？

**デフォルトの名無しさん** · 2022/01/11(火) 13:07:58.15

>>920
普通GCPの～を使ってるって言い方するでしょ。GCPって言い方は変だよ、明らかに

**デフォルトの名無しさん** · 2022/01/11(火) 13:18:52.55

全体を把握してない、全く権限無いんだろうな

**デフォルトの名無しさん** · 2022/01/11(火) 13:21:43.73

reactその他と良し悪しを比較するなら意味があるだろうが、じぇーくえりーしか知らん奴のゴリ押しは無価値なんだよなぁ

**デフォルトの名無しさん** · 2022/01/11(火) 14:17:28.40

jQueryくんはなんかそっち系のスレ出来てるからそっちいって

**デフォルトの名無しさん** · 2022/01/11(火) 15:53:27.16

老害のテンプレみたいな人だな

**デフォルトの名無しさん** · 2022/01/11(火) 16:51:50.09

いわゆる無敵くん

**デフォルトの名無しさん** · 2022/01/11(火) 23:06:45.88

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 の動画を一斉に上げた！

すごい。全員が最先端を攻めている

**デフォルトの名無しさん** · 2022/01/12(水) 07:15:25.17

Railsはどうでもいけどesbuild使うとビルド速くなる以外にメリットあるのかな？

**デフォルトの名無しさん** · 2022/01/12(水) 09:01:00.33

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。

**927** · 2022/01/12(水) 23:33:25.22

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 へ変わる

**デフォルトの名無しさん** · 2022/01/15(土) 09:01:02.57

NextとFirebaseでSNSっぽいの作ってみて思ったんやが、NextとかNuxtとかのフロントエンドのフレームワークって、フロントエンドの技術メインで全部やろうとしたら有用やなとは思ったが、バックエンドちゃんと書けたり書ける人おるんやったら、いらんかもと思ったんやがどう思うよ
古い感覚なんかもしれんがロジックは基本バックエンドで書いて隠蔽して、フロントはjson要求したりjsonの色付けだけの方が、構成として綺麗かなーとは思ったんや
フロントでゴリゴリとロジック書いてて、これええんか…？って思ってまう
Railsみたいなフルスタックから、フロントやバックとかを分離する方向に時代は向かっとるとは思うが、Nextもフルスタックになりつつあるし
フロントがSPAとかSSGになってんのは体感速度爆上がるからそこはええと思うんやがな

**デフォルトの名無しさん** · 2022/01/15(土) 09:37:58.71

ユーザーが何でも変更可能なクライアントのコードで
全部やったら不正しまくりだろ
フロントエンドで重要なことをしたらだめに決まってる

**デフォルトの名無しさん** · 2022/01/15(土) 12:34:20.93

Nextは別にフロントバックエンドがゴッチャにはならんでしょ、シームレスにも出来るってだけで。バックエンド好きなもの使えるし。
FirebaseというかFirestoreはたしかにそんな傾向あるけど、そこは考え方を転換すればセキュリティを担保できるし、必要なとこはFunctionsでやればいいのだ。

**デフォルトの名無しさん** · 2022/01/15(土) 12:50:45.75

>>931
要らんと思う
フロントはあくまでAPIクライアント

**デフォルトの名無しさん** · 2022/01/15(土) 13:49:47.30

フロントしか開発したことない人が使うには良いんだろうね
バックエンドも触ってる人からみれば分離した方が開発も運用も楽っての当たり前に理解しているし

**デフォルトの名無しさん** · 2022/01/15(土) 13:53:38.96

jQuery時代の人なら普通にバックエンドも
プログラミングしてたんだけどね

派手なものを簡単に作れるから
基礎技術ができてない人が多い

**デフォルトの名無しさん** · 2022/01/15(土) 14:07:50.12

別にReactとかじゃなくてもフロント改変なんていくらでもできる
なんならパケット直いじりツール使えばどんなシステムでも変更できるし

**デフォルトの名無しさん** · 2022/01/15(土) 16:41:02.38

ちょこちょこNext.jsやFirebaseやった事ないのかズレた事言ってる奴が居るな……

**デフォルトの名無しさん** · 2022/01/15(土) 16:49:44.37

>>931自体がNextを要らないと言っているのかSPAを要らないと言っているのかポイントが絞れてないからじゃね？

**デフォルトの名無しさん** · 2022/01/15(土) 18:21:05.07

ついにnext.jsを使うプロジェクトを開始したぞ
ちな俺はサーバーサイドもフロントもガッツリやったことがある
その俺が評価してやんよ
ミスったら俺の首が飛ぶ

**デフォルトの名無しさん** · 2022/01/15(土) 19:22:11.97

利用者の体感利便性を考えたら
まずはページ再送出をしないCSR/SPA化が今では必須でしょう
更に最初のアクセスページのためにCSRだけではダメで最低限SSR併用か可能ならSSGが必要

バックエンド開発者もこの変化についてこれない人は
CSRのためのAPI対応しか出来なかったり
もっと古い人はCSR未対応の古きSSRオンリーしか出来なかったりで
なぜ「CSRとほぼ同じコードをSSR/SSGする必要があるのか」さえも理解できていないようです

**デフォルトの名無しさん** · 2022/01/15(土) 19:54:39.76

SPAで利便性がよくなるか？という問題は場合によるとしか言えんからなー
シンプルなMPAのほうが使いやすいと感じるケースは未だに多い
SPAが必須と考えるのは開発側の独りよがりだよ

**デフォルトの名無しさん** · 2022/01/15(土) 20:06:15.24

まあでもSPAのほうが余分なもの読み込まないぶん若干ページ遷移早いよな
そこだけは褒めてやるべきだとおもうわ
まあ作り手の面倒は増えてるし回線速度が速い現在に本当に必要なのかは疑問だけど

**デフォルトの名無しさん** · 2022/01/15(土) 20:11:01.62

>>942
SPAは毎回ページまるごと送出しなおしのMPAよりも以下の利点がある
・サーバーの負荷減少
・トラフィックの減少
・ブラウザ側での表示書き換え減少
・ユーザーの待ち時間減少 (体感の向上)
つまり全てにおいてエコで優れている
もちろんSPAに加えて前述のように最初のページアクセス待ち時間減少のためにSSR/SSG併用
デメリットは「技術の低い人たちは提供できない」

**デフォルトの名無しさん** · 2022/01/15(土) 20:17:20.94

ユーザー目線で言うと非SPAはリロード時、遷移時に画面がしっかりリセットされる安心感があるんだよな
なんか動きが変な気がしたらとりあえずリロード、戻る、適当にハイパーリンククリック
それでまあまあ具合がよくなると経験的にわかってる
これは非常に重要なんじゃないかな

たぶん何も知らんユーザーからするとSPAは巨大でミュータブルなオブジェクトに見えてるんじゃないかとおれは考えてる
逆に非SPAはほとんどイミュータブルな関数に見えてる
もちろんプログラミングの素人であるユーザーがイミュータブルとミュータブルの違いを認識してるはずは無いんだが
ぼんやりと感覚的にその違いを使い勝手という形で体感してるんじゃないかな

**デフォルトの名無しさん** · 2022/01/15(土) 20:17:38.17

>シンプルなMPAのほうが使いやすいと感じるケースは未だに多い

MPAの方がシンプルってそれこそ開発側の視点じゃね？
ユーザーから見てシンプルだというなら仕様が違うものを作っていることになるわけで、そもそも比較にならない。

**デフォルトの名無しさん** · 2022/01/15(土) 20:17:52.19

場合によってはSPAのほうが想定すること少なくて楽。
それはそれとしてSPAが適するかどうかは用途次第。なんだけど、最近MPAはSSGとSPAのハイブリッドばかりでSSR作って無いなぁ

**デフォルトの名無しさん** · 2022/01/15(土) 20:20:47.89

>>945
一般ユーザーはそこまで考えてないと思うし、そう思わせるならUIが悪いと思うな。個人的な意見だけども

**デフォルトの名無しさん** · 2022/01/15(土) 20:26:33.13

>>944
・サーバーの負荷減少はユーザーでなく運用側のメリットで今はユーザー視点のメリットについて議論しているのでは？
・トラフィックも同様
・表示書き換えは、、、SPAのほうが増えてないか？
・ユーザーの待ち時間は減る傾向が見られるね
・技術力が低い人に提供できないのはユーザーにとってはデメリットだね
つまりそれだけ利便性の高いサイトが少ないということだから

こうして一個一個深堀していくとやっぱりユーザー目線ではデメリットのほうが大きい気がするなー
ウェブIDE、オフィス文書編集、BPMエディタ、、、この手の従来デスクトップでしかできなかった超複雑なツールをブラウザで提供出来るようになったのは凄い発明だけど
何でもかんでもSPAってのは典型的なミステイクだね
未だに世の中のほとんどのサイトは従来の非SPAがマッチしてるよ

**デフォルトの名無しさん** · 2022/01/15(土) 20:27:14.48

>>946
ユーザー目線でも開発者目線でもどっちもシンプルということだね