【本命】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/11/08(日) 12:10:46.89

>>693
凄くどうでもいい事で申し訳ないがIDがSQL

**デフォルトの名無しさん** · 2020/11/08(日) 12:11:09.24

>>697
もう全然Blazor関係ない話で恐縮だけど…

大抵のDBって命名規約がスネークケースだよね。
しかも大文字か小文字のどっちか。

一度モデルファーストで作ったテーブルはキャメルケースで作られるから、生のSQL発行しようとしたらカラムIDを全部ダブルクォーテーションで括る必要があって苦労した苦い思い出がある。
LINQと生SQLどっちも使うとなるとこの問題に引っかかる。

自分のEFの知識が数年まえで止まってるのでいまはいい仕組みがあるのかな。

Dapperはパラメータで勝手にマッピングしてくれるから助かる。

**デフォルトの名無しさん** · 2020/11/08(日) 12:42:48.71

>>699
postgresqlは特殊な仕様だからハマりやすいね
なのでNpgsqlのEFにはUseSnakeCaseNamingConventionというオプションがある
他のDBは特にハマった記憶がない

**デフォルトの名無しさん** · 2020/11/08(日) 12:54:19.78

>>692-693
逆だよ。CRUDにEF使うのは便利だから意味がある。
C#のコードが短くなるし直感的にかける

だがスキーマの作成、変更でEF使うとC#のコードが長くなってしまう。
SQL側でダイレクトに変更すればすむものを履歴を持たせて
C#側から操作するから手順が増える。

スキーマが自動生成のものでいいってのはDB知らない奴だな
てきとうにつくるとパフォーマンス劣化する

**デフォルトの名無しさん** · 2020/11/08(日) 12:57:37.72

めんどくさいことになりそうな時は、RubyやRailsを勧めよう！

**デフォルトの名無しさん** · 2020/11/08(日) 13:03:31.26

>>694
原始時代って履歴台帳なんて古臭い言葉つかってるおまえだろう

スキーマ変更したら直後にテストしてるに決まってる
あと間違いやすいのは複雑な手順をとるMigrationのほうだ

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

>>701
最近のEFは良くなってる
ほぼ想像どおりのスキーマを出力してくれる
とはいえ完璧とも言えない

完璧を求めるならMigrationを生SQLで手書きすることもできる
SQLを手書きしたいという要求のためにMigrationの全機能を手放すのは惜しい

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

>>695
パフォーマンスの面でDapperは昔は意味あったとおもうけど
いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。

EFで満足できない箇所だけピンポイントでダイレクトにSQL使うか、
ストアドプロシージャを使えばいいと思うわ

>>697
たしかにEF Core速くなってるね
あとストレージがSSDになったのも超大きい

**デフォルトの名無しさん** · 2020/11/08(日) 13:15:04.98

>>703
いやいやスキーマを変更したあとにテストじゃ遅いだろ
Migrationをしてからテストするんじゃない
テスト済のMigrationを適用するんだ

ちなみにMigrationはアプリケーションをデプロイするだけなので手順ミスは最小化される
手作業でSQLを実行するとSQL数に比例してミスが増える

**デフォルトの名無しさん** · 2020/11/08(日) 13:17:19.61

>>704
ORM、DBのベンチマークたまに見てるし速くなってるのは知ってるよ。

ただstringとかの最適なデータサイズは開発者じゃないとわからないから
最適なスキーマ作ろうと思うとやっぱりSQLでスキーマ作成、変更したほうが
いいってのは今後も変わらないと思う

**デフォルトの名無しさん** · 2020/11/08(日) 13:25:09.54

>>706
根本的に会話になってない
俺の言ってるスキーマ変更するってのは決定事項なんだよ
既に正常に動くプログラムがあってそれをスキーマ変更するんだから
スキーマ変更した後にテストしないと意味ない。

Migrationでrollbackすることもない
動くようになるまで必要ならばC#側を変更するからだ。
なんかうまく動かないからスキーマ変更やめましょうということにはならない。

**デフォルトの名無しさん** · 2020/11/08(日) 13:33:40.14

>>707
EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ

