【本命】Blazor スレ1【真打】

**デフォルトの名無しさん** · 2020/07/20(月) 23:36:36.67

混沌を極めるWebアプリケーション界隈に現れた一筋の光明
型無し言語 JavaScript の悪夢を打ち払い
林立するエコシステムの亡霊を退散
アプリケーション開発者の希望となるMVVMを引っ提げて登場した真のSPA開発環境

Blazorを語る者よ、集え！

ASP.NET Core Blazor の概要
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1

**デフォルトの名無しさん** · 2020/08/22(土) 10:09:59.61

　　　　　　　　　1年後の世界へ行こう！
／'⌒`ヽ、　Blazorが世界1のシェア取ってるはず…
ヽ、┗　ノ
　 `ーｰ' 　　　 γ⌒ヽ／ﾌﾞﾚｷﾁ＼　　　　／'⌒⌒ヽ、
　　,-ｰｰ-､　　 .||~￣~|/-O-O-ヽ|.　　（　　 ┃　 ⌒ヽ
　/　 ┃　　）　　||　　6| . : )'e'( : . |9　　＼ ━┛　　　）
.（. 　 ┃ 　　）　　|| 　　｀‐-＝-‐ '　　　　　＼＿＿_,ノ
　ヽ､＿＿,ノ　　||　＿(つ¶¶と)＿_
　　　　　　　／||'''''| 　三　 | 　　 |'（⌒）
　　　　　　　／　　　'―――――`　￣＼
　　　　　　`＝＝＝＝＝＝＝＝＝＝＝＝'

**デフォルトの名無しさん** · 2020/08/22(土) 10:12:17.96

￣￣￣| |　　　　ｌｌヽ _|　　　　ヽ　
　　　 | |　　　　 |l￣| |　　　　 l　Blazorって未来ではどうなってんの？
　　　 | |　　　　/　　´＼　　 /　　　　　　　　
　　　 | |　　　ヽ､＿　｀＾イ　　　　　　　　　　
二二二」　＿　＿＿ｌﾆ二二ｌ､　　　　　＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ 　 ┌ヽ　ヽ┐　　／´　　　　　｀＼
二二二二二二ｌ　 /　　 |　 | 　 | |.　 /　　　　　　　　　ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| 　 |_|　/　　　　　　　　　　　　ヽ
　 |　　　　／｀ヽ__, ─ ､ノ |─l　　ｌ　　　　　　　　　　　　　 l　　　
　 |───/　／lﾆ/　 /二ﾆluul.　 |　　　　　　　　　　　　 !　　　え？そんなゴミないよ
　 |　　 ___|￣ |　　|　　|_|.　　　　　　l　　　　　　　　　　　 /
　└─（　　　　）(ﾆ| ￣|./二ﾆ)　　　ヽ　　　　　　　　　 /
　　　　　￣￣　　/　　）　　　　　　 >━━━━━━ く
　　　　　　　　｀ー ´　　　　　　 / 　　　　　　　ヽ

**デフォルトの名無しさん** · 2020/08/22(土) 10:14:21.35

Blazorの弱点：
・Payload. Right now if you create a fresh new Blazor project, it weighs in at around 2.4mb. The team hopes to cut this down significantly come May.
・Load time. Due to download size, devices on poor connections can experience longer initial load times.
・Restricted runtime. Apps have to operate in the browser’s sandbox and are subject to the same security restrictions as any JavaScript application.

何にもコンテンツ無しの状態で2.4MBワロタｗｗｗ

ちなみにこれデスクトップ5,563,976 URL、モバイル6,399,199 URLのサイズデータ。
https://beta.httparchive.org/reports/state-of-the-web#bytesTotal

何にもコンテンツ無しの状態でデスクトップ5,563,976 URLの中央値2MB超えててワロタｗｗｗｗ
何にもコンテンツ無しの状態でモバイル6,399,199 URLの中央値1.9MB超えててワロタｗｗｗｗｗ

何にもコンテンツ無しの状態で2.4MBワロタｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2020/08/22(土) 10:16:27.13

>>230と>>232によるまとめ

ブレカスはReactに比べ、
８　倍　の転送帯域を消費し、
表示までに　４　倍　の時間がかかるｗｗｗ
ファーｗｗｗｗｗ

**デフォルトの名無しさん** · 2020/08/22(土) 10:18:46.22

Blazorのデモ
https://isc30.github.io/blazor-lazy-loading/
のlighthouse結果：
https://lighthouse-metrics.com/one-time-tests/5f2b9fddee28bd0008f6ab20

※LighthouseスコアはGoogleスピードアップデートの採用指標です

うちのサイトはGoogle経由でなんかアクセスされたくない！
資本主義反対！！
そんなコミュニストに最適なマイクロソフト最先端フレームワークBlazorをどうぞヨロシク！！！

**デフォルトの名無しさん** · 2020/08/22(土) 10:21:33.20

どけどけ～邪魔だ邪魔だ～
Lighthouse ２３点が通るぞ～ｗｗｗｗ
https://i.imgur.com/E7NMVpe.png
https://i.imgur.com/8oIU2m8.jpg

**デフォルトの名無しさん** · 2020/08/22(土) 11:58:25.34

はいNG

**デフォルトの名無しさん** · 2020/08/22(土) 11:59:55.29

BlazorはInjection簡単でいいな

**デフォルトの名無しさん** · 2020/08/27(木) 07:46:00.11

ASP.NET Core updates in .NET 5 Preview 8
https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-5-preview-8/

Blazorがらみが多いな

・Lazy loading in Blazor WebAssembly
も来てますよ？

**デフォルトの名無しさん** · 2020/08/27(木) 10:02:14.96

23点取ったのがそのlazy loadingのデモサイトです

**デフォルトの名無しさん** · 2020/08/27(木) 11:27:39.94

LazyLoadComponentじゃなくLazyLoadAssemblyが来たか
これがあれば、最初はミニマムなランチャだけロードして素早く表示、ユーザーが操作を始める間にバックグラウンドでdllを落とす、ユーザーがルーティング操作を行う時には既にロード済、といったシナリオができるわけだ
いいねぇ
これなら最初にロードしなきゃいけないアセンブリを削減できるから、ランチャ自体のダイエットも捗りそうだな
サイズ問題はこれで解決の目処がっ立ったね

**デフォルトの名無しさん** · 2020/08/27(木) 12:21:11.65

全然目処なんて立ってないと思うが。
そんなモンじゃすまないほど大きいから。

**デフォルトの名無しさん** · 2020/08/29(土) 00:50:39.31

GitHub - avikeid2007/Covidonus: COVID 19 Tracker
https://github.com/avikeid2007/Covidonus

やっぱりUnoのほうがまし。

**デフォルトの名無しさん** · 2020/09/06(日) 20:41:08.74

blazorってサーバーにあったrazorが
クライアント側で動くだけ？

**デフォルトの名無しさん** · 2020/09/06(日) 21:02:41.59

>>505
少しはググれよ

**デフォルトの名無しさん** · 2020/09/06(日) 21:56:47.21

>>506
基本機能はそうしか見えないけど。
Domの操作はC#でできんの？

**デフォルトの名無しさん** · 2020/09/06(日) 22:27:01.03

>>505
的外れ極まりない

**デフォルトの名無しさん** · 2020/09/06(日) 22:57:19.13

>>508
WebAssemblyなのにHTML使っといて
Dom操作の操作もC#で出来ないんじゃ
javascript撤廃出来ないじゃん。

**デフォルトの名無しさん** · 2020/09/07(月) 00:48:47.43

できるけどJSを通すしかない

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

>>509
撤廃なんか目指してないからね

**デフォルトの名無しさん** · 2020/09/07(月) 00:54:40.90

>>510
js通すというより
js側に処理を委譲するんじゃ...

ドラッグしつつ、
辿った背景を変更してくみたいな
良くある処理も上手く書けないじゃね？

**デフォルトの名無しさん** · 2020/09/07(月) 00:54:55.00

>>511
www

**デフォルトの名無しさん** · 2020/09/07(月) 01:19:54.93

>>513
何かおかしい？少しでもBlazorに触れたことがあるなら誰でも知ってるはず。
とはいっても昔は勘違いしてた人もいるようで、Daniel Rothもわざわざ否定したりしてたね。
https://visualstudiomagazine.com/articles/2018/03/23/blazor-alpha.aspx?m=1#comment-3820611651

**デフォルトの名無しさん** · 2020/09/07(月) 03:28:26.60

ReactとかVue.js使える人だと、パフォーマンスも悪いんじゃ
使うメリットが全くなさそうだ。

そもそも、Webassemblyなら HTML/CSS使わないと思ってたんだけど、
使ってるあたりが Blazorの癌なのかもね。

**デフォルトの名無しさん** · 2020/09/07(月) 04:32:08.66

なぜ使わないと思ってたんだ…

**デフォルトの名無しさん** · 2020/09/07(月) 08:38:18.69

Blazorの本質はC#が使えること自体ではなく、Webフロントエンドに弱め(全く分からないとは言っていない)な業務系ドットネッターに対して
ReactやVueのような仮想DOM系フレームワークを提供しSPAをキャッチアップさせることにある
もちろんReactやVue使えるんなら全く用はないよ

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

>>515
開発のパフォーマンス（生産性）が劇的にあがる
JS不要で開発できるのは大きい

**デフォルトの名無しさん** · 2020/09/07(月) 09:24:10.31

生産性が飛躍的に向上するから
SPA開発者でも乗り換える価値は高いだろう

**デフォルトの名無しさん** · 2020/09/07(月) 09:24:59.55

>>517
自分が資料みて感じた事と一致します。
C#だけで出来る事が少ない。Dom側の操作がJs頼みならそうなっちゃいますね。

Webassemblyという点につられてる人多そう。
やはりUno Platformが本命ですかね。

**デフォルトの名無しさん** · 2020/09/07(月) 09:25:44.72

ReactやVueを使っていてサーバーサイドもNode.jsならわざわざ切り替える意義はないかな。サーバーサイドがC#ならそれなりに恩恵は大きいはず。

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

>>519
それがVue.jsとか簡単なんですよ。
新規で学んでも簡単でパフォーマンスも良いです。
正直、UI凝り始めるとWPFより使いで良いです。

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

どうしたらHTMLとCSSがいらないなんて発想にたどりつくのか…だってRazorでしょw

**デフォルトの名無しさん** · 2020/09/07(月) 09:37:14.11

>>523
Razorは記法だし、
結果を自前でレダリングしてるのかと思いますね。

**デフォルトの名無しさん** · 2020/09/07(月) 09:41:31.06

>>524
何のための記法か知ってる？

**デフォルトの名無しさん** · 2020/09/07(月) 09:43:29.84

node.jsが超低速だから
web frameworkとして、React系のNextとか Vueを
使わないほうがいいと思う
サーバーサイドでJSを使うというのが遅いしダサい

web frameworkとしてみるとnode系よりも
ASP.net Coreのがはるかに高速

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

>>522
JS、TSって時点で酷しい
JSは単純に生産性が低い
TSはC#の作者と同じだけあって優れた言語だが
コストパフォーマンスの良い要員が集まらない

**デフォルトの名無しさん** · 2020/09/07(月) 09:57:58.91

>>527
Jsって頭の良い人が書いたら、
一般人には理解不能な凄いものが書けますからねwww

**デフォルトの名無しさん** · 2020/09/07(月) 10:12:27.38

>>528
頭がいい人は複雑で高度なことも他人(当然ある程度の前提知識はあるものとする)が読めるように書ける
頭の悪い人が難しいことをやろうとすると、他人に理解できない酷いコードになる

**デフォルトの名無しさん** · 2020/09/07(月) 10:36:24.94

>>529
自分言ってるのはそれとは違うやつの事ですね。
一般人なんで説明できないですけどwww

**デフォルトの名無しさん** · 2020/09/07(月) 12:07:46.81

>>528
本当に頭のいい人は理解しやすいコードを書くものだけどね

JSの悪い点は中途半端に知識「だけ」をつけた実質バカが書くと容易に凄惨なコードを生み出せてしてしまうところ

C#は優れたIDEによるコーチングがあるからバカでも及第点のコードが書ける

**デフォルトの名無しさん** · 2020/09/07(月) 12:12:26.47

日本テレビの子供向けプログラミング教育ω番組
今こそ知りたい!めざせ!プログラミングスター
で映ってた画面が jquery だったわωωω

**デフォルトの名無しさん** · 2020/09/07(月) 13:25:47.78

>>512
あ、そういう意味ね
JS側からC#側のメソッドを呼び出せるから一応はできるはず
ただオーバーヘッドは半端ない気がするし
ガッツリJS書く必要はある

**デフォルトの名無しさん** · 2020/09/07(月) 13:35:49.63

Blazorのサーバー版とWebAssembly版の話題が入り乱れてややこしいなw

**デフォルトの名無しさん** · 2020/09/07(月) 13:36:52.17

>>534
妄想だけで語ってるやつがいるからね

**デフォルトの名無しさん** · 2020/09/07(月) 19:12:50.79

Scoped CSS か CSS Modules が実装されたら起こして

**デフォルトの名無しさん** · 2020/09/07(月) 19:21:13.66

>>536
https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-5-preview-8/#css-isolation-for-blazor-components

**デフォルトの名無しさん** · 2020/09/07(月) 19:29:37.93

>>536
https://youtu.be/KRNd8JDRqRc?t=1645

**デフォルトの名無しさん** · 2020/09/07(月) 20:05:00.63

>>537
ありがとう、枕に頭をつける暇もなかったよｗ

**デフォルトの名無しさん** · 2020/09/08(火) 15:59:38.82

あぁ^～Mauiを想うと心がぴょんぴょんするんじゃぁ^～

**デフォルトの名無しさん** · 2020/09/08(火) 18:07:26.14

苦労してWeb appを作るのは時代遅れなのかもしれない
https://gigazine.net/news/20200907-reddit-app-downloads-miserable-web/

redditは使いにくいweb appにしてnative appに誘導している。
これはけっこう参考になる
開発スピードが速くて、使いやすくて、実行スピードも速いのはnative appだしな

>>540
ごちうさ難民

**デフォルトの名無しさん** · 2020/09/08(火) 18:41:03.85

WPF回帰か
まあそれもわるく無い
高速で生産性が高いC#であることが重要

**デフォルトの名無しさん** · 2020/09/08(火) 21:16:43.61

>>542
残念ながらネイティブアプリageの流れはスマホの話
PCは一貫してWebファーストが普通だし、ネイティブアプリ化するにしてもSlackみたいにWebアプリのガワだけネイティブにするのが今時は多いよ

**デフォルトの名無しさん** · 2020/09/19(土) 11:24:45.44

マウスポインターの位置に
コンテキストメニュー表示したいんだけど、
JS使わずに可能？

**デフォルトの名無しさん** · 2020/09/19(土) 12:03:44.03

コンテキストメニューって言葉がわかってるなら
blazor context menu でぐぐればいいだろ

**デフォルトの名無しさん** · 2020/09/19(土) 12:08:37.39

JSでやってたことをC#でやるだけ
JSを呼び出す必要はない

**デフォルトの名無しさん** · 2020/09/20(日) 11:13:54.82

https://docs.telerik.com/blazor-ui/components/contextmenu/overview
https://github.com/stavroskasidis/BlazorContextMenu

これを見ると、
Jsのラッパー使わないと
出来そうに出来そうに見えないが...

https://github.com/stavroskasidis/BlazorContextMenu/blob/master/BlazorContextMenu/wwwroot/blazorContextMenu.js

**デフォルトの名無しさん** · 2020/09/20(日) 11:18:05.38

要らんよ

**デフォルトの名無しさん** · 2020/09/20(日) 20:15:19.21

コード(C#)でDom Treeの任意の位置に
オブジェクトを足したり削除したり出来るって事？？

**デフォルトの名無しさん** · 2020/09/21(月) 11:55:44.53

https://ncov.oktopus59.net/

blazor 使ってんだって

**デフォルトの名無しさん** · 2020/09/21(月) 12:19:35.43

**デフォルトの名無しさん** · 2020/09/21(月) 12:30:35.11

>>550
速度も問題ないね
結局、体感でサクサクならベンチマークとかどうでもいいんだよな
開発生産性が高いメリットを享受できる

ハード性能あがればさらにJSで書く人は減るだろう

**デフォルトの名無しさん** · 2020/09/21(月) 13:28:01.42

>>550
502 Bad Gateway
が出て起動すらしない。

**デフォルトの名無しさん** · 2020/09/21(月) 14:05:36.06

>>552
viewの処理のほとんどは
Chart.jsなんじゃないの？
99%ぐらい。

**デフォルトの名無しさん** · 2020/09/21(月) 14:30:28.63

そうだね
フロントエンドのパフォーマンス的な観点で言えば、100%普通のJSで動いていると言って差し支えない
そもそもWebAssemblyじゃなくてBlazor Serverだしな

**デフォルトの名無しさん** · 2020/09/21(月) 14:38:45.50

Chart.js使った時点で、
Blazorの出番ないし
最初から全部JSで書いたほうが
楽だし、簡単だよね。

クライアントサイドでC#で動かしたいライブラリーが無かったら
何の価値が有るんだろう。

**デフォルトの名無しさん** · 2020/09/21(月) 17:14:00.32

Blazor Serverだったのか
それなら少人数なら快適に動いて当たり前か

Blazor Serverはスケーラビリティはないらしいね
ぜんぶserver sideでやるから当たり前だけど。
不特定多数向けサービスならBlazor Serverは選ばないほうがいいと思う。
アクセス数が予測できるイントラ利用向けと解説されてた

アクセス多い場合はWebAssemblyとかHybridとかnative appとかほかの技術使う

**デフォルトの名無しさん** · 2020/09/21(月) 17:20:21.47

>>557
はぁっ？

**デフォルトの名無しさん** · 2020/09/21(月) 17:28:12.77

>>558
なんなのその頭悪いレス？
言いたいことあったらはっきりかけアホ

**デフォルトの名無しさん** · 2020/09/21(月) 19:27:13.31

WebFormsで作られた業務システムの移行先に考えてるんだけど、
何でもかんでもblazorで作ると開発コストがかさみそうで…。

複雑な画面構成の機能はBlazorで作って
DBの値を更新するだけの単純な機能はMVCのスキャフォールド機能使って作るみたいなことはできるんだろうか。

いいプロジェクトの構成が思いつかない。

**デフォルトの名無しさん** · 2020/09/21(月) 20:03:05.36

MVCか Blazor Server でいいんちゃうの
Blazor でも WebAssembly使うとプロジェクトも二つになるし
考えないといけないことも増えるかな

SPAにしたくってでもJavaScript/TypeScript極力使いたくないならBlazorかな

**デフォルトの名無しさん** · 2020/09/21(月) 21:52:08.52

>>559
全部サーバーサイドだとスケーラビリティがない

これに
は？
以外どんなレスが付くと思った？

**デフォルトの名無しさん** · 2020/09/21(月) 22:47:24.40

サーバーサイドのは
signalRでクライアントと
Websocketでセッションを張る。
この時点で社内システム程度の運用が限界。

**デフォルトの名無しさん** · 2020/09/21(月) 23:03:25.83

>>562
558のアホか？
初心者のくせに上から目線、ウザすぎ
反論、質問があるなら伝わるように具体的にかけ

俺の見解じゃなくスペシャリストの見解だ
断言する。Blazor Serverはスケーラビリティはない

ServerのCPUとRAMのリソースを最大限に浪費する
セッションも最大限に使う
Serverの処理が重いというのにさらに
SignalRはリアルタイムなJSレスポンスを要求してくる
認証とか絡むと単純にサーバー増やしても解決できない
スケールアウトは極めて困難と言われている

これが理解できないのはサーバー増やせばスケールアウトすると
考えてるような初心者かバカだ

**デフォルトの名無しさん** · 2020/09/21(月) 23:13:14.88

>>563
SignalRがリアルタイムの処理が要求してくるからな
そこで破綻する

**デフォルトの名無しさん** · 2020/09/21(月) 23:38:03.42

リアルタイムリアルタイムってバカの一つ覚えわろた

株価の情報配信するわけでもないだろうに

**デフォルトの名無しさん** · 2020/09/22(火) 00:11:30.38

>>566
何も表示しない画面でも
Websocketのセッションを張るんだよ。
不得意多数の要件には使えない。

なんでらこんな不安なシステムを考案したか
理解できない。

が

多分Webassembly版が出せない時代の
お茶濁しだろうけどね。

**デフォルトの名無しさん** · 2020/09/22(火) 00:14:57.89

あ！

Webassemblyが動作しない処理系にも
同一コードが使えるメリットはある。

いらんけど。ね。

**デフォルトの名無しさん** · 2020/09/22(火) 00:24:35.49

>>567
566はろくにコード書けない上に上からのアホだから
ほとんどレスを理解できてないぞ

Blazor Serverの数少ないメリットはセキュリティ。
コードをclientに極力見せずに作れる。
スケーラビリティを犠牲にしてでもセキュリティが
重要な社内用途とかなら使いどころになりうる

**デフォルトの名無しさん** · 2020/09/22(火) 00:42:48.24

>>567
うん、セッション張るのは Signal-r使ったことあるからわかるよ
っていう今もある業務システムで使ってるわ

ただ、リアルタイムが云々っていうのちょっとね

あと不特定多数って言ってもそんなにたくさんの人がずっと接続し続けるものもあればそうでないものもあるからね

結局どういうアプリ次第なんだよ

**デフォルトの名無しさん** · 2020/09/22(火) 01:17:58.77

>>569
ソース漏は
Webassemblyなら大丈夫でね？
なのでサーバーサイドの使い道は
殆ど思いつかん。

**デフォルトの名無しさん** · 2020/09/22(火) 01:29:18.19

デイトラで有名な、東京フリーランスのとだこうきの動画

0から手を動かして作るRailsチャットアプリ【チュートリアル】
https://www.youtube.com/watch?v=WCsgcp5dg7M

Ruby on Rails で、Web Socket

**デフォルトの名無しさん** · 2020/09/22(火) 01:40:46.22

>>564
あ、はい

**デフォルトの名無しさん** · 2020/09/22(火) 08:14:13.81

>>561
ありがとう
あなたのレス以降Blazor Serverがディスられてて複雑な心境。。

しかし、イントラネット内で千人くらいしか使わないような業務システムならBlazor Serverがベターな気がする。

不特定多数が使うウェブアプリならWebAssemblyがベターなんでしょう。

**デフォルトの名無しさん** · 2020/09/22(火) 09:07:26.70

>>574
同時使用ユーザー数次第だが1000人って規模としては大きめ
基幹業務のシステム？

あとあとパフォーマンス問題でたら無能扱いされるよ
スケールできない技術でやって破綻したら最悪、全部つくりなおし
高価なサーバーの購入が必要になる可能性もある。
責任とれるの？

>>553　で
502 Bad Gateway
でてる人いただろ、これパフォーマンス不足が原因の可能性ある

俺はパフォーマンスでない技術だけは選ばないわ
Blazor Serverでなければならない理由もないのに選ぶ理由がわからん

**デフォルトの名無しさん** · 2020/09/22(火) 09:19:17.86

責任てw
呑み屋で見ず知らずのオヤジに説教受けているみたいな

**デフォルトの名無しさん** · 2020/09/22(火) 09:31:32.20

サラリーマンなら特に重要だろ
プロジェクト失敗したら上流設計やったやつらは
完全に無能扱いされるし
社員からもあいつが上流設計したせいでって陰口叩かれるわｗ

**デフォルトの名無しさん** · 2020/09/22(火) 10:42:28.47

>>577
おっしゃるとおりパフォーマンス問題が出たら、後々何言われるか分からないのがこの業界の常でございます。

ただ機能数が百を超える業務システムを全部が全部blazorで作るわけではない。
特定の機能だけblazorで作りたい…

しかしそんなにパフォーマンスでないもんなんかね

https://devblogs.microsoft.com/aspnet/blazor-server-in-net-core-3-0-scenarios-and-performance/
これ見てると
a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency.

とあるけどこれまさかあのクリックするたびにカウントアップしますよアプリで試してるんだろうか…
複雑な画面でやるとダメダメなんだろうか…

**デフォルトの名無しさん** · 2020/09/22(火) 11:37:42.85

WebSocketのセッションが5000までいけるってことなんじゃないの
VPSなんかだとサーバの設定もあるから
きちんと設定できないとすぐに制限いっぱいになっちゃうんでしょ

どこにサーバーおくかも考えて決めたら

**デフォルトの名無しさん** · 2020/09/22(火) 14:43:37.98

ローカルの環境でIIS Express使ってテストしたら
5000コネクション余裕で張れたわ

**デフォルトの名無しさん** · 2020/09/22(火) 15:17:57.43

SSRがスケールしないって嘘ついてまでBlazorを貶めたいのかねぇ

**デフォルトの名無しさん** · 2020/09/22(火) 16:27:39.02

>>580
scalabilityについては多くの人があげてるけど一例
Blazor Serverの長所短所
Blazor server-side vs client-side (WebAssembly) | What should you choose?
https://youtu.be/HFvPKmS2gig?t=588

localでセッションだけ張れても安心ではないだろう
Blazor ServerはRAMやCPUのリソースも多く使う。
処理速度も遅くなる

あとWAN経由でもアクセスするならネットワークのパフォーマンスも問題になる
結局、パフォーマンス絡みは稼働後に問題が発覚することが大半
採用するなら徹底的にパフォーマンスは事前検証したほうがいい
失敗したら確実に無能の烙印おされる

**デフォルトの名無しさん** · 2020/09/22(火) 17:07:46.37

サーバでテンプレートエンジンを動かして、HTMLを生成
必要なところだけ部分的に、AJAXで更新

結局のところ、それだけでよかったんだ
SPAもSSRも最初から失敗だった

**デフォルトの名無しさん** · 2020/09/22(火) 23:24:11.38

https://docs.microsoft.com/ja-jp/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1#blazor-server
> 多くのユーザーがいるアプリで、スケーラビリティが課題になります。

**デフォルトの名無しさん** · 2020/09/22(火) 23:40:57.68

AWS Elastic Beanstalk は、次の言語と開発スタックをサポートしています

Apache Tomcat for Java アプリケーション
Apache HTTP Server for PHP アプリケーション
Apache HTTP Server for Python アプリケーション

Nginx or Apache HTTP Server for Node.js アプリケーション
Passenger or Puma for Ruby アプリケーション

Microsoft IIS 7.5, 8.0, and 8.5 for .NET アプリケーション
Java SE

Docker
Go

**デフォルトの名無しさん** · 2020/09/22(火) 23:48:23.46

だからその
多くのユーザーって何人の話なんだよ
10万人か100万人か

**デフォルトの名無しさん** · 2020/09/23(水) 00:08:25.99

>>584
個人的にはこっちのほうが嫌だな

SignalR 接続に "スティッキーセッション" を実装する必要があります。

負荷分散装置やらプロキシサーバーやらでいつも苦労する

**デフォルトの名無しさん** · 2020/09/23(水) 02:33:18.98

結論的だけど、
Blazorてjsすら使えないエンジニアの為の
救世主ぐらいしか価値を見いだせない。

Blazorだって学習コストかかるのに
その分JS学んだ方が将来的な
メリットは計り知れないと思うけど。

**デフォルトの名無しさん** · 2020/09/23(水) 12:28:24.15

>>581
アンチと決めつけうざい
じぶんはずっと前からからC#とASP.net推してきてる
スケールしないといってるのはBlazor Serverだ。
Blazor WebAssemblyについてはスケールしないといっていない

>>584にも
MSのサイトにスケーラビリティの欠点かいてあっただろ
前にはなかったが追加された

**デフォルトの名無しさん** · 2020/09/23(水) 12:33:56.41

>>588
JSのほうが将来性ないのになにいってんだ
Wasmが普及したらメインの開発言語でJSを選ぶ人はいなくなる

JSは開発生産性が低いしnode.jsなどserver sideで使っても遅い

Blazor使う層はC#が使える
JSは使えないのではなく、生産性が低いから使いたくないのだ

**デフォルトの名無しさん** · 2020/09/23(水) 13:46:42.94

JavaScriptとセキュリティーについては、紙教材ベースでは学習してはいるけど・・・・
どっかで実務経験を積まないことには、素人サービスであっても実戦投入なんて危なくてできないな

**デフォルトの名無しさん** · 2020/09/23(水) 17:06:15.80

>>590
開発生産性は
VS code + Hot Relode の
vuejsとかreactの方が高いですよ。
言語もTypescriptとか使えば死角がなくなります。