Vue vs React vs Svelte Part.6

**デフォルトの名無しさん** · 2020/10/27(火) 13:09:05.31

実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Angular Part.5
https://mevius.5ch.net/test/read.cgi/tech/1596029929/

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

**デフォルトの名無しさん** · 2020/10/27(火) 14:12:34.02

・jQueryトップページ
http://jquery.com/

・ダウンロード、CDN
http://jquery.com/download/

・ブラウザサポート
http://jquery.com/browser-support/

・jQuery UI
http://jqueryui.com/

・jQuery UI ダウンロ－ド
http://jqueryui.com/download/

・リファレンス等
http://js.studio-kingdom.com/jquery/
http://alphasis.info/jquery/ (http://alphasis.info/jquery-api/)
http://www.jquerystudy.info/

**デフォルトの名無しさん** · 2020/10/27(火) 14:13:07.59

Q. jQueryはどのバージョンを使えばいいのですか？
A. IE9以上であれば、jQuery 3.0以上を使用してください。
IE8以下にも対応するならば、jQuery 1.12を使用してください。

補足

jQuery 1.9 までは一系統しかなく、古いブラウザも含めて全て対応していました。
その後、古いブラウザを切り捨てるためにバージョンを分岐させました。
古いブラウザにも対応した1系（1.10、1.11、12）と
古いブラウザを切り捨てた2系（2.0, 2.1, 2.2）です。

1系と2系は対応ブラウザの違いだけで機能は全く一緒です。
機能が同じなのにメジャーバージョンが違っているのが分かりにくい
ということでバージョン番号の付け方を変えることになり、
新たに古いブラウザを切り捨てたjQuery 3.0、そして古いブラウザにも対応した
jQuery Compat 3.0がリリースされる予定でした。

しかしマイクロソフトが古いIEのサポートポリシーを変更し
サポート中であるOSで動く、最新のIEしかサポートしなくなったために、
2016年1月でVista上のIE8のサポートが終了しました。

そのため予定されていたjQuery Compat 3.0がなくなり、
jQueryは3.0に一本化されました。

**デフォルトの名無しさん** · 2020/10/27(火) 14:13:31.16

jQuery 3.0正式版がついにリリース。通常版のほかに、Ajax機能を省略したスリムビルド版も提供
http://www.publickey1.jp/blog/16/jquery_30ajax.html

2006年1月にjQueryが初めて世の中に登場してから10周年となる今年。jQuery 3.0の正式版が登場しました。

jQuery 3.0 Final Released! | Official jQuery Blog
これまでjQueryは、、モダンブラウザのみをサポートすることで軽量化と安定化をはかった
「jQuery 2.x」系と、Internet Explorer 8以前を含む古いバージョンのブラウザまで
サポートする互換性重視の「jQuery 1.x」系の2系統が存在しました。

また、フル機能のjQuery 3.0のほかに、Ajaxの機能を省略して軽量化したスリムビルド版のjQuery 3.0の提供が行われます。

Along with the regular version of jQuery that includes the ajax and effects modules, we’re releasing a “slim” version that excludes these modules.

通常バージョンとしてAjaxやエフェクトモジュールなどを含んだjQueryと同時に、これらを外した“スリム”バージョンも提供する。
最近のWebアプリケーションではjQueryのAjaxを使うことは少なくなったと思われますので、スリム版のjQueryで十分だという開発者も多いでしょう。
圧縮後のサイズは通常版が30kbなのに対し、スリム版は23.6kb。

**デフォルトの名無しさん** · 2020/10/27(火) 14:15:29.26

jQueryはオワコン？いやいやjQueryのシェアはまだまだ増えてます。
誰が初めたかわからない中身のない脱jQueryキャンペーンこそがオワコンだったのです。
https://w3techs.com/technologies/history_overview/javascript_library/all/y

jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
　　2月 74.4%（1ヶ月で+0.2%）
　　6月 75.5%（4ヶ月で+1.1%）
　　8月15日 76.2%（2ヶ月で+0.7%）
　　10月15日 76.5%（2ヶ月で+0.3%）
　　10月25日 76.7%（0日で+0.2%、10ヶ月で+2.5%）

Vue.js　0.4%（1年で+0.1%）
Angular　0.4%（1年で+0%）
React　0.3%（1年で+0%）