より詳細な調整をしたい場合はMigrationを手書きしてMigrationBuilderに生えてるDDLラッパーを呼び出せば良い
DDLラッパーはCreateTableメソッド、DropTableメソッドなど.NETのメソッドではあるがDLLを書くのと非常に近い感覚で使うことができる
これはラッパーなので複数ベンダに対応することができる
代わりに最大公約数的な機能に制限されるが十分な機能揃っている

完全にMigrationをコントロールしたい場合には生のSQLを書いてもいい
EFはもちろん生のSQLもサポートしている
原始時代や産業革命時代に行っていたような作業はすべてEFでできる
ただし生のSQLを使うとベンダ依存が発生するのでそこはトレードオフだ

更に加えてMigrationとして.NETのカスタムコードを実行することが可能だ
例えば今まで保護されていなかった個人情報をC#で暗号化して保存し直すといったことも可能だ
手作業でSQLを実行する

**デフォルトの名無しさん** · 2020/11/08(日) 13:34:04.97

手作業でSQLを実行するだけではこのような複雑なMigrationには対応できない

**デフォルトの名無しさん** · 2020/11/08(日) 13:38:33.92

>>708
決定事項だろうがなんだろうがテストは必要だ

これからDBに対して行う変更を事前にテストする
テスト済の変更を確実にミスなく適用する

これを実行するための最もスマートな方法がMigrationだ
先程も書いたがこれをオレオレshellで代用することはできる
しかしそれは洗練された手法ではない
産業革命時代のやり方でしかない

もちろん適用したあとに最終チェックとしてテストを行うことはこちらとしても全く否定していない

**デフォルトの名無しさん** · 2020/11/08(日) 13:39:48.71

>>700
そんなのあるのか。EFにもどろうかなあ。
あとはバルクインサートやバルクアップデートができたら完璧。

**デフォルトの名無しさん** · 2020/11/08(日) 13:47:17.26

なおMigrationとその後のテストのどちらかが失敗した場合は
途中まで適用したMigrationをロールバックしなければならない
ロールバックはEFの機能で行うかDBバックアップをリストアするかどちらかだが
EFの機能で実施したほうが圧倒的に速い
リストアは最後の手段と考えよう

バグを放置してアプリケーションコードを修整するなどもってのほかである
これはサービスの停止時間を悪戯に伸ばすだけで損失を増やすばかりでなんの利益も産まない

バグがあったらロールバックを行い
Migrationとアプリケーション双方を見直し修整しテストする
テストした後にまたMigrationを適用する
これが現代人の働き方だ

**デフォルトの名無しさん** · 2020/11/08(日) 14:14:26.86

そういやMigrationって、データベースのデータの移行とかはできるもんなの？
できるのなら素人保守のSQLServerからPostgreSQLのマネージドデータベースに変えたいんだけど・・・・

**デフォルトの名無しさん** · 2020/11/08(日) 15:17:40.45

>>714
自分でコードを書けば柔軟できると思うけど
あるクラスのあるプロパティを別のクラスに移したいみたいなのは
自動生成では無理だと思う。

個人的にはmigrationは本番環境で使うものじゃなくて
開発中のコードとそれテストするときのデータベースの同期を楽にするもの程度で認識してる

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

>>714
Entity FrameworkのMigrationはそういう機能はないよ
スキーマ変更の履歴を保持してロールバックとかができるだけ
俺はロールバックしたことないからめんどくさくなってMigration使ってない

Managedの維持費のがSQL Serverのオンプレミス維持費より高いんでは？
SQL Serverなんてバックアップ、リカバリできれば運用かんたんでしょう
DBの種類変更したらデータ型互換性なくなるから慎重にテストしないといけない。
よほど問題ない限り安定稼働してるDBはいじらんほうがいいとおもうよ

**デフォルトの名無しさん** · 2020/11/09(月) 15:36:48.48

https://www.youtube.com/watch?v=VPB_J6Egi28

**デフォルトの名無しさん** · 2020/11/09(月) 22:46:28.72

朝は動いていたStateHasChangedメソッドが、
昼になったら動かなくなった。
こんなセリフは一生使わないと思っていたが使わしてもらう。
何もしてないのに壊れた。

**デフォルトの名無しさん** · 2020/11/09(月) 23:19:22.08

何もしてないなら壊れたことも観測できないはず
何かをしたのは明白だ

