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/24(金) 07:54:54.35ID:N+F9nul4
GitHubは、Ruby製。
Rubyアンチは、使用禁止！
650デフォルトの名無しさん
垢版 |
2020/07/24(金) 09:07:10.80ID:c87Ipt6p
俺からすればC#, Perl, PHP, JSなんてクソの背比べ
2020/07/24(金) 09:26:39.30ID:fpaVh+C9
そこで満を持して登場するのが
2020/07/24(金) 10:02:11.66ID:fMjVnhWI
jQuery
2020/07/24(金) 15:03:44.79ID:VpzRbTvR
どうせ不毛ならｊおじとBlaおじの不毛な争いが見たかったな
2020/07/24(金) 16:17:24.32ID:v+EKAnTC
まるで有毛な争いがあったかのような言い草だ・・
2020/07/24(金) 18:26:38.54ID:9v9Epd9J
三大ｶﾞｲｼﾞ全員ハゲだからな。
2020/07/24(金) 21:12:27.82ID:PfN6NIjK
Blazorお姉さんだけど
jQueryおじさんとかはframeworkつかえないし
スクリプトおじさんはC#理解できないし
相手にならない

ところでJSのSPAの最初の読み込みは
何MBくらいになるのが普通？
何MBまで許される？
有名どころのSPA使ってるサイトあったら計測したいから教えてほしい
2020/07/24(金) 21:34:50.64ID:9H+RWfuB
GMailは？
2020/07/24(金) 21:46:23.70ID:j4NCrF6q
blazer婆まで出てくるとはｗ
2020/07/24(金) 21:54:02.91ID:U/Nd6Iq0
>>656
一方SPAを使わなければ、必要なデータだけ読み込むので
数KBですむから、本末転倒になってるんだよなぁ

SPAかどうかはユーザーにとっては関係ない話
ページ表示の目安はGoogleがレポートしている
https://developers.google.com/speed/pagespeed/insights/

https://marketingnative.jp/how-to-measure-page-speed/
遅延する時間 ユーザーの反応
0~100ミリ秒 すぐに結果が得られたと感じる。これ以上時間がかかると、操作と反応にずれが生じる。
100~300ミリ秒 少しの遅れを感じる。
1000ミリ秒（1秒）以上 実行したタスクについて関心を失う。

つまり1秒以内だよ。100Mbpsだったら1秒で12.5Mバイトだけど
そんなスピードは出ないだろう。通常だと20Mbpsかねぇ。つまり1.5Mバイト
でも速度制限や回線が遅い場合を考えると500Kバイト程度に抑えたほうがいいだろうね
2020/07/24(金) 21:55:42.66ID:U/Nd6Iq0
お、Googleの推奨があった。

Googleの推奨は1.6MB。7,866のウェブサイトの平均は 2.43MB。あなたのトップページは？
https://webtan.impress.co.jp/u/2018/08/20/30244

通常だと～の計算と近いね
2020/07/24(金) 21:58:15.51ID:9H+RWfuB
wasmなら最適化も簡単だろう
今後どんどん速くなっていくとおもわれ
2020/07/24(金) 21:59:19.49ID:U/Nd6Iq0
WebAssemblyはファイルサイズがでかくなる
2020/07/24(金) 22:01:51.85ID:U/Nd6Iq0
WebAssemblyはバイナリだから小さくなると考えているやつがいるが、
JavaScriptでも配布する時はgzip圧縮をかけるので
バイナリになって小さくなるんだよな
2020/07/24(金) 22:35:06.44ID:yCEn1h9i
AngularもReactもVueも使ったことあるよーって人に聞きたいんだけど、どれが一番好き？
665デフォルトの名無しさん
垢版 |
2020/07/24(金) 23:16:35.73ID:PfN6NIjK
>>657
GmailのwebはSPAなのか
FirefoxでGmailを計測してみたら170 requestsくらいしてて11MBくらいだった。
しかもこれcache削除しないで測ってるから画像は除外された数字
backgroundで読み込むから読み込み完了まで25秒超えてる。

今はトップページ読みだけで10MB以上でも許される世界になってるのかな？
Gmailでかすぎ？完全にcacheけしたらどの程度いくんだろう, たぶん試さないけど。
666デフォルトの名無しさん
垢版 |
2020/07/24(金) 23:19:14.32ID:PfN6NIjK
>>657
ちなみにBlazor WebAssemblyのサンプルは初回読み込みで17MB程度だが
2回目以降は400kbとすごく小さい