**デフォルトの名無しさん** · 2020/10/27(火) 14:22:42.13

>>1 書き忘れた
★推奨NGワード
jQuery
Ruby
C#
Blazor

全くスレタイと関係ないものばかりなので、連鎖あぼーん有効で問題ないでしょう。透明あぼーんもオンにしときましょう。

**デフォルトの名無しさん** · 2020/10/27(火) 15:26:28.81

シェアを根拠にｊQueryを自慢してるやつは
マクドナルドのハンバーガーを自慢するのと同じだってことに気づけ

**デフォルトの名無しさん** · 2020/10/27(火) 16:37:25.48

マクドナルドのハンバーガーの何が間違っているか言えるか？

あれは、「一番普及してる＝美味しい」としてしまったこと
美味しいが間違いなのであって「一番普及している＝総合的に優れている」という
結論であれば間違いじゃないんだよ

「美味しい」というのは優れている要素の1つでしかない、
「一番普及している＝安い」ということだってできる。もちろん一番安いわけでもないだろう
いろんな要素があって、それらを総合的に見た時優れている。
「マクドナルドのハンバーガーは総合的に一番優れている」という言い方ならおかしくもなんともなかった

あの話は「美味しい」にしたところが間違いなだけ。
一番普及しているという事実には、そこに優位な理由が存在していることを意味している
jQueryもそうだわな。Windowsだってそうだ。
すべての面で他より勝ってることなんてありえない
しかし一番普及しているものは総合的に優れているということなら正しい

**デフォルトの名無しさん** · 2020/10/27(火) 16:43:47.62

ウェンディーズのハンバーグが一番旨かったと思うが
ウェンディーズは死んでしまった
良いものが残るとは限らない

**デフォルトの名無しさん** · 2020/10/27(火) 16:59:35.60

× 良いものが残るとは限らない
○ 美味しいものが残るとは限らない

旨かった＝良いものではない。そこが間違っている
戦略的に"優れているもの"が生き残る

生き残っているものは結局の所、（重要な点が）優れているものなんだよ

**デフォルトの名無しさん** · 2020/10/27(火) 17:21:32.60

ことばあそびですね判ります

**デフォルトの名無しさん** · 2020/10/27(火) 17:29:22.15

>>11
そう。あのコミック自体が言葉遊びだったんだよ。

あれ読んで、一番普及しているものに優れたところはないと
解釈してしまった読者はアホ

**デフォルトの名無しさん** · 2020/10/27(火) 17:32:23.93

「一番売れているのは、一番美味しいからだ」と言ったどこかのモブに対して
イヤイヤイヤイヤ「一番売れているのは、販売戦略が一番優れていたからだろ」と
ツッコミを入れなければいけない所

別の所が一番なんだよと指摘すると、実はこの話は成り立たなくなる

**デフォルトの名無しさん** · 2020/10/27(火) 18:19:35.54

jQueryを熱く語ってるの滑稽なんだけど自覚ある？

**デフォルトの名無しさん** · 2020/10/27(火) 20:29:20.43

どのスレが本物なんだ？

**デフォルトの名無しさん** · 2020/10/27(火) 22:18:04.19

フレームワークは腐る、乱立する
大体同じ内容をメソッド名とか引数パターンだけ
覚え直しという無駄な学習コストの三重苦
ネイティブコードこそ至高

**デフォルトの名無しさん** · 2020/10/28(水) 11:59:43.20

jQueryが普及してるとか
jQuery使ってれば良いって主張してるけど
jQueryが糞ってことは否定してないしな

**デフォルトの名無しさん** · 2020/10/28(水) 12:01:11.48

>>16
すごい判る
大抵は覚えることが増えるだけで
思ったほどメリット出ない

**デフォルトの名無しさん** · 2020/10/28(水) 12:30:28.11

WebのUIの複雑さに対処するように進化してきてるから
ちょっとしたサイトを作るくらいではメリットを感じられないんだろう

**デフォルトの名無しさん** · 2020/10/28(水) 12:35:58.13

>>17
今までjQueryがクソという話が出てないんだから
否定がないのは当たり前だろｗ

お前がこのスレではじめて言ったが明確に否定するよ
jQueryはクソではない

**デフォルトの名無しさん** · 2020/10/28(水) 12:40:55.43

>>16
覚え直しという無駄な学習コストの三重苦

