Vue vs React vs Angular Part.4

**デフォルトの名無しさん** · 2020/06/11(木) 19:01:45.26

実際どうなん？
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/25(土) 13:33:34.03

JSの余命もあと1年足らずか
感慨深いな

**デフォルトの名無しさん** · 2020/07/25(土) 13:38:29.51

脱jQueryと言われてから何年経ったっけな？ｗ

**デフォルトの名無しさん** · 2020/07/25(土) 13:56:24.05

C#erって昔はこんなにスレチなところで延々と講釈を垂れ続けるようなバカじゃなかったはずなんだがなぁ
大体本当に優れてるものならそんな意味の分からん喧嘩なんて売りに来なくても広まるものは広まるだろ

**デフォルトの名無しさん** · 2020/07/25(土) 13:58:58.64

長いJSの歴史の終焉を目の当たりにして感慨深いなぁって思っただけであって喧嘩を売ってるつもりは微塵もない

**デフォルトの名無しさん** · 2020/07/25(土) 13:59:34.29

>>682
jQueryはWeb"サイト"分野では永劫に使われ続けると思うよ
ブラックボックスってわけじゃないからブラウザベンダーに排除されることもないだろうし

**デフォルトの名無しさん** · 2020/07/25(土) 14:05:25.78

>>684
その終わるという根拠とやらはなんなの？

**デフォルトの名無しさん** · 2020/07/25(土) 14:13:44.26

jQueryはすばらしいからこそJavaScriptに吸収される形でなくなって欲しいわ
実際、jQueryでしか書けなかったセレクタがJavaScriptに取り込まれたりしてるよね

**デフォルトの名無しさん** · 2020/07/25(土) 14:16:37.16

>>686
占いとかそんな感じ

**デフォルトの名無しさん** · 2020/07/25(土) 14:23:57.80

>>686
自明でしょ

**デフォルトの名無しさん** · 2020/07/25(土) 14:25:56.10

>>689
全然自明じゃないから聞いてるだが
具体的にどんなプロセスでどう終わるのか説明してみたまえ

**デフォルトの名無しさん** · 2020/07/25(土) 14:30:04.27

>>690
より良いものが残る
当たり前

**デフォルトの名無しさん** · 2020/07/25(土) 14:59:28.18

じゃあJSは良いから残るのか。

**デフォルトの名無しさん** · 2020/07/25(土) 18:31:03.23

>>683
C#でもunityユーザーとかはマシだからC#erがガイジというよりはBlazorがガイジなんだろう

**デフォルトの名無しさん** · 2020/07/25(土) 18:41:39.82

JSガイジの断末魔

**デフォルトの名無しさん** · 2020/07/25(土) 21:25:42.82

JavaもVMで動かすなんて遅すぎるしクソとか批判されたが
C#含め普及していった。
Blazor、いやwasmもこれからpeformance改善されて
使う人が増えるのは間違いない

>>693
こうやってマシとか言ってる人はC#使えない人

**デフォルトの名無しさん** · 2020/07/25(土) 21:30:14.29

煽りに乗りたいヤツはその思いの丈は全部こっちにぶちまけてやってくれ

【本命】Blazor スレ1【真打】
https://mevius.5ch.net/test/read.cgi/tech/1595255796/

**デフォルトの名無しさん** · 2020/07/25(土) 21:35:09.44

GmailはSPAらしいけどAngularか？
いくらJSがブラウザ内でBlazorより早いといっても
Gmailだと11MBもサイト開くたびにデータ通信してるように
とてつもなく無駄なことやってる

ダウンロードサイズ、時間を考慮すると
Wasmとあんまり差がないってことにもなる
Blazor WebAssemblyは2回目以降のデータ非常に小さい。
データ消費量が課金にもかかわってくるモバイル回線では
Gmailのように大量にデータ通信するサイトよりwasmのがいいんじゃないか

**デフォルトの名無しさん** · 2020/07/25(土) 21:42:59.39