**デフォルトの名無しさん** · 2020/11/10(火) 02:27:35.40

ウソをつくのはやめろ
お前は息をした

**デフォルトの名無しさん** · 2020/11/10(火) 13:07:54.58

長時間動かしてたんだったら、ゴミだと間違われてGCに回収されちゃったんじゃないの？

**デフォルトの名無しさん** · 2020/11/10(火) 18:27:27.96

>>718
昼休みだろ
もしくはハードウェア、ネットワーク障害

**デフォルトの名無しさん** · 2020/11/10(火) 20:49:01.81

Nuget使って気付いたけど.NET 5.0来てるな

RCなの知らずにNugetでUpdateしてしまった

**718** · 2020/11/10(火) 21:35:46.33

処理済み件数/全件数のパーセンテージ出してたんだけど
数値の型変えたり、全件数のカウントを変数に入れたりしたら出るようになったわ。
なんだったろうなあ…
なんらかの呼吸が悪さしたんだろうな…

**デフォルトの名無しさん** · 2020/11/10(火) 21:42:11.59

リリースノート見ると.NET 5.0 RC2けっこう前にでてたようだ
EFとかはNugetのPackageで5.0対応のがでてそれで気付いた。
バグ人柱になりたくないのでもう少し.NET Core3.1でいくわ

.NET Coreという名前ももうおしまいみたいだし

**デフォルトの名無しさん** · 2020/11/11(水) 05:33:40.57

New Git experience in Visual Studio 2019
https://www.youtube.com/watch?v=UHrAg3iKoe0

**デフォルトの名無しさん** · 2020/11/11(水) 07:22:02.02

デバッグに至るまでになかなか時間がかかるんだが、皆さんPCのスペックどれくらい積んでますか
会社のパソコンSSDは積んでるけど、メモリが8GBしかない。

**デフォルトの名無しさん** · 2020/11/11(水) 07:47:11.57

>>727
8GBあれば仮想化以外は余裕でしょ
遅いならCPUがへぼすぎるんじゃないかな？
CPU型番とPassmarkスコアは？
Dockerとかの仮想化つかってる？
仮想化つかうと滅茶苦茶おもいのは仕方ない

あとVisual Studioの中のSQL Server Object Explorer
あれは重すぎるな
DB専用の管理ツール使うほうが快適

**デフォルトの名無しさん** · 2020/11/11(水) 12:45:25.01

新規開発をするに当たってフロントの言語選定に悩む
Blazorを選択したいところなんだけどSilverLightのハシゴ外をされた件が怖すぎて

**デフォルトの名無しさん** · 2020/11/11(水) 12:47:54.87

クライアント版で開発すればサーバー側の実装まで一緒に死ぬことはないと思われるんだけど…
ReactじゃなくてBlazorを選ぶのか？と言われると揺らぐ

**デフォルトの名無しさん** · 2020/11/11(水) 13:30:01.83

>>729
あれはブラウザー内にデスクトップアプリ
動かすようなレベルのもんだから
何もってきても無理じゃね？

**デフォルトの名無しさん** · 2020/11/11(水) 13:45:18.87

フロントは使い捨て

**デフォルトの名無しさん** · 2020/11/11(水) 14:55:53.43

>>729
Silverlightと違ってWasmはstandardだから無くならない。

BlazorはMSだから長期サポートされる。
Reactとかは人気落ちたらセキュリティパッチすらでるか怪しい
サポート期間の長さでMSより安心できるベンダーはない

Blazor WebAssemblyならば、
server-sideをASP.NET MVC + Web APIsで作るわけで
これ以上、安心できるserver-sideはないだろう。
速度も速いし長期サポートあるしC#使えるし。
もしBlazor廃れたらWeb UI frameworkだけ入れ替えればいい

**デフォルトの名無しさん** · 2020/11/11(水) 16:54:13.95

速度が速いとウソをつく
↓
激遅の現状を突っ込まれる
↓
速度など問題じゃないと強がる

**デフォルトの名無しさん** · 2020/11/11(水) 16:56:17.09

MS新ﾌﾚｰﾑﾜｰｸBlazor、Lighthouseで23点を叩き出すｗ
https://mevius.5ch.net/test/read.cgi/tech/1596698340/