Reactは将来移行しなければいけないほどの作業がありますんで
覚悟しておいてください。大丈夫！移行の問題を緩和する仕組みも作りました。
2つのバージョンを共存できるんです！同時に2つのバージョンを使えばいいんです！

React 17では、将来のReactバージョンへの移行の問題を緩和
https://www.infoq.com/jp/news/2020/10/react17-easy-future-migration/

> Reactチームは、React 16の2年後にReact 17（最初のリリース候補版）を最近リリースした。
> React 17は、2つの同時バージョンが共存できるようにすることで、
> Reactの将来のメジャーバージョン間の移行が簡単になるよう努めている。

他にも沢山変更したいことはあるのですが、移行は大変なので
React 17の後に延期しましたよ。えっへん！

> 特に、React 17は「足がかり」のリリースであり、あるバージョンのReactで管理されているツリーを、
> 別のバージョンのReactで管理されているツリー内に安全に埋め込むことができる。
> […]他の変更はReact 17の後に延期しました。

**デフォルトの名無しさん** · 2020/10/28(水) 12:40:57.19

いやまあクソやろ

**デフォルトの名無しさん** · 2020/10/28(水) 12:48:48.73

jQueryの凄さにAPIの互換性が高いという点がある。
最新版のjQueryは2020年4月にリリースされた3.5だが
おそらく1.10あたりでもほぼ同じように使える
1.10がリリースしたのは2013年だ

**デフォルトの名無しさん** · 2020/10/28(水) 13:21:16.49

進化しなかったのねーー

**デフォルトの名無しさん** · 2020/10/28(水) 14:21:23.16

jQueryで成長が止まった残念なおじさんｗ

**デフォルトの名無しさん** · 2020/10/28(水) 15:48:02.16

それはあるね
JSのフレームワークに限らないけど、ライブラリーがバージョンアップの度に破壊的な変更を繰り返して、ライブラリーの更新に合わせて本体を修正するより本体を新規に作り直した方がマシというのはよくある
それで廃れたのがRailsだと思う

**デフォルトの名無しさん** · 2020/10/28(水) 17:26:28.99

確かにrailsは特に酷い。
railsはrubyと、大量のgemに依存してるだろ？
うっかりrubyのバージョン上げようものならマイナーバージョンアップでも動かなくなるgemが大量に出てくる。
それぞれのgem作者がrubyの破壊的仕様変更に対応しないと今まで使えてたgemが使えない。
これで昔は一世を風靡してた今は使えないgemがかなりある。
だんだんこんなのやってられるか、ってgem作者がrubyワールドから離れてくから。

**デフォルトの名無しさん** · 2020/10/28(水) 18:15:48.06

Rubyっつうかウェブ系オープンソース文化はみんなそうだろうな
だからマイクロソフトの.NETがいいんだよね
C#だとほぼ公式のパッケージだけで一通り揃ってて快適に開発できる
互換性の問題もゼロにはならないがほとんど考えなくていい

**デフォルトの名無しさん** · 2020/10/28(水) 18:56:26.31

「フレームワークの使い方覚えた、成長したぞ」

その機能は非推奨になりました。これからはこっち使ってね。もっと簡単だよ！

「せっかく成長したのに、なかったことにされた。しかも前より簡単って苦労して覚えた努力は一体・・・」

Angularはそうなったね
Reactもそうなるみたいだね
そのうちVueもそうなるんだろうな

使い方を覚えるのが成長とか思ってるからそうなる

**デフォルトの名無しさん** · 2020/10/28(水) 19:18:08.22

ヘッダーとかフッターとか
ナビゲーションメニューとか
ハンバーガーメニューみたいなの考えた奴死ねよ
めっちゃ開発しにくいだろ

**デフォルトの名無しさん** · 2020/10/28(水) 19:18:18.34

成長どうの語る前に勉強しろよ

**デフォルトの名無しさん** · 2020/10/28(水) 21:39:03.34

>>29
この発言からして本当にjQueryの時点で成長が止まったままの
おじさんらしいなｗ

フレームワークで使われてるイディオムみたいなものは
ネイティブで自前実装するときにも活きてきたりする
実力の底上げになるんだよ
デザインパターン覚えたりしたときみたいにね
お前はそこが限界だったんだなｗかわいそうにｗ

**デフォルトの名無しさん** · 2020/10/28(水) 21:40:50.17