初回通信でバイナリがほとんどcacheされてる
Blazor WebAssemblyのがはるかに優秀

やっぱりJSのSPAの時代は終わりだわ
JSは言語もゴミだし

これからはC#でBlazorの時代と確信した
2020/07/24(金) 23:27:28.52ID:PfN6NIjK
>>659
non-SPAと比べるのはフェアじゃない
SPAはUXが上というメリットがあるわけだからな
その目安はSPA関係ないし制限1秒はきつすぎる

あとMVNOだとランチタイムで速いところでも10Mbps
10秒待ってくれても12.5MBか

とりあえずBlazorの2回目以降400kbで
改めて優秀さは確認できた
MVNOのうんこ回線のランチタイムでも快適にloadできるはずだ

初回10MB超えるのも5Gきたら気にならない世界かもしれない
2020/07/24(金) 23:46:29.59ID:SsZ4AS8R
Blazorの初回転送量は1.7MBくらいじゃなかったっけ？開発者ツールの見方間違ってない？
2020/07/24(金) 23:51:43.42ID:SsZ4AS8R
Blazorのテンプレートなら、Brotliで1.8MBだね
2020/07/25(土) 00:37:15.39ID:WCMFimkk
ここまでスレタイに全く関係無い話を続けられるの逆にすごいな
ボケがはじまってんのか
2020/07/25(土) 02:39:20.52ID:ZlqyHRW3
>>664
JavaScriptを主として掛けるからReact
他はhtmlタグが主でJavaScript従な感じ
2020/07/25(土) 02:51:04.72ID:uhXYZAuD
世界最速のサイトは、Ruby on Rails 製！
https://dev.to/

元乃木坂46 の川後陽菜のWebサイト、SKIYAKI も速い。
https://kawagopro.com/

Rails に勝てる、フレームワークは無い！
2020/07/25(土) 04:22:17.09ID:icwPneMN
>>668-669
どのテンプレートプロジェクト作成した？
Blazor WebAssemblyじゃなくてBlazor Serverになってない？
Storageにダウンロードされたdllとか確認した？
dotnet new blazorserver
で作成するとファイルサイズ小さくなるがそれだとWebAssemblyになってない。
Blazor Serverだとserver sideで動く

wasmで使うtemplateは
dotnet new blazorwasmを使う

本番向けのbuildするとかなり小さくなると書かれているがやり方まだ知らない。
それやったら初回17MBではなくもっと小さくなるかも
やり方知ってる人いたら教えて
2020/07/25(土) 04:40:17.49ID:icwPneMN
>>668-669
template動かしたときにrelease buildした記憶がないから
自分の書いた17MBはBrotliになってなかったかも
あとで試してみる

sizeはfirefox開発者ツールのnetwork tabでみた
初回1.8MBならぜんぜんOKだね
Blazor WebAssembly、ファイルサイズすごい小さい
2020/07/25(土) 04:56:22.14ID:vIjhxGJs
フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
https://krausest.github.io/js-framework-benchmark/current.html

二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。
2020/07/25(土) 05:11:49.78ID:vIjhxGJs
最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
（BlazorはJSよりも10倍遅く、スピード競争に勝つことはない）
と述べた。
2020/07/25(土) 05:23:04.98ID:vIjhxGJs
AOTサポートにより（JSに勝つことはないにせよ）性能向上が期待され、また宣伝し、信者も大いに期待していたが…

AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
https://twitter.com/christianweyer/status/1270602821688328192?s=20
延期されたｗｗｗｗ
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよｗ
https://twitter.com/5chan_nel (5ch newer account)
2020/07/25(土) 05:51:38.78ID:VPBor6Kz
まあそれも時間の問題だろう
wasmのほうが最適化しやすいのだからそう遠くないうちに逆転する
これはほぼ既定路線と考えていい
679デフォルトの名無しさん
垢版 |
2020/07/25(土) 07:29:16.19ID:l/9hXNF1
これか
Next for Blazor: AOT for 'Massive Speed Gains'
https://visualstudiomagazine.com/articles/2020/05/22/blazor-future.aspx

WASMで動く.NetランタイムがJIT無しのインタープリターだからILの実行が遅いってことね
これじゃあWASMがJSより速いと言っても、延期されたAOT(ILからWASMだよね？)が実装されないと、その速さが Blazor に反映されることは無い

