Vue vs React vs Angular Part.4

■ このスレッドは過去ログ倉庫に格納されています
2020/06/11(木) 19:01:45.26ID:uGsh0NQC
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.3
https://mevius.5ch.net/test/read.cgi/tech/1560333895/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
2020/07/26(日) 16:13:52.38ID:wM09/xME
>>726-727
SPA調べてまさにそのSPAの中途半端さに気付いた
UXも開発スピードもNative appが最強だから
業務系ならnative appだけもあり

SPAは開発のコストと時間かかるわりにUX改善はたいしたことない
しかもサポート期間が短くメンテナンスも金がかかる
2020/07/26(日) 16:17:08.52ID:cZIElTbP
blazor wasmで殴りこんで来て今度はネイティブアプリって
マジで何しに来たんだ
2020/07/26(日) 16:23:42.24ID:2YJHPn7i
>>735
ネイティブと比べた時のBlazorの利点はセキュリティと配信しやすさ
サポート期間と開発生産性はマイクロソフトだから心配してない
2020/07/26(日) 16:27:20.70ID:wM09/xME
>>734
WindowsならGroup policyとかのシステム管理機能で
Applicationの自動インストールとかできるしdeployは楽だよ

JavaはORACLE所有になってライセンス実質有料になったし
ますます下火になるでしょう
2020/07/26(日) 17:35:09.81ID:zlLRIuAw
SPAフレームワークが使えないんじゃなくてオメーらゴミエンジニアが使えるレベルに達していないだけな
2020/07/26(日) 18:00:38.42ID:ZAj9kjW9
どっちにしても、今のSPAフレームワーク使っている奴ならこれからwasmやblazorとかが台頭してきても
それらが使い物になってから手を出しても全然遅くないだろう。
今phpやrailsとかで食えている人ならそもそもwasmに手を出す必要性すらないかもしれない。
2020/07/26(日) 18:03:22.00ID:2YJHPn7i
使うなら使うで問題ないが、使う価値があるか、は全く別の問題だからなぁ
バカだったら、なんか知らんけど新しいもの、ぐらいの軽い気持ちで採用しちゃんだろうけど
2020/07/26(日) 18:08:17.16ID:8c+LEo48
>>740
WordPressで済むようなWebサイトにJSフレームワークを入れるのが非効率なのと同様
一般的なWebにwasmなんて不要なはずなんだよ
canvasにゴリゴリレンダリングする様な演算回数が多い様な場合とかそういう場合だよね必要になるとすれば
2020/07/26(日) 18:10:19.01ID:pVqRHFCg
>>733
> SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ

失われないよ
SSRの仕組みは下記記事分かりやすいからおすすめ
https://qiita.com/amakawa_/items/e7d0720e1ab8632769bf


> SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損

同じこと書くけどGoogleに限ればSPAでもSEO的に問題ない
それにSSR・SSGなら他検索エンジンでもSEO的に問題ない
GoogleはJSを読んでくれるっていうのも結構前の話だから、今は他検索エンジンでもOKなやつあるかも
2020/07/26(日) 18:12:53.56ID:pVqRHFCg
YahooもGoogleのエンジン使ってるみたいだから多分YahooもSPAでSEO的におけやね
2020/07/26(日) 19:08:50.21ID:aJKoeTZN
SPAでもSEO的に問題ないんじゃなくて
SEO的に問題ないSPAを使うべきだよ

SPAが高速っていうのは2ページ目以降の話で
1ページ目は結局全体を読み込むんだから
静的ページとほぼ同じものをサーバー側から返すようにするべき
そうしないとJavaScriptの処理でレンダリングが遅くなる

2ページ目以降は速いなると言うがGoogleのクローラーなんかはページ読み込みの
タイミングはバラバラなので2ページ目以降も1ページと同じように読み込む。
そうするとSPAの速いっていうこうかがなくなる
ページ読み込みの速さもSEOで重要なので、どのページを最初に読み込んでも
JavaScriptなしで表示されるようにするのが正しいやり方
2020/07/26(日) 19:09:51.27ID:aJKoeTZN
ようするに2ページ目以降JavaScriptあり（SPA）で表示する
1ページ目JavaScriptなしで表示する
これを実現するためにSPAでサーバーサイドレンダリングは必須なの
2020/07/26(日) 19:15:51.29ID:BJnciPIh
SEOを考えるような内容のサイトでSPAが効果的な物って例えばどんな物がある？
pgadmin4のような高度なappならSPAが効果的って主張は理解できる
だけどqiitaのようなsiteにSPAを使うメリットは無いと感じた
伝統的なsiteの振る舞いと異なるから直感的な操作感で言うとマイナスまでありえる
2020/07/26(日) 19:16:05.21ID:8c+LEo48
寧ろSEOが必要ない様な利用者が限られる部分に使うべきなんだよ