**デフォルトの名無しさん** · 2020/11/11(水) 17:34:11.90

ドキュメントを読んでいて、コンポーネント間コミュニケーションのパラメーターやカスケードパラメーターが出てきたんだけどさ
便利そうだけど、これって使ったらコンポーネント同士が強固に依存しちゃうんじゃないの？
ファイルの編集・差し替えを繰り返すうちにスパゲティー化してきたり、いつか破綻しちゃわないか気になるな
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/components/?view=aspnetcore-5.0#component-parameters
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/components/cascading-values-and-parameters?view=aspnetcore-5.0

**デフォルトの名無しさん** · 2020/11/11(水) 18:34:49.69

>>733
MSのLTSはあまり期待してないなぁ
ソース管理についてもTFSがフェードアウトしてる感あるよね？
かと言って、Githubにデータ移行はできないし
MSはこういう所が横暴でロックインし難い

**デフォルトの名無しさん** · 2020/11/11(水) 18:50:22.79

>>736
上位コンポーネントからパラメータで渡す分には問題ないと思う
通常のプログラミングでいうと関数的な使い方

カスケードプロパティは危険な臭いがプンプンする
これはグローバル変数のようなもの
俺はカスケードプロパティは全く使う気がしない

パラメータで渡さない場合は状態を管理するクラスを1個作ってInjectするといい
コンポーネントからはこのクラス経由でしか状態にアクセスしない
これはインメモリリポジトリのようなもの

**デフォルトの名無しさん** · 2020/11/11(水) 19:05:28.34

>>734-735
backendのベンチマークだ
JavaやC#が動的言語より速いのは常識
知らないやつは初心者

>>735
また計測不能ばかりのクソサイト張る無能
楽天も計測不能

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

>>737
LTSは同類のほかのソフト出さないって意味じゃないだろ
セキュリティパッチ出てるならサポートしてるってこと
Googleとか他社はそれすらできてない

**デフォルトの名無しさん** · 2020/11/11(水) 19:23:06.81

遅さに関してはＭＳの責任者が１０倍遅いと言ってるし、
実際使うとともっさりしてんだよな。
サーバサイドのよりましだけど。

**デフォルトの名無しさん** · 2020/11/11(水) 19:32:33.32

>>741
10倍遅いというその発言も捏造
JS interopは.NET 5でかなり高速化したと発表されてる

wasmはよほどしょぼいハードの人以外は問題ないスピードになってる

**デフォルトの名無しさん** · 2020/11/11(水) 19:46:14.98

でも実際使うとともっさりしてんだよ。
JS interopの影響なのだろうけど、
処理概要を聞いたら感覚的に卒倒しとうなアーキテクチャだ。

サーバサイドのよりましだけど。

**デフォルトの名無しさん** · 2020/11/11(水) 20:34:50.42

むやみにevent呼ばなければ遅くならない
高速化のtipsも書かれてる
Blazor Serverの名前も出てこないようだしまともに
ドキュメント読んでるとは思えない

**デフォルトの名無しさん** · 2020/11/11(水) 20:39:05.32

>>734 の予言、当たってしまうｗｗｗｗ
速度が速いとウソをつく ( >>733 )
↓
激遅の現状を突っ込まれる ( >>735,741,743 )
↓
速度など問題じゃないと強がる ( >>742 )

**デフォルトの名無しさん** · 2020/11/11(水) 20:45:42.57

激遅の現状を捏造する

の間違いだな
実際速くなってるよ.NET5

**デフォルトの名無しさん** · 2020/11/11(水) 20:48:31.47

>>745
おまえアーキテクチャ全然理解してないのがバレバレ
backendとfrontendの違いも
WasmとBlazor serverの違いもわかってない

おまえはjQueryおじかweb app作れない奴だろうな

**デフォルトの名無しさん** · 2020/11/11(水) 20:51:59.41

Blazorはもともと高性能を目指したものではないからなーー。

https://ichi.pro/blazor-de-no-shumatsu-burauza-de-c-o-jikkosuru-118284362990616

開発者自身も了解している事じゃないの？
開発スタートの経緯を聞いてもそう思う。
偶然の産物なんだよ。このプロダクトは。

**デフォルトの名無しさん** · 2020/11/11(水) 21:27:58.47