>>697
Googleでその手のフレームワーク使ってるサービスって意外とないんだよね

**デフォルトの名無しさん** · 2020/07/25(土) 23:21:18.28

BlazorプロジェクトマネージャーDaniel Roth「BlazorはJSよりも10倍遅く、スピード競争に勝つことはない」

今でも遅いのにブレキチのオナニーのためにBlazorでさらに10倍遅くさせられるGmail哀れｗｗｗｗｗ

**デフォルトの名無しさん** · 2020/07/25(土) 23:46:07.69

>>699
10倍遅いとか捏造しつこいな
chatでソースないのをいいことに捏造しまくり

**デフォルトの名無しさん** · 2020/07/26(日) 00:32:01.45

>>700
JITの無いインタプリタでJSと同等の速度が出るはずないだろ
JITの有無で速度の桁がひとつ変わるとか普通だ

**デフォルトの名無しさん** · 2020/07/26(日) 00:40:34.12

>>700
>>696

**デフォルトの名無しさん** · 2020/07/26(日) 00:42:21.83

AoTコンパイラはバスに乗り遅れちゃって早くて一年後♪
嗚呼、それでも「JSにスピード競争で勝つことはない」
ミジメｗｗｗ
Blazorすごい！→宣伝してる俺すごい！
しようと思ってたのにまさかBlazorがC#おじさんのミジメな境遇まで堕ちてくるとはねｗｗｗｗｗ

**デフォルトの名無しさん** · 2020/07/26(日) 01:14:39.39

つかこんなに
フロントエンド界隈のライブラリが乱立して
ビルド構築手順ががわちゃわちゃしてる状況は異常
もうHTML自体をバージョンアップした方がいい

HTMLに直でReactやVueやTS SASSとかを記述して
ブラウザネイティブで解釈できるようにするべき
Bootstrapもどうせみんな使うんだか初めから
HTMLの仕様内に組み込んどけ

**デフォルトの名無しさん** · 2020/07/26(日) 05:35:40.74

>>701
ソースなしでは信ぴょう性がないし
どうせそういうのは発言の切り取り

Blazor wasmはAOT compile実装の予定あるのだから
速度は大幅に向上する

Browser外ではC#のがJSより速いのだから
speedは十分にはやくなる

**デフォルトの名無しさん** · 2020/07/26(日) 05:53:06.94

>>704
こんな発言しちゃうのがスクリプトおじさん

セットで仕様化したらどれか失敗したら全部が失敗するだろ
あと必要なcodeだけloadするから無駄な通信が減るのも常識
bootstrapは使ってないサイトたくさんある
View(html)とlogicをセットで仕様化など狂気の沙汰

あとbuildが煩雑なのはうんこframework使ってるからだ。
ASP.net MVCとかならクオリティ高いのがセットになってる
SPAなんてやらずにASP.net Coreみたいなまともなweb framework使えでおしまい
95%のサイトはSPAの必要がない

**デフォルトの名無しさん** · 2020/07/26(日) 07:13:59.04

いいかげんCの民は別スレ行けよ
ここのスレタイ
Vue vs React vs Angular
だから

**デフォルトの名無しさん** · 2020/07/26(日) 08:13:28.39

それにしてもAngular使ってるサイトだけは全然見つからないよね
Angular本家とお名前と去年の技術書展くらい(今年はReactに変わってた)

**デフォルトの名無しさん** · 2020/07/26(日) 08:52:05.09

WebAssembly使えばこういう問題も回避できるの？

Apple、プライバシー問題のため16ものWeb APIのSafariへの実装を拒否
https://css-tricks.com/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/
Appleが実装拒否したAPI一覧:
- Web Bluetooth
- Web MIDI API
- Magnetometer API
- Web NFC API
- Device Memory API
- Network Information API
- Battery Status API
- Web Bluetooth Scanning
- Ambient Light Sensor
- HDCP Policy Check extension for EME
- Proximity Sensor
- WebHID
- Serial API
- Web USB
- Geolocation Sensor (background geolocation)
- User Idle Detection