EC的なものなら確かにシステム的な側面とSEO的な側面の両方が必要だけど
それ以外のシステムならそもそもトップページ以外検索エンジンにヒットする必要ないものって結構多いはず
2020/07/26(日) 19:22:21.71ID:1X4Tbs5Z
SS
2020/07/26(日) 19:25:42.98ID:1X4Tbs5Z
SSRはバックエンドのリソース消費量が増えるから嫌だな
クラウドだとコストにも響いてくる
2020/07/26(日) 19:27:42.35ID:ydM4arRa
>>747
ないと思うよ。だからReactとかvueとかの
ウェブアプリ用フレームワークはjQueryの代替にはならないし
ウェブサイトがウェブアプリに作り変えられることもない
俺がもう5年ぐらい前に出した結論

そしてこの5年のjQueryのシェアの増え方と
フレームワークのシェアの増え方を見ればそれが
正しかったと証明されてる。
2020/07/26(日) 20:02:03.99ID:BYN8HZ/f
しかしそう考えると、学ぶべきフレームワーク、人気のフレームワークといった文句でSPAフレームワークが紹介されるのはなぜなんだろう？
そんなに人気があるなら、採用するサイトも増えるはずだけど、ほとんど見かけない
SPAフレームワークを覚えた人は何処で働いていて、どんな成果物を残したのか？
このスレの人の手がけた公開サイトがあるなら、ぜひ知りたい
2020/07/26(日) 20:22:09.40ID:zlLRIuAw
業務用Webアプリの開発に使うからだろ
Webアプリ作れないゴミエンジニアは格安だから使えなくていいんだよ
2020/07/26(日) 20:24:15.75ID:0MyKPfk8
業務用アプリだとC#のほうがいいね
2020/07/26(日) 20:26:03.01ID:pVqRHFCg
>>752
SaaSで使われまくってるよ
てか求人サイトでフレームワークの名前で検索するといっぱい出てくる
静的なWebサイトだとツールのドキュメントとかコーポレートサイトでちょくちょく見かけるかな
SasSでもWebサイトでも無い感じのやつだとTwitterとかYahooとかPixivとか
2020/07/26(日) 20:29:12.45ID:zlLRIuAw
>>754
裏は好きなの使えばいい
2020/07/26(日) 20:52:24.56ID:8c+LEo48
>>752
見かける見かけないってそもそもブラウザにインジケーターアドオン入れてから言ってくれよ
どうせ入れてないんだろ？
2020/07/26(日) 22:06:58.75ID:6PuC7aMz
ふーん
で、何割ぐらいのサイトでSPA使われてんの？
2020/07/26(日) 22:49:08.46ID:rfO/oa4K
誰も知らないだけでたくさん使われてるよ
2020/07/26(日) 22:51:16.76ID:J91SE58H
誰も知らないことをなんで知ってるの？
2020/07/26(日) 22:53:37.55ID:zlLRIuAw
ゴミサイト含めたら圧倒的にほんの少しだろ
そんなにゴミサイトが気になるなら一生気にしていればいい
762デフォルトの名無しさん
垢版 |
2020/07/26(日) 23:03:35.73ID:iYDWpAIp
なんでそんなにSPAを敵視すんの？
2020/07/26(日) 23:06:58.57ID:Lwmxod4b
自分が分からない・作れない技術が普及したら恥ずかしくて困るから。
それに対するアクションがこんな辺鄙な場所でジタバタ足掻くこととはねｗ
こりゃ仕事できませんわｗ
2020/07/26(日) 23:10:26.86ID:8c+LEo48
寧ろ
・Wappalyzer
・React Developer Tools
・Vue.js devtools
・Augury
これらの拡張機能(アドオン)を入れずにどうやってないって判断してんだよ
2020/07/26(日) 23:11:26.10ID:tvVrKRgD
敵視はしてないが純粋に疑問なんだ
これがどれほど役に立つのか
噂に聞くほどの実績が本当にあるのか
今のところそれほど有用ではなさそうだなといった感想
それを覆すほどポジティブな意見が見られない
2020/07/26(日) 23:21:06.77ID:ZAj9kjW9
そのプログラミングモデルを自分で気に入るか気に入らないかでいいと思うがねぇ。
自分に合わないと思うなら別に使わなくていい。
2020/07/26(日) 23:31:12.58ID:zlLRIuAw
現に俺様がSPAフレームワーク使って業務アプリ作りまくってるんだからこれが正しいんだよ
SPAフレームワーク使わなかったらもっと開発に時間かかる
さらに実際の業務にも時間がかかるようになる