>>740
あーそか
LTSは別の話だったね

**デフォルトの名無しさん** · 2020/11/11(水) 22:17:54.32

EdgeだけでもC#がnativeで動くようにしちゃえばいいのにな
MSがブラウザの独自エンジン開発放棄したのは失敗だった

まさかのIE12でもいいよ
C# native実行できちゃうやつな

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

メジャーフレームワークの事前ダウンロードオプションはそのうちサポートするんじゃないの
それか単にブラウザ拡張を作ればいい
事前キャッシュするだけだから簡単だろう

**デフォルトの名無しさん** · 2020/11/12(木) 00:16:11.70

フロントは使い捨てと書いてる人いるけど
フロント側でC#がガンガンうごくので、
APIがデータベースの土管になって、データ加工して表示するロジックとかrazor側にガリガリ書いちゃってる。これまずいのかな。
いやでもそれがwasmのメリットだよな…

**デフォルトの名無しさん** · 2020/11/12(木) 01:50:40.38

いいよ
UIにまつわるダーティな処理はクライアントでやろうがサーバーでやろうがUI入れ替えとともに消える運命

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

>>752
クライアント（View）は表示のみですね。
クライアントなくても、Curl等でAPI直叩きで業務が流せればOKです。

それが出来ないような実装なら、単体テスト出来ないでしょ。

**デフォルトの名無しさん** · 2020/11/12(木) 05:45:40.02

>>752
データ表示に関するコードはwasm内でやるべきでしょ
なるべくclient-sideでやってserver-sideをスケールしやすくする。

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

>>748
wasmで作ったゲームサイト、スムーズに動いてるな
https://aesalazar.github.io/AsteroidsWasm/

ゲーム以外でこれ以上ぬるぬる動かす用途ないだろ
読み込みloadingも2秒程度だった

>>745
これみれば一発でわかる。
計測できないlighthouseがクソなだけだ
https://aesalazar.github.io/AsteroidsWasm/

**デフォルトの名無しさん** · 2020/11/12(木) 10:03:52.41

>>752
それC#だからとか関係なくね？
業務ロジックはサーバーサイドで、データが取得できたあと表示に関する部分はどうぞご自由に、というのが手離れの良い設計だと思う

**デフォルトの名無しさん** · 2020/11/12(木) 10:30:35.87

ドメインモデルとプレゼンテーションモデルの変換はプレゼンテーションで行うのが正解

ReactなどのJSフレームワークは言語が貧弱だからこの変換処理が増えてくるとキツい

その回避策として先人はバックエンドforフロントエンドなどというバカみたいなパターンを作り出してしまった
プレゼンテーションモデルへの変換処理をバックエンドの高生産で高速な言語でやってしまおうという発想だ
なんという本末転倒

Blazorなら変換処理もC#で快適に実装できるのでいちいちバックエンドにやらせる必要はない
バックエンドはドメインモデルをJSONで返すだけでよい
これが世界中の開発者が本当に求めていたものだ

**デフォルトの名無しさん** · 2020/11/12(木) 10:59:08.18

>>758
TypescriptはC#とjsの良い事どりの呈してますよ。

**デフォルトの名無しさん** · 2020/11/12(木) 11:02:54.43

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
つまりまだ全然安定しておらず、成熟していない。

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

>>759
同じ設計者の末弟ケンシロウだからね。
C#はジャギ。
Delphiはトキ。

**デフォルトの名無しさん** · 2020/11/12(木) 11:15:38.91

>>760
すぐに解決するだろう

**デフォルトの名無しさん** · 2020/11/12(木) 11:17:38.70

>>759
TSは悪くない選択肢だね

**デフォルトの名無しさん** · 2020/11/12(木) 11:34:11.07

>>760
アホだ。最適化が終わってないだけは安定してないとはいわない。

しかもほとんどチェックマークついて対策済みになってるし
残りも.NET5までに対策される
.NET5はもうRC2だし

深刻なのはコピペしかできない>>760の頭の悪さ
>>756 でゲームデモで論破された

**デフォルトの名無しさん** · 2020/11/12(木) 11:51:45.96

>>763
node.jsの開発者がTypeScript直接実行できるの作ってますよ。
https://ja.wikipedia.org/wiki/Deno