.NET 5に間に合わないならAOTは来年以降
それまで Blazor スレで頑張ってください
2020/07/25(土) 11:28:31.85ID:NJ9vLrlx
>>675
公開処刑じゃんワロタｗｗｗ
2020/07/25(土) 13:33:34.03ID:0jDIZWNk
JSの余命もあと1年足らずか
感慨深いな
2020/07/25(土) 13:38:29.51ID:cd2WXu1h
脱jQueryと言われてから何年経ったっけな？ｗ
2020/07/25(土) 13:56:24.05ID:ZlqyHRW3
C#erって昔はこんなにスレチなところで延々と講釈を垂れ続けるようなバカじゃなかったはずなんだがなぁ
大体本当に優れてるものならそんな意味の分からん喧嘩なんて売りに来なくても広まるものは広まるだろ
2020/07/25(土) 13:58:58.64ID:0jDIZWNk
長いJSの歴史の終焉を目の当たりにして感慨深いなぁって思っただけであって喧嘩を売ってるつもりは微塵もない
2020/07/25(土) 13:59:34.29ID:ZlqyHRW3
>>682
jQueryはWeb"サイト"分野では永劫に使われ続けると思うよ
ブラックボックスってわけじゃないからブラウザベンダーに排除されることもないだろうし
2020/07/25(土) 14:05:25.78ID:ZlqyHRW3
>>684
その終わるという根拠とやらはなんなの？
2020/07/25(土) 14:13:44.26ID:CLKbPK7s
jQueryはすばらしいからこそJavaScriptに吸収される形でなくなって欲しいわ
実際、jQueryでしか書けなかったセレクタがJavaScriptに取り込まれたりしてるよね
2020/07/25(土) 14:16:37.16ID:4ePue1ew
>>686
占いとかそんな感じ
2020/07/25(土) 14:23:57.80ID:0jDIZWNk
>>686
自明でしょ
2020/07/25(土) 14:25:56.10ID:ZlqyHRW3
>>689
全然自明じゃないから聞いてるだが
具体的にどんなプロセスでどう終わるのか説明してみたまえ
2020/07/25(土) 14:30:04.27ID:0jDIZWNk
>>690
より良いものが残る
当たり前
2020/07/25(土) 14:59:28.18ID:Lg+2ZtBy
じゃあJSは良いから残るのか。
2020/07/25(土) 18:31:03.23ID:kGS+eXd8
>>683
C#でもunityユーザーとかはマシだからC#erがガイジというよりはBlazorがガイジなんだろう
2020/07/25(土) 18:41:39.82ID:DiPEvk/l
JSガイジの断末魔
2020/07/25(土) 21:25:42.82ID:icwPneMN
JavaもVMで動かすなんて遅すぎるしクソとか批判されたが
C#含め普及していった。
Blazor、いやwasmもこれからpeformance改善されて
使う人が増えるのは間違いない

>>693
こうやってマシとか言ってる人はC#使えない人
2020/07/25(土) 21:30:14.29ID:ZlqyHRW3
煽りに乗りたいヤツはその思いの丈は全部こっちにぶちまけてやってくれ

【本命】Blazor スレ1【真打】
https://mevius.5ch.net/test/read.cgi/tech/1595255796/
2020/07/25(土) 21:35:09.44ID:icwPneMN
GmailはSPAらしいけどAngularか？
いくらJSがブラウザ内でBlazorより早いといっても
Gmailだと11MBもサイト開くたびにデータ通信してるように
とてつもなく無駄なことやってる

ダウンロードサイズ、時間を考慮すると
Wasmとあんまり差がないってことにもなる
Blazor WebAssemblyは2回目以降のデータ非常に小さい。
データ消費量が課金にもかかわってくるモバイル回線では
Gmailのように大量にデータ通信するサイトよりwasmのがいいんじゃないか
2020/07/25(土) 21:42:59.39ID:ZlqyHRW3
>>697
Googleでその手のフレームワーク使ってるサービスって意外とないんだよね
2020/07/25(土) 23:21:18.28ID:vIjhxGJs
BlazorプロジェクトマネージャーDaniel Roth「BlazorはJSよりも10倍遅く、スピード競争に勝つことはない」