オメーが知らねえだけで世界を知った気になるな
768デフォルトの名無しさん
垢版 |
2020/07/27(月) 00:08:34.56ID:Ri9S2nsL
フレームワーク自慢程反吐が出るものは無い
フレームワークは何でもそうだけど

フロントサイドだったら
必ずしも全員がHTMLや
CSSの仕様を完璧に理解している訳では無い
View層は特にやり方に絶対の正解がない
DBMSみたいなカッチリとしたデザパタはない。

フレワなしの純粋なHTML CSS
JavaScriptだけなら最初から全てを知っている必要なくて
必要なところだけ即興でググって記述することで
細かな調整ができるけど

フレワでそれを隠蔽したら
頭の中にCSSやHTMLの仕様を完璧に知っている必要がある
まずググるのが難しくなる
必要な箇所だけ自力で修正する事が難しくなる
フレワが自動生成するコードが増えるほど
DevToolsでの解析が難しくなる
自動生成されたclass属性のどれがどんな効果を持っていて
DOM要素にどのような影響を及ぼしているのかの
推測が立てにくくなる

そしてそれを頭の中に完璧に理解してる人間なら
HTMLやCSSや普通のJavaScriptを書いた方が早い
新たにフレワの文法を覚えるのが馬鹿馬鹿しい。
フレワが何種類も乱立してたらなおさらだ。
2020/07/27(月) 00:15:47.58ID:b6SXhPTe
>>768
オメーがゴミなだけだろ
htmlとcssができないってどんだけ低レベルなんだよ？
デブツールみてわからんとかゴミクズじゃん

とにかくできない奴が声高々に吠えるな
ここにきちんとできている俺様がいるのにゴミが勝手に決めつけんじゃねえよ
2020/07/27(月) 00:21:48.49ID:c0Q45HfR
>>769
スマンな俺もUI/UXのフレームワークに頼りっきりでCSSは微調整以外は碌に書けん
2020/07/27(月) 00:23:19.80ID:vIJ2AS+M
このスレはいつみても
どうでも良いことで
盛り上がってんな
2020/07/27(月) 00:38:02.84ID:rA5gK0Vx
外部向けサイト⇒SPAより非SPAのが向いてる
社内向けサイト⇒人材と既存資産が豊富なC#が有利⇒Blazor
773デフォルトの名無しさん
垢版 |
2020/07/27(月) 00:42:11.06ID:UrkoV9IC
>>765
？
Webアプリ作るなら今のところ最適解がSPAだろ？
なんで化石も含めて大量にあるWebサイトの中でどれくらいの割合使われてるか知りたいの？
2020/07/27(月) 00:44:08.53ID:PSP0suJc
> Webアプリ作るなら今のところ最適解がSPAだろ？