**デフォルトの名無しさん** · 2020/11/12(木) 12:15:23.47

5の次がLTSだっけ
Blazorもそこに合わせて仕上げてくるだろうね
いよいよだ
さよならJavaScript

**デフォルトの名無しさん** · 2020/11/12(木) 13:32:02.28

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/11/12(木) 13:53:32.08

いつまで過去の情報に振り回されてんだこいつ

**デフォルトの名無しさん** · 2020/11/12(木) 13:56:33.64

では現在AoTになりましたか？ｗｗｗ

**デフォルトの名無しさん** · 2020/11/12(木) 14:11:17.34

エッ！一年前から遅い遅い指摘されてたのに、まだ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　　　　 |　　　　|
（（ |:ｄ: :♯| 　　 ((・|・))　　 !　　　　「延期！」
　　ヽ: : /＾ヽ､＿　ノっ＿ﾉ－､
　　　|: :|　　＼_／＾＼／＾＼_:ノ
　　　|: :|　　　　　　　　　　　　　　　＼
　/⌒＼ヽ　（⌒ヽ⌒）　　　））
　|　　　＼＼_／＾＼_／ﾉ　＿＿＿＿＿
　|　　　　　＼─┬─　´　|　　　　　　　　|_
　|.　＼.　　　＼ | 　＼　 |　　延期　（＿）
　| 　　＼　　＼.／￣￣）　　　　（＿)
　　　　　＼　　 /　　￣)　　　　　　　 |

**デフォルトの名無しさん** · 2020/11/12(木) 14:16:03.74

遅さはAOTだけで改善出来るもんじゃないと思う。
WASMと期待させておきながら、
画面描画を全部ＪＳでやるという仕様が回避できなければ、
永遠に遅いままかと。

**デフォルトの名無しさん** · 2020/11/12(木) 15:12:17.29

>>754
この人だけ意見が違う…
取得するデータごとに違うapi用意しだしたら、業務システムとか大変なことになるんだが…

**デフォルトの名無しさん** · 2020/11/12(木) 20:31:18.84

サーバーサイドと言語を揃えれるのがいいね
.NET5でLinuxデスクトップもサポートされるようだし
これでC#大統一理論にまた一歩近づいた

**デフォルトの名無しさん** · 2020/11/12(木) 21:39:57.08

やっぱり.NET5の正式版でてた
https://dotnet.microsoft.com/download/dotnet/5.0

>>723 >>725
でNuGetにだけ.NET5出てきて混乱したが
webの更新が遅れていただけのようだ
さっそく.NET5.0に入れかえよう

**デフォルトの名無しさん** · 2020/11/12(木) 22:01:02.38

981 名前：デフォルトの名無しさん[sage] 投稿日：2020/11/12(木) 00:44:34.38 ID:h5L0232Z

Announcing .NET 5.0
https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
Announcing ASP.NET Core in .NET 5
https://devblogs.microsoft.com/aspnet/announcing-asp-net-core-in-net-5/
Announcing the Release of EF Core 5.0
https://devblogs.microsoft.com/dotnet/announcing-the-release-of-ef-core-5-0/

**デフォルトの名無しさん** · 2020/11/13(金) 17:22:02.50

「Python」生みの親グイド・ヴァンロッサム氏、マイクロソフトに入社 - CNET Japan:
https://japan.cnet.com/article/35162404/

MSがPython開発者もとりこんできたぞ
どうなるんだこれ

**デフォルトの名無しさん** · 2020/11/13(金) 19:22:12.07

いいね
次はLinuxカーネルを取り込むのかな

**デフォルトの名無しさん** · 2020/11/13(金) 20:05:27.67

静的言語じゃないからASP.NETやwpfはpython対応しないだろうな

**デフォルトの名無しさん** · 2020/11/13(金) 23:51:54.28

IronPythonの話？

**デフォルトの名無しさん** · 2020/11/14(土) 21:54:51.97

純粋Pythonの話
IronPythonは良く知らない

.NET5でF#もバージョンアップしてるようだけど
あまり流行ってる気がしない

**デフォルトの名無しさん** · 2020/11/16(月) 10:49:42.55

