【本命】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/19(水) 01:45:20.48

うるせーこのヤロー

**デフォルトの名無しさん** · 2020/08/19(水) 01:47:17.91

>>471
いや普通サイズはでかくなるやろ

**デフォルトの名無しさん** · 2020/08/19(水) 01:47:53.20

DesktopのC#ってなんのことかさっぱりだが

**デフォルトの名無しさん** · 2020/08/19(水) 01:49:44.55

>>474
Blazorとは関係なく、もともとのWindows環境のWinFormsやWPFなどで、
AOTを使った場合が、使わない場合と比べてどのくらい速くなるか、ということ。

**デフォルトの名無しさん** · 2020/08/19(水) 01:50:40.35

>>473
この板で、小さくなると言ってた人を見かけたけど、どうなの？

**デフォルトの名無しさん** · 2020/08/19(水) 01:52:58.02

ラッシュかましてきてんじゃねえぞこのヤロー！

**デフォルトの名無しさん** · 2020/08/19(水) 01:57:03.38

>>475
>>476
はい
https://github.com/dotnet/aspnetcore/issues/5466#issuecomment-639890420

**デフォルトの名無しさん** · 2020/08/19(水) 01:59:34.38

wasmへのコンパイルとAOTを混同しちゃってるのかもね

**デフォルトの名無しさん** · 2020/08/19(水) 02:04:57.56

あ、というよりサイズが小さくなるって言ってる人はlinkerのことを言いたかったのかな？

**デフォルトの名無しさん** · 2020/08/19(水) 02:07:11.31

Hi @MichaelPeter. The initial page load time is dominated by downloading the app and starting
the runtime. AoT won't really help that. AoT is intended to improve runtime performance,
not reduce the app download size.
For JIT based runtimes AoT can improve startup performance because you avoid the need
to JIT at runtime, but Blazor WebAssembly uses an IL interpreter based runtime without
any JIT support.

In all likelihood, AoT will actually make the app larger to download, because .NET IL is a more
compact format than its natively compiled representation.
So using AoT will likely result in a tradeoff between speeding up runtime performance at the
expense of increased download size.
The current thinking is that we will make the AoT toolchain available to developers so that
you can decide how much of your app you want to AoT and then the app will run in a mixed
mode, where some of the app still runs as .NET IL, while the performance critical paths are
precompiled to WebAssembly.

To improve the app starup performance we are looking at further improvements to the
.NET IL linker and also doing work to the core framework libraries to make them more linkable.
We also plan to look at startup performance of the runtime itself once it is downloaded.

**デフォルトの名無しさん** · 2020/08/19(水) 02:13:43.95

ReadyToRunならもう既にWinformsやWPFでも普通に試せるからやってみたら？アセンブリのサイズがでかくなることもすぐわかるはず。まあこれは余計なILも含んでいることが大きいけど…

**デフォルトの名無しさん** · 2020/08/21(金) 23:16:12.00

>>475
デスクトップではVMにJITがあるからAOTしなくても致命的ては無い
でもブラウザで動くVMはJITが無い原始的なインタプリタなので、AOTしないとちょー遅い

**デフォルトの名無しさん** · 2020/08/21(金) 23:18:38.19

デスクトップならふつうにC#で作りゃよくね？存在価値なに？

**デフォルトの名無しさん** · 2020/08/21(金) 23:54:28.41

ぐだぐだうるせーなーこのヤロー

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

>>484
クロスプラットフォーム、リモートアプリ

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

>>484
目新しいものが好き

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

>>186
Reactこんなかかるのか？
論外だろ
こんなサービス誰が使うの

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

フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
https://krausest.github.io/js-framework-benchmark/current.html

二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。

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

最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
（BlazorはJSよりも10倍遅く、スピード競争に勝つことはない）
と述べた。

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

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/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なら大丈夫でね？
なのでサーバーサイドの使い道は
殆ど思いつかん。