たまたまSPAになってるだけだと思うけどな
通常はAjaxで十分だと思うよ
2020/07/27(月) 00:46:12.83ID:c0Q45HfR
>>773
スマホを視野に入れたPWAならSPA構成でいいと思う
2020/07/27(月) 00:49:34.50ID:PSP0suJc
PWAとSPAにどういう関係があるの？
2020/07/27(月) 00:50:57.41ID:b6SXhPTe
ゴミクズの知識の薄さがやべえな
2020/07/27(月) 01:18:09.78ID:PSP0suJc
流れをぶった切って悪いけど、SPAでレスポンシブに
対応したフレームワークって何がある？
2020/07/27(月) 01:20:38.79ID:sZwTyFBE
>>773
最適じゃないからPHP、Ruby、Pythonなどの伝統的なフレームワークが選ばれる
SPAは僅かな領域だけでしか通用しない
2020/07/27(月) 01:29:33.69ID:c0Q45HfR
>>778
Bootstrapでも入れたらいいんじゃないか？
BootstrapVueでもReact BootstrapでもNative JavaScript for Bootstrap本家Bootstrap5αでも選択肢は選り取り見取り
2020/07/27(月) 01:32:36.13ID:PSP0suJc
でもBootstrapはDOM操作をするだろ？
そうするとフレームワークと一緒に使えない
2020/07/27(月) 01:37:23.48ID:c0Q45HfR
>>781
上に挙げてるが
BootstrapVueやReact Bootstrapのようにフレームワークに特化したパッケージもちゃんとある
2020/07/27(月) 02:16:55.64ID:o3qaYBwJ
>>781
わろたｗｗｗ
2020/07/27(月) 02:31:44.31ID:TfnjDE3E
>>778
スレタイのうちどれ使ってるの？
ReactならChakraUI超オススメ。
2020/07/27(月) 05:19:08.57ID:P2Gsimd7
Rails + React + Bootstrap

Bootstrap は、CSS/SASS を知らなくても、簡単に見た目を整えられるから、
GUI に弱い、サーバー側開発者にとって必要

Rails 6.0 からは、Webpack が標準になったから、Node.js も必須

API モードもある。
描画せず、JSON だけで、やり取りする
2020/07/27(月) 06:55:20.10ID:UFheIHQs
>>765
お前のその疑問に>>755が答えと探し方、>>764が確認の仕方を書いてくれてるやん
その感想が探してない、確認していない、認めたくない、ってことの証明になってるよ
2020/07/27(月) 07:43:46.66ID:Mg1HGRsd
>>786
>>755
使われまくってる⇒子供か
いっぱい出てくる⇒子供か
ちょくちょく見かける⇒子供か
求人サイトで〜⇒求人に乗ってる情報なんて極々僅かな割合でしかない
Twitterとか〜⇒事例たったの3つしか挙げられないのか

>>764
アドオン〜⇒ウェブ全体を走査する方法がわからねえだろ少しは考えてレスしてくれ
2020/07/27(月) 08:15:16.74ID:c0Q45HfR
そもそも>>752が見かけないっていうから
どうやってない事を確認したんだ？って話じゃん
2020/07/27(月) 10:42:39.38ID:7YZXD5wT
ぶっちゃけてしまうとね

コンサルの養分です
2020/07/27(月) 12:14:51.29ID:q4lb5yU9
SPAの短所いろいろ書いてSPAって必要なの？って書いたら
批判、炎上するかと思ってたけど予想外にそうならなかった。
SPAに興味ありつつもSPAで開発経験ある人少ないってことだな

SPAは短所もあるからSPAのframework決める前に
SPAでやるかどうかをしっかり考えて決めるべきだと思う。
明らかに向かない用途ってある

SEO以外にもセキュリティ低下とか、開発工期、コスト上昇
JS-SPAなら短いサポート期間とか
2020/07/27(月) 12:35:21.60ID:cUoRU5UD
SPAは目的じゃないからね
ページの一部を動的に変更するならただのJavaScriptでいいし
全体に近いぐらい変更するならページ移動しても大差ない。

それに下手するとSPAにすることでユーザビリティが低下することがある
例えばURLをブックマークに入れてもそのページにたどり着けなかったり
ブラウザの進む、戻るがまともに機能しなかったりする

ユーザビリティの設計は難しくなるのにその設計をしないで
フレームワークを使ったからSPAになりました。
なにも工夫してないけどSPAなら速くなってるんでしょ？なんて
適当にやってる人が大半

ゲームやフォトショップみたいにアプリ（ウェブアプリ）を起動して
そこからデータファイルを読み込んで編集するツールならいいけど
ページ移動が行われるようなSPAはページ設計が重要になってくるのに
それを理解していない
2020/07/27(月) 12:36:04.26ID:q4lb5yU9
>>743
SSRだと更新は差分のみだから速いっていう主張だと思うけど
serverもUAも負荷が高くなければページ全体の更新でも
高速にレンダリングできるでしょう