今でも遅いのにブレキチのオナニーのためにBlazorでさらに10倍遅くさせられるGmail哀れｗｗｗｗｗ
2020/07/25(土) 23:46:07.69ID:icwPneMN
>>699
10倍遅いとか捏造しつこいな
chatでソースないのをいいことに捏造しまくり
2020/07/26(日) 00:32:01.45ID:qCaLfESG
>>700
JITの無いインタプリタでJSと同等の速度が出るはずないだろ
JITの有無で速度の桁がひとつ変わるとか普通だ
2020/07/26(日) 00:40:34.12ID:8c+LEo48
>>700
>>696
2020/07/26(日) 00:42:21.83ID:Lwmxod4b
AoTコンパイラはバスに乗り遅れちゃって早くて一年後♪
嗚呼、それでも「JSにスピード競争で勝つことはない」
ミジメｗｗｗ
Blazorすごい！→宣伝してる俺すごい！
しようと思ってたのにまさかBlazorがC#おじさんのミジメな境遇まで堕ちてくるとはねｗｗｗｗｗ
704デフォルトの名無しさん
垢版 |
2020/07/26(日) 01:14:39.39ID:5rw0opQZ
つかこんなに
フロントエンド界隈のライブラリが乱立して
ビルド構築手順ががわちゃわちゃしてる状況は異常
もうHTML自体をバージョンアップした方がいい

HTMLに直でReactやVueやTS SASSとかを記述して
ブラウザネイティブで解釈できるようにするべき
Bootstrapもどうせみんな使うんだか初めから
HTMLの仕様内に組み込んどけ
705デフォルトの名無しさん
垢版 |
2020/07/26(日) 05:35:40.74ID:wM09/xME
>>701
ソースなしでは信ぴょう性がないし
どうせそういうのは発言の切り取り

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

Browser外ではC#のがJSより速いのだから
speedは十分にはやくなる
706デフォルトの名無しさん
垢版 |
2020/07/26(日) 05:53:06.94ID:wM09/xME
>>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.04ID:pVqRHFCg
いいかげんCの民は別スレ行けよ
ここのスレタイ
Vue vs React vs Angular
だから
2020/07/26(日) 08:13:28.39ID:8c+LEo48
それにしてもAngular使ってるサイトだけは全然見つからないよね
Angular本家とお名前と去年の技術書展くらい(今年はReactに変わってた)
2020/07/26(日) 08:52:05.09ID:kppqwmU4
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.95ID:J91SE58H
>>709
Webはこんな方向に進もうとしてるのか
もはやプラットフォーム（OS）だな
そのうちベアメタル（直接ハードウェア）にインストールできるWebブラウザーとか出てきそう
2020/07/26(日) 09:34:24.57ID:2YJHPn7i
>>709
ブラウザベンダが実装拒否してるんじゃJSかwasmは関係なく無理だ
もしできるならセキュリティホールだし
2020/07/26(日) 09:42:00.76ID:2YJHPn7i
ブラウザがなんでもできるようになったらappletやactivexの時みたいにセキュリティ事故が相次いで
何処かの団体がセキュアなもののみを選択したAPIセットを発表して
そのAPIセットを実装したセキュアブラウザみたいなのが登場して
みんなそっちに乗り換えて
需要がなくなった多機能ブラウザは廃れて
すべてが最初に戻る
2020/07/26(日) 09:59:58.67ID:8c+LEo48
まぁブラウザAPIは基本的なもの以外はサイト毎にそのAPIの実行権限をユーザーが許可するかどうかっていうのが大前提なんだけどね
2020/07/26(日) 11:36:06.50ID:J91SE58H
もうやってることがbrowse（拾い読み）の域を超えてるね
2020/07/26(日) 11:36:26.24ID:mCc1k6Br
>>704
同意
もっと言うとHTMLなんか無くした方がいいよね
2020/07/26(日) 11:42:58.77ID:C7Nh/5jG
>>712
本当にこうなったら笑う
717デフォルトの名無しさん
垢版 |
2020/07/26(日) 12:36:40.14ID:wM09/xME
SPAの特徴まとめてみた

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

メリットは高速なページ遷移が可能なことだが
逆に言えばそれが不要ならSPAは必要ないな
むしろコストアップや初回読み込み遅延などのデメリットが上回ってしまう
2020/07/26(日) 12:43:20.43ID:kHoCQhob
> メリットは高速なページ遷移が可能なことだが
これ体感したことある？
2020/07/26(日) 13:05:55.45ID:WcA1r3qH
静的HTML+API+Vueの素朴なマルチページ構成がバランスいい
2020/07/26(日) 13:09:44.19ID:wM09/xME
>>718
画面全体をロードせず、必要な部分を
読み込むので高速になる、と一般的に言われてる。

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