**デフォルトの名無しさん** · 2020/07/26(日) 09:16:46.95

>>709
Webはこんな方向に進もうとしてるのか
もはやプラットフォーム（OS）だな
そのうちベアメタル（直接ハードウェア）にインストールできるWebブラウザーとか出てきそう

**デフォルトの名無しさん** · 2020/07/26(日) 09:34:24.57

>>709
ブラウザベンダが実装拒否してるんじゃJSかwasmは関係なく無理だ
もしできるならセキュリティホールだし

**デフォルトの名無しさん** · 2020/07/26(日) 09:42:00.76

ブラウザがなんでもできるようになったらappletやactivexの時みたいにセキュリティ事故が相次いで
何処かの団体がセキュアなもののみを選択したAPIセットを発表して
そのAPIセットを実装したセキュアブラウザみたいなのが登場して
みんなそっちに乗り換えて
需要がなくなった多機能ブラウザは廃れて
すべてが最初に戻る

**デフォルトの名無しさん** · 2020/07/26(日) 09:59:58.67

まぁブラウザAPIは基本的なもの以外はサイト毎にそのAPIの実行権限をユーザーが許可するかどうかっていうのが大前提なんだけどね

**デフォルトの名無しさん** · 2020/07/26(日) 11:36:06.50

もうやってることがbrowse（拾い読み）の域を超えてるね

**デフォルトの名無しさん** · 2020/07/26(日) 11:36:26.24

>>704
同意
もっと言うとHTMLなんか無くした方がいいよね

**デフォルトの名無しさん** · 2020/07/26(日) 11:42:58.77

>>712
本当にこうなったら笑う

**デフォルトの名無しさん** · 2020/07/26(日) 12:36:40.14

SPAの特徴まとめてみた

開発の時間とコストが大幅に増える
初期のローディングにかかる時間が増える
SEOの面で不利になる
開発者が少ない
外注する場合にコストが増える
セキュリティが低下する

メリットは高速なページ遷移が可能なことだが
逆に言えばそれが不要ならSPAは必要ないな
むしろコストアップや初回読み込み遅延などのデメリットが上回ってしまう

**デフォルトの名無しさん** · 2020/07/26(日) 12:43:20.43

> メリットは高速なページ遷移が可能なことだが
これ体感したことある？

**デフォルトの名無しさん** · 2020/07/26(日) 13:05:55.45

静的HTML+API+Vueの素朴なマルチページ構成がバランスいい

**デフォルトの名無しさん** · 2020/07/26(日) 13:09:44.19

>>718
画面全体をロードせず、必要な部分を
読み込むので高速になる、と一般的に言われてる。

アプリっぽく軽快に操作できないと困るサイトなら必要だけど
実際のところそこまで素早く操作が必要になるweb appはない気がする。
本当に快適にしたいならnatvie appしかないわけで
SPAは位置づけが微妙、手間とコストかかるわりに微妙すぎじゃないか？

FacebookがSPAで有名な事例だろうけど嫌いだから使わない

**デフォルトの名無しさん** · 2020/07/26(日) 13:37:49.50

SPAはWEBアプリケーションを作るための物であってWEBサイトを作るための物ではないからな
結局は使い分けだよ
世界に向けて情報発信するならWEBサイトが基本だからSPAの採用実績が少ないのは仕方ない
複雑になりがちな社内アプリケーションなどは今後はSPAが主流になっていくだろう

**デフォルトの名無しさん** · 2020/07/26(日) 13:54:45.15

>>717
SSRかSSG使えば初期ローディングとSEOの懸念事項は無くなるんでないかい
Googleだけに関して言えばJSも読んでくれるらしいからSPAでもSEOに関しては問題ない

**デフォルトの名無しさん** · 2020/07/26(日) 14:27:11.75

SPAは自分がユーザーの立場になってみると思ったより使い難いんだよね