UA側はPCはもちろん2万円の中華SPでもサクサクページ全体を開ける性能ある。
server側の性能さえ十分確保すれば差分更新かページ更新かは
あんまり問題にならないと思う
793デフォルトの名無しさん
垢版 |
2020/07/27(月) 13:14:37.14ID:q4lb5yU9
>>764
Wappalyzer
Firefoxにいれてみたけどおもしろいな

大手でもSPA web frameworkの採用の少なさに気付いた
React人気と言ってる人多いがReact系のweb frameworkはあまり使われてない
ただのUIのライブラリとしてReactを使ってるだけってところばかり
Twitterもそう

>>708
Googleが作ったというにAngular自社で使ってないのが笑えるな
YouTubeはPolymerしか検出されない

Google MapもSPA framework使ってない
Vanilla JSでゴリゴリ書いてるんだろうな
2020/07/27(月) 13:19:03.18ID:b6SXhPTe
WebサイトみてReactとか使われていないとかいうゴミがいたらオメーの認識が未だに改まってねえからさっさと治せとしか言えない
2020/07/27(月) 13:21:55.01ID:hYUf9ncg
>>794
誰もReact使ってるサイトがゼロとは言っていない。
React使ってるサイトは0.4%程度だと言ってる。
796デフォルトの名無しさん
垢版 |
2020/07/27(月) 13:24:09.61ID:FyobjYdi
ExtJS 使ってた人居る？
2020/07/27(月) 13:28:57.64ID:q4lb5yU9
>>781
メジャーなframeworkで
bootstrap使えないやつないんじゃないか
2020/07/27(月) 13:43:11.84ID:DcqVOXlA
だから言ったじゃん


コンサルの養分なんだよキミタチ
2020/07/27(月) 13:47:44.32ID:Rr+dRFNS
>>792
SSRはサーバー負荷めちゃ高まるから嫌だ
このサーバーレスの御時世では最悪の選択肢1つと言って過言ではない
だいたいサーバーサイドに状態を持たせるとか大昔に逆行してるし
2020/07/27(月) 13:52:43.84ID:TfnjDE3E
つまりGatsby最高！
う〜んマンダムｗｗｗ
2020/07/27(月) 13:56:40.28ID:hYUf9ncg
>>799
サーバーサイドに状態を持たせないで作れるものを言ってみ
例としてオンラインゲームは無理な
2020/07/27(月) 14:01:10.49ID:Rr+dRFNS
>>801
なんでもいいよ
セッション持たないRESTな設計なんて今どき珍しくもない
メモリキャッシュとか言い出しそうだから予め言っとくが
これは高速化のためであってSSRのようにしかたなくリソース食いつぶすゴミとは真反対だからな
2020/07/27(月) 14:04:19.38ID:S26P/GM8
> セッション持たないRESTな設計なんて今どき珍しくもない

HTTPはセッション持たないじゃなくて持てないんですが？
あれあれ？すべてのウェブサイトはサーバーサイドに
状態を持たないって話でいいですか？ｗ
2020/07/27(月) 14:08:52.18ID:S26P/GM8
セッション持たないRESTってなんですかね？
どのユーザーでも同じデータ返すって言ってるんですかね？ｗ
2020/07/27(月) 14:16:28.42ID:O6ncpH5Z
>>804
バカかな
状態持たなくてもリクエスト（パラメータ）に応じて結果変えられるじゃん
RESTではこれが基本
セッションオブジェクトはあまり使わない
2020/07/27(月) 14:19:17.79ID:S26P/GM8
>>805
セッションオブジェクトはリクエスト（パラメータ）に応じて結果変えてるので
サーバーに状態は持っていません

はぁ、仕組みを知らないんだな
フレームワークばっかり使ってるから
そういうアホなこと言うんやで（笑）
2020/07/27(月) 14:20:28.76ID:S26P/GM8
>>805
あとはURLにセッションIDを入れる方式は
セキュリティ的に脆弱なもの扱いだからな
そんなもの提案したら素人だってバレるでｗ
2020/07/27(月) 14:21:53.57ID:O6ncpH5Z
ん？なんか俺おかしなこと言ったか？
2020/07/27(月) 14:24:54.73ID:S26P/GM8
言ってますねｗ　気付いて無いんですねｗ