バージョンアップごときの変化についていけないのはエンジニアとして終わってるよｗ

**デフォルトの名無しさん** · 2020/10/28(水) 21:46:09.34

初めて触るフレームワークだったとしても
普通に1つの仕事やる間に基本＋ちょっとした応用くらいのことは身につけられるし
「学習する労力」というほどのことじゃない
jQueryバカは本当に学習能力が低すぎて辛いのかもしれないがｗ

**デフォルトの名無しさん** · 2020/10/29(木) 11:09:35.04

BlazorってクライアントサイドEFCoreってできんのかね？
Queryableをシリアライズして飛ばすだけだからできそうなもんだが

**デフォルトの名無しさん** · 2020/10/29(木) 11:11:13.80

クライアントEFCoreが実現したらGraphQLが要らなくなりそうだ

**デフォルトの名無しさん** · 2020/10/29(木) 12:03:49.84

>>35
https://blog.jeremylikness.com/blog/ef-core-and-cosmosdb-with-blazor-webassembly/

**デフォルトの名無しさん** · 2020/10/29(木) 12:14:17.20

MSKK必死だな（藁）

**デフォルトの名無しさん** · 2020/10/29(木) 12:28:48.42

>>37
へーもうあるんだ
今までRESTだのGraphQLだのgRPCだのと色々と疲弊してたのって何だったんだろうな

**デフォルトの名無しさん** · 2020/10/29(木) 15:52:40.12

>>30
ハンバーガーは最悪
開発する方だけじゃなくて
ユーザー側も使いにくいわ

**デフォルトの名無しさん** · 2020/10/29(木) 19:10:36.91

>>30
お前が無能なだけだろ
こんなチンケなものすら作れねえのかよ

**デフォルトの名無しさん** · 2020/10/29(木) 21:46:29.31

React使って生産性とか管理しやすさとか
幻想だからよ。
そもそも「管理しやすさ」っていう漠然としたものがなんなのか
と言うのが人によって認識が違う訳よ
オブジェクト思考がなんなのかって事延々と考えるのと同じよ
SQL HTML CSS JavaScriptだけでも覚えること大量にあるのに
それを覚えたばかりの人間がそんなこと理解出来るわけがない
GUIなんて千差万別あるのにReact使ったくらいで
簡単に共通化や再利用などできるわけが無い

そんなくだらない幻想のために一度覚えたHTMLやJavaScript
をまた文法変えて覚え直しさせれられる苦痛が分かるか？
そんなもんに学習コストかけるくらいなら
ネイティブのDOMのコーディングスピードとセンスあげて
毎回ゼロベースで作った方がシンプルで余程生産性が高いに決まってる

共有化さまくってるパーツを使うストレス、
共有化パーツに頼りまくってる画面を解析して改修するストレスがどんなものかぐらい想像つくだろ
コードを使い捨てることが出来る安心感
ネイティブであることの信頼感。これぞ至高

**デフォルトの名無しさん** · 2020/10/29(木) 22:07:56.68

>>42
何が言いたいのかまったくわからん
React使ったらhtmlは文法変えてんの？
変えてねーだろアホかこいつ

**デフォルトの名無しさん** · 2020/10/29(木) 22:37:42.80

いやいや共通化はしとけよ
ReactだろうがjQだろうがバニラだろうがそこは同じだ

**デフォルトの名無しさん** · 2020/10/29(木) 23:08:35.79

>>43

★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

**デフォルトの名無しさん** · 2020/10/29(木) 23:08:58.57

>>44

★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

**デフォルトの名無しさん** · 2020/10/30(金) 21:30:34.87

シングルページってアイデア、結局要らなかったな
URL変わったらloadし直してくれたほうがシンプルで良い

**デフォルトの名無しさん** · 2020/10/30(金) 21:41:48.97

アホには使えないからあっち行け

**デフォルトの名無しさん** · 2020/10/30(金) 22:03:55.00

いちいちURLを変える必要がなくなったというだけ

**デフォルトの名無しさん** · 2020/10/30(金) 22:32:52.75

ふつうクライアントサイドルーティングで変えるけどな。エアプ乙。

**デフォルトの名無しさん** · 2020/10/30(金) 23:25:04.93

