【本命】Blazor スレ1【真打】
レス数が1000を超えています。これ以上書き込みはできません。
混沌を極めるWebアプリケーション界隈に現れた一筋の光明
型無し言語 JavaScript の悪夢を打ち払い
林立するエコシステムの亡霊を退散
アプリケーション開発者の希望となるMVVMを引っ提げて登場した真のSPA開発環境
Blazorを語る者よ、集え!
ASP.NET Core Blazor の概要
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1 作りかけ本番採用ゼロの欠陥フレームワークだからしょうがないw この盛り上がらなさである。
人気がなくて悔しいから、人気のスレに寄生して煩く宣伝するしかない。
だから嫌われる。
C#ガイジはRubyガイジと全く一緒。
C#コミュニティとRubyコミュニティは、これらガイジを生み出して迷惑かけてる責任を取ってもらいたい。 >>8
それは日本人の大半が英語がろくにできないからだ
YouTubeの英語動画みてみろ
Blazorの英語の解説動画はたくさんあって
海外では既にかなり人気になってるのがわかる
ただ日本が遅れてる
YouTubeのBlazor動画いろいろみてると
front endの開発でうんこJS使う必要なくなって良かった!
めちゃくちゃ生産性あがった!
ってみんな感激してるわ 仕方なく使わされていたJSとは比較できない
JSという罰ゲーム開発から解放されたひとたちは
喜んでC#とBlazorを使っているのだ >>8
ホンマこれ。
C# Ruby jQueryは使用者が頭おかしい荒らしばっかだよな Webのフロントエンドに疎く、これまでReactみたいなクライアントサイドテンプレートに触れたことがなかった.NETerが現代文明に触れて感動している図 >>13
JS界隈がレガシーすぎるんだがね
JSは互換性を重視しすぎて化石のようになってる言語
>>12
言語ではないjQueryまでいれてしまう頭のおかしい12なのであった ESnextも悪くないしPHP8も悪くない
ただ現場見てる人からだとイメージは違うかも お前の同類にRubyガイジとjQueryガイジがいるから並べられただけだろう >>17
最近RubyガイジがおとなしくなってるせいでBlazorガイジが悪目立ちしてるよな オーバーナイトBlazorになってからアクセスしてこいって感じ ケンカ売って、荒らして、かき回して注目を集める強盗宣伝しかできない。良くて子供のダダっこか。
本スレはこの体たらくwww
人気のなさは隠せない。
こどおじらしい自分本意ないやらしいこといくらしても誰も注目してくれない。
お前と一緒なフレームワーク。
だから親近感覚えたのかな?www この板はC#が理解できない低能が多いから
まだ人気がないのは仕方がない >>20
確かにBlazorガイジが他スレで暴れ回ってるのに本スレが過疎とか笑えないな。
基地外しかBlazor使ってないのか? 三大サーベイの中で最もJSに厳しいIEEEの今年のランキングが出たぞーwww
Top Programming Languages 2020
https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020
あっれれ〜?おっかしぃぞ〜?wwww >>20
せっかく隔離スレ立てたのにお前みたいな嵐が乗り込んで来たらこっちが過疎るわ
お前はあっちのスレも相変わらず荒らしてるしどうしようもないクソだな >>23
C#がランク外でアホが喜んでるが
おまえの推してたTSもランク入ってないし
ここまで実態を反映しないランキングなどどうでもいい
Pythonは過大評価されすぎ
AI以外であまり使われてない
言語ではないArduinoまで入ってる こっちが過疎ってるのはC#が不人気のクソ言語だからw フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
https://krausest.github.io/js-framework-benchmark/current.html
二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。 最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。 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
延期されたwwww
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよw
https://twitter.com/5chan_nel (5ch newer account)
https://twitter.com/5chan_nel (5ch newer account) アンチというかキチガイが他所に喧嘩売りに行ってんだからそらヘイト買うだろ blazorガイジ「JSは終わる」
それGoogleに言ってみろよw >>34
世界のブラウザシェアも知らんでJS終わるとか言ってんの? なぜC#は失敗したのか…
ドトネトのクロスプラットホーム転換があと10年早ければ…
ほんとに残念。 たった一人の醜態でBlazorのイメージがどんどん悪くなってるな .NETって名前がまずダメでしょ
これを変えるべき それな。ナカタ.NETでまず混乱。
ショップジャパン.NETで再び混乱w もうEdgeもChromium系になったしなMSもブラウザでそこまで独自規格とかもうやらんのやない? Windows 10 Mobileも終わったもんな
MSってあんまクロスプラットフォームで売り出すのには向いてないんじゃないかって思う >>47
jsも一部使ってるけど、C#をjsにトランスパイルしているわけではないよ >>46
結局プラットフォームで商売してるからね
.NET Core系もAzureとの抱き合わせ戦略の結果だんだんおかしくなってきてるし というかソースを見れば分かるがもろscriptタグ使ってる
blaおじはjsオワコンみたいに言ってるからもちろんjsコードは一切書いてないんだろうし
となるとハンドライベントなんかはトランスパイルとは言わないまでも自動生成とかそんな感じなんじゃないの? jsコード一切書かないならwasmの読み込みも出来ないなw
あれもjsコードだからw クロスプラットフォームを売りにしたCoreも結局他プラットフォームには浸透しなさそうって意味じゃない? >>52
だから自動生成とかそんな感じか?って書いてあるじゃん デタラメな妄想を垂れ流すんじゃなくてちゃんとコードに基づいて書けよ >>51
IEが駄目になったのも、Javaが流行ったのも、サーバーサイドがUnix一色になったのも、
MobileでMSが駄目だったのも、理由が分からないのはMSのみ。 >>44
.NET は、亜種が沢山ありすぎる上に、短時間で次から次へと変化して、大混乱中だし、
細かく調べれば調べるほど、誇大宣伝ばかりでMSが言った通りにはなってないので
信用が下がってる。
どれでプログラムしたらいいかもさっぱりわからないから、結局、昔からあるものを
使わざるを得ない。
新しいのに飛びついても、数年でさらに新しいのが出るし。
しかも、変化してるだけで良くなってない。 WinForms, WPF, UWP, Xamarin.Forms, XAML, Blazor, Razor, .NET MAUI
沢山有りすぎて選べない。
始まったと思ったら、すぐ終わる。
「WinFormsは終わってWPFですよ」
何て言ってもWPFはWinFormsより劣った部分も多くて、結局、下火に。
UWPは見る影も無く。
Xamarinは調べれば調べるほどおかしい。
Blazorもおかしい。
結局、一番最初に出たWinFormsが一番開発し易くて、いろいろな意味で安定している。 >>58
というか、まともなアプリの開発に最も適するのは MFC(Win32)。 よく >>58 みたいな体たらくのくせして
「今度は、Blazor は大丈夫!」なんて楽観的に踊れるよな信者は。
過去の経験を記憶する海馬あたりに障害があるんじゃないだろうか?
誇大広告でも、それでも性能で夢見させてくれるのかと思ったら >>28-30 の有り様。もうね…w >>58
少しはググれよw
全然用途の違うものを並べてぼくわかりましぇーんって言われてもな >>63
用途は関係ないよ
マイクロソフトが普及を諦めてなおざりにしてきたライブラリの歴史だよ
マイクロソフトのことだからBlazorもすぐに捨てるだろってこと >>63
用途ごとにフレームワークを変えるなんて、馬鹿ですか。 >>62
xamarinはもうちょっと長生きするかと思ったんだけどなあ。
COCOAで挽回できるかと思ったけどかえってミソつけちゃったね >>65
変えるのが当たり前だろ
スマホアプリ作りたいって要件なのにWPF使うか? .NET MAUIって、.NETまいうーに見える
>>58
いくつか種類があるのは悪いことじゃない
MSはそれだけ長期間サポートしてる証拠でもある
JSのOSSの世界だと破壊的なバージョンアップで仕様変更してるだけ。
MSは長期サポートしないといけないから、名前かえて新しいのを作る
Desktop:
いまさら新規でWinFormsもない。迷わない
WPFは悪いとは思わない。とがってる部分は使わなければいいし。
Cross-platform:
Xamarinの後継が.NET MAUIだからこれも迷わない。
迷わず新しい.NET MAUIにいけばいいんじゃないか
https://qiita.com/nskydiving/items/927b39c2983eb1f2d2b3 >>64
普及するかはユーザーが選ぶか次第だろう
ちゃんと長期サポートするからこそこうやって選択肢がたくさんある
プラットフォーム、用途、安定性、実績を考えて
新しいものから選べばいいとおもう
Xamarinカオスだったから.NET MAUIは楽しみだ WinFormsはUIしょぼいじゃないの
WPFで作った後は戻れない
戻ったら負け感があるだろう?
ASP.net MVC(Core)はこのまま開発終了なのかな
Blazor系だけになったら悲しい >>73
簡単なツールならそもそもGUI要らなくね?って事で結構CUIで作ってたっけな 少し前までは何でもUIを求められたけど、RPAやらタスクランナーで業務が回りだすとコンソールアプリでいい気がしてる
あととりあえずjsonで出し入れできるようにしてると困らなくなった WebAssemblyを批判してる人たちは
GoogleもWebAssemblyに取り組んでるの知ってるのかな?
MicrosofとGoogleが取り組んでて普及しないわけがない wasmは普及するよいずれ。
その時にはblazorなんて滅んでるけどwww 1年後の世界へ行こう!
/'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーー' γ⌒ヽ/ブレキチ\ /'⌒⌒ヽ、
,-ーー-、 .||~ ̄~|/-O-O-ヽ|. ( ┃ ⌒ヽ
/ ┃ ) || 6| . : )'e'( : . |9 \ ━┛ )
.(. ┃ ) || `‐-=-‐ ' \___,ノ
ヽ、__,ノ || _(つ¶¶と)__
/||'''''| 三 | |'(⌒)
/ '―――――`  ̄ \
`============'  ̄ ̄ ̄| | llヽ _| ヽ
| | |l ̄| | l Blazorって未来ではどうなってんの?
| | / ´\ /
| | ヽ、_ `^イ
二二二 」 _ __ lニ二二l、 ____
─┴┐ ⊆フ_)__./ ┌ヽ ヽ┐ /´ `\
二二二二二二l / | | | |. / ヽ
_l_____| /`ー─‐|_| |_| / ヽ
| /`ヽ__, ─ 、ノ |─l l l
|───/ /lニ/ /二ニluul. | ! え?そんなゴミないよ
| ___| ̄ | | |_|. l /
└─( )(ニ|  ̄|./二ニ) ヽ /
 ̄ ̄ / ) >━━━━━━ く
`ー ´ / ヽ WebAssemblyのプロジェクトを作ると、サーバーも同時に作られちゃうけどさ
これWebAssembly部分だけ作るにはどうすりゃいいの? >>84
たいしてサイズ変わらないんだしBlazorServerのも同時に
作られたっていいじゃない Blazorのせいで、Wasmが使いにくい印象を持たれる恐れあり。 >>84
dotnet new blazorwasm -o projdir
だったかなコマンドラインヘルプ見てみて MSはそんなしないよ
そういうことするのは大体勘違いした迷惑な信者 例えば迷惑な信者って声優関係ではめっちゃあるあるなんよね
無駄に別の声優やファンに余計な喧嘩売ったり https://www.telerik.com/forums/blazor-response-is-slowly!
blazor-server: 入力に対するレスポンスがとても遅く、反応が失われることすらある。
blazor-client: 起動すれば反応は速いが、ロードが遅い。
なお、後者の反応が早いといっても、ベンチマーク的にはツールキットの中で最も遅いらしいが。 Blazorに比べれば、UnityのWasmポートの方がまだ速いらしい。 遅いという評判しか聞かないな…
反面、速いという話しは信者の「一年後には最速になる!」といった希望的観測ばかり。
韓国の「10年後には日本を追い抜く!」と同じ精神を感じる。 >>95-96
らしい、らしいって試したこともないバカが他人の
コメントで知ったかぶり
C#を理解できないから自分で試すこともできない。無能
Blazor Serverはserver遅ければ遅くなるのは当たり前
スケールしにくいアーキテクチャだ
社内利用など人数がわかってる場合は爆速で使える
WebAssemblyの初回ロードは決して大きくないし
2回目以降は通常のwebサイトよりも相当小さい
GmailやAmazonのほうがはるかにデータ転送量が多い。 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ワロタwww
ちなみにこれデスクトップ5,563,976 URL、モバイル6,399,199 URLのサイズデータ。
https://beta.httparchive.org/reports/state-of-the-web#bytesTotal
何にもコンテンツ無しの状態でデスクトップ5,563,976 URLの中央値2MB超えててワロタwwww
何にもコンテンツ無しの状態でモバイル6,399,199 URLの中央値1.9MB超えててワロタwwwww
何にもコンテンツ無しの状態で2.4MBワロタwwwwww そもそもwasmが現時点で遅いでしょ
V8のJITの方が早いから使う意味がない >>99
>WebAssemblyの初回ロードは決して大きくないし
Blazorの場合は、かなり大きい。
>GmailやAmazonのほうがはるかにデータ転送量が多い。
大嘘。 >>101
Wasm自体は、結構速い。
遅いのは、Blazor。 CUI的なHelloWorldが2.4MBという時点で終わってる。 >>102
使ったことないだろ?
MS demoなんて2回目は400kb程度しかない
Amazonはトップページで15MB近くある。
それくらいは許容される時代になってるし
Wasmが初回のみ1-2MBとかあったとしても何も問題ない >>104
1-2MBというのは最初のランタイム込みだろうが、
2回目は激減するからどうでもいい
wasmではないweb appよりもcacheが効いている。
ランタイムはブラウザ同梱にしてしまう手もある だれも使ってないEdgeにかw
いつか来て潰れた道だなwww サイドバイサイドが売りだったはずの.NETをWin同梱にしたらバージョン上げにくくなってインプレースでアップデートをやりはじめて
そしたらまたサイドバイサイドを売りにした.NET Coreが出てきたと思ったら今度はASP.NET Coreの同梱とかISSへの統合とかやりはじめて依存関係地獄へ逆戻り
.NETって延々同じ失敗を繰り返してるよな そもそもSPAはアプリケーション、つまり長時間開きっぱなしが前提
だから開くのに数秒かかるぐらいはユーザーは全く気にしない
起動に数秒かかるVSCodeでもみんな大好きだろ、そういうこと
それより重要なのは、開いたあとに安定して速度を出せるかどうか
その点についてはJSよりwasmのほうが高性能って結果がすでに出てる
開くまでの速度が重要ならそもそもSPAを使わずz従来の非SPAの静的サイトあるいはASPNET Core MVCを始めとしたFWが最速なのでそっちにすればいい 二回目から速いから初回訪問は遅くてOK!
…が通るならSSRなんか流行ってない。
現在GoogleがSSR勧めてるのは、以下の二点から。
・SEO
Googleはクライアント側JSでレンダリングされるコンテンツも把握するようボットを継続的に改善してきているが、今はまだ、SSRを勧めるという。
・初回訪問時パフォーマンス
初回訪問時に重い・遅いBlazorみたいなサイトは離脱率が高い傾向があり、せっかく誘導してもムダになるので検索での格を落とすという。いわゆるパフォーマンスアップデートと呼ばれるもので、現在コロナで一時的に延期中。
検索を落とされたくなければ、サイトのサイズを小さくして初回訪問時のパフォーマンスの向上に努めること。SSRはその手段のひとつとして進められている。
Googleが把握するサイトパフォーマンスは、
キャッシュの効かない、
初回訪問時のパフォーマンス
である。
Blazor何にもコンテンツ無しの状態で2.4MBクソワロタwww
ちなみにこれデスクトップ5,563,976 URL、モバイル6,399,199 URLのサイズデータ。
https://beta.httparchive.org/reports/state-of-the-web#bytesTotal
何にもコンテンツ無しの状態でデスクトップ5,563,976 URLの中央値2MB超えててワロタwwww
何にもコンテンツ無しの状態でモバイル6,399,199 URLの中央値1.9MB超えててワロタwwwww
何にもコンテンツ無しの状態で2.4MBワロタwwwwww >>105
>Amazonはトップページで15MB近くある。
無い。嘘つき。 >>105
二回目で400KBって。どんなに大きいねん!
二回目は0でなくてはならん。 1.8MBのはずだけど、いつの時代の話をしているんだ? >>114
それはすごい!さすがBlazor!!
モバイル6,399,199 URLの中央値1.9MBだから、画像含むコンテンツをあと100KB内に納めると、速くもなく遅くもない、ちょうど中間のサイトができるな!
さすがBlazorすごい!! >>111
だからSEOが気になる、初速が重要なサイトにはSPAなんてそもそも必要ないんだよ
SPAの必要がないサイトにむりやりSPAを通そうとしてるからおかしなことになる
銀の弾丸はないっていい加減学ぼう そう、Blazorは銀の弾丸ではない。
遅くて重いがWebがワカラナイC#業務ソフトおじさんを再利用できる介護フレームワークなのだ! 再利用大いに結構
偏屈で高い割に柔軟性がないJSユーザーより一緒に仕事しやすい人材が多いから >>105
1MBのDLに12秒くらいかかる環境でも、amazon.co.jp は、初回でも
数秒以内に利用できる状態になる。
ということは、300KB位しかなく、15MBなんてとんでもない。 >>105
トップページの転送料は3.3MBだったけど? 開発者ツールで見てみたけど、最終的には9MBダウンロードするが、1〜2MBでページは完成してるしスクロールもできる 現実には、ページが見られるまでに必要なのは、300KB程度のはずだ。 >>112 >>119
アマゾンは広告が変わるから日時によってサイズは変わる。
今見たらアマゾンのトップは10MB程度ある。
おまえが調べ方知らないだけだろ
Firefox developer tool使え
>>121
それCache無効化してないだろ
Firefoxの場合は
Shift押しながらreloadしないとcacheを読んでしまう
Twitterのtimelineとかも画像多いから10MB程度いくこともある。
フォローしてる人、画像にもよるがけっこう食う。
それ考えたらBlazor Wasmの初回のみ2MB程度なんてたいしたことない。 >>124
いやいやありえないってw
開発者ツールの画像晒してみ twitterは無限スクロールでどんどんロードしてくんだから当たり前。
それともBlazorでは無限スクロールは
実 装 で き な い
のかなぁ…?
だって実装したら同じように10MB20MB簡単に行っちゃうからね。
フォローしてる人、画像にもよるがけっこう食う。
それはフォローしてる人の投稿内容、画像というコンテンツがあるから。
一方Blazorはなんにもない。
なんにもなくて2MBwww
なんにもコンテンツなくて既に全サイト中真ん中のパフォーマンスwwww
さて内容カラッポで2MBwwwここからコンテンツ足したら重くなるのでしょうか軽くなるのでしょうか?wwwww >>125
今見てみたら、やはり、主要部分は300KB程度で、あとは、商品の画像ファイル
の読み込みが続き、最上部の映画などの宣伝動画がずっと続く。
商品の画像は大体、見てる範囲が先にDLされ、すべてがDLし終わらなくても
見られるから、余りDLの遅さを感じない。
宣伝動画が8MBくらいあるようだが、ストリーミングで再生されているので、
全部 DL されなくても見られる。
これは、Blazor/Wasmが、最初に2MBくらいをDLし終わらないと全く実行できない
のとは全く異なる。 2MB弱で騒いでるアホは
アナログ回線でダイヤルアップ接続でもしてるの?
クソ回線自慢にしかなってないんだがw >>128
そうやって、相手のハードウェア環境を馬鹿にしたりするのはソフトウェア失格。
そんなこと言い出したら、もともこもない。
如何にハードウェアの性能を出し切るかがソフトウェア。 >>126
そういや去年くらいの当時のAngular最新版の実装の新機能で挙がってた機能だかスクロールで表示範囲外になった部分の内容がアンロードされる仕様今のTwitterに入ってるね >>126
通常のサイトは、たとえ 2MB と言っても、ページを表示してから時間を掛けてDL
しているものが多い。
まず、タイトルと文書が見られるようになって、上から順に画像がDLされていくような。
だから、実際には最初の100KBくらいDLされた時点でページ事態は見られる状態になっている。
一方、Blazor/Wasmの場合は、2MBが完全にDLしきらない限りは、全くページが見られない。
この差は大きい。 すぐに改善される部分にしかイチャモンつけられない時点でアンチの敗北なんだがわかってないのかねぇ >>132
MS製品は、未だかつて何も改善されたためしがないのだが。 MSは、サイズに関しては小さく出来たためしがない。 起動が遅いアプリの場合、スプラッシュウインドウを表示するべし。
大昔からの言い伝えだ。 楽天のトップページが20MBあるから。
リアクトで100kbに減らせるなら美味しい。 まあただ同じ低価格帯ならリゴルよりシグレントのほうが歪み少ないね。
テクトロは別格だけど100万するからね。
まあプロならLinux使っとけってことだよね。 最近のオシロはどれもUSB接続できるけど、シミュレータ含めてアプリがWindowsに対応していないからね。
Ubuntuに慣れておくべきだよね。 アナログプローブがWindowsに対応していないのが痛い。
デジタルだけならWindowsでも良いんだけど、結局デジタルも突き詰めて言えばアナログの一部なので、Ubuntuが必要になる。
富岳に対応していないのも使いにくい。
業務だから。 富岳はさすがに日本の技術の粋を集めただけあって速かったね。
Windowsで一時間かかるプログラミングが、富岳なら30分で終わる。
これはイケルと思いました。 MSは、サイズに関しては小さく出来たためしがない。 MSの悪口を言われた雇われエバンジェリストが、任された仕事を全うするため
全く関係ないオシロスコープの話題を出して、ごまかそうとしている。 Blazorなんか業務システム用途だろ
朝に一度立ち上げるだけなんだから
ダウンロードの量とか大した問題じゃないわ
開発の生産性あがる方が大きい だよな。
遅すぎ重すぎでとてもコンシューマーには見せられないよな。 最初おそかったけど気付いたら最速になっていた程度の認識でいいと思います Linux板だとLAMPとWindows Serverを比較してああだこうだ言う人が居るんだけどね。 赤帽で動いてる既存システムをとりあえずなるはやでdockerizeしたいときに便利そう←SYSTEMD >>147
Blazor Wasmはブラウザ閉じて立ち上げ直しても
アプリがちゃんとキャッシュされてる。
全部のダウンロードは本当に最初の1回だけ。
朝だろうが関係ない、翌日以降含めてずっとサイズ小さい https://youtu.be/ctSqiD8BGPM?t=170
ASP.NET coreはnode.jsより7倍速い。
node.jsはオワコン。低速・開発生産性も低い 最初の一回って、オンラインアップデートが常に高速にできることがWebアプリ
のいいところでもあるのに、それができなくなるってことじゃん。
それに最初の一回でも20秒もかかるのは駄目だ。 まぁどんなことでもそうだけど
要はバランスだからな
向く用途と向かない用途がある
どんな技術でも
自分の目的用途で最適だと思うのを選べばいいだけ >>154
ダウンロードするwasmのコードに変更あったら
アップデートされるだろう
それなかったら変更のたびにエラーが出る Yモバ、UQ、Rakuモバなどだと、Blazorでは、HelloWorldの初回起動に20秒以上かかるだろう。 >>158
なお、その環境でも、amzon.co.jpのページは、2秒くらいで使えるようになる。 今後は遅延ロードがカギになんのかな
Blazorの場合どうなってんだろ
メソッド呼び出し時にまだアセンブリがロードされてなかったらそこでダウンロード開始なのか
メイン開始時にバックグラウンドでダウンロード開始なのか
どちらにしても今のDIコンテナはエントリポイントでアセンブリを全部読み込む必要があるから再検討が必要かもしれんな ランタイム部分だけはせめて、全サイトで共用になって欲しいな >>159
これ言っとかないとBlazorおじさんが「Amazonも〜」とか捏造し出すからなw >>161
Blazorの同一バージョンが効果的にキャッシュヒットするほどBlazorが普及するというありえない仮定のもとでは同意 >>159
GmailやAmazonは実際のデータ量は大きいだろう
backgroundで落としてるから気になりにくいだけ。
見かけの速さではなく実データのダウンロードサイズを見るべきだ
>>158
MNOやサブブランドは速いしそんなに時間かからない。 Blazorに文句つけてるやつの大半が
激遅いスクリプト言語つかってるんだよな >>165
いや、Blazor関係なしにお前が嫌われてるだけやぞ 形態の格安キャリアだと一ヶ月5GBを過ぎると1Mbit/s位に速度が落ちる。
5GBだと、まともな画質でYouTubeを見るとなると、2時間もたないだろう。
となると、一ヶ月の内の大部分の日は、1MBbit/sの状態で過ごすことになるだろう。
ならば、Blazorの2MBのDownloadに20秒かかるのはあながち間違いではない。 >>167
低速1Mbpsは格安SIMとは呼ばない。それは
サブブランドかMNOの低速モードだ。
格安と呼ばれるMVNOは、低速200kbps以下
200kbpsの人たちは切り捨てでいいだろ
IE対応と同じで切り捨てていく
光回線も持たずに動画見まくってギガ不足になって追加課金も
しないような事例だされても知らんがなで終わり SSRとWASMのスイッチングをサポートするのが現実的な落としどころかも
デフォルトはSSR
気に入って起動コストが無視できるぐらい利用時間が増えたらWASMに乗り換え もうすでにLazy Loadingは実装されてるみたいだね
https://isc30.github.io/blazor-lazy-loading/
コンポーネント単位で、依存アセンブリが未ロードならダウンロードって感じのようだ
React.lazyと似たような感じかな
これで最初にロードしなきゃいけないのはキャッシュしやすいランタイムだけになった
ほとんど待たされずに最初のページが表示される >>164
GMail、CPUが1コアとかだとメッチャ遅いな > これで最初にロードしなきゃいけないのはキャッシュしやすいランタイムだけになった
ゴチャゴチャと屁理屈捏ねた結果…
>>126 >>131 から状況は何も変わっていないwwww
Blazorはなんにもない。
なんにもなくて2MBwww
なんにもコンテンツなくて既に全サイト中真ん中のパフォーマンスwwww
さて内容カラッポで2MBwwwここからコンテンツ足したら重くなるのでしょうか軽くなるのでしょうか?wwwww ウェブブラウザーから派生して、アプリブラウザーというものが出来るなら、Blazorが標準かもしれないんだよな。
そういう未来もあり得るからな。 むしろ、アプリブラウザーが存在しない状態のほうが、不思議に感じるが。 HTMLの代わりにXAMLを標準とするアプリブラウザがあっても良いはずだよな。 そうだな。Silverlightと名付けよう。流行らない理由がない! Silverlightはフラッシュを意識しててちょっと違うんだよな。
俺たちが欲しいのはそういうものじゃない。 ページにはjQuery、アプリにはBlazorという使い分けだろね。
これは良い考え。 >>174
2Mってなんか勘違いしてないか
そんなでかくないよ >>174
もうここだけがアンチの希望なんだな
こんなのすぐに最適化されて小さくなる
あっという間にダウンロードできる
2回目からキャッシュされてダウンロード時間ゼロ
ほとんど全員が不快感を感じることなく受け入れられるパフォーマンスだね 格安SIMを使ってる人が沢山いる以上、2MBはウェブページにはもちろん、
ウェブアプリにも適さない。 >>183
いや、Windows Updateなんかも最悪なのに、OSにWindows以外の選択肢が
実質存在しないのでみんな仕方無しに使ってるだけで、2MBが少ないなんて
ことはない。1.4MBのFDにOSもCコンパイラもゲームも入っていた時代もあるし、
ファミコンゲームなんてもっと小さかったわけだし。 >>185
話飛びすぎ
急にOSの話しだすとか思考回路どうなってんだろこの人 >>186
Reactもかなり遅いが、Blazorは、未だに起動できない、全く問題外の遅さ。
こんなに遅いWebページ見たことない。 Wasmが本質的にこんなに遅いならまだしも、遥かに起動が速いものもあるから。 >>188
嘘ついてまでアンチしたいのか
両方とも僅かなもたつきですぐに開くぞ >>190
いや、俺の環境では実際に起動できない。 50秒は待ったが起動できないので、不良品と判断した。 50秒は待ったが起動できないので、不良品と判断した。 こっちはどっちとも1秒で開くぞ
遅いっていってたのはパソコンの故障が原因だったのか?
人騒がせな >>194
それは、通信環境が速いだけ。
自分が速い環境にいると、遅い環境の事が分からない。
だから、わざと遅い環境で試すことも重要。 言っておくが、この環境でも、Yahoo、livedoor、amazon.co.jp、5ch/2ch
などは1秒くらいで開く。
Googleも問題ないし、ほとんどのサイトの閲覧も問題ない。
ReactとBlazorは異常。Reactは、まだ30秒くらい待てば開いたが、
Blazorは50秒は待ったが開かない。 Googleのシンプルなトップページが600kb程度だけどな。 >>195
ごく普通に一般向けに提供されてる回線だよ
無線だから回線全体から見ればむしろ遅い部類だ つまり帯域制限された後の異常に遅い回線とかだと使用に耐えられないが
普通に使ってる分にはなんの問題もないということか
それがわかっただけでもよかった
遅いという意見は無視してもいい特殊なケースだったということだ Blazorの時代が来てるな。
キチガイアンチの湧き具合で判断できる。 楽天のトップページが20mbあるんだよ。
2mb程度で重い言うても仕方ないだろ。
アプリなんだから。 >>197
楽天の場合、上の方の検索ボックスが数秒後に表示され、しばらくすると、
下の方の画像以外の枠類が表示されてきて、なんとなく「待てる」。
>>198
キャッシュが全く無い状態からでも、600KBと6秒程度で表示できるのでなんとかなる。
OSを最初に使い始めたとき以外には、Googleのページはキャッシュに乗っているので
遅さを感じない。 >>201
個人的に反論してるだけだから、Blazorの時代は来てないし、今後も来ないと思われる。 https://www.rakuten.co.jp/
これか
Blazor、Reactのデモより遅いじゃん
でもみんななんとも思わず普通に使ってるんだろ
SPAの初回負荷はユーザー目線ではそんなに気にならないってことだな >>202
個人的には楽天は大嫌いで、ほとんど使ったことが無い。
ごちゃごちゃして、めちゃくちゃ使いにくい店に感じる。
文字の大きさがめちゃくちゃで、落書きみたいだ。 >>206
いや、実際に遅い回線だと、Blazorの方がずっと遅いぞ。
Blazorは、全く表示されずにグルグルが回っているだけで全く使い物にならないが、
楽天は、まだ、5秒後くらいに検索ボックスが使える状態になり、しばらくすれば、
なんとなくサイトの構造が見える状態になるから、まだ、操作も出来そうだし、
心理的にも待てる。
Blazorは、何にも出来ない状態で数分間待たされることになるので、役に立たない。 >>208
極端に遅い回線ではそういうことも稀にあるんだろうね
SPAってそういう回線で使うようなものじゃないから気にしなくていいよ 一連のレスにより一般的なシチュエーションではなんの問題もなくBlazorが使えることがわかった
楽天のような規模のサイトと比較すると逆に早く表示される場合もあるということがわかった
今日はいい収穫があったね >>211
あんたは実際に遅い環境で試してないから間違ってる。
楽天は、遅い回線でも、現実的にはなんとかなる。
Blazorは、同じ回線でも、全く起動すらしない。
前者では、全部読み込まなくても使える/見える状態になるのに対し、
後者は、全部読み込まなくては、全く文字すら見えないから。
楽天は画像以外は、割と早い段階で見えるのでなんとかなってる。
>>210
アンチが多いものとしてデスクトップのLinuxがあるが、未だに普及できてない。
5ch以外でもBlazorはアンチが多いので、デスクトップLinuxと同じ運命をたどる
かも知れない。
逆に、Rubyは初期のころはアンチが少なく、使っているうちに問題点が見えてきて、
アンチが多くなるにしたがって、シェアも激減した。
だから、アンチが多いことと優れていることの相関は低いどころか、逆相関で、
アンチが多いことは、そのままそれが劣っていると言うことだ。 遅い遅い言ってるのって、VisualStudioか何かのスレで、いまだにADSL使ってるくせにアップデートでかすぎ!ユーザのことを考えてない!とか騒いでいた奴と同一人物かも。 格安SIMしか使えない貧乏人がアンチしてるだけか
わろた >>212
一般的にみて比較的遅い回線でためした
結果、なんの問題もなかった
楽天よりデモのほうがはやかった
アンチはお前だけだ
現実を直視しろ じゃあ、あなたの思う普通の人向けをターゲットにして、
貧乏人には見てもらえないページを作ってればいいさ。
それで結果がどうなろうとあなたの自由だ。 極々少数の極細回線を無視してもビジネス的には全く問題ない
逆にサポートするためのコストを考えると無視しないほうがマイナスになりかねない >>218
そうか。
だから、Win10のUpdateも、普通の人々だと数分くらいに済む程度に軽くなって
いるから、世界の普通の人々は何の問題もなく快適に行えており、
MS人気は高止まりだからWindowsは売れ続けているんだよね。
株価もなんといっても、アメリカ3位だし。 「ブラウザなら環境に依存しない」という謳い文句を真に受けて「あらゆる環境をサポートすべきだ」
と考えを飛躍させてしまう初心者は少なくない
しかしこれは全く持って現実的ではない
どんなアプリでも必ずサポート対象範囲は有限にしなければならない
どこまでサポートするかはアプリの特性や客層を分析してアプリごとに最適解を導かなければならない うん。だから、Blazorは、Blazorの遅さを許容できる普通の人々だけを
ターゲットにするから、何の問題もないね。
お前の中ではな! >>221
そうだね
一般的なレベルの回線を使ってるふつーのユーザーなら2M程度、なんのストレスもないね
これは一般的な感覚だよ 深夜と真っ昼間にID真っ赤にして発狂してるお前暇すぎだろ。無職なの?
無職で金がなくて、2MBで発狂してるの? しかしこれは凄いぞ。
C#でデスクトップアプリを書くかの如くウェブアプリが書ける。 まとめると、楽天みたいに重くてゴチャゴチャしたサイトをさらに重くてゴチャゴチャさせたいときに使えるのがblazor ってことか まとめると、複雑なサイトを高生産、高速動作にしたいときに使えるのがBlazorということだよ クライアントサイドはデバッグがむずいんよねー
Mauiでなんか進展あればいいんだけど >>186
そのweb appをひらくまでの時間
Blazorは3秒、Reactは10秒だった
application serverの遅さ、
node.jsの遅さ、どれが原因か不明だが、
Blazor、実用的な速さだよな >>208
どんなクソ回線使ってんだよ
MVNOなかでも低品質なSIMか低速モードだろ
光回線やまともなSIMなら>>186 のBlazorは
3秒以内に開く。
2回目以降はcacheあるから爆速 >>186
このblazorの激遅クソアプリ、
69リクエスト、
7.6MB(圧縮転送6.2MB)、
表示されるまで38.93秒www
その間ポケモンボールみたいなのが白っぺっぺの画面上でグールグル(^-^;)
なーんにも表示されないww
なーんにも操作できないwww
何このゴミwwwww >>230
ゴミはお前さんの環境だろw
超低スペックPCをADSLで繋いでアクセスしてるのか? >>230 とまったく同じ環境で今度は >>186 のreactのほうを開く。
15リクエスト、
3.0MB(圧縮転送809kB)、
表示されるまで10.35秒 >>230と>>232によるまとめ
ブレカスはReactに比べ、
8 倍 の転送帯域を消費し、
表示までに 4 倍 の時間がかかるwww
ファーwwwww wasmって圧縮効かねえのな。
ま、そりゃそうか… 何倍というと大げさに聞こえるが
一般的なレベルの回線ではどちらも体感であっという間におわるので無視していい差でしかない
巨人からみたらアリの大小なぞ見分けがつかないということだね 最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。
4倍ならまだマシなほうだなwww しかも提示されたデモサイト内容はBlazorのほうが複雑だ
ハンディキャップありでほとんど体感できる差がないというのはBlazorの優秀さの証明である >>236
JSユーザーを哀れんで言ってるだけ
実際にはBlazorはまあまあ速い
そしてこれからもっと速くなる >>231
ADSLはそこまで遅くないだろう
ゴミみたいなMVNO SIMでテザリングしてるんじゃないかな
>>233
その遅すぎなハードウェアと回線を書いてみろ
Speedtestの結果もな >>240
フィルムストリップがポケモンボールで埋まっててワロタw
しかしGoogleのスピードアップデートを控える今、こんな体たらくでは誰も使わないだろうね。
さすがにパフォーマンス23点ではスピードアップデート後は検索に出てこなくなるだろう。 lighthouseってあんまり信用できないだろ
楽天市場で試すと
遅すぎて半分以上が測定不能になってる 信用しないならそれでもいいけどGoogleのスピードアップデートの指標に採用されてるから低いとGoogle八分にされるねw
Bingで頑張ってねw こういう計測サービスって最も重要なユーザーの体感速度を全く考慮してないから参考にもならんよ
実際に目で見るとBlazorはすぐに表示されてるんだからなんの問題もない >>232
圧縮後のバイト数で考えれば、Blazorが、38.9秒というのはむしろ速すぎで、
75秒くらいになってもおかしくない。
>>229
光回線で3秒と言うのは、使い物にならないほど遅いことを意味する。 もうキチガイは相手しない方がいいんじゃないの
時間の無駄
.net 使えないのが悔しいとかそんなんだろ
あほくさ >>245
lighthouseで楽天市場、計測不能だよなw?
>>246
lighthouseは実態とかけ離れてるね
かなり昔のスマートフォンの性能を前提に計算してるのかも
>>244
wasmはweb standardだし
C#も .NETもオープンソース
囲い込みとか関係ない 現実
>>230
>>232
Lighthouse
>>240
まったくかけ離れてない。むしろ甘いくらい。 実際に、この環境では、楽天の方がBlazorのデモより早く開く。
さらに、amazonはもっとずっと早く開く。
これは、Blazorを貶めるために嘘を言っているとかではなく、本当の話。
事実だ。 アンチが必死になる気持ちもわからないでもない
フロントJSに一点集中して必死に勉強して、JS好きじゃない(苦手とは言ってない)バックエンドエンジニアにマウントをとろうとするフロントエンドエンジニアは少なくない
けどC#でバックエンドエンジニアがフロントもストレスなく開発できるようになったら、非生産的なJSはすぐに用済みとなる
必死に学んできた知識は無価値となり、フロントエンジニアの市場価値が大暴落する可能性が高い
彼らが生き残る為にはBlazorが普及してしまう前に難癖つけて、フォーラムを荒らし回って、流行る前に潰さなきゃならない
まあアンチの考えは、だいたいこんなところだろう 別に必死にならなくても勝手に気付いたら死んでるだろww
SilverlightもXamarinもそうだったwww
俺は貶してるんじゃなくて、客観的事実書いてるだけ。
信者にとっては事実がアンチwww
でもそれがBlazorなんだよねwwww 客観性ゼロのアンチしつけー
まあ消えるのも時間の問題だ
断末魔の叫びと思えば多少は許せるかな >>252
遅いと騒いでるのがお前の環境での話だけで、お前の環境なんてみんなどうでもいいと思ってるというのも、また本当の話。 ID:3k5Zhdnk
ID:Dywe59yG
普通の人が仕事してる時間に発狂する200kbps回線の無職。
スレ立て荒らしもやらかしてるキチガイですね。 ID:QzF98GH4 ID:PW5B5ZEe のことかな?平日昼間からお暇なことでwww
>>259
おやぁ?単発なのはもしかしてwwww アンチニート暴れすぎだろ
専用のアンチスレ立ててそっちで思う存分やれって >>227
ブラウザのデバッガ使えば全然困難ってほどじゃないだろ デモサイトみてBlazorが問題ないスピードっていう認識の
人は増えた感じだな
まだ批判してるのは200kbpsおじだけ なんだデタラメな計測だったのか
怪しいと思ったんだ ウェブサイトはjQuery、ウェブアプリはBlazorという住み分けが出来てくるのでは。 >>264
阿部寛サイトは今は亡きフレームタグ(iframeじゃないぞ)使ってるからだろうな。
これは昔からあるサイトだからいいけど今から作るサイトでフレームタグなんて使ってたらグーグルにガン無視喰らうだろう。 でもパフォーマンスには関係ないだろ
やっぱ測定基準が怪しい 怪しかろうがGoogleはパフォーマンスアップデートでLighthouseの値を使ってサイトをランク付けする。 そもそもアプリだからグーグルのランクは関係ないのでは。 Googleからの流入を期待しないのであればそれでいいと思うよ。 高ランクとれるサイトからアプリに誘導するからアプリ自体のランクはどうでもいい
こういった常識を知らないのだろうね そもそも、アプリに流入というのが少々キチガイっぽい。 主張がコロコロ変わるんだよな。
今は、アプリなんだから激重・激遅で何の問題ないだろ!って主張?
それならいんじゃね?
今後変えんなよw 変わってないぞ
Blazorは軽快で高生産
これで一貫してる ああじゃあ軽快というのは嘘だからBlazorは誇大広告フレームワーク、信者は嘘吐きだな。 楽天のウェブサイトがトップページ20MBの時代に、アプリが2MBというのは、軽量な部類に入るはずだけど。
入力欄一つのグーグルのトップページですら600KBあるのに。 写真コンテンツテンコ盛りの楽天と違って、
コンテンツなーんにも無しのガワだけBlazorで2MB
ショボいメニュー付いた >>186 のBlazorで7.5MB
これに楽天並みの写真コンテンツ載せたらどうなっちゃうのwww
表示までに日が暮れそうwwww >>278
そもそも、楽天を実際に使う場合、トップページからではなく、
Googleで商品を検索してたままた楽天にたどり着くので、
トップページの遅さは関係ない。 それに、楽天は苦戦中で、amazonよりずっと使用者数が少ないと聞いている。
楽天のページは、表示し終わるまでに閉じる。 しかし、既存フレームワークがこれだけビビってるところを見ると、ルールそのものを変える可能性があるのでは?
アンチの湧き具合から、大きな可能性が見える。 >>282
ルールを変えるのはWasmそのものであって、Blazorではない。
Wasmは、Blazorの占有物ではない。 アンチではなく、事実を書いてるだけ。
Blazorが激重・激遅という事実を。
信者にとっちゃ事実はアンチらしいw そりゃ「こんなものウェブサイトには使えないぜ!!」と延々と主張するのは、アンチでは? グーグルのランクが云々言ってるようでは、おそらくMicrosoftに追い付くのは難しい。
まともなウェブアプリを提供できているのは、事実上Microsoftだけに見える。 >>286
何言ってるの?
Blazorのデモは、「まともな」でも「提供」でもない。
一方、Wasmには、Qtのデモ、AutodeskのCADのデモなどで、ウェブアプリのデモがある。
ウェブアプリ全般としては、HTML5ゲームがある。 ビビッドアーミーをグーグルで測定するとどうなるかやってみろ。 >>285
最初から貶すのが目的で決め付けてかかるのが「アンチ」。
実験した事実に基づいて非難するのは科学的批判。 >>288
Blazorは、ビビッドアーミーのレベルには全く達してない。
他のやり方では100KBも必要ないようなものでも、2〜7.5MBも必要となる。 >>290
科学的実験が出来ていると思いこんでいる人と、本当に出来ている人の違いだ。
アメリカのIT企業は、客観的評価をすれば、どこも技術力は低い。
騙された馬鹿な女子高生がiPhoneを買いまくっている。
Win95もそうだった。 >>292
そんなにはない。
それだと、遅い環境では初回起動するのに三時間くらいかかるはずだが、実際には、
10分程度だった。 10分かけてゲーム起動する人は居ないんだよ。
おまえに合わせて製造してたら会社がつぶれる。
つまり、おまえの意見なぞきくだけ無駄。 ついにビビッドアーミーと戦いだしたBlazor信者www >>296
俺の考えではビビッドアーミーをはじめとする中国のH5アプリは本質をつかんでいる。
もちろんMicrosoftのウェブアプリも。
日本勢はちょっと駄目だな。
ユーザー目線が無いから。 SSRなんて最悪の事態だからな。
「SSRしてしまいましたか」
「やっちゃいましたね」
「反省してます」
これが本来の姿なんだけどな。 俺は中国に学べと何度も言ってるはずだが。
中国は凄いぞ。
俺たちより10年先を行ってる。 Amazon→楽天→ビビッドアーミーwww
Blazor信者の藁人形は一体どこまで後退していくのかwwww 中国のビビッドアーミーを馬鹿にしてるが、日本勢がこれを製造するのは無理だぞ。 Blazorを使えば、中国勢と同じようなものが作れる。
これは日本にとって朗報だ。 >>301
馬鹿にしてない。
Blazorは駄目だが、ビビッドアーミーは割りとまとも。 Blazorはビビッドアーミーのようなアプリを作るためのもの。
ウェブサイトを作るものではない。
ここが理解できていないのが、日本人のダメなところ。
これでは世界で戦えない。
中国人に教えを請うべき。 MicrosoftのGithubが開発したElectronというものがあるのだが。 MicrosoftのGithubがBlazorionを作る可能性もある。 まあビビッドアーミーなんてMixiの農業と大して変わらんシステムだけどな。
Mixiの農業も中国だったな。 ビビッドアーミーは、cocos2dでJSを使っており、Blazorとは全く関係ない。 全世界に8カ所あるMSRのうち2箇所が中国にある。
日本には一つも無い。
なぜか?
本質を理解するものが日本には存在しないからだ。 Blazorを見て、グーグルの点数などと言い出す始末。
これじゃ日本が見捨てられたのも納得。 >>311
何その論理飛躍。
全く論理的でない。
結論のみで、全く根拠や理由が述べられてない。 わざわざ完全論破されにやってきて何がしたいんだコイツラ。 ReactなんかのSPAフレームワークに乗り遅れた人が、Blazorを先取りすれば
上に立てると勘違いしてるんだろう。
他の人はBlazorが使い物になったらキャッチアップするだけ。 ヤフーでひどいことになってる。
他人の個人情報が見れたり、他人のデータが書き換わる事態
https://www.asahi.com/amp/articles/ASN86721MN86ULFA02Z.html
https://about.yahoo.co.jp/pr/release/2020/08/06b/
Wappalyzerで検出するとヤフーの登録情報変更のページは
Vue, Nuxt, node.jsを使っているようだが
おまえらはどういうバグだと推測する? BlazorはC#とVisualStudio(or Code)でフロント系スキルが低い非フロント専門職でもリッチなフロントを安く作れる
それで浮いた金をバックエンドに投資できるからその分だけセキュリティ事故も減るだろうね
まあバックエンドに金かければ確実に事故を防げるというわけでもないが確率は減らせるだろう >>317
常識的に考えて純粋にバックエンドの問題だろう
さすがにそんな事故はフロントエンドがどれだけバグってようが改竄されようが発生しないように作るものだ
むしろフロントエンドが関係あると思ってる君もかなりヤバいから人を笑う前に気をつけたほうがいい >>319
フロントとバックの境界ははっきりしていないし
フロントエンド担当者の問題でなければいいと
考えてるおまえのがレベル低いだろう。
そういうバックエンドの知識がないフロントが関与してるからこういう不具合が起こる。 >>319
フロントエンドのコストが高いからバックエンドへの投資が減ってセキュリティがおろそかになったんじゃないの?
資金は有限だからフロントエンドのコストが増えるほどバックエンドに使える費用が減るのは自明ではないかな
あと1人日でもバックエンドへの投資を増やしてレビューとテストを増やしていれば起こらなかった事故かもしれない 結局、アンチのおかげでBlazorの素晴らしさが理論づけられたな。
アンチもたまには役に立つ。
しかし、何がしたかったんだコイツラ。
叩かれるのが好きなのか? まあそうだな
アンチも含めスレがこれだけ勢いよく伸びてるのはBlazorに関心のある人が多いってことだし
いまはまだアンチの人もBlazorに興味は持ってるわけだ アンチも内心で焦りがあるんだろうな
JSがオワコンになったら乗り換えないと仕事がなくなる
自分達の生活を脅かす新技術に憤りを示すと同時に
、迎合して自分を変えなきゃならないという事も頭では理解してる
その葛藤を5chで喚き散らしてどうにか発散しようともがいてる 革命的な技術の黎明期ってのはいつもこうなんだ
クラウドが現れた時のインフラ技術者とかも同じだね >>321 なんか見ても、HTMLエンジニアのコストが高いとか書いてるし。
そんなもん時給1000円で良いだろ。 HTMLエンジニアなんてむしろこっちが金貰いたいくらいだ。 セッション情報の共有について全然出てこないんだけどさ
認証を使った場合って、Blazorの機能としてクラスタリングには対応してないの? クラスタリングって具体的には何のことを言いたいの? ロードバランサやらフェールオーバーやらでサーバー切り替わったときに
セッション引き継ぎたいとかそういうやつだろ ユーザーの立場で言わせてもらうと、ウェブサイトのアプリ化は、イラっとするだけでメリットなにも無いからな。 グーグルのランキング云々言ってるのは、ウェブサイトだからよ。
ホームページエンジニアは間抜けしかいないのか。 >>329
それはフロントエンドじゃなくてAPIサーバーの責務
APIサーバー側で暗号化プロバイダのキーファイルを同じものにすればいい
React、Vueも同じこと >>325
そうなったらそうなってから乗り換えりゃいいだけの話だと思うが、なんでそんな発想になるのか不思議。
フレームワークを1つしか使えない縛りがあるのか、それともは頭のキャパがそれしかないのかね。 string A { get; set; }
string B => A?.ToLower();
string C => A?.ToUpper();
A, B, Cをそれぞれinputにバインド
ブラウザからAに文字列を入力してもB, Cのinputが連動しない
string C {
get => A?.ToUpper();
set {}
}
setもつけると何故か連動するようになる
どういう仕組みで動いてんだこれ >>337
俺は分からんがILSpyで見てみたら? 遅いとか以前に、個人的には、blazorは、書き方が好きになれないな。 Razorはシンプルで書きやすくていい
インテリセンスの効き具合も最高 プレゼンテーションがRazorのうちは、ロジックをC#で書けるだけじゃそんなに美味しくないよなぁ。
早いところWPF/MVVM実現してもらいたいところ。 Razorはシンプルで使いやすいとおもうがな
WPFは記述量が多くなりがちですきじゃない
テンプレートエンジンの是非は置いておいて
JSからC#に移行できるだけでもありがたい
特にValidationが共通化できるから凄い楽になった >>317
リリース後にテストしてればすぐ発覚したのにな
客が使い始めて何時間も経ってから客からの報告で気付くとか情けない
システム設計とか管理職のバグやろ >>317
>6.再発防止策
>再発防止策として「実際のアクセス規模などを想定した事前検証の強化」「問題の早期発見に向けたシステムの監視強化」などを行なってまいります。
これが原因のヒントになってると考えると
ID重複とか初歩的なミスっぽいな
64bitのデータを32bitの変数に描き込んだとかもあり得るな >>347
違う
詳しくらんがサードパーティのOSSだったと サーバーサイドのバリデーションを忘れたってミスで大事なデータ壊す事故は信じられないがたまにあるらしい
なんでそうなるかというと
・フロントエンドでバリデーションを書いたからサーバーサイドは要らないとおもった
・バリデーションを別の言語で2回も実装するだけの工賃をもらってない
ということなんだそうだ
BlazorならバリデーションをC#コードで共通化できるので
追加の工数なしにバリデーションの多重化ができるようになるので
バリデーション不足が原因のセキュリティ事故が減ると期待できる
何よりもまず安全でメンテナンスしやすいシステムを作ることが大事だ
その上でパフォーマンスはじっくり改善していけばいい
Blazorはそんな堅実な開発スタイルによく合う >>352
client sideでは改ざんできるからserver sideでのvalidationは
必須に決まってるのにそんな主張するアホ会社があるんだな
Blazorの前のASP.NET MVCのころから
validationとかdata bindingはめちゃくちゃ楽で良くできてると思うわ WebAssembly版のBlazorはそろそろ使いもんになってきたの?
スマホ対応も考えた場合 >>354
今はまだダメだ
.NET Core 5 まで待て
その時点でダメだったらもう見込み無い .Net Core 5 と Xamarin の違いを教えてください 開発楽ちんすぎて気分いいわ
VisualStudioってやっぱスゲーな WPFならViewModelを普通にユニットテストするだけでいい
しかしBlazorだとどうすればいい?
@codeブロックに書いたコードをユニットテストしたい
WASMでxUnitって動くのか…?
Seleniumを使えばテストはできそうだけど量が多くて大変だ
Reactではコンポーネントのユニットテストどうやってんだろ Reactのコンポーネントは単なる関数だから普通にユニットテストすればいい。
好きなテスティングフレームワーク使えばいいけど人気なのはJest + React-testing-libraryの組み合わせかな。
Blazorは俺も知らん。 >>361
Code BehindとかPartial ClassつかえばViewModelみたいなもんだから普通にテストできる >>363
普通にってのがわからん
xUnitをwasm上でどう走らせるんだ? https://twitter.com/juners/status/1293333277109964800
やはり Blazor WebAssembly だと読み込み時間が長い感ある。
今日はClipboard(クリップボード)にコピー機能を実装しました。
unicode.juner.net
https://twitter.com/5chan_nel (5ch newer account) アプリだから問題ない
キャッシュされるから問題ない ほっときゃそのうち速くなるよ
.NETコミュニティはパフォーマンスにはうるさいから 探したらbUnitというのはあるようだが
しかしこれも結局は開発マシンのランタイムで実行してんだろ?
wasmでテストしたいんだが VisualStudio、WPFも、C#はどれも遅いが。 Windowsは何で書かれてるの?えっC++?どうしてC#で書かないの?www >>374
でも Windows 自身は C/C++ なんでしょ? >>375
コンパイラが対応してないから途中でC++に自動変換されるだけの話
開発してる言語は実質的にC#だ
おまえのロジックでいうとC/C++もだめでマシン語以外不可になる
プログラマーが書く言語がC#ならそれでいい >>372
VSが遅いことは多くの人が認めている。 >>376
>コンパイラが対応してないから途中でC++に自動変換
???
意味不明ですね
C# から C++ に変換?どういう意味ですか? >>377
同程度の規模のIDEの中では最速だろう
もちろん機能も最高峰 >>378
MSの開発者はC#でWindowsを開発しC/C++に変換している >>380
cs2cpp、そんな便利なトランスレータがあったら欲しいですね‥‥ マイクロソフトの主力製品はいまだにC++
Windows、Office、Visual Studio、・・・
Visual Studioはたしかに遅いとこあるな
いまだに32ビットプロセスのままでメモリ節約に四苦八苦してるので
SQL ServerのGUI(Management Studio)が.NETで作られてるっぽかったけど遅いね >>380
C# はガベージコレクタを内蔵していますが、C++ には GC はない
いったいどうしているのですか? EcilpseやAndroid Studioと比べたらVSは激速でしょ >>387-388
OSSでもC#からC++に変換するものはある。
もっと洗練されたものをMSが自社開発してても不思議はないだろ。
C#作ったのもMSだし、MSには天才エンジニアがたくさんいる。 >>390
>OSSでもC#からC++に変換するものはある。
恥ずかしながら聞いたことがありません
よろしければ github のレポジトリを教えてください >>391
ほんとうに恥ずかしいと思ってるなら
英語をもっと勉強して検索してみればわかる >>392
検索しても出てきませんでした
検索キーワードのヒントを教えてください >>385
Visual Studio が遅いのは、WPF(C#)で書かれているからだそうだぞ。 Visual StudioってWPFになったのかよ
最悪だな blazorよりxamarinの方が良くねえか?
てか統一してくれるとC#使いとしては有り難いんだけど いまspy++で調べた
まじで Visual Studioが.NETになっとる
Microsoft.VisualStudio.PlatformUIという.NETアセンブリが使われてた
こらがWPF上に構築されてるのかはよく分からんかった
プロパティウィンドウなど一部にはWinFormsも使われてるっぽいな 過去からタイムスリップしてきた人か
そんなんでよく批判できたな >>400
2005でも使ってたんじゃない?
2010でいきなり重くなって、2015まで次々に悪化。2017、2019で逆に軽くなってきているように感じるね。 VS 2019は、Core i5 3.4GHz (4 cores)だとどのくらいで起動しますか?
当方は、もっと力の弱いCPUを使っており、デスクトップアイコンをクリックしてから、
IDEが起動し、マウスカーソルがくるくる回る状態から脱するのに、23秒くらいかかり
ます。 >>403
CPUは型番で書かないと伝わらない
似たような名前でも世代とかモバイルとか省電力版とか種類がたくさんある
23秒ってHDDじゃないか?
IDE起動はランダムアクセス重要だからSSDは必須。SSDなら数秒 WPFは凝ったUI作れるしいいだろう
>>397
Xamarinは廃止されてMAUIに変わるの確定してる。
BlazorもMAUIに統合されるという噂もある >>407
もとはMicrosoft Build 2020で出た話のようだけど元の動画は見てない
下のページで見たから噂とかいたが
MSがいったのなら実現性は割と高いかもな
https://qiita.com/nskydiving/items/927b39c2983eb1f2d2b3 >>408
MAUIに「統合される」わけじゃないでしょ >>405
LGA1155, SSD 500B, Memory: 4GB x 2枚挿し、
の Core i5 3.4GHz
だとVS 2019の起動速度はどれくらいでしょう?
CPU以外は同じ環境で、現在、実測すると 23秒でした。 >>410
同じBlazorが他の開発製品とだぶって存在するようになるのはありえない
MAUIでBlazorがサポートされるってのはBlazorの位置づけが
変わることを意味する。
MAUIの範囲の一部になるってことだ
統合という表現が不適切とは思わない >>414-415
アホ発言禁止
それはありえない。native appからwasmに変更なら劣化するだけだ
>>416
>>408でわざわざURL探してやったのに感謝のひとこともないのかよ
いつからそんなカス人間になった 散々イキっておいてMAUIに統合とかワロタwww
はい泡沫局所技術終了w
MAUIスレ立ててそこで壮大な話ししようぜw >>418
バカすぎだろ
MAUIに入るってことは位置づけが上になるってことだ。
ブラウザ用のnative appの代表としてBlazorが入ることになる
今はASP.NET Coreのたくさんある技術のひとつでしかない。 たしかにMAUIでマルチプラットフォームアプリ作ればブラウザでも動くようになるってことだもんな
実現したらすごいけどホントにできるんかな? MAUIでBlazorが使えるようになると
Android, iPhone appなどと共通コードベースで
Web appを開発できるようになるってことだ
おそらくAndroidやiPhone, Windows appで成功した後だと思うが
実現したらすごいことがおこる
開発は楽になりそうだがエンジニアの案件、仕事が急激に減りそうでこわい
生産性があがりすぎてしまう 日本の話題扱うのに「岡山県」ってスレでやるか?って話。
MAUIのいちパーツの分際で身の程をわきまえろよwww >>420
もうすでにUnoがデスクトップ、スマホ、ブラウザで動作するクロスプラットフォームXAMLエンジン実装してるよ
MAUIでUnoを吸収するのか新しく作り直すのかは知らんが技術的には楽勝ムード
BlazorはBlazorで生き残ると思う
MAUIがwasmサポートしても十中八九XAMLだからHTML/CSSフレンドリではない
HTML/CSSを使いたいって需要は確実にある >>396
今頃知ったのかよ
15年くらい前やぞwww >>424
HTML/CSS使いたいというのはWebアプリ屋の発想じゃない?
XAMLで普通にアプリ作ってそれがそのままブラウザで動くならそのほうがいいよ
だってマルチプラットフォームアプリだよ?
ブラウザで動かすときだけHTML/CSSで細かく制御したいなんて思わないよ MAUIはXamarinの後継であってBlazorとは交点ないでしょ >>428
BlazorはMAUI陣営に入る可能性あり
Browserで動くnative appなんだからおかしくない
>>408
Blazor Serverはnative appじゃないし
Blazor Serverはどうなるかよくわからないがね >>426
web appはHTML+CSSがめんどくさすぎ、さらにJSがめんどくさい。
GUIはwindows appみたいにコントロール張り付けて開発したい > 将来的には Blazor(Web)のサポートも計画されているようです。
この一文をもって鬼の首を取ったような騒ぎをしているけど
qiitaのこの人以外にこれ言ってる人いる?
blazorはblazorで垂直展開計画してるからmauiの一部門になるような規模のものじゃないんだが
https://www.publickey1.jp/2020/blazorwebassembly502.gif >>430
マウス作業が増えるからポトペタは嫌いだ >>431
公式にはこの程度。
"Enable developer options to use Model-View-Update (MVU) and Blazor"
https://github.com/dotnet/maui#goals >>424
Unoができているからと言って、どうして技術的に楽勝ムードなのか理解に苦しむが。
どうして他の組織が出来ていれば、MSでは楽勝で出来ると思ってしまうのか。
むかしから、MSは技術では「一番」ではなかったのに。
MSにも優秀な人は集まるが、小さな会社でももっと優秀な人がいないとは限らない。
何の根拠で他の会社が出来れば、MSは楽勝だと思っているのだろうか。
頭がおかしいのではないか。 BlazorはMAUI陣営に入る?
それもうBlazorじゃないw
まぁなんであろうとBlazorはないと思うが。 >>435
でも、いくら金の有る大企業であっても、他の小企業が出来たことが容易に出来る
とは限らないと思うけどね。
アメリカの大手IT企業で典型的に問題なのは、サイズや速度。
機能の量は多いけれど、それは通常では考えられないほど大量の社員が
プログラムしているから。
富豪的プログミングすれば、サイズや速度は無視すれば、大量の人がいれば、
機能自体は実装できてしまう。
しかし、今までは、OSのインストール時間やUpdate時間は、独占的立場で
不平不満にも関わらず最悪の状態でも続けられていたが、ひとたび競争原理
が働き始めれば、果たしてどうなるであろうか。 >>432
GUIまわりは特にマウスが生産性高いだろう
editorで数値でサイズ指定しても思った通りにならず
何度も数字を入れなおす羽目になる >>431
なんだよ、Blazor5種類にパワーアップするのかよ
想像以上のスケールだわ
Blazor NativeとBlazor Hybridやりたい Net界のPHPがRazor、Net界のReactがBlazor、Net界のQtがMAUI。 Net界は少なくともAndroidに侵食しないといけないし、iOSにも浸食したほうが良いだろう。
Linuxはオマケだろう。 Net界は会社用なのでウェブ浸食は無いと思うけど、会社専用でも結構なシェアを取れるのはJavaが証明した。 >>439
可変サイズ画面と相性悪すぎ
細かい調整が難しすぎ >>438
マイクロソフトを甘く見すぎ
そこらの並の企業とは技術者の層が違いすぎる
OSSの成功例が既にあってマイクロソフトにできないわけがない
百歩譲って仮にできなかったとしても出来る技術者を雇うか買収すりゃいい 今からUNO勉強して来年無駄になってたらおいちゃん怒るで? 技術力とビジネスの成功は直結しないからなあ
マイクロソフトもGoogleも世界屈指の技術力を持っているのは確か、それでもいくつものプロダクトを失敗させ破棄している
いくら技術力があってもユーザー(開発者コミュニティ)の支持を得られないとダメなのさ >>450
しつこい奴だな
近年のVSは速い
時代に追いついてからレスしてくれ VSCodeだとrazorの構文解析がぜんぜん効かないね
実務レベルではVS必須か 個人的にはSilverlightがwasmにトランスパイルされる+今風な認証を付加してくれるだけで十分なんだけどね Blazor + Electron.NET もよろしく .net coreで既にクロスプラットフォームなのになんでelectronかます必要あるんだ?意味わからん技術 Razor pagesとBlazorって何がどう違うんや?
MSは似たような名前の派生多すぎやろー Razor Pages の後継が Blazor だと思っていい
記法としては Razor記法 >>459-460
たしかに紛らわらしい
日本人はRとLの区別が苦手なのでなおさら紛らわしい
Razor pagesとRazor syntaxは別物
Razor syntaxは現役なので覚える必要ある
たしかRazor pagesはMVCに比べて制限があって
MVC覚えればRazor pagesの知識はいらないはず BlazorのBはもともとBrowserのBだった。
しかしブランドが拡大してBlazor DesktopとかBrowserと
関係ないものまで出てきてきた。 >>462
MVCはWeb APIを書くためのもので、UIを書きたいならRazor Pagesだね .NET5でパフォーマンス関係のインフラ整えて改善に取り組んでるね 少し待てばすぐにパフォーマンスアップするだろ
JavaやNodeじゃねえんだから遅いままなんてこたない スピードってブラウザ次第じゃないの?
どのみち再コンパイルが必要なんだろ? AoTはおあずけ食らいました。少なくともあと一年は速くならない そもそも、DesktopのC#は、AOTでどのくらい速くなるの?
特にサイズはどのくらい変化する?
小さくなるの?
なるとしたら何分の一になる? >>474
Blazorとは関係なく、もともとのWindows環境のWinFormsやWPFなどで、
AOTを使った場合が、使わない場合と比べてどのくらい速くなるか、ということ。 >>473
この板で、小さくなると言ってた人を見かけたけど、どうなの? wasmへのコンパイルとAOTを混同しちゃってるのかもね あ、というよりサイズが小さくなるって言ってる人はlinkerのことを言いたかったのかな? 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. ReadyToRunならもう既にWinformsやWPFでも普通に試せるからやってみたら?アセンブリのサイズがでかくなることもすぐわかるはず。まあこれは余計なILも含んでいることが大きいけど… >>475
デスクトップではVMにJITがあるからAOTしなくても致命的ては無い
でもブラウザで動くVMはJITが無い原始的なインタプリタなので、AOTしないとちょー遅い デスクトップならふつうにC#で作りゃよくね?存在価値なに? >>484
クロスプラットフォーム、リモートアプリ >>186
Reactこんなかかるのか?
論外だろ
こんなサービス誰が使うの フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
https://krausest.github.io/js-framework-benchmark/current.html
二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。 最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。 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
延期されたwwww
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよw
https://twitter.com/5chan_nel (5ch newer account) 1年後の世界へ行こう!
/'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーー' γ⌒ヽ/ブレキチ\ /'⌒⌒ヽ、
,-ーー-、 .||~ ̄~|/-O-O-ヽ|. ( ┃ ⌒ヽ
/ ┃ ) || 6| . : )'e'( : . |9 \ ━┛ )
.(. ┃ ) || `‐-=-‐ ' \___,ノ
ヽ、__,ノ || _(つ¶¶と)__
/||'''''| 三 | |'(⌒)
/ '―――――`  ̄ \
`============'  ̄ ̄ ̄| | llヽ _| ヽ
| | |l ̄| | l Blazorって未来ではどうなってんの?
| | / ´\ /
| | ヽ、_ `^イ
二二二 」 _ __ lニ二二l、 ____
─┴┐ ⊆フ_)__./ ┌ヽ ヽ┐ /´ `\
二二二二二二l / | | | |. / ヽ
_l_____| /`ー─‐|_| |_| / ヽ
| /`ヽ__, ─ 、ノ |─l l l
|───/ /lニ/ /二ニluul. | ! え?そんなゴミないよ
| ___| ̄ | | |_|. l /
└─( )(ニ|  ̄|./二ニ) ヽ /
 ̄ ̄ / ) >━━━━━━ く
`ー ´ / ヽ 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ワロタwww
ちなみにこれデスクトップ5,563,976 URL、モバイル6,399,199 URLのサイズデータ。
https://beta.httparchive.org/reports/state-of-the-web#bytesTotal
何にもコンテンツ無しの状態でデスクトップ5,563,976 URLの中央値2MB超えててワロタwwww
何にもコンテンツ無しの状態でモバイル6,399,199 URLの中央値1.9MB超えててワロタwwwww
何にもコンテンツ無しの状態で2.4MBワロタwwwwww >>230と>>232によるまとめ
ブレカスはReactに比べ、
8 倍 の転送帯域を消費し、
表示までに 4 倍 の時間がかかるwww
ファーwwwww Blazorのデモ
https://isc30.github.io/blazor-lazy-loading/
のlighthouse結果:
https://lighthouse-metrics.com/one-time-tests/5f2b9fddee28bd0008f6ab20
※LighthouseスコアはGoogleスピードアップデートの採用指標です
うちのサイトはGoogle経由でなんかアクセスされたくない!
資本主義反対!!
そんなコミュニストに最適なマイクロソフト最先端フレームワークBlazorをどうぞヨロシク!!! 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
も来てますよ? 23点取ったのがそのlazy loadingのデモサイトです LazyLoadComponentじゃなくLazyLoadAssemblyが来たか
これがあれば、最初はミニマムなランチャだけロードして素早く表示、ユーザーが操作を始める間にバックグラウンドでdllを落とす、ユーザーがルーティング操作を行う時には既にロード済、といったシナリオができるわけだ
いいねぇ
これなら最初にロードしなきゃいけないアセンブリを削減できるから、ランチャ自体のダイエットも捗りそうだな
サイズ問題はこれで解決の目処がっ立ったね 全然目処なんて立ってないと思うが。
そんなモンじゃすまないほど大きいから。 GitHub - avikeid2007/Covidonus: COVID 19 Tracker
https://github.com/avikeid2007/Covidonus
やっぱりUnoのほうがまし。 blazorってサーバーにあったrazorが
クライアント側で動くだけ? >>506
基本機能はそうしか見えないけど。
Domの操作はC#でできんの? >>508
WebAssemblyなのにHTML使っといて
Dom操作の操作もC#で出来ないんじゃ
javascript撤廃出来ないじゃん。 >>510
js通すというより
js側に処理を委譲するんじゃ...
ドラッグしつつ、
辿った背景を変更してくみたいな
良くある処理も上手く書けないじゃね? ReactとかVue.js使える人だと、パフォーマンスも悪いんじゃ
使うメリットが全くなさそうだ。
そもそも、Webassemblyなら HTML/CSS使わないと思ってたんだけど、
使ってるあたりが Blazorの癌なのかもね。 Blazorの本質はC#が使えること自体ではなく、Webフロントエンドに弱め(全く分からないとは言っていない)な業務系ドットネッターに対して
ReactやVueのような仮想DOM系フレームワークを提供しSPAをキャッチアップさせることにある
もちろんReactやVue使えるんなら全く用はないよ >>515
開発のパフォーマンス(生産性)が劇的にあがる
JS不要で開発できるのは大きい 生産性が飛躍的に向上するから
SPA開発者でも乗り換える価値は高いだろう >>517
自分が資料みて感じた事と一致します。
C#だけで出来る事が少ない。Dom側の操作がJs頼みならそうなっちゃいますね。
Webassemblyという点につられてる人多そう。
やはりUno Platformが本命ですかね。 ReactやVueを使っていてサーバーサイドもNode.jsならわざわざ切り替える意義はないかな。サーバーサイドがC#ならそれなりに恩恵は大きいはず。 >>519
それがVue.jsとか簡単なんですよ。
新規で学んでも簡単でパフォーマンスも良いです。
正直、UI凝り始めるとWPFより使いで良いです。 どうしたらHTMLとCSSがいらないなんて発想にたどりつくのか…だってRazorでしょw >>523
Razorは記法だし、
結果を自前でレダリングしてるのかと思いますね。 node.jsが超低速だから
web frameworkとして、React系のNextとか Vueを
使わないほうがいいと思う
サーバーサイドでJSを使うというのが遅いしダサい
web frameworkとしてみるとnode系よりも
ASP.net Coreのがはるかに高速 >>522
JS、TSって時点で酷しい
JSは単純に生産性が低い
TSはC#の作者と同じだけあって優れた言語だが
コストパフォーマンスの良い要員が集まらない >>527
Jsって頭の良い人が書いたら、
一般人には理解不能な凄いものが書けますからねwww >>528
頭がいい人は複雑で高度なことも他人(当然ある程度の前提知識はあるものとする)が読めるように書ける
頭の悪い人が難しいことをやろうとすると、他人に理解できない酷いコードになる >>529
自分言ってるのはそれとは違うやつの事ですね。
一般人なんで説明できないですけどwww >>528
本当に頭のいい人は理解しやすいコードを書くものだけどね
JSの悪い点は中途半端に知識「だけ」をつけた実質バカが書くと容易に凄惨なコードを生み出せてしてしまうところ
C#は優れたIDEによるコーチングがあるからバカでも及第点のコードが書ける 日本テレビの子供向けプログラミング教育ω番組
今こそ知りたい!めざせ!プログラミングスター
で映ってた画面が jquery だったわωωω >>512
あ、そういう意味ね
JS側からC#側のメソッドを呼び出せるから一応はできるはず
ただオーバーヘッドは半端ない気がするし
ガッツリJS書く必要はある Blazorのサーバー版とWebAssembly版の話題が入り乱れてややこしいなw Scoped CSS か CSS Modules が実装されたら起こして >>537
ありがとう、枕に頭をつける暇もなかったよw あぁ^〜Mauiを想うと心がぴょんぴょんするんじゃぁ^〜 苦労してWeb appを作るのは時代遅れなのかもしれない
https://gigazine.net/news/20200907-reddit-app-downloads-miserable-web/
redditは使いにくいweb appにしてnative appに誘導している。
これはけっこう参考になる
開発スピードが速くて、使いやすくて、実行スピードも速いのはnative appだしな
>>540
ごちうさ難民 WPF回帰か
まあそれもわるく無い
高速で生産性が高いC#であることが重要 >>542
残念ながらネイティブアプリageの流れはスマホの話
PCは一貫してWebファーストが普通だし、ネイティブアプリ化するにしてもSlackみたいにWebアプリのガワだけネイティブにするのが今時は多いよ マウスポインターの位置に
コンテキストメニュー表示したいんだけど、
JS使わずに可能? コンテキストメニューって言葉がわかってるなら
blazor context menu でぐぐればいいだろ JSでやってたことをC#でやるだけ
JSを呼び出す必要はない コード(C#)でDom Treeの任意の位置に
オブジェクトを足したり削除したり出来るって事?? >>550
速度も問題ないね
結局、体感でサクサクならベンチマークとかどうでもいいんだよな
開発生産性が高いメリットを享受できる
ハード性能あがればさらにJSで書く人は減るだろう >>550
502 Bad Gateway
が出て起動すらしない。 >>552
viewの処理のほとんどは
Chart.jsなんじゃないの?
99%ぐらい。 そうだね
フロントエンドのパフォーマンス的な観点で言えば、100%普通のJSで動いていると言って差し支えない
そもそもWebAssemblyじゃなくてBlazor Serverだしな Chart.js使った時点で、
Blazorの出番ないし
最初から全部JSで書いたほうが
楽だし、簡単だよね。
クライアントサイドでC#で動かしたいライブラリーが無かったら
何の価値が有るんだろう。 Blazor Serverだったのか
それなら少人数なら快適に動いて当たり前か
Blazor Serverはスケーラビリティはないらしいね
ぜんぶserver sideでやるから当たり前だけど。
不特定多数向けサービスならBlazor Serverは選ばないほうがいいと思う。
アクセス数が予測できるイントラ利用向けと解説されてた
アクセス多い場合はWebAssemblyとかHybridとかnative appとかほかの技術使う >>558
なんなのその頭悪いレス?
言いたいことあったらはっきりかけアホ WebFormsで作られた業務システムの移行先に考えてるんだけど、
何でもかんでもblazorで作ると開発コストがかさみそうで…。
複雑な画面構成の機能はBlazorで作って
DBの値を更新するだけの単純な機能はMVCのスキャフォールド機能使って作るみたいなことはできるんだろうか。
いいプロジェクトの構成が思いつかない。 MVCか Blazor Server でいいんちゃうの
Blazor でも WebAssembly使うとプロジェクトも二つになるし
考えないといけないことも増えるかな
SPAにしたくってでもJavaScript/TypeScript極力使いたくないならBlazorかな >>559
全部サーバーサイドだとスケーラビリティがない
これに
は?
以外どんなレスが付くと思った? サーバーサイドのは
signalRでクライアントと
Websocketでセッションを張る。
この時点で社内システム程度の運用が限界。 >>562
558のアホか?
初心者のくせに上から目線、ウザすぎ
反論、質問があるなら伝わるように具体的にかけ
俺の見解じゃなくスペシャリストの見解だ
断言する。Blazor Serverはスケーラビリティはない
ServerのCPUとRAMのリソースを最大限に浪費する
セッションも最大限に使う
Serverの処理が重いというのにさらに
SignalRはリアルタイムなJSレスポンスを要求してくる
認証とか絡むと単純にサーバー増やしても解決できない
スケールアウトは極めて困難と言われている
これが理解できないのはサーバー増やせばスケールアウトすると
考えてるような初心者かバカだ >>563
SignalRがリアルタイムの処理が要求してくるからな
そこで破綻する リアルタイムリアルタイムってバカの一つ覚えわろた
株価の情報配信するわけでもないだろうに >>566
何も表示しない画面でも
Websocketのセッションを張るんだよ。
不得意多数の要件には使えない。
なんでらこんな不安なシステムを考案したか
理解できない。
が
多分Webassembly版が出せない時代の
お茶濁しだろうけどね。 あ!
Webassemblyが動作しない処理系にも
同一コードが使えるメリットはある。
いらんけど。ね。 >>567
566はろくにコード書けない上に上からのアホだから
ほとんどレスを理解できてないぞ
Blazor Serverの数少ないメリットはセキュリティ。
コードをclientに極力見せずに作れる。
スケーラビリティを犠牲にしてでもセキュリティが
重要な社内用途とかなら使いどころになりうる >>567
うん、セッション張るのは Signal-r使ったことあるからわかるよ
っていう今もある業務システムで使ってるわ
ただ、リアルタイムが云々っていうのちょっとね
あと不特定多数って言ってもそんなにたくさんの人がずっと接続し続けるものもあればそうでないものもあるからね
結局どういうアプリ次第なんだよ >>569
ソース漏は
Webassemblyなら大丈夫でね?
なのでサーバーサイドの使い道は
殆ど思いつかん。 デイトラで有名な、東京フリーランスのとだこうきの動画
0から手を動かして作るRailsチャットアプリ【チュートリアル】
https://www.youtube.com/watch?v=WCsgcp5dg7M
Ruby on Rails で、Web Socket >>561
ありがとう
あなたのレス以降Blazor Serverがディスられてて複雑な心境。。
しかし、イントラネット内で千人くらいしか使わないような業務システムならBlazor Serverがベターな気がする。
不特定多数が使うウェブアプリならWebAssemblyがベターなんでしょう。 >>574
同時使用ユーザー数次第だが1000人って規模としては大きめ
基幹業務のシステム?
あとあとパフォーマンス問題でたら無能扱いされるよ
スケールできない技術でやって破綻したら最悪、全部つくりなおし
高価なサーバーの購入が必要になる可能性もある。
責任とれるの?
>>553 で
502 Bad Gateway
でてる人いただろ、これパフォーマンス不足が原因の可能性ある
俺はパフォーマンスでない技術だけは選ばないわ
Blazor Serverでなければならない理由もないのに選ぶ理由がわからん 責任てw
呑み屋で見ず知らずのオヤジに説教受けているみたいな サラリーマンなら特に重要だろ
プロジェクト失敗したら上流設計やったやつらは
完全に無能扱いされるし
社員からもあいつが上流設計したせいでって陰口叩かれるわw >>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.
とあるけどこれまさかあのクリックするたびにカウントアップしますよアプリで試してるんだろうか…
複雑な画面でやるとダメダメなんだろうか… WebSocketのセッションが5000までいけるってことなんじゃないの
VPSなんかだとサーバの設定もあるから
きちんと設定できないとすぐに制限いっぱいになっちゃうんでしょ
どこにサーバーおくかも考えて決めたら ローカルの環境でIIS Express使ってテストしたら
5000コネクション余裕で張れたわ SSRがスケールしないって嘘ついてまでBlazorを貶めたいのかねぇ >>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経由でもアクセスするならネットワークのパフォーマンスも問題になる
結局、パフォーマンス絡みは稼働後に問題が発覚することが大半
採用するなら徹底的にパフォーマンスは事前検証したほうがいい
失敗したら確実に無能の烙印おされる サーバでテンプレートエンジンを動かして、HTMLを生成
必要なところだけ部分的に、AJAXで更新
結局のところ、それだけでよかったんだ
SPAもSSRも最初から失敗だった 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 だからその
多くのユーザーって何人の話なんだよ
10万人か100万人か >>584
個人的にはこっちのほうが嫌だな
SignalR 接続に "スティッキー セッション" を実装する必要があります。
負荷分散装置やらプロキシサーバーやらでいつも苦労する 結論的だけど、
Blazorてjsすら使えないエンジニアの為の
救世主ぐらいしか価値を見いだせない。
Blazorだって学習コストかかるのに
その分JS学んだ方が将来的な
メリットは計り知れないと思うけど。 >>581
アンチと決めつけうざい
じぶんはずっと前からからC#とASP.net推してきてる
スケールしないといってるのはBlazor Serverだ。
Blazor WebAssemblyについてはスケールしないといっていない
>>584にも
MSのサイトにスケーラビリティの欠点かいてあっただろ
前にはなかったが追加された >>588
JSのほうが将来性ないのになにいってんだ
Wasmが普及したらメインの開発言語でJSを選ぶ人はいなくなる
JSは開発生産性が低いしnode.jsなどserver sideで使っても遅い
Blazor使う層はC#が使える
JSは使えないのではなく、生産性が低いから使いたくないのだ JavaScriptとセキュリティーについては、紙教材ベースでは学習してはいるけど・・・・
どっかで実務経験を積まないことには、素人サービスであっても実戦投入なんて危なくてできないな >>590
開発生産性は
VS code + Hot Relode の
vuejsとかreactの方が高いですよ。
言語もTypescriptとか使えば死角がなくなります。 >>592
ありえない
reactはframeworkじゃないし関係ない
静的言語は速度も生産性もC#に勝てない
C#やasp.netを知らない人の意見とすぐわかる
必要なコードの量が全く違う Javaの方が早く死にかけてるのに驚いてる
古くからのC#erですよ。
ASP.NETの前のASPのベータ版から親しんでる
爺です。 >>584
Blazor WebAssemblyと比較しての欠点でしょ
シンクライアントとファットクライアントを比べたら当然のことが書いてあるだけ 技術選定するにあたって、
Blazorの対抗馬としてReactやらVueやら最近流行りのフレームワークは当然候補に上がってくる。
しかしこの手の技術、実際手を動かして作ってみたことがない…
本当のところ生産性ってどうなんだろう。
両方使いこなせてる人に生産性の違いを教えてもらいたい。
以前なんかのブログに、
TypeScriptは型が使えるんですよ。するとIDEでコード補完やリファクタリング機能が使えるんですよ!これは便利!
と書いてあるのを見た。
実はWeb系の人たちってこれまでものすごい苦行を強いられてきていたのでは… >>596
server-sideの生産性はasp.net coreが格段に上
UI component作るだけならJS/C# どちらの言語に慣れているかで
変わるかもしれない。
流行ってるかどうかではなく、優れているかどうか、
自分のスキル、好みで決めればいいよ
PHPみたいにそこそこ流行っていてもクソみたいな言語もある >>597
チームで開発してるからなかなか自分の好みだけでは決めれなくて…
Blazorつかいます!ってなったら
そんなのよりVueを使いたまえとか言ってくる偉い人が必ず出てくる。
若い子も流行りのtsやReact、Vueをマスターしたいってなると思う。
そのとき、君たちの憧れの言語やフレームワークはこんな苦行を強いられるのですよと言えるようにしておきたい。 >>598
流行りで決めるほうがよっぽど論理的でないだろう
server-sideのbenchmark見てみりゃわかる
node.js系はasp.net coreよりかなり遅い。
それだけでJS系frameworkを使わない理由になる。
同じ言語C#でclient-sideも開発できればコストも削減できる。
Vueなんて個人ベースで作ってるものだろ
長期サポートされないしnode系だから速度も遅い。 流行ってるかどうかでいったら普及率ナンバーワンの
web frameworkはWordPressなわけだけど、
本格的なweb appをそんなゴミで開発しようとはならないでしょ。
シェアで技術を選ぶのは完全に間違いってこと JavaScript は改良が続くんだろうし
いつかTypeScriptとの違いもなくなっちゃうのかもしれんね
そうなったらクライアントサイドがJavascriptでもいいのかもしれない >>602
JSは互換性重視だから大幅には変わらない。
wasm普及したらJSの役割はおしまいだろ
PCとSPで動くnative appを開発できるツールが
でてきてweb appが下火になる未来も来ると思うわ
AppleもMAC向けARM系独自プロセッサ開発する。
最後はcross platform対応のnative appに向かう 中途半端Bootstrapより、なんかまともなもんを一つ移植して欲しいな WebAppは、下火になるとしても、独特の面白さがある。
ビビッドアーミーなんかも、Webからすぐに始められるから、インストール型
のゲームよりも罪悪感が少ないため、ヒットした可能性がある。 >>596
最近までasync/awaitもなかったんやで・・推して知るべし
自分は最近仕事で使ったからReactはギリ推せる
なぜかというとhooksが導入されたり関数コンポーネントが主流になったりで
React周りの記述量が大幅に減ったから
Reduxなんか挫折する人が出るくらい記述量が無駄に多かったらしい
それもRedux-Toolkitでずいぶん楽になったようだ
調べているうちに新旧のコードを見かけるけど
旧Reduxで組んでた人はよく発狂しなかったと感嘆した
まだまだ記述量が減る余地はあると思うから期待したい
BlazorはRedux-Toolkit以上の使いやすい状態管理が提供されれば
仕事でも使ってみたい
ReactとVueは選定するとき迷ったが、サポートしているのが
FaceBookとコミュニティでは巨人の肩に乗るほうがよいと判断した
Augularは構文デザインになぜか吐き気を覚えたので選定から外した みなさん貴重なご意見ありがとう。
Web系のひとたち、俺たちは最先端のことやってるぜ感出してるけど、
昔のVBAみたいな、あとで誰も手をつけれてないようなシロモノを職人技で苦労しながら作ってるような気がしてて…
そういうのは仕事では使いたくない…
あとBlazorに望むこととしては、
WinFormsやWebFormsみたいに標準のコントロールを充実させてほしい。
DataGridViewやTreeViewが海外のサードパーティ製にしかないのはこれまたお仕事では困る…
ぼちぼちGrapeCityあたりが出してくれそうだが… YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる
この2つ以外は、出てこない
GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
言語よりも、Docker, Kubernetes, AWS などの、サーバー構築・新規案件を重視する。
上流工程・新規案件の方が、価格交渉力が強いから。
一方、下流工程・保守案件は低価格しかない
>>585
で書いた、AWS Elastic Beanstalk の中で、
Puma for Ruby, Docker, Go を抑えておけばよい サーバー版Blazorのシステム納品間近
サーバーサイドとクライアントサイドをC#同一ソースコードで記述できるから開発効率高いね >>609
Blazor ServerのApplication Serverは何台構成?
同時使用ユーザー数の規模はどれくらい?
良い言語C#でclient-server両方かけるっていうメリットは大きい >>607
web系はアホが多い
過去に失敗した経験に学ばず同じことを繰り返してるし ウェブ系は雇用の安定感が無いから新しい事やってます感をアピールしないと次がないのよ
だから同じようなことを言い方や見せ方を変えながら繰り返してる >>607
サードパーティ製コントロールって
JS & CSSのラッパーコントロールですよ。C#の。
なので、コントロール欲しければ、普通の配置して、
JSをC#から interopすればよろし。 俺的にはまず、Blazor Serverside + Blazor Webassemblyの組み合わせで使えるようにして欲しいな
これができないことには、いつまで経ってもJavaScriptから逃げられん
Blazor Serversideでログイン関連等の基本的な部分を作り、Blazor Webassemblyでウィジェットのようなものを作るような、そういう組み合わせができるように改良して欲しい WebAssemblyとJavaScriptの処理速度を比較してみる
https://qiita.com/mink0212/items/c7fc8d1e7c036b706544
やはりhtml domを突いて画面だしてる現状では意味ないかも... 業務アプリならsilverlightを温めとけばよかったのよ
ria service も廃止してAzure売り出す始末でタチ悪すぎるわ
どうせまた3年でオワコンになり、再開発させられる羽目になるんだよな
wcfとかどうなるんだよ WCFはまだ現役じゃろ
Remotingは終わったけど >>619
Remotingは「レガシーとされている」状態ね。 Silverlight はFlashと一緒で消える運命でしょ
Blazorは Server版は既存の記述組み合わせたものだし
WebAssembly もマイクロソフトが単独でやってるわけでもないし
すぐには消えなさそうだけど
それも世の中の技術の進歩とトレンド次第かな 全く性質が違うからねー
Blazorがいつまで続くかはわからないがクライアントサイドC#はずっと残ると思う
Webasm自体が続く限りは >>619
WCFからgRPCへ乗り換えを勧めているらしいぞ ASP.NET CoreのRazor Pagesと
ASP.NET CoreのMVCと
Blazor WebAssemblyの使い分けがよくわからない。
ページ単位でURLを持たせたい場合は
Blazor WebAssemblyは使えない? ポストバックを多用する昔ながらの単純なウェブアプリならPages
ビューを開いた後にクライアントサイドでゴリ押しする少し複雑なウェブアプリならMVC
MVCでクライアントサイドが管理しきれない規模の高難易度ウェブアプリならBlazor
MVCが一番バランスいい
Blazor、というかSPAにするほど複雑なウェブアプリが滅多にない
SPAはPgadmin、CodeServerみたいなガチめのアプリのための技術 MVCはどっちかというとWeb API向け。UIがあるんならRazor Pagesが無難。 そうかな
テンプレートは1回表示して終わりだからMVCのほうがシンプルでいいと思う
ポストバックするならPagesのほうがやりやすいけどね 少し規模が大きくなると、MVCはどこでどのエンドポイントが呼ばれているかカオスになるからね… >>620
MSの言い方は知らんけど.NET Coreで使えないんだからもう終わりでしょ >>634
.NET Frameworkでは使えるし、Windowsが生きている限りサポートされ続けるから「終わった」は言い過ぎやろ 今、wpfをクライアントとしてサーバーのsqlserverにcrudするには何が主流なの?
wcf?asp.net mvc? >>635
新しく立ち上げるプロジェクトで使用できないなら「終わった」でいい
VB6は終わった技術じゃないというならそれでもいいが >>638
使用できるでしょ。.NET FrameworkはWindowsのサポート期限と同じなんだから。 >>639
言葉足らずですまん
.NET Core で使えない==新しく立ち上げるプロジェクトで使用できない
とすっ飛ばして書いた。
.NET Frameworkの保守で使う新規プロジェクトなら使えるね Blazor WebAssemblyをテンプレートからいろいろいじってみたけど、
もうちょいテンプレートしっかり作ってほしい。
せめてCRUDのテンプレ欲しかったなあ。
あとClient側、trycatchくらい書いとけよと。
あととにかくデバッグがうまくいかない
ctrl+shift+iだったかな、これ押すと一応デバッグできるようになるんだけど、そんなん分かるか!ってかんじ。 Blazor使って作られたサービスってある?
調べても使ってみたとかばっかでる >>647
実際の公開サイトでの統計
https://www.wappalyzer.com/technologies/web-frameworks/
Blazorは670 sitesだから徐々に増えてきてる
あと企業内のシステムでBlazor Server使ってるシステム増えてるはずだが
非公開web appなので上の統計には出てこない。
MSの技術は法人利用多い
しかしまだBlazorではないASP.netのシェアが圧倒的
ほとんどのサイトはSPAである必要がないので
ASP.NET MVCとかRazor Pagesで十分ってことかもしれない >>648
なるほどねー
たしかにMVCで十分なシーン多いわ
ありがとう助かりました ユーザー名+パスワードのハッシュの入った既存のデータベースを、Blazorのユーザー認証に使い回す方法ってどっかに紹介されてない? >>650
A Demonstration of Simple Server-side Blazor Cookie Authentication
https://blazorhelpwebsite.com/ViewBlogPost/36 >>651
ありがとう!これは便利だ!
クッキー発行前に自分のやりたい認証コードを書けば、なんでも使いまわせちゃうぜ! >>651
そのサイトはいいかんじにまとまってるサンプルがあるね
ブックマークしておいた 俺は逆に、Blazorで登録してもらったユーザー情報で他のnode等で作ったページにログインできるような技が知りたいな
先の技と似た方法でASP.Net Coreでクッキーだけ発行してnodeでも同じクッキーを使うのもいいけど、データベースを使い回す方法も見てみたい
だけどデータベースを見たところ、パスワードハッシュらしきものはすぐ見つかるもののソルト等がどこにあるのかよくわかんない
もしかしてハッシュに見える一部分がソルトなのか?パスワードハッシュらしきものは、どうやって生成されてる値なんだろう・・・・ Blazor WebAssembly in .NET 5 is two to three times faster
for most scenarios. For more information,
see ASP.NET Blog: ASP.NET Core updates in .NET 5 Release Candidate 1.
.NET 5でかなり速くなるんだな
楽しみ Blazorで作ったうちのサイトに、大量のユーザ登録をする奴が出てきた
掲示板みたいなものがあるので、宣伝の書き込みに使いでも使うんだろうか?よくわからないけど不気味で仕方がない
大量登録を防いだり、ユーザーの行動をスコア化したりBANしたり、何かBlazorでできる手軽な対策ってない? >>657
しっかりやるならSMS認証だろうけど手軽ではないね。
手軽なのはメールアドレスとIPアドレスベース
登録時のメールアドレス認証はやってる?
同じIPから一定日数は登録できないようにすれば、
固定回線からの登録はある程度防げると思う
ISP次第で固定でもIP変更できちゃうけど
ただの宣伝目的ならそういうめんどうな
手順必要なところは避けてほか行くんじゃないか Azure AD使ったら多要素認証も気軽に実装できるよ >>659
そうなのか
全部クラウドでやるのは高すぎて避けたい。
認証だけAzure AD使うのってありなのかな Blazorに限る話ではないかも知れないけど…
ServerにWeatherForecastController作って、
ClientからアクセスするときはGetFromJsonAsync<WeatherForecast>(“WeatherForecast”)とControllerの名前を「文字列」で引数に入れる。
これがせっかくここまでC#の型を使えてるのになんか無駄だなあと。
Shareにあるクラスは参照できてるのに、
なんでServerへのアクセスは文字列なのか。
ここタイプミスしたらオジャンじゃん。
外部のAPIならわかるけど、同じソリューション内のプロジェクトなんだから
WeatherForecastContoroller.GetAll WeatherForecast() でええやんと思ってしまう。
gRPCとか使ったらSOAPチックなことできるの? >>663
ハードコード避けたいときはnameofとかtypeof使うといいとかsampleかいてあったような。
//return CreatedAtAction("GetTodoItem", new { id = todoItem.Id }, todoItem);
return CreatedAtAction(nameof(GetTodoItem), new { id = todoItem.Id }, todoItem);
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&tabs=visual-studio
Web APIのTutorialのコード。
References the GetTodoItem action to create the Location header's URI.
The C# nameof keyword is used to avoid hard-coding the action name in the CreatedAtAction call. >>663
上みたいな感じで
Controllerの名前もなんらかのmethodでstringとして取得できるんじゃないかな てかWebAPIならAttribute Routingの方がよくね? >>664
nameofありだね
スペルミス減りそう
>>666
Attribute Routing調べたけど
API側でルーティングを文字列で指定してる。
文字列をやめたいんだけど…
メソッド名があるんだからメソッド名をそのまま使いたい。
そもそもREST APIの原則に囚われすぎな気がする。
毎回あんなURIを考えるのって大変じゃないか?
汎用性を考えるならわかるけど。 >>663
それコントローラー名じゃなくてUriでしょ
DefaultRoute使えばuriとコントローラー名は一致するからそれでいいけど
プロジェクトの都合で
URIとコントローラー名異なるようにすることはあるでしょ。 >>666
言ってることが分かったかも
API側で
[Route(“GetHogeData”)]
public Hoge GetHogeData(){}
にするってことかいな? すまんリロードせずに書き込んでしまった
そゆことね よくおぼえてないまま書くけど
ルーティングの機能でコントローラー名とアクション名から
アドレス作れたはずだから
それを渡せばいいんじゃないの
それだとnameofも利用できると思うし
カスタムルーティングの場合でも問題なくいけると思う razorファイルに書いたC#がバリバリ動くのは感動すら覚えるが
最初に作られるサンプルサイトがショボショボすぎてこれは普及しないだろうなあ…とおもう。
入力もできるグリッド、DateTimePicker、TreeView、モーダル
こういうのをサンプルに組み込んでもらわないと
いちいちググるはめになる。 >>672
いやいやテンプレートに機能満載されてるほうが困るわ そんな複雑なUI作られても使う側が困るしなぁ
シンプルイズベストですわ
MVCでいいじゃないの >>672
お前はサンプルとテンプレートを混同している いろんなGUIサンプルはGitHubに置いておいてくれればいいね
Wizardで生成されたら困る テンプレートでもサンプルでもどっちでも良くて、
MSがそういうものを用意しないと流行らないと言っている。
そんなことをこんなところで言っても仕方ないけどな。 WebFormsぽとぺたさんにも使ってもらうなら要るかもねえ >>677
ウィザードでサンプル出力しろという主張だったのに都合よく主張変えるなよ MSはWebFormsの代替としてBlazor使えって言ってる。
使いたいがこれではハードル高いだろ。
外部の会社が作ってるUIコンポーネント集入れないと使い物にならん。
仕組み上ポトペタは無理としても、それに代わる何かがないと、学習コストがかかって採用されないよという話。
ウィザードでゴリゴリの画面が作られのもまずいというのはわかるが、さすがにシンプルすぎやせんか。 単に自分の能力が足りてないだけじゃないの
まー言うとするなら
WebFormsのように基本的なコントロールは入れてほしい
って感じ?
サンプル云々の話じゃないよね
たぶん WebFormsってそんなに便利だったっけ?
あっという間にMVCに置き換えられたからわからねえや MVCにすら移行出来なかった層の
最後の救済目的がBlazorだからだろう。 >>681
リッチUIを最速で作りたいならWPF使えばいい
外から使い人にはWindows tabletとか持たせるだけ。
Bootstrapでだいぶ敷居さがったがCSSベースのデザインはめんどくさい
>>683
HTML, CSSをよく知らない人、デザイン苦手な人には便利だったんだと思う
ただ細かいデザイン制御ができない、吐き出すhtmlが汚いから
ASP.NET MVCにとってかわられた Entity Framework使ってる人、Migration機能は使ってる?
Migration使うほうが複雑になる気がするんだけどどうだろう
Migrationのメリットが見えてこない
PostgreSQLのpgAdminとか
RDBの管理ツールで直接、スキーマの作成や変更をしてる。 Ruby on Rails では、SQLite, PostgreSQL, MySQL の3大DB を、1つのファイルで定義できる(抽象化)。
Migration 用のファイルも、自動的に作られる
Roll Back もできる
Scaffold という魔法の呪文で、CRUD アプリが自動的にできる >>686
アプリでSqliteなどのローカルDBでは凄く有効だが、サーバー弄れる場合は手動でいいと思うわ >>687
rollbackもできるというけどそれがMigrationの主要機能だし
rollbackできなかったら意味ないでしょ
Entity FrameworkのMigrationにもrollbackある。もちろんScaffoldもある
Rubyのコマンド見てみたがEFのMigrationと似てる気がした。
ORMが履歴を持つことでrollbackできるようになる半面、長ったらしいコードが
生成されその記述を理解しないといけなくなる。
DB側のカラムに制約とかデータ型とか細かく設定するべきだが
ORM使わずにpgAdmin, SQL Workbenchでやるほうが速いしわかりやすい。
さらにORM経由は操作できる範囲が限定される。
SQL使ってできる操作>ORM使ってできる操作。 >>687
RubyおじはASP.NET Coreは使えてるのか?
ASP.NET Core使えるなら低速なRails, Rubyなんて使わなくていいだろ
>>689
Sqlite以外ではMigration使ってないのか
本当にMigrationは誰得の機能かわからないわ それ言うならそもそもEntity Frameworkの存在意義自体がない気もするけど あー、SQL自動生成だけでも意義はあるか
まぁ、単に開発中のコードとデータベース同期を楽にする機能でしかないから
使いたければ使えばいいし
データベース熟知してて自分でDBスキーマ決めたいのならそうすればいいだけの話 いちいち手作業でDBにつないで順番を間違えないように慎重にSQL実行して…
後で困らないようにどんなSQLを実行したかリリース履歴台帳に記入して…
手作業だからテストという概念もなくて…
これちょっとアナログすぎだしめんどくさいし間違えやすいんじゃねえか?って疑問を持つところがスタート地点
疑問すら持てないなら開発者として必要なセンスが欠けてる
紙とハンコのほうが性に合うオールドタイプならそのまま手作業を続けてどうぞ
ここは未開の原始時代
実行するSQLはファイルにしよう
SQLファイルのアップロードと実行はshellで自動化しよう
shellをソースコードと同じ所でバージョン管理したら便利だな
shellがバグってたらやばいから本番レプリケーションで事前にテストしよう
同じshellを間違えて実行したらやばいから実行履歴もテーブルで管理して多重実行を避けよう
これ全部1つのコマンドでできるように整備しよう
このように不便さを自動化で解消できたならすこしマシになった段階
産業革命の始まり
便利だけど色々と拙くまだまだコスパが悪い
shellは便利だけどオレオレ感が強くて属人生が高く保守しにくいな
なにか開発者間で共通認識となるフレームワークがあれば便利だろうな
MigrationをC#で書きたい場合もあるよな
そもそもshellの実行すらめんどくさいんじゃないか
などなど細かい不満点を解消していって出来上がったのがMigration系フレームワーク
ここがひとまずのゴール
より洗練されてエコな現代テクノロジの集大成 ORM全般に言えることだけど、複雑になってくると使い物にならなくなる。
sansanもEFをDapperに置き換えたって発表してた。
正規化するのが正解じゃない時もあるし、サロゲートキーで対応 途中で書き込んでしまった。
サロゲートキーだけではうまくいかない場合もある。 >>695
CQRSのCではEFのほうが遥かに洗練されてる
Qでは高速で複雑なSQLを書きたくなる場合が増えてくるのでDapperが有利になる
多くの開発者が複雑化したQのせいでEFは使えないと思い込んでいるがEFはDapperと共存可能だ
更にいうと昔と違ってEFは随分と速くなった
ネイティブSQLもサポートしている
Dapperに頼らなくてもQを上手く実装することができるようなってる >>693
凄くどうでもいい事で申し訳ないがIDがSQL >>697
もう全然Blazor関係ない話で恐縮だけど…
大抵のDBって命名規約がスネークケースだよね。
しかも大文字か小文字のどっちか。
一度モデルファーストで作ったテーブルはキャメルケースで作られるから、生のSQL発行しようとしたらカラムIDを全部ダブルクォーテーションで括る必要があって苦労した苦い思い出がある。
LINQと生SQLどっちも使うとなるとこの問題に引っかかる。
自分のEFの知識が数年まえで止まってるのでいまはいい仕組みがあるのかな。
Dapperはパラメータで勝手にマッピングしてくれるから助かる。 >>699
postgresqlは特殊な仕様だからハマりやすいね
なのでNpgsqlのEFにはUseSnakeCaseNamingConventionというオプションがある
他のDBは特にハマった記憶がない >>692-693
逆だよ。CRUDにEF使うのは便利だから意味がある。
C#のコードが短くなるし直感的にかける
だがスキーマの作成、変更でEF使うとC#のコードが長くなってしまう。
SQL側でダイレクトに変更すればすむものを履歴を持たせて
C#側から操作するから手順が増える。
スキーマが自動生成のものでいいってのはDB知らない奴だな
てきとうにつくるとパフォーマンス劣化する めんどくさいことになりそうな時は、RubyやRailsを勧めよう! >>694
原始時代って履歴台帳なんて古臭い言葉つかってるおまえだろう
スキーマ変更したら直後にテストしてるに決まってる
あと間違いやすいのは複雑な手順をとるMigrationのほうだ >>701
最近のEFは良くなってる
ほぼ想像どおりのスキーマを出力してくれる
とはいえ完璧とも言えない
完璧を求めるならMigrationを生SQLで手書きすることもできる
SQLを手書きしたいという要求のためにMigrationの全機能を手放すのは惜しい >>695
パフォーマンスの面でDapperは昔は意味あったとおもうけど
いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。
EFで満足できない箇所だけピンポイントでダイレクトにSQL使うか、
ストアドプロシージャを使えばいいと思うわ
>>697
たしかにEF Core速くなってるね
あとストレージがSSDになったのも超大きい >>703
いやいやスキーマを変更したあとにテストじゃ遅いだろ
Migrationをしてからテストするんじゃない
テスト済のMigrationを適用するんだ
ちなみにMigrationはアプリケーションをデプロイするだけなので手順ミスは最小化される
手作業でSQLを実行するとSQL数に比例してミスが増える >>704
ORM、DBのベンチマークたまに見てるし速くなってるのは知ってるよ。
ただstringとかの最適なデータサイズは開発者じゃないとわからないから
最適なスキーマ作ろうと思うとやっぱりSQLでスキーマ作成、変更したほうが
いいってのは今後も変わらないと思う >>706
根本的に会話になってない
俺の言ってるスキーマ変更するってのは決定事項なんだよ
既に正常に動くプログラムがあってそれをスキーマ変更するんだから
スキーマ変更した後にテストしないと意味ない。
Migrationでrollbackすることもない
動くようになるまで必要ならばC#側を変更するからだ。
なんかうまく動かないからスキーマ変更やめましょうということにはならない。 >>707
EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ
より詳細な調整をしたい場合はMigrationを手書きしてMigrationBuilderに生えてるDDLラッパーを呼び出せば良い
DDLラッパーはCreateTableメソッド、DropTableメソッドなど.NETのメソッドではあるがDLLを書くのと非常に近い感覚で使うことができる
これはラッパーなので複数ベンダに対応することができる
代わりに最大公約数的な機能に制限されるが十分な機能揃っている
完全にMigrationをコントロールしたい場合には生のSQLを書いてもいい
EFはもちろん生のSQLもサポートしている
原始時代や産業革命時代に行っていたような作業はすべてEFでできる
ただし生のSQLを使うとベンダ依存が発生するのでそこはトレードオフだ
更に加えてMigrationとして.NETのカスタムコードを実行することが可能だ
例えば今まで保護されていなかった個人情報をC#で暗号化して保存し直すといったことも可能だ
手作業でSQLを実行する 手作業でSQLを実行するだけではこのような複雑なMigrationには対応できない >>708
決定事項だろうがなんだろうがテストは必要だ
これからDBに対して行う変更を事前にテストする
テスト済の変更を確実にミスなく適用する
これを実行するための最もスマートな方法がMigrationだ
先程も書いたがこれをオレオレshellで代用することはできる
しかしそれは洗練された手法ではない
産業革命時代のやり方でしかない
もちろん適用したあとに最終チェックとしてテストを行うことはこちらとしても全く否定していない >>700
そんなのあるのか。EFにもどろうかなあ。
あとはバルクインサートやバルクアップデートができたら完璧。 なおMigrationとその後のテストのどちらかが失敗した場合は
途中まで適用したMigrationをロールバックしなければならない
ロールバックはEFの機能で行うかDBバックアップをリストアするかどちらかだが
EFの機能で実施したほうが圧倒的に速い
リストアは最後の手段と考えよう
バグを放置してアプリケーションコードを修整するなどもってのほかである
これはサービスの停止時間を悪戯に伸ばすだけで損失を増やすばかりでなんの利益も産まない
バグがあったらロールバックを行い
Migrationとアプリケーション双方を見直し修整しテストする
テストした後にまたMigrationを適用する
これが現代人の働き方だ そういやMigrationって、データベースのデータの移行とかはできるもんなの?
できるのなら素人保守のSQLServerからPostgreSQLのマネージドデータベースに変えたいんだけど・・・・ >>714
自分でコードを書けば柔軟できると思うけど
あるクラスのあるプロパティを別のクラスに移したいみたいなのは
自動生成では無理だと思う。
個人的にはmigrationは本番環境で使うものじゃなくて
開発中のコードとそれテストするときのデータベースの同期を楽にするもの程度で認識してる >>714
Entity FrameworkのMigrationはそういう機能はないよ
スキーマ変更の履歴を保持してロールバックとかができるだけ
俺はロールバックしたことないからめんどくさくなってMigration使ってない
Managedの維持費のがSQL Serverのオンプレミス維持費より高いんでは?
SQL Serverなんてバックアップ、リカバリできれば運用かんたんでしょう
DBの種類変更したらデータ型互換性なくなるから慎重にテストしないといけない。
よほど問題ない限り安定稼働してるDBはいじらんほうがいいとおもうよ 朝は動いていたStateHasChangedメソッドが、
昼になったら動かなくなった。
こんなセリフは一生使わないと思っていたが使わしてもらう。
何もしてないのに壊れた。 何もしてないなら壊れたことも観測できないはず
何かをしたのは明白だ 長時間動かしてたんだったら、ゴミだと間違われてGCに回収されちゃったんじゃないの? >>718
昼休みだろ
もしくはハードウェア、ネットワーク障害 Nuget使って気付いたけど.NET 5.0来てるな
RCなの知らずにNugetでUpdateしてしまった 処理済み件数/全件数のパーセンテージ出してたんだけど
数値の型変えたり、全件数のカウントを変数に入れたりしたら出るようになったわ。
なんだったろうなあ…
なんらかの呼吸が悪さしたんだろうな… リリースノート見ると.NET 5.0 RC2けっこう前にでてたようだ
EFとかはNugetのPackageで5.0対応のがでてそれで気付いた。
バグ人柱になりたくないのでもう少し.NET Core3.1でいくわ
.NET Coreという名前ももうおしまいみたいだし デバッグに至るまでになかなか時間がかかるんだが、皆さんPCのスペックどれくらい積んでますか
会社のパソコンSSDは積んでるけど、メモリが8GBしかない。 >>727
8GBあれば仮想化以外は余裕でしょ
遅いならCPUがへぼすぎるんじゃないかな?
CPU型番とPassmarkスコアは?
Dockerとかの仮想化つかってる?
仮想化つかうと滅茶苦茶おもいのは仕方ない
あとVisual Studioの中のSQL Server Object Explorer
あれは重すぎるな
DB専用の管理ツール使うほうが快適 新規開発をするに当たってフロントの言語選定に悩む
Blazorを選択したいところなんだけどSilverLightのハシゴ外をされた件が怖すぎて クライアント版で開発すればサーバー側の実装まで一緒に死ぬことはないと思われるんだけど…
ReactじゃなくてBlazorを選ぶのか?と言われると揺らぐ >>729
あれはブラウザー内にデスクトップアプリ
動かすようなレベルのもんだから
何もってきても無理じゃね? >>729
Silverlightと違ってWasmはstandardだから無くならない。
BlazorはMSだから長期サポートされる。
Reactとかは人気落ちたらセキュリティパッチすらでるか怪しい
サポート期間の長さでMSより安心できるベンダーはない
Blazor WebAssemblyならば、
server-sideをASP.NET MVC + Web APIsで作るわけで
これ以上、安心できるserver-sideはないだろう。
速度も速いし長期サポートあるしC#使えるし。
もしBlazor廃れたらWeb UI frameworkだけ入れ替えればいい 速度が速いとウソをつく
↓
激遅の現状を突っ込まれる
↓
速度など問題じゃないと強がる >>733
MSのLTSはあまり期待してないなぁ
ソース管理についてもTFSがフェードアウトしてる感あるよね?
かと言って、Githubにデータ移行はできないし
MSはこういう所が横暴でロックインし難い >>736
上位コンポーネントからパラメータで渡す分には問題ないと思う
通常のプログラミングでいうと関数的な使い方
カスケードプロパティは危険な臭いがプンプンする
これはグローバル変数のようなもの
俺はカスケードプロパティは全く使う気がしない
パラメータで渡さない場合は状態を管理するクラスを1個作ってInjectするといい
コンポーネントからはこのクラス経由でしか状態にアクセスしない
これはインメモリリポジトリのようなもの >>734-735
backendのベンチマークだ
JavaやC#が動的言語より速いのは常識
知らないやつは初心者
>>735
また計測不能ばかりのクソサイト張る無能
楽天も計測不能 >>737
LTSは同類のほかのソフト出さないって意味じゃないだろ
セキュリティパッチ出てるならサポートしてるってこと
Googleとか他社はそれすらできてない 遅さに関してはMSの責任者が10倍遅いと言ってるし、
実際使うとともっさりしてんだよな。
サーバサイドのよりましだけど。 >>741
10倍遅いというその発言も捏造
JS interopは.NET 5でかなり高速化したと発表されてる
wasmはよほどしょぼいハードの人以外は問題ないスピードになってる でも実際使うとともっさりしてんだよ。
JS interopの影響なのだろうけど、
処理概要を聞いたら感覚的に卒倒しとうなアーキテクチャだ。
サーバサイドのよりましだけど。 むやみにevent呼ばなければ遅くならない
高速化のtipsも書かれてる
Blazor Serverの名前も出てこないようだしまともに
ドキュメント読んでるとは思えない >>734 の予言、当たってしまうwwww
速度が速いとウソをつく ( >>733 )
↓
激遅の現状を突っ込まれる ( >>735,741,743 )
↓
速度など問題じゃないと強がる ( >>742 ) 激遅の現状を捏造する
の間違いだな
実際速くなってるよ.NET5 >>745
おまえアーキテクチャ全然理解してないのがバレバレ
backendとfrontendの違いも
WasmとBlazor serverの違いもわかってない
おまえはjQueryおじかweb app作れない奴だろうな Blazorはもともと高性能を目指したものではないからなーー。
https://ichi.pro/blazor-de-no-shumatsu-burauza-de-c-o-jikkosuru-118284362990616
開発者自身も了解している事じゃないの?
開発スタートの経緯を聞いてもそう思う。
偶然の産物なんだよ。このプロダクトは。 EdgeだけでもC#がnativeで動くようにしちゃえばいいのにな
MSがブラウザの独自エンジン開発放棄したのは失敗だった
まさかのIE12でもいいよ
C# native実行できちゃうやつな メジャーフレームワークの事前ダウンロードオプションはそのうちサポートするんじゃないの
それか単にブラウザ拡張を作ればいい
事前キャッシュするだけだから簡単だろう フロントは使い捨てと書いてる人いるけど
フロント側でC#がガンガンうごくので、
APIがデータベースの土管になって、データ加工して表示するロジックとかrazor側にガリガリ書いちゃってる。これまずいのかな。
いやでもそれがwasmのメリットだよな… いいよ
UIにまつわるダーティな処理はクライアントでやろうがサーバーでやろうがUI入れ替えとともに消える運命 >>752
クライアント(View)は表示のみですね。
クライアントなくても、Curl等でAPI直叩きで業務が流せればOKです。
それが出来ないような実装なら、単体テスト出来ないでしょ。 >>752
データ表示に関するコードはwasm内でやるべきでしょ
なるべくclient-sideでやってserver-sideをスケールしやすくする。 >>748
wasmで作ったゲームサイト、スムーズに動いてるな
https://aesalazar.github.io/AsteroidsWasm/
ゲーム以外でこれ以上ぬるぬる動かす用途ないだろ
読み込みloadingも2秒程度だった
>>745
これみれば一発でわかる。
計測できないlighthouseがクソなだけだ
https://aesalazar.github.io/AsteroidsWasm/ >>752
それC#だからとか関係なくね?
業務ロジックはサーバーサイドで、データが取得できたあと表示に関する部分はどうぞご自由に、というのが手離れの良い設計だと思う ドメインモデルとプレゼンテーションモデルの変換はプレゼンテーションで行うのが正解
ReactなどのJSフレームワークは言語が貧弱だからこの変換処理が増えてくるとキツい
その回避策として先人はバックエンドforフロントエンドなどというバカみたいなパターンを作り出してしまった
プレゼンテーションモデルへの変換処理をバックエンドの高生産で高速な言語でやってしまおうという発想だ
なんという本末転倒
Blazorなら変換処理もC#で快適に実装できるのでいちいちバックエンドにやらせる必要はない
バックエンドはドメインモデルをJSONで返すだけでよい
これが世界中の開発者が本当に求めていたものだ >>758
TypescriptはC#とjsの良い事どりの呈してますよ。 blazor-wasmは深刻なパフォーマンス問題があって、
[Blazor WebAssembly] Serious performance issues
https://github.com/dotnet/aspnetcore/issues/21085
その対策は進行中↓
Blazor performance optimizations #22432
https://github.com/dotnet/aspnetcore/issues/22432
つまりまだ全然安定しておらず、成熟していない。 >>759
同じ設計者の末弟ケンシロウだからね。
C#はジャギ。
Delphiはトキ。 >>760
アホだ。最適化が終わってないだけは安定してないとはいわない。
しかもほとんどチェックマークついて対策済みになってるし
残りも.NET5までに対策される
.NET5はもうRC2だし
深刻なのはコピペしかできない>>760の頭の悪さ
>>756 でゲームデモで論破された >>763
node.jsの開発者がTypeScript直接実行できるの作ってますよ。
https://ja.wikipedia.org/wiki/Deno 5の次がLTSだっけ
Blazorもそこに合わせて仕上げてくるだろうね
いよいよだ
さよならJavaScript 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
延期されたwwww
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよw
https://twitter.com/5chan_nel (5ch newer account) エッ!一年前から遅い遅い指摘されてたのに、まだAoT実現できてないの?
このプロジェクト大丈夫??
https://www.reddit.com/r/csharp/comments/c7qtwy/is_blazorwasm_faster_than_js_today/
> No. Blazor is currently interpreted. That makes it very slow compared to JS. It will at some point be AOT, which should yield a massive performance boost, but we're not there yet.
いいえ。Blazorは現在インタプリタ動作です。そのためJSに比べて非常に遅くなります。ある時点でAOTになり、パフォーマンスが大幅に向上するはずですが、まだ実現していません。
↑これが一年前。
さーてそろそろAoT実現してるかな〜
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
_____
ゝ/ \ /
/ _______ヽ
| | : : : : : :\_人ノ: : :| /
| | : : / ⌒ ヽ: :/ ⌒ ヽ
/^v─ i | |
(( |:d: :♯| ((・|・)) ! 「延期!」
ヽ: : /^ヽ、 _ ノっ _ ノ−、
|: :| \_/^\/^\_:ノ
|: :| \
/⌒\ヽ (⌒ヽ⌒) ))
| \\_/^\_/ノ _____
| \─┬─ ´ | |_
|. \. \ | \ | 延期 (_)
| \ \./ ̄ ̄) (_)
\ /  ̄) | 遅さはAOTだけで改善出来るもんじゃないと思う。
WASMと期待させておきながら、
画面描画を全部JSでやるという仕様が回避できなければ、
永遠に遅いままかと。 >>754
この人だけ意見が違う…
取得するデータごとに違うapi用意しだしたら、業務システムとか大変なことになるんだが… サーバーサイドと言語を揃えれるのがいいね
.NET5でLinuxデスクトップもサポートされるようだし
これでC#大統一理論にまた一歩近づいた やっぱり.NET5の正式版でてた
https://dotnet.microsoft.com/download/dotnet/5.0
>>723 >>725
でNuGetにだけ.NET5出てきて混乱したが
webの更新が遅れていただけのようだ
さっそく.NET5.0に入れかえよう 「Python」生みの親グイド・ヴァンロッサム氏、マイクロソフトに入社 - CNET Japan:
https://japan.cnet.com/article/35162404/
MSがPython開発者もとりこんできたぞ
どうなるんだこれ 静的言語じゃないからASP.NETやwpfはpython対応しないだろうな 純粋Pythonの話
IronPythonは良く知らない
.NET5でF#もバージョンアップしてるようだけど
あまり流行ってる気がしない Blazor WebAssembly、難しすぎる
Identyと
ASP.NET CorehostedありでProject作ると
counterのデモすら動かない。
Authorizingがでたまま止まる。
ブラウザ下にはunhandled exception。unhandledは現状デバッグできないらしい
dotnet v3.1でも.NET 5.0でも同じ。
Identity Serverのしっかり学習して設定しないとデモすら動かないのかな?
hostedのWasm、これどうやって動かすの wasmはunhandled exceptionが対応するまでハードル高い気がした
どこが間違ってるのか見当がつかないので大変だわ デバッグはちょっとしんどいよな
普通にC#で開発するときの生産性を期待するとガッカリする
まあそのへんもまだ黎明期ってことで時間が解決するだろうけど ほんまそれ
try catchで飛ばしても
エラー内容が改行されてないから見づらい。 ホットリロードも効かないしな。
ガチでやり始めると地獄だよ。マジ WebAssemblyはガチでやる前に挫折した
Wasmはunhandled exceptionとか機能が充実するまで待つとする
Front何で作ろうかな
Blazor Serverは人数増えたらスケールしなくて破綻しそうだし
ReactはJS/TSでだるいし。
XamarinかFlutterでも始めるかな
Flutter for Web使ってる人いるかな 何を作るかによるけど、サーバーサイドと型の共有ができないと色々めんどくさい
フロント側を違う言語にして型が共有できなくなるか
デバッグがめんどいけどwasmにして型を共有できる恩恵を享受するか…
悩ましい
エディットコンティニュー、ウォッチ式、ホットリロード等この辺充実させてからリリースしてほしかったなあMSさん。
ホットリロードそのうちできるみたいな記事を海外のTwitterかなんかで見た気がするんだけどどうなったんだろう。 スレ違い宣伝爆撃で荒らし回ってたのってやっぱりMSの工作員だったんだな。
MSKK社員はコーディングできないしステマしか仕事ないんだろうなw >>787
そのふたつちょっと調べてみたがJSへtranspileする言語だな
transpileで我慢するならTSのがましな気がする ???svelteはtsで書くんだけど…
まあjsでも書けるけど… >>790
1年後の.NET6の前にベータで機能追加くるだろうし
たまにリリースノートとかチェックすればいいんじゃないか .NET6はLinux desktopも対応予定らしい。
Blazor WebAssemblyいじって気づいたけど
実はXamarion.Forms最強じゃないか?
XamarinならWindows, iOS, Androidで動く
nativeとあまり変わらない程度に速いらしい
C#使える
UI開発がReactとかより圧倒的に楽に見える
Apple Silicon Macでも動くはず
Windows, iOS, Androidで動くなら手間かけてweb appにする意味なくない? >>795
Hot reloadはXamarin.FormsやFlutterにあるようだぞ C#大統一理論、もしかして現実的な話だったのか
世界最高シェアのwindowsと相性抜群
主要デスクトップ、サーバーで動く
モバイルも簡単、ゲームもUnityがある
ブラウザでも動く
今後増えてくるWasmエッジ環境でも動く
これらが圧倒的高生産性のVS、VSCodeで開発可能 他は知らんけどBlazorに関してはその高い生産性とやらが出せてから言えって感じ。
自分もC#好きだからMSには頑張ってほしいけど、こうも中途半端だと、
世間には悪い印象しか与えないんじゃないかな。
何でもかんでも手を出してる&早くリリースすることが悪い方向に行っている気がするなあ。 >>796
Nativeアプリは配布が一手間だからWebアプリで済むならWebアプリで済ましたいわけですよ >>800
企業向けアプリの話?
不特定多数の個人向けの話? >>801
関係なくない?
何回かこの議論さてる気がするけど…
結局作ったシステムを納品する先の環境に左右される
お客さんによってはネイティブアプリ禁止なところも最近増えてきている。
特に事務系のシステムはWebじゃないとはねられることが多い。 >>802
利用者がだれなのかは決定的に大事なとこだ
法人なら一括でかんたんにインストールできる
Deployを理由にweb appにしてくれというなら
その企業のシステム部門が無能なだけ
かんたんにdeployする方法を教えてやれば方針も変わる。
web appはnativeに比べて従業員の生産性も落ちる。
開発の納期も延びてコストも増える いまのBlazorは生産性最悪ですよ。
でたばっかの製品版なんでしょうがないちゃそうなんですけど、
MSが言ってる通りはなからJS使えないWebForm向けのエンジニア救済用と思えました。 あとMAUIがflutterみたいにWebに対応するんじゃないかと思えて... Blazor Server生産性高くて気に入ってる
社内向けだとスケールとか心配ないし Webアプリっていってもなぁ
社内オンプレに納品だとSSL通信が厳しい。
やろうとすると色々めんどい上に高くなるし。 >>803
そのシステム部門に合わせるのも大事
少なくともWebアプリよりハードルが高いのは確かなんだから、楽な方選んでくるでしょ。
Blazorの登場によって生産性も高くて配布も不要になる!
と思ったがそうでもなかったって話だな。 >>804 >>806
生産性問題あるのは「Blazor WebAsssemblyは」じゃないのか?
Blazor Serverは楽だと思ったよ
Blazor Serverはスケールしないから不特定多数には向かないが
人数が予測できる社内利用ならありだとおもう >>808
Web appよりもXamarinのが楽だよ
YouTubeでXamarinのtutorial, 入門動画見てみなよ
C#使える人ならすんなりはいっていけるし
UIまわり超楽だからひとりでフルスタックやるのも無理はない。
特にReactやBlazor WebAssemblyいじった後なら天国と思えるはず >>809
社内ツールをwasmで作ったが、作り替えよかな…
>>810
Blazorを使う=何かしらネイティブアプリが使えない事情があるんだろう。その誘導は的外れでは? BlazorはServerでもWasmでも
ウェブ配信でもバイナリ配信でもフレームワーク前提の配信でも
なんでもOK
おそらく今最も配信しやすいフレームワーク 早速BlazorSeverためしてみたが
確かにこれは生産性高そう。
api設計もいらないし。
スケーラビリティの問題はあるが、百人前後で使うような
業務システム系はこれでいいんじゃなかろうか
しかし…
SignalRで動くというのがなんとも気持ち悪い…
他の言語でもSignalRみたいな仕組みで動いてるアプリとかるのかな…
あとStartupでひたすらAddSingletonしてるのも気になる…
Serviceが数十〜百とかになっても耐えれるのだろうか。 >>811
前半
何から何への作り替え?既に安定稼働してるならいいのでは。
後半
システム管理の知識ないひとはdeploy大変と思い込んでる場合多いし
なんとなくまわりにあわせてweb appにしちゃってるところがほとんどだと思う。 >>814
前半
Blazor wasmからBlazor Severへ作り替え。
小さなシステム&Blazorの実験なので作り替えることは苦ではない。
それよりwasmの生産性の低さがつらい。
後半
他のシステムがWebでそこにネイティブアプリ入れるほうが逆にハードルが高かったりする。
そのシステム管理の知識をお客さんの情報部門に強要できないしな。
自分もなんでもWebシステムであることに懐疑的で、これまではWebではなくてネイティブを選択してきた。
しかし、近年フロントの仕組みが成熟してきた(ネイティブに比べたらまだまだだけど)ので
逆に配布の手間がネックになりつつあるなあと。
よっぽど複雑なシステム(医療系?)であればWebは選ばないけどね… 前言撤回
やはりBlazorServerはなんか邪道な気がする
そのうちMSが
新規プロジェクトで選択しないでくださいとか言い出しそう
一年なんてあっという間だし.NET6まで待ちますかね。 >>816
だから最高の生産性ならWPFかXamarinだって。
速度も速いし使いやすい。
本来、業務用ならばWeb appなんて消去法で
最後に仕方なく選ぶものだと思ってる。
deployなんてかんたん。
管理者が無能で一括でdeployができなければ
2,3回クリックするだけでインストールできるようにすればいい。 ええ加減スレチやで
Xmarinスレに移動しましょうや 完成したら最強になる候補ならUNO Plathomeだろ
UWPで開発してそのまんまBlazorとxamarinに翻訳して実行できる >>819-820
MAUIってまったく新規にできるものじゃなくてXamarin FormsがCoreと統合だろう。
だからMAUI行く前にXamarin.Formsの学習は無駄にならないとおもうぞ。
Evolution of Xamarin.Formsとはっきり書いてある
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
MAUIが出るのは.NET6だし実践投入できる安定度考えたら
あと1.5から2年かかる。出てすぐはWasmみたいに実践投入できないレベルかもしれない。
Blazor wasmとMAUIの安定を待ちつつそれまでは
Xamarin.Formsでいくというのはいい選択だろう
Xamarin.Formsは大手企業でも使ってて実績も十分
>>818
過疎な板でそこまで細かく分けたら人が誰もいなくなるし
.NETの未来というテーマで共通してる >>820
UNO platform、こんなのもあるのか
https://platform.uno/how-it-works/
ここみるとUNOはC# + XAMLで開発とある。
Xamarin. Formsと一緒だ
結局、生産性を考えたらUIをHTML + CSSでやるのはゴミだってことだろうな。
>>819
MAUIのブラウザ対応といいたいのかな
XAMLで書いてHTML, CSSの世界との変換も自動でやるわけ?
WebAssemblyが難航してるの見ても簡単に行くとは思えない >>821
Xamarinは前にやっとる
失望した。
flutterの方が良さげだ。 >>824
いつ頃のバージョン?失望したところは?
FlutterのがXamarinやReact Nativeより満足度高いらしいな
俺もさわっては見るつもりだ
ただFlutterはWindowsの対応予定ないのが難点
Flutter webもbetaだからwindows対応が問題になる >>826
すばらしい
FlutterもWindows appいけるようになるのか、いいね
早くweb appの必要のない世界が来て欲しいわ
Compose for Desktopはまだ時間かかりそう
クロスプラットフォーム開発では現時点ではXamarinとFlutterが抜け出ている感じかな
React Nativeはもうだめそう ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www >>828
それはFlutterのが新しいからだ
FlutterやってるひとはReact Nativeやってた人が多く、
React Nativeはゴミだといってる
バグが多い
JSを使うから生産性が低い
ホットリロードも対応してない
Facebookが作る開発ツールってたいていゴミだな
ほぼすべて消える >>830
ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www >>831
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
ここみると2020年のFlutterの伸びがすごい
来年はトップになるのは確実に見える
これ見るとXamarinは人気落ちてるのか
C#慣れてるし好きだからXamarinいいかなと思ったんだけど
いま開発者に人気なのはFlutterっぽいんだよな
C#使いにとってはReact NativeはJSってだけで候補外だろう >>833
ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www
恥ずかしがってないで書けよwww
まさかひとつも無いなんてことはないだろwww >>834
>>833みてもわからないんだな
あたま悪すぎ Flutterは10万種類以上のアプリがでているとのこと
So far, we’ve shipped production-quality support for Android
and iOS, with eight stable releases and over 100,000 apps
shipped to the Google Play Store alone.
XamarinもFlutterも実績は十分
あとは自分にあったものを選べばいい。実績できたらMAUIでもいいけど ほーん?www
で?www
どんな素晴らしいアプリが出てるの?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www
一つくらい挙げたら?www お前らが他の技術との比較を始めるから変なの呼び込むんやで
ここではblazorに集中せいよ
xamarinとflutterの話は専用スレでやれ vs+C#に慣れすぎた身からすると、vscode+tsが苦行にしか見えなくて、手を出したくない。
でもこんなにjs界隈が盛り上がってるということは
自分が知らないだけで、いざバリバリ使い出したら新しい世界が広がって実は素晴らしいものなのかもしれない。
今の自分は、かつてコボラーがJavaに手を出さなかったのと同じことなのかもしれない。 C#erこそTSへの移行じゃねえの?
アンダースヘルスバーグ入魂の一刀やで。
C#で出来んかった事を
ここでやらんとしていることが垣間見えるぞい。 TSって金融系の大規模システムにも使えるんだろうか とりあえずBlazor serverでjsのコーディング量が大幅に削減できて快適だわ 相変わらずフカシこいてんなwww
Blazor serverでjsのコーディング量が減る?wwww
今までサーバーでnodeでも使ってたのか?wwwww
適当なインチキ宣伝ばっかだなこいつwwwwww >>841
大規模pj御用達のangularとか
最初からts必須ですよ。 そら減るんじゃないの
それが目的のフレームワークなんだし
ゼロにはならないだろけど >>846
大規模だけじゃなくて
金融系とかかっちりしたやつ
大量データのお金や税の計算するやつ >>841
嘘つきに騙されるなよ
金融といってもいろいろあるが
金融の勘定系のバックエンドでそもそもスクリプトが使われない
速度と信頼性から静的言語が使われる
COBOL, Java, C#, Cなどだ
Angularなど実績の少ないものは使われない
金融は保守的だから新しい技術を避けたがる COBOLは言語としてはゴミだが
昔からCOBOLが多いから保守的な企業は
いまでもCOBOLでやりたがる >>844
JSの記述量はほとんどゼロになるけど? >>849
↑バックエンドとフロントエンドの区別もつかない糞ザコナメクジwww
> COBOL, Java, C#, Cなどだ
> Angularなど実績の少ないものは使われない
サーバ側言語とフロントエンドフレームワーク比べてなにがしたいんだこのカスwwwww
何がどこで動くのかもわからんのかwwwww >>851
「blazor serverにしたらjsの記述量がゼロになった」ということは、
今までのサーバーはnodejsだったということでOK?w
サーバー側にjsの記述があったから、
「ゼロになった」んだよね?ww >>852
>>846がAngularなんて書いてるから上げてる
区別がついてないわけないだろ
英語読めずに的外れなコピペしてるおまえみたいな無能と一緒にするな >>853
クライアントサイドもjsかなり減らせるよ
ゼロにはなかなかならないけどね FlutterとXamarinはスレ立ってたのでリンクはっておいた
ただその話題を排除したらこのスレ過疎るよな
Wasmまだデバッグ的に使うの難しい状態だし
Blazor Serverは使いどころが限られる。
個人的にスケールしにくい技術は使わない >>852
バックエンドでもts動くのでは?
やるならフロントとバックの言語は合わせたい
C#erなのでBlazorに手を出したい一方で
tsに鞍替えしようと言う案もある
やってる業務が金融系なんだけど、耐えれるのかなあと。。 >>860
Blazor ServerとWasmのどっちだよ
金融系だけじゃわからん >>862
そこもなやみどころですよ
そりゃwasmにしたいけど、生産性に難あり、api設計地獄にはまりそう。
Serverは既存資産が活かせそうだけど
スケーラビリティに難あり。負荷分散装置挟んだらセッション管理で地獄を見そうだ。
結局やってることは画面転送型のシンクライアントと変わらん気もする。
いまやるならServerかな…
.NET6になってwasmの生産性がマシになってたらwasmかな あと機能数が100超えるようなプロジェクトになっても絶えれるのかも気になるところだな >>863
Blazor Serverでスケールしなくて失敗したら
無能のレッテル貼られるぞw
SignalRは単純にロードバランサーでスケールさせることはできない。
今やるならASP.NET MVCかXamarinかFlutterだろ >>849
なんでバックエンドにangularがあんのよ。
バックエンドは大半がJavaでしょ。
新規はしらんけど。 >>867
言語ってサーバーとクライアントで同じ方がメリット多いと思うんだけど… >>866
だから6行目は話が別だっての
読解力ないな
>>854を嫁
Angularが使われてるとか嘘ついてる人いたから
そもそも勘定系は保守的でスクリプトではなく
型のある言語でやるって話だ >>869
後付けで誤魔化してるだけじゃん嘘つき無能www >>866
なんだ、最初にAngularとかずれたこと言い出したアホはおまえじゃないかよw
大規模とかいってるんだからふつうserver-sideの話ととらえるわ
client-sideだけのAngularなら規模は関係ないし
スクリプトしかできない奴なのがバレバレだぞ >>870
無能は最初にAngularとか言い出したお前のような奴のことだ
大規模って書いてあんだろw なんかごじれてるな…改めて聞くけど、
大規模、お堅い系業務システムで
バックエンドもフロントエンドもjs系の言語、フレームワークを使うのは現実的なんだろうか。 >>873
バックエンドはJavaやC#が多い
スクリプトは遅いし大規模に向かない だよね
>>828に挙げられているようなアプリでは適してるんだろうけど
>>873のような要件では使うべきではない。
俺が書いた>>841に対する回答の>>846は、大規模というキーワードだけ注目しただけっぽい。
大量のユーザーが使うアプリもある意味大規模だからまあ分からんでもない。
ただ>>873のような要件で使えるかは改めて回答してほしい。 なんで何処にでもアンチって湧くんだろうな
アンチの活動なんてこういう情強がいるスレではなんの効果も無いのに >>868
大体バックエンドとフロント同じメンバーでやってるケースは小規模なシステムだけだろ。
打ち合わせでサーバーサイドのAPIの仕様にはガンガン突っ込むが、
なんで作ってるかなんて範疇外だし
ノウハウで秘密なザービスあって
呑み会ネタだよ。 >>877
同じメンバー?同じ言語であってバックエンドとフロントが同じメンバーとは限らないよ。
でも、人の募集かけるときに複数の言語で募集かけずに済むし、バックエンドの人が余ったらフロントに回すとかもできるのはメリットかもしれない。
そこじゃなくて、言語が同じなら型の共有ができるとかそういうメリットがあるのでは?
>>877はバックエンドの経験なし?
そういう体制で作るのってゲームとか?
飲み会でwebassemblyの話題とかあがったりする? まさにフロントエンドとバックエンドを分けずに開発できるのは本当にいいね >>872
誤魔化したりなすりつけたりまるでチョンだなwww フロントとバックの境目なく開発できるのが効率よすぎる
工数かなり削減できる >>878
このスレ眺めてると、いろいろアレすぎて
父ちゃん情けなくて涙が出てくらぁ
ですわ。 >>880
>>883
あれだ。ね。
>>879
型の共有ってあれだ。設計がwww
>>バックエンドの経験なし?
大・中規模はなけいど小規模は沢山ある。
大・中規模はクラウド全盛であんたらの考えてるのとはレベルが違うぞい。
言語なんて依存するサービスによって使い分けるわーー。って感じ。
>>webassemblyの話題
あるねーー。おれ初? とりあえずバックエンドの経験はあまりなさそうだな
>>873の質問に答えて欲しかったが…
メガバンクや地銀が基幹システムをtsで作りました
みたいな事例は聞かないしな… 動けば何でもいいんだよ
動くコードを侮っちゃいけない C#で作りました、なんて話は確かに聞かないな。COBOLからJavaの話ばかりだ。
あるというなら銀行名を挙げてみたまえw それもそうだな
まあとにかくスクリプト系言語では作られてないと言うことだな
向き不向きはあって当然だ。 COBOLからJavaにしたところは失敗だったな
ORACLEのせいでJavaは死んだ
C#にしておけばよかったのにな >>892
”ORACLEのせいでJavaは死んだ”
どんな状況ですか?
UIまわりはSwiftにシフトしてきてますが Javaが死んでSwiftにシフト?wwww
何いってんだこいつww
Swift使われてるiOSはJVMじゃねーよカス
JVM上でアプリ動くのはAndroidだボケwww
なんでJavaが死んでSwiftにシフトすんだこの嘘吐きウンコなすびがwwwww セキュリティ厳しい分野で有名なのだとパスワード管理のオープンソースで急速にシェアを伸ばしてるBitwardenがあるな
サーバーサイドC#、モバイルC#、ウェブTS、デスクトップTS、コマンドラインTS、データベースMS SQL Server
マイクロソフトにベッタリだけど、オープンソースでクロスプラットフォーム対応が完璧
クロスプラットフォームやるならマイクロソフトがGood、なんて少し昔なら信じられない時代が来たのかもしれん >>894
死んだのはバックエンドの話な
Javaが実質有料化したから使う人減っただろう。
例えばJavaでもっとも流行っていたweb frameworkのSpringがシェア1%しかない。
https://www.wappalyzer.com/technologies/web-frameworks/
バックエンドJavaの代替言語としてC#の存在意義が高まっている >>898
”Javaの代替言語としてC#の存在意義が高まっている”
これまじ?C#やってると肩身が狭い思いをする事多々だったけど。
>>897
MSは開発環境に力いれてた時代はおわりましたよ。
MSの名前が前面にでると流行らないのでオープンソースでひっそりと。
MS直下の案件でもAngulr、Backbone.js、Knockout.js とか多かったですね。
そもそも今はクラウドで儲ける会社ですから。 マイクロソフトってその絶大な人気のおかげでアンチも多いから人気がないって勘違いしちゃう人が居るんだろうね
アンチは往々にして人気に比例するものさ >>900
アンチ多いです。
飲み会とかだと非常に露骨なので、非常に肩身が狭いです。
通常会議の席でも、MSは...みたいな発言してくる人たまにいます。(苦笑)
tsとかはMSの影がチラつかなったから流行ったのだと思ってます。
つられてVS Codeがオープンソース界隈で天下とった感じ。
MacでもVS Code使ってる人多いですよ。 最強開発環境 VS
最強エディタ VSCode
最強型安全OOP言語 C#
最強型付スクリプト言語 TS
最強サーバーサイドWebフレームワーク ASP.NET(Core)
最強Wasmフレームワーク Blazor
最強モバイルフレームワーク Xamarin
最強ソース管理 GitHub
最強共同作業ツール Teams
最強クラウド Azure
全部マイクロソフトじゃんw >>902
最強共同作業ツール Teams
最強クラウド Azure
これは絶対に違うわ
TeamsはGithubとの親和性がいまいちなのでJiraの方がいい
クラウドサービスはAWS>>>>>>>Azureくらい差があるな MSといえば最強OS Windowsでしょうが!
冗談はさておき、坊主憎けりゃ袈裟まで憎いな精神でMS嫌う人多いよね
どの企業もいいとこもあれば悪いとこあるのに。
いいとこ取りしたらいいんですよ。 Javaの有償化でJava離れがあるにしても、なんでそれがC#に流れると思うんだろう JavaでもC#でもどっちでもいいんだけど、
俺がずっと聞いてるお堅い金融系とか基幹システムでスクリプト系言語つかわれないよねって質問はYesなんだよね?
言っておくけど俺は静的言語最強とか言わないよ
それぞれ適材適所があって、どの言語フレームワークも銀の弾丸ではないのだ。
使われるシステムや要件の前提条件なしに、お互いの言語をディスり合うのはもうやめるのだ
これでいいのだ… >>909
そうだな
じゃあワシとBlazorの話をするのだ
BlazorServerってロードバランサー挟んだらもう完全にダメなのだ?回避策もないのだ? >>908
金融系のソフトを作っている人は恐らく限られているので、ここには僅かしか
来ていないかも知れない。
以前調べてみたら、日本のプログラマで多くを占めるのは、Webプログラマと
企業向けのカスタマイズソフトウェア。
後者は推定だが、一番多いのは顧客管理と在庫管理、勤怠管理のようなものらしい。
なお、金融系は、少し前まではJavaが多かったが、だんだんとC#に移るものが
増えていると聞いた気がする。
スクリプト言語は余り使われてないかもしれない。
これも金融系ではない一般的な話として、バイナリまたは仮想コードに直さないと
安定性に不安が残るから、と聞いたことがあるい。
なぜかと言われても答えるのは難しい問題だが。
よくある感覚は、WindowsプログラミングでもDLLを使った動的リンクもプログラマには
嫌われていた。MS的には厳密に管理しているからstaticリンクと変わらないと言うが、
多くのプログラマは不安を抱えていた。
インタプリタ言語にも似た感覚があると思う。
作者の判断で何でも変えてしまうことが多いから。
そもそも、スクリプト言語では動的に型を変えることが多いことが一番の原因かも知れないが。 >>911
感覚的には、x=y; とソースコードに書いたとして、コンパイルすると、
アセンブリ言語レベルでは、
mov eax,[_x]
mov [_y],eax
となるが、Javaの場合でもこれに類する仮想コードになると考えられる。
ところが、インタプリタ言語だと、こう単純にはならずに、xやyの中に
入っているオブジェクトの種類を調べたり、さまざまなグローバルな設定に
依存してインタプリタがさまざまに「いじくってしまう可能性」も残っている。
それがまず怖い。
現実的にもっと怖いのは関数呼び出しが、例えば64BITモードに変わったら
エラーも無く勝手な変換をインタプリタが行ってしまって何事も無く
過ぎ去るが、そことは全然別の場所でそのことが原因で原因の特定が難しい
とんでも無い不具合を引き起こすとか。
コンパイル型の言語なら、このような場合は大抵の場合、警告くらいは出して
くれる可能性が高い。 >>906 >>899
Javaとの共通点に気付かないのか?
もともとJava対抗で作られたのがC#だ。
Static
Javaと同等のスピード
中間言語
大手ベンダーのサポート
OOP
Javaが死んだら自然と代替のC#が使われるようになる。
web frameworkで実際にASPが人気になってるだろう
Javaやってたひとはスクリプトでは納得できない。遅い >>902
最強Wasmフレームワーク Blazor
これは同意しかねる。debugがまだ弱い
最凶ブラウザ IEもあるぞ >>908
金融じゃなくても基幹業務のサーバーサイドでスクリプトは極力避けるもの
メンテのコストがかかる フロントはまだ決定的じゃないけどサーバーサイドはもうC#以外でやりたくない
俺的にはC#9.0でOOP言語の決定版となった >>913
Javaが有償化して離れた人が有償のC#に流れるという不思議。OpenJDKの方がまだ理屈が通るな。 >>917
C#が有償ってなにいってんだ?
オープンソースだし無料だろう >>919
情弱はWindowsでしか使えないと思ってるんだろうね
>>918
草はやしてるいつものアホもやっぱりC#なにも知らなかった
C#できないやつはこのスレ来るなよ 普段スクリプトしか触らない「ホビー」の子達が紛れ込んでそうだね
彼らにガチの業務系バックエンドやらせたら
泣いちゃうんじゃないか? >>910
スケールアウトできるんじゃないですか?
インフラはSignalRですから。
>>914
Blazorは(Wasm+JS)のフレームワークですからね。
自分のWebAssemblyの定義には含まれないです。 >>923
Blazor Serverはスケールアウトは要注意。
ドキュメントにも注意点かかれてる。
サーバー増やすとSignalRで再接続した場合に同じサーバーにつながるとは限らない
がっつりステートフルだからきつい
Blazor Serverは多くの処理がサーバーに投げられてハードリソースを浪費する。
レスポンス良くしようと思うとかなりハイスペックなサーバー構成が必要になるはず
サーバー側のリソース良く使うからAzureで儲けたいMicrosoftに
とっては都合のよい仕組みなんだろうけど。
Azureで儲けるために作ったと信じてる。
大規模はステートレスにするっていう流れと逆行してるからな >>923
>>925
二人ともありがとう
今回作ろうとしてるシステムは社内で使うだけだからセッション維持ができるロードバランサーを使えば大丈夫なのかなと思ってる
しかし客先に入れようとすると、ロードバランサーの設定が大抵の場合他社任せになるから辛いんだよな…
ともかく、二人とも仲良くするんだぞ >>925
ステートサーバー立ててください。宜しく。 スクリプトキッズにサーバー建てるのは難しいだろうな >>927
ステートフルでめんどくさそうで調べてない
>>926
なるほど、そういう機能で解決する手もあるか
社内利用なら利用者数が想定できるし
悪くないね、Blazor Server
標準的なスペックでBlazor Server同時接続どれくらいさばけるんだろう
実験した人いるかな >>929
HelloWorldと多機能なグリッドで全然変わるんじゃないか
ページ数とかは影響しないんだろうか
仕組みがわかるようでわからんので想像がつかない >>925
>サーバー側のリソース良く使うからAzureで儲けたいMicrosoftに
>とっては都合のよい仕組みなんだろうけど。
>Azureで儲けるために作ったと信じてる。
>大規模はステートレスにするっていう流れと逆行してるからな
今までと違ってクラウドは珍しく競争原理が働いているように見えるので
殿様商売をやってきた成功経験豊富なMSが今後どうなるか見物。
コストパフォーマンスの良いサービスに流れるはずだから、無意味に
サーバーリソースを食いまくるようなフレームワークは淘汰されていく可能性が高く、
MSは今までの成功体験とは勝手が違って混乱していくかもしれない。 >>901
>tsとかはMSの影がチラつかなったから流行ったのだと思ってます。
>つられてVS Codeがオープンソース界隈で天下とった感じ。
>MacでもVS Code使ってる人多いですよ。
VS Codeを喜んで使っている人の大部分は、Webプログラマ系の人達なんだそうだ。
なぜならそれ以外のプログラマは、本物のVSを普段から使っているので敢えて
VS Codeを使おうとしないからと書いてあった。
なお、MSがVS Codeを作った理由は、それで一儲けできるかも知れないと思ったから
と考えられるそうだ。 MSは今までから他の人がやって成功したものを模倣することで成功してきたそうだが
クラウドの場合、その成功体験とは異なる結果となる可能性が少しある。
そうなることに期待している。 MSはナデラが就く前まで上手く行かなくなってきたので
破壊的創造などと言って社内で多様なものを作らせる方針に変更した。
結果としてさまざまなフレームワークが登場してきた。
しかし、それを使う開発者目線で見ればそういう多様性は混乱の原因ともなる。
あちらでできる事がこちらでは出来ない。組み合わせることが出来ない。
すべてを含んだものがない。
せっかく慣れてきたと思ったらすぐに非推奨になり全く異なる流儀のものを学び直さなければ成らない。
(それもどれを選んでも結局、数年後には全てが非推奨になる。)
統一感が無いため汚く感じる。 >>934
いろいろな物が出てきて「あれもできますこれもできます」ということが謡われるが
試して見ると中途半端で謡われているほどにはちゃんとできていない。
そして後先考えずに社員達に作らせるから、長い目で見れば自社の他製品と競合し、
結果的に大事な主力製品を衰退させることにつながっていく。
つまり、多様性といえば聞こえがいいが、大黒柱の製品の衰退を招きかねないが
MSが衰退した方がハッピーになる大部分の国々の人々にとっては高みの見物である。 MS製品では既に、WinForms, WPFが非水晶になった苦い経験を積んだ人が多い。
結果としてFlutterやUno,Embarcadero製品,Qtなどだと苦しまずに済むのではないかと
思われる様になった。
人は経験から学び同じ轍を踏む危険を回避しようとするが、MSが今までやってきた
酷い仕打ちは人々の心の中にしっかりと記憶されているので今後は苦しくなってくる
可能性がある。今までは選択肢が無いため不買運動も出来なかったが、今後、
選択肢が出てくれば。 >>932
会社がVS買うお金がないから仕方なくVSCode使ってると思ってた。
一方、個人でVSCode使う人たちは、イケてるWebプログラマのブログを盲信してしまって、他のIDEを使おうとしない…ということなんだろうか。
VSが対応してない言語やMarkdownのドキュメント作るためにVSCode使うのはわかるんだが
tsとかはVS対応してるよね…? BlazorがAzureで儲けるために開発されたのは多分その通りで
だとすればBlazorの存在を脅かすことになるMAUIはAzureの存在も
脅かすことになる。 >>938
いけてるエンジニアの大半が
VS codeに移行してますよ。 >>938
SSHとコンテナとWSL2に対してRemote DevelopmentできるイケてるIDE教えて >>940
別スレだったかで聞いた話だが、
VSCodeとtsの生産性をVS+C#並にあげようとMSが頑張ってるらしいよ
ほんとかどうかはわからんが、もし本当ならなんで生産性低いやり方を選んだってことになる
なんか別の魅力があるんだろうけど。
お金かからないとか。 >>941
なるほどそういう使い方したいとなるとvsでは無理なのか
でもなんでわざわざそんな環境選ぶの?
無償だから? VSというのは開発のフレームワークで
有ることを理解してない人が多い。
マイクロソフトがオープンソースに舵をきった時点で
VSからcodeへの移行が始まりました。
VSはオープンソース扱えませんので... VS使えるけどVS Codeのが軽いから好きっていう人はいるみたいだぞ
特にスクリプトで開発してる人にはVS Codeで十分なのかもしれない。 Javaのエンジニアからよく
VSでの開発はお気楽でいいーっていわれてました。
暗にVSがなければビルドすら出来ない
低レベルのエンジニアだろ?て言う嘲笑を込めて... >>943
逆になんでわざわざローカルで開発するの?
環境がどんどん汚れていくよ >>944
開発のフレームワークを強要すると言うこともあります。
VSプロジェクトのテンプレ構成がどうなっているか理解してる人は少数でしょう。
SDKだけ取得してVSに頼らずに
“ハローワールド!“
すら表示させることが出来ないエンジニアにされてしまいます。
昔VSは低レベルエンジニア量産マシーンだと
言われた事があります。
否定は出来ません... >>947
なるほど!
そういうメリットがあるのね
ためになります
生産性とトレードオフだと思うけど、高い生産性をキープできつつそう言う環境であれば最強だな。 >>948
低レベルは否定はしないけど、そんなSDKだけ取得してプログラム組まなきゃいけない状況なんかある…?
ソフトウェアを作るのは目的があるわけで、早く間違いのないプログラムを組む必要があるわけじゃん?
そのために不要な作業を無くしてくれてるのがIDEなのでは。 >>950
不具合時に対応出来ない。
そもそもVSpjテンプレが
どの様なライブラリを利用していて
それをどう動かしてるのかわからないと。
仕事中にデプロイヤーが自席にやってきて
CIに載せるからビルド方法を教えろとかいわれて
オロオロする光景が目に浮かぶ。
そんな事も出来ないと思われると、
以後、まともな評価を受けられなくなる。 >>951
そのために生産性を落としてまで普段からIDEを使うなと?
災害時にMT車使うかもしれないから普段からAT車に乗るなみたいな感じかな >>952
生産性とか下がらない。
VSが不便なのでVS Coceを使う。
VSで開発してるとイライラの連続になる。 >>952
IDEを使っても使わなくてもビルドできるようにする話でしょ? >>954
いや元はなんでVS使わずにVSCode使うのかという疑問
しかしVSそんな不便なのか…?
開発するものによるのかな >>955
同時に両方つかってます。
出来るだけVScodeに移したいのですが...
VScodeをメインにしてから
オープンソースをガンガンに使うようになりました。 >>951
MSBuild使ったらIDE用のソリューションをコマンドラインでビルドできるでしょ VSがオープンソース扱えないって全く持って意味不明なんだけど
>>944 >>951
?
VS使ってればデプロイ用にビルドできるから
テンプレートがどんなライブラリ使ってるかなんて考える必要すらないでしょ
あー.C++で作ったものとかはしらねーけど >>956
具体的に何の言語で開発してるか知りたい
TypeScript? VSはちょっとオーバースペックだよな
C#でMVC作りたいなと思ったらdotnet new mvcだけで始められるVSCode+SDKの構成は悪くない選択肢だ
これならインストールしっぱなしでも重くないし環境汚染も最小限で済む
VSは色々とブチこまれて気持ち悪いから本当に必要になった時に仮想マシンにインストールして使う >>963
ですね。
イラン機能てんこ盛りなんで...
あとNuGetが使えなさすぎる...
Bland側にデザイナー機能だけ集約してくれれば、
(Projファイルなしで起動できるようにして、、)
VSCode+Blendでイイ感じには出来そうなんですが... VSはバナナが欲しいだけの時にも毎回ジャングルまで付いてくる感じ。
ゴリラ大暴れ。 >>966
普段の開発はVSでやってちょっとファイル確認したいだけのときにはテキストエディタ起動すればいいだけだね ページ内リンクにジャンプする機能つけてくれないかしら
jsでscrollToElement使えば良いんだけど、C#で統一したいお >>1
次スレはタイトルにASP.NETはいれたほうがいい
検索で見つかる確率がおちてる asp.net webフォームの話とかされたらウザイから入れなくていい >>970
それならASP.NET 4.0以降と1に書いておけばいいだけの話
本命とか真打とか主観的な言葉はいらない >>969
Blazorに興味のある人は「Blazor」で検索かけるんだから今のスレタイで検索に引っかからないとかあり得ないだろ >>972
ASP.NETはやっているがBlazorはまだ未経験のひとは
たいていBlazorで検索しない。
BlazorはASP.NETのごく一部の機能や名称でしかない。
ASP.NETとかMicrosoftとかのキーワードはないとまずい
BlazorだけでなくASP.NETの今と未来の話題も多い 970超えたので立てておいた。
意外と伸びたな。プログラム板で10位くらいになった
Microsoft ASP.NET Blazor #02
http://mevius.5ch.net/test/read.cgi/tech/1605990630/ .NETの次世代フレームワーク
MAUIやらUnoやらの話ができるスレッドがほしい >>976
>>974のスレで大丈夫だよ
今までもあったし新しめの.NETの話題ならだいたいOK
それはっきり書くと反対意見がうるさくなりそうだからあえて書かなかった。
Blazorの話題だけでは単独スレとして維持できないほど過疎る >>976
cross-platformのnative appsなら
Xamarinスレッドでもいいと思う。
MAUIはXamarinの進化系なんでね
あとはC#が好きな住人がいる
MAUIはベータでもいいから実用レベルになったら
単独スレッド立てればいいんでは じゃblazorも実用レベルになってから立てろや
人柱集め必死だな(藁) >>1の意向がどうあれ、ああいう形で立てちゃった以上MAUIとかはスレチだろうな。 >>963
dotnet new mvc で作ったものと
Visual Studio のテンプレートで作ったものは
全く一緒なんだけどな
Visual Studio も今では裏で dot net new 使ってるだけだから。
ホントあほやな >>981
主にVSインストール時に
何でもかんでもつっ込まれる
いらんライブラリーの事含めてるのでは?
VScodeはVSより使いこなし必須なので人によるが、
サクッと短時間ではじめるには最良かと。 >>981
同じだったらコマンドのほうが圧倒的に早くていいじゃんw
え?なんでdotnet newで済むことを超ヘビー級のVSインストールしてやらなあかんのwww >>983
>>983
最初の一分ケチってその後何十時間の開発無駄にするあほwww >>979
Microsoftが正式版といって出したなら実用レベルなんだな
wasmもdubugが困難というだけで動作は問題ないし
Blazor Serverはなにも問題がない。 VSのコーディング体験は確かに素晴らしいものだが、環境汚染とリソース消費は無視できない問題だ
数カ月から数年渡ってC#のコーディング”のみ”に集中する予定があり、その間、他のプロジェクトには参加しない
そんな時なら流石に自分もVSで開発する
そうでないなら、SDKとVSCodeでカジュアルに開発したほうが負担が少ないんだな >>984
VSからcodeに移行してから世界が変わりましたよ。
貴殿が何も出来ないからでは? >>986
そもそも与えられてるPCが開発用なんだからVS入れると環境汚染だという考えが理解できないんだよな
そのためのPCだもん >>980
そういうのはっきり境界決めようとすると荒れるからこれでいいんだよ
MSの技術の話題ならあまりうるさく反対するひといないよ >>983
>>981に論破されてるし。
コマンドだとパラメーターを覚えて一字一句、正確に打たないといけない
覚えるのが無駄。
ファイルからコピペするならファイル探してる間にウィザードなら終わってるわ >>988
うんだからそれだけに集中していい簡単なお仕事ならそれでいいんじゃないの
俺は複数案件持ってるし、1つの案件でも使う言語は1つじゃない
様々なミドルウェア、サーバー、ツールを組み合わせて使ってる
そしてそれらをDockerでまとめ上げて環境汚染を回避してる
最近だとこういう構成のほうが多いんだよ
C#のコーディングだけやっとけばOKなんてことは稀 >>990
入力補完もヘルプもあるから問題ない
そもそもそれぐらい覚えることができない低スペック脳でIT従事したらだめだろw 現場でコマンド叩けなないと恥かきますよ。
リモートでターミナルしか繋がってなくて
コマンドでgitからソース落としてビルドなんて結構普通。
いつもVSだから出来ませんします? 偉そうなこと言ってるけど結局MSBuild知らないレベルだったもんな
>>951 dotnet new はインストールされているSDKの最新バージョンがデフォルトで適用されるのに対して
VisualStudioではまだ.NET Core 3.1 をターゲットとして作成されるし
コマンドの方がオプションは豊富だから最初から作りたい構成に近づけて作ることはできるかな
でも一度作ってしまった後はVISUAL
STUDIO使った方が全体として楽
まぁ企業で VisualStudio買ってもらえないところは
目をつぶってVSCodeマンセーッイワナイト
やってられないんだろうけど >>996
ターゲットは最後に選んだのが出てくるだけでは?
SDK .NET5.0いれてwizardで最初に.NET5選んでからは
wizardで5.0が選択された気がするよ >>994
その現場はなんでVS入れてないの?
お金もったいないから? >>997
あー、asp.net core ではバージョン選択できたわ
この間Consoleapp作ったときに選べなかったから
勘違いしてた このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 124日 12時間 25分 32秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。