**デフォルトの名無しさん** · 2020/07/26(日) 14:43:43.07

全ページSSRにしたらJSが無くても使えるしね。
SPAは便利だね。

**デフォルトの名無しさん** · 2020/07/26(日) 14:46:29.68

業務系システムとSPAは相性がいい
業務系では複雑怪奇なUIを求められることが多い
そして業務系と言えばJavaかC#
Javaは廃れ行く運命だがC#にはBlazorがある
業務系はもう全部Blazorでいんじゃねえの

**デフォルトの名無しさん** · 2020/07/26(日) 15:27:13.88

やっぱ業務系か
SPA需要ってPCありきかなと感じていたんだ
Android/iOSならSPAにこだわらずネイティブAppにしちゃったほうがユーザビリティ高いよね
そう考えるとモバイルファーストが謳われてる現在、SPAは下火になっていくのだろうか

**デフォルトの名無しさん** · 2020/07/26(日) 15:36:09.11

SPA自体PWAありきなんじゃない？

**デフォルトの名無しさん** · 2020/07/26(日) 15:50:04.51

非SPAの採用実績と比較したらSPAの実績なんてカスみたいなものだろうね
そしてこれから先もそんなに伸びることはないと思う

そもそもSPAを導入したら何か大きな恩恵を得られるかっていうとほとんどのサイトがいやー別にそれほどでも…って感じでしょ？
糞言語のJSに縛られてSPAを導入するぐらいなら、使い慣れたPHP、Ruby、Pythonでサクッと非SPAで作っちゃったほうが安くて、品質もいい