ページの初期化は
ブラウザ駆動で
location.reload()でいつでも状態消去出来る
それより、保持し続けたかった画面状態が
画面遷移で消滅してしまう方が問題
保持してるものを破棄するのは簡単だが
無いものを引き継がせたり復元したりするのは大変
ならばセッションに保持しようとすると
今度はそれが残り続けて不具合の要因になる
セッションは意識して破棄するのは面倒
そう考えるとSPAで画面遷移減らすのが最適解

**デフォルトの名無しさん** · 2020/10/30(金) 23:50:46.09

★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

**デフォルトの名無しさん** · 2020/10/31(土) 04:18:19.38

確かに少なくともURLは変わった方がいい

**デフォルトの名無しさん** · 2020/10/31(土) 12:34:03.58

SPAが叩かれるのはSPAを前提としたビューを切り替えたりする
ビューの下らないテクニックが嫌われるだけであって

SPAの考え方自体が悪いわけではないと思う
SPAは基本的にAjaxをバンバン飛ばすから
Ajaxが叩くURLというのは分離されている
画面と関係の無いURLを気軽に定義出来るようになり
「画面」と「画面遷移」だけを減少させることが出来る
URLは減少しない、むしろ更にきめ細かくできる

**デフォルトの名無しさん** · 2020/10/31(土) 12:37:15.04

シングルページにこだわる必要はないと思う
2個でも3個でも構わないが
とにかく無駄な画面遷移を減らす事が重要

**デフォルトの名無しさん** · 2020/10/31(土) 13:27:15.39

ブラウザに無駄に大量の履歴が残るのを防止出来るし
終わったsessionに対して変に履歴から横入りも防止出来るしメリット多い

**デフォルトの名無しさん** · 2020/10/31(土) 13:33:14.30

単純にさ、メンテナンスしやすいように小さく分けろってことなんだよね
どうしても密結合しなきゃならないっていうなら話は別だけど
そうでないなら結合度は低く保つのはシステム開発の常識なんだし

**デフォルトの名無しさん** · 2020/10/31(土) 13:59:51.18

小さく分けるなら別のページにしたほうがわかりやすいんだよね
開発者もユーザーも

**デフォルトの名無しさん** · 2020/10/31(土) 14:06:46.75

別にそんなことないが

**デフォルトの名無しさん** · 2020/10/31(土) 14:11:33.12

ルーターつかえてんのかな？

**デフォルトの名無しさん** · 2020/10/31(土) 14:19:10.79

単にケチつけたいから理由を無理やりひねくりだしてるように見える
パヨ野党と同じ

**デフォルトの名無しさん** · 2020/10/31(土) 14:32:47.48

単に能力不足の認識すらないだけかと

**デフォルトの名無しさん** · 2020/10/31(土) 15:03:24.58

まあ待て
WebAssemblyが全てを薙ぎ倒す

**デフォルトの名無しさん** · 2020/10/31(土) 15:25:03.69

まであと50年？

**デフォルトの名無しさん** · 2020/10/31(土) 15:56:06.31

UNITYの事かな？

**デフォルトの名無しさん** · 2020/10/31(土) 19:30:23.25

単純明快にページを分ける、というやり方をやめて、わざわざ処理を追加して無理矢理ページ内で遷移したように見せかけるという、複雑で愚かな選択
これによりTwitterのサムネがおかしくなったり様々な問題を招き入れてしまった

**デフォルトの名無しさん** · 2020/10/31(土) 20:10:22.22

バカは黙ってろ

**デフォルトの名無しさん** · 2020/10/31(土) 21:02:58.40

ここでグダってないでツイッター社に説教して来いよもう

**デフォルトの名無しさん** · 2020/10/31(土) 22:26:48.89

ツイッターは一例でしょ。しょぼい会社じゃなくて
ツイッターレベルであっても対応に苦労しているという話だ

**デフォルトの名無しさん** · 2020/10/31(土) 22:44:41.94

SPA基本のルーターすらしらんやつが
わめいてるけど無視した方が無難かな。

**デフォルトの名無しさん** · 2020/10/31(土) 23:02:30.40

>>70
今そんな話してないよ
グローバルに保持してる状態の話をしてる

**デフォルトの名無しさん** · 2020/10/31(土) 23:54:28.99

今そんな話してない（恥ずかしいから蒸し返すな）

**デフォルトの名無しさん** · 2020/11/01(日) 00:03:13.60