Blazor WebAssembly、難しすぎる
Identyと
ASP.NET CorehostedありでProject作ると
counterのデモすら動かない。
Authorizingがでたまま止まる。
ブラウザ下にはunhandled exception。unhandledは現状デバッグできないらしい

dotnet v3.1でも.NET 5.0でも同じ。
Identity Serverのしっかり学習して設定しないとデモすら動かないのかな？
hostedのWasm、これどうやって動かすの

**デフォルトの名無しさん** · 2020/11/16(月) 11:00:59.37

wasmはunhandled exceptionが対応するまでハードル高い気がした
どこが間違ってるのか見当がつかないので大変だわ

**デフォルトの名無しさん** · 2020/11/16(月) 12:23:29.18

デバッグはちょっとしんどいよな
普通にC#で開発するときの生産性を期待するとガッカリする
まあそのへんもまだ黎明期ってことで時間が解決するだろうけど

**デフォルトの名無しさん** · 2020/11/16(月) 12:51:41.00

ほんまそれ
try catchで飛ばしても
エラー内容が改行されてないから見づらい。

**デフォルトの名無しさん** · 2020/11/16(月) 15:57:18.90

ホットリロードも効かないしな。
ガチでやり始めると地獄だよ。マジ

**デフォルトの名無しさん** · 2020/11/16(月) 22:44:17.44

WebAssemblyはガチでやる前に挫折した
Wasmはunhandled exceptionとか機能が充実するまで待つとする

Front何で作ろうかな
Blazor Serverは人数増えたらスケールしなくて破綻しそうだし
ReactはJS/TSでだるいし。
XamarinかFlutterでも始めるかな
Flutter for Web使ってる人いるかな

**デフォルトの名無しさん** · 2020/11/16(月) 22:48:59.15

SvelteかElmでいいんじゃねーの

**デフォルトの名無しさん** · 2020/11/17(火) 08:39:28.22

何を作るかによるけど、サーバーサイドと型の共有ができないと色々めんどくさい

フロント側を違う言語にして型が共有できなくなるか
デバッグがめんどいけどwasmにして型を共有できる恩恵を享受するか…
悩ましい

エディットコンティニュー、ウォッチ式、ホットリロード等この辺充実させてからリリースしてほしかったなあMSさん。

ホットリロードそのうちできるみたいな記事を海外のTwitterかなんかで見た気がするんだけどどうなったんだろう。

**デフォルトの名無しさん** · 2020/11/17(火) 08:52:54.81

>>788
.NET6.0

**デフォルトの名無しさん** · 2020/11/17(火) 09:32:33.92

.NET6が出たら起こしてくれ

**デフォルトの名無しさん** · 2020/11/17(火) 10:07:43.97

スレ違い宣伝爆撃で荒らし回ってたのってやっぱりMSの工作員だったんだな。
MSKK社員はコーディングできないしステマしか仕事ないんだろうなｗ

**デフォルトの名無しさん** · 2020/11/17(火) 11:43:25.58

>>787
そのふたつちょっと調べてみたがJSへtranspileする言語だな
transpileで我慢するならTSのがましな気がする

**デフォルトの名無しさん** · 2020/11/17(火) 11:47:52.17

？？？svelteはtsで書くんだけど…
まあjsでも書けるけど…

**デフォルトの名無しさん** · 2020/11/17(火) 11:54:00.50

>>790
1年後の.NET6の前にベータで機能追加くるだろうし
たまにリリースノートとかチェックすればいいんじゃないか

**デフォルトの名無しさん** · 2020/11/17(火) 11:57:26.47

>>794
いや、起こしてくれ

**デフォルトの名無しさん** · 2020/11/17(火) 12:03:11.01

.NET6はLinux desktopも対応予定らしい。
Blazor WebAssemblyいじって気づいたけど
実はXamarion.Forms最強じゃないか？

XamarinならWindows, iOS, Androidで動く
nativeとあまり変わらない程度に速いらしい
C#使える
UI開発がReactとかより圧倒的に楽に見える
Apple Silicon Macでも動くはず

Windows, iOS, Androidで動くなら手間かけてweb appにする意味なくない？

**デフォルトの名無しさん** · 2020/11/17(火) 12:09:39.89

>>795
Hot reloadはXamarin.FormsやFlutterにあるようだぞ