HTTPの仕組みを知ってるのであれば
状態をもたせるやり方を言ってみ
2020/07/27(月) 14:29:25.84ID:O6ncpH5Z
サーバーにセッションオブジェクト（メモリ）を確保する
セッションオブジェクトに対してセッションIDを発行する
セッションIDリクエストパラメーターやクッキーで維持される
クライアントは複数のリクエストに渡って同じセッションIDをサーバーに渡すので
サーバーはクライアントのリクエストの連続性（セッション）を認識できる
またセッションIDからセッションオブジェクトを引くことでセッションの状態（情報）を継続利用できる

間違っとる？
2020/07/27(月) 14:30:08.08ID:S26P/GM8
>>810
RESTでも同じことをしてる
2020/07/27(月) 14:30:48.23ID:S26P/GM8
ああもしかして、セッションID＝リクエスト（パラメータ）だって知らないのかなｗ
2020/07/27(月) 14:31:03.28ID:S26P/GM8
セッションIDが魔法の技術とか思ってそうｗ
2020/07/27(月) 14:32:52.85ID:O6ncpH5Z
いやRESTはセッション使わない構成多いよ
REST＝関数のイメージ
引数に対して戻り値が返る
引数はリクエストパラメーター、戻り値はレスポンスね
RESTは一問一答で完了するパターンが多い
以前のREST呼び出しの内容な作用されない
だからセッションオブジェクトを使わないと言っている
2020/07/27(月) 14:33:59.07ID:S26P/GM8
http://itdoc.hitachi.co.jp/manuals/3021/3021901610/HCSR0051.HTM
REST APIでは、セッションを使用して、複数のリクエストを同一クライアントによる一連の操作として識別します。
2020/07/27(月) 14:34:05.80ID:O6ncpH5Z
セッションIDはリクエストパラメーターになることはあるけど
リクエストパラメーターがセッションIDということなはならんよ
2020/07/27(月) 14:35:55.62ID:O6ncpH5Z
/add?param1=123&param2=456
この足し算RESTにセッション要るか？
このパラメーターがセッションIDなのか？
2020/07/27(月) 14:36:39.82ID:S26P/GM8
OWASPの"REST Security Cheat Sheet"ではただ一言。「セッションベースのユーザ認証を使え」と書いてある。
https://www.glamenv-septzen.net/view/1350#id55be56

ユーザ認証にはセッション管理を使え、とあり、さらに、セッションIDやAPIキー、ログインIDとパスワード、
トークンなどはURLに含めるな、ともある。
他にもこのページにはRESTスタイルで開発するときのセキュリティ上の注意点が解説されている。英語になるが、
内容的には普通のWebサイトと同じように入力チェック＋出力時のJSON/XMLに合わせたエンコーディング、
CSRF対策などをしてください、という流れ。
また以下のページは、逆にRESTなWeb APIを診断する、pentester向けのガイドとなっている。
クロールできたURLだけでは、全部のREST APIの機能を見れたことにはならない可能性があるので、
ソースコード診断（ホワイトボックステスト）も可能なら実施したい、などとあり、参考になる。
2020/07/27(月) 14:37:32.58ID:S26P/GM8
>>817
だからオンラインゲーム無理ってことですねｗ
820デフォルトの名無しさん
垢版 |
2020/07/27(月) 14:38:15.39ID:ffgSx4MU
>>800
最近Next触り始めたけどドキュメントにやたらSSG推してたから、あながちGatsby最高マンダムなんかもなと思うわ
GatsbyはでもGraphqlと結びついとるから気軽にカスタマイズしようとしたらエラー吐きまくる
2020/07/27(月) 14:38:36.28ID:S26P/GM8
>>817
クライアントだけで実装できるものしか
作れないと言ってます。

お前のやり方ではログインが必要なものは作れません。
オークションサイトは作れないし
ブログの管理をすることもできません。
2020/07/27(月) 14:39:56.60ID:Rr+dRFNS
>>803
ド素人がセッションも知らないのか？
CookieにセッションIdメモってサーバーサイドオブジェクトと紐付けるんだよ
2020/07/27(月) 14:41:27.35ID:S26P/GM8
>>822
お前の理屈は、クッキーの代わりにパラメーターでセッションIDを渡せすという
セキュリティ的に脆弱なセッション管理を実装すれば
サーバーに状態は持ってないことになるんやろ？ｗ
アホやなぁと言ってる
2020/07/27(月) 14:42:38.43ID:O6ncpH5Z
>>821
だからSPAのバックエンドにRESTが適してるんだよ
SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
サーバーがセッション管理から解放される
これもSPAのメリットと言えるかもしれないね
2020/07/27(月) 14:43:20.19ID:S26P/GM8
もしかしてパラメーターのキーの名前がsession_idじゃなかったら
サーバーサイドに状態を持たせてないことになるとでも思ってるのか？ｗ
2020/07/27(月) 14:44:06.24ID:S26P/GM8
> SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの

え？ URLにパラメータとかユーザー名とかパスワードを入れればいいんだから
SPA関係ないじゃんｗ
2020/07/27(月) 14:45:41.88ID:S26P/GM8
クッキーを使えばクライアントに状態を持ってる！
例えばセッションIDをクッキーに入れておけば、
ウェブサイトにアクセスしたときにログインしたことになる！
JavaScriptも不要！古くから使われてるログインの仕組みだ！

みたいな話をされてこ困るんだよなぁ（笑）
2020/07/27(月) 14:48:59.96ID:S26P/GM8
クライアントにしかデータを持ってないと
別のパソコンでログインしてもデータが見れなくなる（笑）

まあそれでいいなら普通のウェブサイトのほうがいいだろうねｗ
HTML+CSS+jQueryで
2020/07/27(月) 15:03:07.49ID:Rr+dRFNS
アホのために説明してやるか

Cookieとサーバーサイドのオブジェクトの紐付けで擬似的にリクエスト間の状態維持を実現する手法がセッションな
従来のシステムではよく使われていたが思ったよりメモリ消費がバカになんねえなぁってことで今はもう廃れた

今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
そうすれば極僅かなCPUの負荷増でメモリ消費をぐっと抑えることができるようになる
リクエストに乗せたくない重大な機密や大きすぎるデータは永続化層で管理する
これがメモリに乗るのはデータ利用するその時とキャッシュされた時だけ
これでサーバーサイドのリソース効率がだいぶ良くなった
ついでにいうと水平スケールもしやすくなって一石二鳥

SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRの特性上どうしてもﾋビューに関するほとんどの状態をサーバーのメモリ上に確保してクライアントが去りゆくまでずっと維持し続けなければならない
これがどれだけリソース効率が悪い邪悪なアーキテクチャかは猫でもわかるだろう
クラウドファーストなこの御時世ではサーバーサイドのリソース増加はコストに直結する
こんな金食い虫のアーキテクチャではやってられんのだ
2020/07/27(月) 16:01:20.39ID:FzUtUUvl
>>793
ちなみにWappalyzerでは検知出来ないけどReact Developer Toolsなら検知されるパターンもある
多分Webpackの難読化の影響かとは思うが
Amazonの欲しいものリストのページやプライムビデオのページとかそんな感じ
2020/07/27(月) 16:11:00.85ID:A4vSpavl
>>797
AngularはMaterial系が主流だからBootstrapの対応はあんま良くないな
2020/07/27(月) 16:18:49.53ID:SDAq9vDF
>>829
> 今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている

その方式はデータが大量になったときに破綻するので
セッションIDぐらいしか入れない
2020/07/27(月) 16:20:12.25ID:SDAq9vDF
>>829
> SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている

SSRとは無関係
2020/07/27(月) 16:22:25.22ID:SDAq9vDF
https://ssr.vuejs.org/ja/

従来の SPA (シングルページアプリケーション) と比べて、SSR の利点は主に次の点にあります:

・検索エンジンのクローラが完全に描画されたページを直接解析するため、SEO が向上します。
現在のところ、Google と Bing は同期的 JavaScript アプリケーションのインデックスを作成できます。
同期がキーワードです。あなたのアプリケーションが読み込み中にスピナが表示され、
Ajax 経由でコンテンツを取得する場合、クローラーはあなたが完了するまで待たないでしょう。
つまり、SEO が重要なページで非同期にコンテンツを取得する場合は、SSR が必要な場合があります。

・特にインターネットの遅さや遅いデバイスでは、コンテンツの再生時間が短縮されます。
サーバで描画されたマークアップは、すべての JavaScript がダウンロードされて表示されるまで待つ必要がないので、
ユーザは完全に描画されたページをすぐに見ることができます。これにより、一般的にユーザーエクスペリエンスが向上し、
コンテンツの所要時間が直接コンバージョン率に関連付けられているアプリケーションにとっては重要になります。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況