>>67
匿名掲示板だと反論できなくなった人ってすぐ悪口言うよねｗ

**デフォルトの名無しさん** · 2020/11/01(日) 00:15:18.28

謎文脈を発生させて論点をずらす奴もいるけどな

**デフォルトの名無しさん** · 2020/11/01(日) 10:16:49.22

>>66
だからその無理やりページ遷移したように見せかける
っていう部分だけが愚策なんだって

ページ自体が複数も要らないんだよ
見かけ上のページも複数要らない

**デフォルトの名無しさん** · 2020/11/01(日) 12:27:33.30

表面上SPAの癖に
時々別のURLに飛ばす造りって
単にSEO対策なんだろ
SEO稼ぐにはURL多い方が良い
SPAの使い易さとSEOは無関係

**デフォルトの名無しさん** · 2020/11/01(日) 12:30:09.02

別のURLに飛ばしてOKなものなら、飛ばしたほうがいいじゃん
状態を引き継ぐよりもステートレスの方がいいんだから

**デフォルトの名無しさん** · 2020/11/01(日) 12:38:01.74

>>77
それな
ステートフルすぎて気持ち悪い

**デフォルトの名無しさん** · 2020/11/01(日) 13:03:27.79

アプリケーションは内部状態を持つのが当たり前だが、その状態をサーバー側に持つか
クライアント側で持つかの違いだけじゃね？
どっちかというとサーバー側とそのAPIがステートレスになってくれた方が嬉しいと思うが。

**デフォルトの名無しさん** · 2020/11/01(日) 13:10:01.61

ステートフル”すぎる”な
表示してない物の状態まで持つな
ページを切り替えるなら状態をクリアしろ
切り替えたように見せかけて裏で状態を維持するとか最悪だぞ

**デフォルトの名無しさん** · 2020/11/01(日) 13:14:42.09

>>80
おめー無知すぎんだろ
SPAフレームワークをページ遷移だけで見てるからそれしか言えねえんだよ

**デフォルトの名無しさん** · 2020/11/01(日) 13:22:07.47

”すぎる”と”すぎない”の境界がわからんなぁ。
気持ち悪く感じるのは主観だろうからどうしようもないが。

**デフォルトの名無しさん** · 2020/11/01(日) 13:36:14.94

>>81
俺はMVC+Vue.jsのような軽い使い方までは否定してない
SPA的な全部JSでやっちゃえって考え方が駄目だ

**デフォルトの名無しさん** · 2020/11/01(日) 15:59:43.06

webサイト画面構成のビューの作法というか
テンプレみたいなのを誰かが勝手に定義するから
害悪になるんだって
Webサイトにはヘッダーフッターやサイドバーや
ナビメニュー、バーガーメニューがあるべきとか
パンくず付けるべきだとか
SPAのサイトは見かけ上のURLで画面を切り替えるように
すべきとか、こういうの一体誰がなんの権限があって
決めてんの？
実装がどれだけ面倒になるかも考えずにさ
ビューの構造考えてる奴らに「シンプルにしろよ、馬鹿が」
って言ってやりたいわ

**デフォルトの名無しさん** · 2020/11/01(日) 17:46:49.50

>>84
音声ブラウザで適切に読むため

**デフォルトの名無しさん** · 2020/11/01(日) 17:52:41.96

馬鹿たちかい。
サーバーサイドでステート維持するのは
実装大変だし、バカ高いコストになりますよ。

スケールの設計とかした事あんですかね？

**デフォルトの名無しさん** · 2020/11/01(日) 18:17:26.00

ステートサーバー用意するだけだな
簡単にスケールする

SPAにすると最初はフロントにステートがあったんだけど
SEOとか諸々の事情でやっぱSSRにしなきゃってなって
サーバーサイドにめちゃくちゃステートを持つことになる
ステートをスケールしたいだけなのにフロントもスケールもしなきゃならなくなって最悪

**デフォルトの名無しさん** · 2020/11/01(日) 18:42:58.59

>>87
スーテトサーバー

笑

**デフォルトの名無しさん** · 2020/11/01(日) 18:49:19.76

SSRにしたらサーバーにめちゃめちゃステート？笑
エアプここに極まるｗｗｗ

**デフォルトの名無しさん** · 2020/11/01(日) 18:53:46.69

>>88
なにわろてんねん

>>89
お前がエアプ