ということでSPAの生存戦略として、業務系にフォーカスするってのは有効だと思う
今のところBlazorだけが唯一そっち方面で流行しうる下地を持ったSPAフレームワークと言っていい
業務系ではJSもTSも蛇蝎のごとく嫌われてて人材が足りないから、業務系で既存SPAフャ戟[ムワーク三試墲ﾌ生き残りは血ｵしい
Blazorがうまく行ったら、Javaが後追いでパクリを出してくるだろうね
そしたらまた、勢力図が変わるかもしれん

**デフォルトの名無しさん** · 2020/07/26(日) 15:51:12.91

>>721
Web siteを作るのにSPA framework使ってる人は
ほぼいないしいたらアホでしょう

Web app限定の中でも95%以上はSPA必要ないだろうってこと
>>717のデメリットがメリットを上回る

**デフォルトの名無しさん** · 2020/07/26(日) 15:55:43.15

Googleが期待したほどSPAは盛り上がらなかったね
それで結局ChromeOSも方針転換してAndroidアプリ・Linuxアプリがインストールできるという流れになってしまった

でもVSCodeのようなWeb技術をベースにしたネイティブアプリも人気があるんだよね
Web技術はマルチプラットフォーム対応アプリを作るのには向いているのかも

**デフォルトの名無しさん** · 2020/07/26(日) 15:59:33.53

>>721
最終行
業務用のweb appはASP.net系シェアが圧倒的だし今後も変わらない。
ASP.net系は開発生産性が高い
長期でMSがセキュリティとかのパッチ出してくれる
だからASP.netは法人に選ばれる

Windows PC限定にしてWPFとかのnative appだけで作るのもあり
開発スピードが最速になるしUXも最高レベルになる
社内限定ならcross platformなんていらないし

**デフォルトの名無しさん** · 2020/07/26(日) 16:02:26.11

ActiveDirectoryに縛られて惰性で使ってるだけ

**デフォルトの名無しさん** · 2020/07/26(日) 16:06:32.34

>>722
SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ

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

**デフォルトの名無しさん** · 2020/07/26(日) 16:11:06.69

>>731
ふーんJavaよりシェア大きいんだ
俺もネイティブは楽で高品質だから、良いと思うけど、
従業員への配信がめんどくさくないかい？

**デフォルトの名無しさん** · 2020/07/26(日) 16:13:52.38

>>726-727
SPA調べてまさにそのSPAの中途半端さに気付いた
UXも開発スピードもNative appが最強だから
業務系ならnative appだけもあり

SPAは開発のコストと時間かかるわりにUX改善はたいしたことない
しかもサポート期間が短くメンテナンスも金がかかる

**デフォルトの名無しさん** · 2020/07/26(日) 16:17:08.52

blazor wasmで殴りこんで来て今度はネイティブアプリって
マジで何しに来たんだ

**デフォルトの名無しさん** · 2020/07/26(日) 16:23:42.24

>>735
ネイティブと比べた時のBlazorの利点はセキュリティと配信しやすさ
サポート期間と開発生産性はマイクロソフトだから心配してない

**デフォルトの名無しさん** · 2020/07/26(日) 16:27:20.70

>>734
WindowsならGroup policyとかのシステム管理機能で
Applicationの自動インストールとかできるしdeployは楽だよ

JavaはORACLE所有になってライセンス実質有料になったし
ますます下火になるでしょう

**デフォルトの名無しさん** · 2020/07/26(日) 17:35:09.81

SPAフレームワークが使えないんじゃなくてオメーらゴミエンジニアが使えるレベルに達していないだけな

**デフォルトの名無しさん** · 2020/07/26(日) 18:00:38.42

どっちにしても、今のSPAフレームワーク使っている奴ならこれからwasmやblazorとかが台頭してきても
それらが使い物になってから手を出しても全然遅くないだろう。
今phpやrailsとかで食えている人ならそもそもwasmに手を出す必要性すらないかもしれない。

**デフォルトの名無しさん** · 2020/07/26(日) 18:03:22.00

使うなら使うで問題ないが、使う価値があるか、は全く別の問題だからなぁ
バカだったら、なんか知らんけど新しいもの、ぐらいの軽い気持ちで採用しちゃんだろうけど

**デフォルトの名無しさん** · 2020/07/26(日) 18:08:17.16

>>740
WordPressで済むようなWebサイトにJSフレームワークを入れるのが非効率なのと同様
一般的なWebにwasmなんて不要なはずなんだよ
canvasにゴリゴリレンダリングする様な演算回数が多い様な場合とかそういう場合だよね必要になるとすれば

**デフォルトの名無しさん** · 2020/07/26(日) 18:10:19.01

>>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.56

YahooもGoogleのエンジン使ってるみたいだから多分YahooもSPAでSEO的におけやね

**デフォルトの名無しさん** · 2020/07/26(日) 19:08:50.21

SPAでもSEO的に問題ないんじゃなくて
SEO的に問題ないSPAを使うべきだよ

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

2ページ目以降は速いなると言うがGoogleのクローラーなんかはページ読み込みの
タイミングはバラバラなので2ページ目以降も1ページと同じように読み込む。
そうするとSPAの速いっていうこうかがなくなる
ページ読み込みの速さもSEOで重要なので、どのページを最初に読み込んでも
JavaScriptなしで表示されるようにするのが正しいやり方

**デフォルトの名無しさん** · 2020/07/26(日) 19:09:51.27

ようするに2ページ目以降JavaScriptあり（SPA）で表示する
1ページ目JavaScriptなしで表示する
これを実現するためにSPAでサーバーサイドレンダリングは必須なの

**デフォルトの名無しさん** · 2020/07/26(日) 19:15:51.29

SEOを考えるような内容のサイトでSPAが効果的な物って例えばどんな物がある？
pgadmin4のような高度なappならSPAが効果的って主張は理解できる
だけどqiitaのようなsiteにSPAを使うメリットは無いと感じた
伝統的なsiteの振る舞いと異なるから直感的な操作感で言うとマイナスまでありえる

**デフォルトの名無しさん** · 2020/07/26(日) 19:16:05.21

寧ろSEOが必要ない様な利用者が限られる部分に使うべきなんだよ

EC的なものなら確かにシステム的な側面とSEO的な側面の両方が必要だけど
それ以外のシステムならそもそもトップページ以外検索エンジンにヒットする必要ないものって結構多いはず

**デフォルトの名無しさん** · 2020/07/26(日) 19:22:21.71

**デフォルトの名無しさん** · 2020/07/26(日) 19:25:42.98

SSRはバックエンドのリソース消費量が増えるから嫌だな
クラウドだとコストにも響いてくる

**デフォルトの名無しさん** · 2020/07/26(日) 19:27:42.35

>>747
ないと思うよ。だからReactとかvueとかの
ウェブアプリ用フレームワークはjQueryの代替にはならないし
ウェブサイトがウェブアプリに作り変えられることもない
俺がもう5年ぐらい前に出した結論

そしてこの5年のjQueryのシェアの増え方と
フレームワークのシェアの増え方を見ればそれが
正しかったと証明されてる。

**デフォルトの名無しさん** · 2020/07/26(日) 20:02:03.99

しかしそう考えると、学ぶべきフレームワーク、人気のフレームワークといった文句でSPAフレームワークが紹介されるのはなぜなんだろう？
そんなに人気があるなら、採用するサイトも増えるはずだけど、ほとんど見かけない
SPAフレームワークを覚えた人は何処で働いていて、どんな成果物を残したのか？
このスレの人の手がけた公開サイトがあるなら、ぜひ知りたい

**デフォルトの名無しさん** · 2020/07/26(日) 20:22:09.40

業務用Webアプリの開発に使うからだろ
Webアプリ作れないゴミエンジニアは格安だから使えなくていいんだよ

**デフォルトの名無しさん** · 2020/07/26(日) 20:24:15.75

業務用アプリだとC#のほうがいいね

**デフォルトの名無しさん** · 2020/07/26(日) 20:26:03.01

>>752
SaaSで使われまくってるよ
てか求人サイトでフレームワークの名前で検索するといっぱい出てくる
静的なWebサイトだとツールのドキュメントとかコーポレートサイトでちょくちょく見かけるかな
SasSでもWebサイトでも無い感じのやつだとTwitterとかYahooとかPixivとか

**デフォルトの名無しさん** · 2020/07/26(日) 20:29:12.45

>>754
裏は好きなの使えばいい

**デフォルトの名無しさん** · 2020/07/26(日) 20:52:24.56

>>752
見かける見かけないってそもそもブラウザにインジケーターアドオン入れてから言ってくれよ
どうせ入れてないんだろ？

**デフォルトの名無しさん** · 2020/07/26(日) 22:06:58.75

ふーん
で、何割ぐらいのサイトでSPA使われてんの？

**デフォルトの名無しさん** · 2020/07/26(日) 22:49:08.46

誰も知らないだけでたくさん使われてるよ

**デフォルトの名無しさん** · 2020/07/26(日) 22:51:16.76

誰も知らないことをなんで知ってるの？

**デフォルトの名無しさん** · 2020/07/26(日) 22:53:37.55

ゴミサイト含めたら圧倒的にほんの少しだろ
そんなにゴミサイトが気になるなら一生気にしていればいい

**デフォルトの名無しさん** · 2020/07/26(日) 23:03:35.73

なんでそんなにSPAを敵視すんの？

**デフォルトの名無しさん** · 2020/07/26(日) 23:06:58.57

自分が分からない・作れない技術が普及したら恥ずかしくて困るから。
それに対するアクションがこんな辺鄙な場所でジタバタ足掻くこととはねｗ
こりゃ仕事できませんわｗ

**デフォルトの名無しさん** · 2020/07/26(日) 23:10:26.86

寧ろ
・Wappalyzer
・React Developer Tools
・Vue.js devtools
・Augury
これらの拡張機能(アドオン)を入れずにどうやってないって判断してんだよ

**デフォルトの名無しさん** · 2020/07/26(日) 23:11:26.10

敵視はしてないが純粋に疑問なんだ
これがどれほど役に立つのか
噂に聞くほどの実績が本当にあるのか
今のところそれほど有用ではなさそうだなといった感想
それを覆すほどポジティブな意見が見られない

**デフォルトの名無しさん** · 2020/07/26(日) 23:21:06.77

そのプログラミングモデルを自分で気に入るか気に入らないかでいいと思うがねぇ。
自分に合わないと思うなら別に使わなくていい。

**デフォルトの名無しさん** · 2020/07/26(日) 23:31:12.58

現に俺様がSPAフレームワーク使って業務アプリ作りまくってるんだからこれが正しいんだよ
SPAフレームワーク使わなかったらもっと開発に時間かかる
さらに実際の業務にも時間がかかるようになる

オメーが知らねえだけで世界を知った気になるな

**デフォルトの名無しさん** · 2020/07/27(月) 00:08:34.56

フレームワーク自慢程反吐が出るものは無い
フレームワークは何でもそうだけど

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

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

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

そしてそれを頭の中に完璧に理解してる人間なら
HTMLやCSSや普通のJavaScriptを書いた方が早い
新たにフレワの文法を覚えるのが馬鹿馬鹿しい。
フレワが何種類も乱立してたらなおさらだ。

**デフォルトの名無しさん** · 2020/07/27(月) 00:15:47.58

>>768
オメーがゴミなだけだろ
htmlとcssができないってどんだけ低レベルなんだよ？
デブツールみてわからんとかゴミクズじゃん

とにかくできない奴が声高々に吠えるな
ここにきちんとできている俺様がいるのにゴミが勝手に決めつけんじゃねえよ

**デフォルトの名無しさん** · 2020/07/27(月) 00:21:48.49

>>769
スマンな俺もUI/UXのフレームワークに頼りっきりでCSSは微調整以外は碌に書けん

**デフォルトの名無しさん** · 2020/07/27(月) 00:23:19.80

このスレはいつみても
どうでも良いことで
盛り上がってんな

**デフォルトの名無しさん** · 2020/07/27(月) 00:38:02.84

外部向けサイト⇒SPAより非SPAのが向いてる
社内向けサイト⇒人材と既存資産が豊富なC#が有利⇒Blazor

**デフォルトの名無しさん** · 2020/07/27(月) 00:42:11.06

>>765
？
Webアプリ作るなら今のところ最適解がSPAだろ？
なんで化石も含めて大量にあるWebサイトの中でどれくらいの割合使われてるか知りたいの？

**デフォルトの名無しさん** · 2020/07/27(月) 00:44:08.53

> Webアプリ作るなら今のところ最適解がSPAだろ？

たまたまSPAになってるだけだと思うけどな
通常はAjaxで十分だと思うよ

**デフォルトの名無しさん** · 2020/07/27(月) 00:46:12.83

>>773
スマホを視野に入れたPWAならSPA構成でいいと思う

**デフォルトの名無しさん** · 2020/07/27(月) 00:49:34.50

PWAとSPAにどういう関係があるの？

**デフォルトの名無しさん** · 2020/07/27(月) 00:50:57.41

ゴミクズの知識の薄さがやべえな

**デフォルトの名無しさん** · 2020/07/27(月) 01:18:09.78

流れをぶった切って悪いけど、SPAでレスポンシブに
対応したフレームワークって何がある？

**デフォルトの名無しさん** · 2020/07/27(月) 01:20:38.79

>>773
最適じゃないからPHP、Ruby、Pythonなどの伝統的なフレームワークが選ばれる
SPAは僅かな領域だけでしか通用しない

**デフォルトの名無しさん** · 2020/07/27(月) 01:29:33.69

>>778
Bootstrapでも入れたらいいんじゃないか？
BootstrapVueでもReact BootstrapでもNative JavaScript for Bootstrap本家Bootstrap5αでも選択肢は選り取り見取り

**デフォルトの名無しさん** · 2020/07/27(月) 01:32:36.13

でもBootstrapはDOM操作をするだろ？
そうするとフレームワークと一緒に使えない