FacebookがSPAで有名な事例だろうけど嫌いだから使わない
2020/07/26(日) 13:37:49.50ID:wgRaBi9V
SPAはWEBアプリケーションを作るための物であってWEBサイトを作るための物ではないからな
結局は使い分けだよ
世界に向けて情報発信するならWEBサイトが基本だからSPAの採用実績が少ないのは仕方ない
複雑になりがちな社内アプリケーションなどは今後はSPAが主流になっていくだろう
722デフォルトの名無しさん
垢版 |
2020/07/26(日) 13:54:45.15ID:r3Yqqk7H
>>717
SSRかSSG使えば初期ローディングとSEOの懸念事項は無くなるんでないかい
Googleだけに関して言えばJSも読んでくれるらしいからSPAでもSEOに関しては問題ない
2020/07/26(日) 14:27:11.75ID:BK/V/n6o
SPAは自分がユーザーの立場になってみると思ったより使い難いんだよね
724デフォルトの名無しさん
垢版 |
2020/07/26(日) 14:43:43.07ID:w6lN3yjx
全ページSSRにしたらJSが無くても使えるしね。
SPAは便利だね。
2020/07/26(日) 14:46:29.68ID:XdP3besl
業務系システムとSPAは相性がいい
業務系では複雑怪奇なUIを求められることが多い
そして業務系と言えばJavaかC#
Javaは廃れ行く運命だがC#にはBlazorがある
業務系はもう全部Blazorでいんじゃねえの
2020/07/26(日) 15:27:13.88ID:J91SE58H
やっぱ業務系か
SPA需要ってPCありきかなと感じていたんだ
Android/iOSならSPAにこだわらずネイティブAppにしちゃったほうがユーザビリティ高いよね
そう考えるとモバイルファーストが謳われてる現在、SPAは下火になっていくのだろうか
2020/07/26(日) 15:36:09.11ID:8c+LEo48
SPA自体PWAありきなんじゃない？
2020/07/26(日) 15:50:04.51ID:3eREBna8
非SPAの採用実績と比較したらSPAの実績なんてカスみたいなものだろうね
そしてこれから先もそんなに伸びることはないと思う

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

ということでSPAの生存戦略として、業務系にフォーカスするってのは有効だと思う
今のところBlazorだけが唯一そっち方面で流行しうる下地を持ったSPAフレームワークと言っていい
業務系ではJSもTSも蛇蝎のごとく嫌われてて人材が足りないから、業務系で既存SPAフャ戟[ムワーク三試墲ﾌ生き残りは血ｵしい
Blazorがうまく行ったら、Javaが後追いでパクリを出してくるだろうね
そしたらまた、勢力図が変わるかもしれん
2020/07/26(日) 15:51:12.91ID:wM09/xME
>>721
Web siteを作るのにSPA framework使ってる人は
ほぼいないしいたらアホでしょう

Web app限定の中でも95%以上はSPA必要ないだろうってこと
>>717のデメリットがメリットを上回る
2020/07/26(日) 15:55:43.15ID:J91SE58H
Googleが期待したほどSPAは盛り上がらなかったね
それで結局ChromeOSも方針転換してAndroidアプリ・Linuxアプリがインストールできるという流れになってしまった

でもVSCodeのようなWeb技術をベースにしたネイティブアプリも人気があるんだよね
Web技術はマルチプラットフォーム対応アプリを作るのには向いているのかも
2020/07/26(日) 15:59:33.53ID:wM09/xME
>>721
最終行
業務用のweb appはASP.net系シェアが圧倒的だし今後も変わらない。
ASP.net系は開発生産性が高い
長期でMSがセキュリティとかのパッチ出してくれる
だからASP.netは法人に選ばれる

Windows PC限定にしてWPFとかのnative appだけで作るのもあり
開発スピードが最速になるしUXも最高レベルになる
社内限定ならcross platformなんていらないし
2020/07/26(日) 16:02:26.11ID:cZIElTbP
ActiveDirectoryに縛られて惰性で使ってるだけ
2020/07/26(日) 16:06:32.34ID:wM09/xME
>>722
SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ

SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損
2020/07/26(日) 16:11:06.69ID:wOzQ8kCZ
>>731
ふーんJavaよりシェア大きいんだ
俺もネイティブは楽で高品質だから、良いと思うけど、
従業員への配信がめんどくさくないかい？
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
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況