Microsoft ASP.NET Blazor #02

**デフォルトの名無しさん** · 2020/11/22(日) 05:30:30.13

ASP.NETのBlazorのスレッド part2です。

ASP.NET
https://dotnet.microsoft.com/apps/aspnet
ASP.NETは、クロスプラットフォーム対応、無料、オープンソースのフレームワーク
Free. Cross-platform. Open source.
A framework for building web apps and services with .NET and C#.

Introduction to ASP.NET Core Blazor
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-5.0

【本命】Blazor スレ1【真打】
http://mevius.5ch.net/test/read.cgi/tech/1595255796/

**デフォルトの名無しさん** · 2020/12/02(水) 10:29:09.09

サーバー不要の方式がSPA

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

>>60
エンジニア向けの説明？
MS技術に詳しくない人ならSignalRも知らないはず

類似のSPA技術はないだろう。
ほかのframeworkはなるべくステートレスにやろうとするが
Blazor Serverはステートフルでサーバーが多くの仕事をする。
しかもJSを書かない

**デフォルトの名無しさん** · 2020/12/02(水) 12:25:38.82

古くなったWebFormの移行先の技術選定で、社内のお偉方に説明する必要がある。
Serverの方は既存コードから再利用性が高そうだから使ってみようと思ったが
こんな技術が身についても潰しが効かないし、若手が嫌がりそう。

wasmも使い物にならんし
ts+Reactとかに思い切って移行するほうがいいのかもしれないと俺は思い始めた。

**デフォルトの名無しさん** · 2020/12/02(水) 12:31:47.85

既存のクソコードを一掃する
チャンスでもあるわけだ。

**デフォルトの名無しさん** · 2020/12/02(水) 12:35:05.78

>>63
BlazorとWebFormsは全然違うからダイレクトに移行するメリットはないよ
WebFormsをリファクタリングしてAspNet Core Webapi+WebFormsの形に落とし込む
その後WebFormsを好きなフレームワーク乗せ変える
移行先のフレームワークとしてBlazorを選んでもいい
これが移行の王道

**デフォルトの名無しさん** · 2020/12/02(水) 12:49:23.65

>>65
なるほどなあ
しかしwebapiの設計がまじでわからん

みんな本当にget,put,post,deleteのRESTの原則に従って作ってるのだろうか。

バッチ処理とかどうしてるんだろう

**デフォルトの名無しさん** · 2020/12/02(水) 12:53:18.42

>>66
大分まえから普通がRESTよ。
つい最近もオレオレREST？API作ってきたベンダーが集中砲火。

**デフォルトの名無しさん** · 2020/12/02(水) 13:54:47.31

REST, GraphQL とか

バッチ処理は、AWS Batch, Lambda とか

**デフォルトの名無しさん** · 2020/12/02(水) 14:00:38.77

>>63
思い切って移行ならXamarin.Forms
速くて使いやすくて喜ばれる
スマートフォンアプリ作れるようになるしエンジニア教育の
面でもベストだわ
少し待ってMAUIでもいいとおもうが。

>>65
AspNet Core Webapi+WebForms
はいったんレガシーとミックスさせる方法だから、
無駄にコストと手間かかりすぎだと思うわ
新規で作って切り替えるほうが楽だし現実的

**デフォルトの名無しさん** · 2020/12/02(水) 14:02:40.02

Visual Studio使ったら難しいこと考えなくてもC#でREST API生成できるやん

**デフォルトの名無しさん** · 2020/12/02(水) 14:03:35.26

Xamarin野郎来たからBlazor本スレに戻るわ

**デフォルトの名無しさん** · 2020/12/02(水) 14:09:13.66

>>71
新しいことを学べない人には無理だろうな
Xamarin.Formsという言葉だけで拒絶反応を示す

スタンドアロンスレに戻りなｗ

**デフォルトの名無しさん** · 2020/12/02(水) 14:28:48.10

あ、知識・スキル共に皆無なことが露呈してXamarin本スレから逃げ出した人や
こいつこんな所におったんか

**デフォルトの名無しさん** · 2020/12/02(水) 15:32:11.71

>>66
今どきRESTだけなんて無いよ
クエリスタックはRESTとGlaphQLの組み合わせ
コマンドスタックはgRPC
これが今のスタンダード

**デフォルトの名無しさん** · 2020/12/02(水) 16:08:55.57

>>74
gRPCが今のスタンダード？

笑

**デフォルトの名無しさん** · 2020/12/02(水) 16:10:32.50

MagicOnionマジおすすめ

**デフォルトの名無しさん** · 2020/12/02(水) 18:02:17.85

昔SOAPを使っていたのもあって
なかなかREST APIに馴染めない
に加えてあのURIを文字列で記述するのが嫌
クエリパラメータも文字列なのが嫌
スペルミスしてたら動かないとかつらすぎる。
（あんまり使ったことないから間違ったこと書いてたすまん）

せっかく同じC#なんだから型安全がいい
おそらく自分にはgRpcの方が馴染みそう

しかし一番馴染むのはBlazorServerのXXXService()
あんな楽なものはない。
だからBlazorServerが魅力的なんだよおおおお
惜しい

**デフォルトの名無しさん** · 2020/12/02(水) 19:39:41.09

>>75
そだよ
コマンドスタックは現状これしかない

**デフォルトの名無しさん** · 2020/12/02(水) 19:44:30.50

>>78
スタンダードの意味は？

**デフォルトの名無しさん** · 2020/12/08(火) 10:45:05.78

何をやっているか知りたいので空のプロジェクトから解説しているサイトないですか？
dotnet new web

**デフォルトの名無しさん** · 2020/12/08(火) 16:14:08.34

>>80
？

dotnet new webっていうコマンドが
なにをやっているか知りたいってこと？

**デフォルトの名無しさん** · 2020/12/08(火) 16:23:50.99

>>81
もんもー？

dotnet new web後の流れが知りたいってことでしょ

**デフォルトの名無しさん** · 2020/12/08(火) 16:43:22.34

本ならあった気がするがサイトは知らんな

**デフォルトの名無しさん** · 2020/12/08(火) 16:45:34.63

スレチ

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

文もう

**デフォルトの名無しさん** · 2020/12/08(火) 18:21:19.48

>>82
それってテンプレートから作ったものを
読めばいいんじゃね

**デフォルトの名無しさん** · 2020/12/09(水) 10:00:37.08

>>80
>1-2 のテンプレートに書いてあるだろう
まずはMicrosoftのドキュメントに目を通す

**デフォルトの名無しさん** · 2020/12/18(金) 07:21:07.35

この技術に限らずMSの出してくるフレームワークに手を出しづらい理由
MS自身が使ってないからなんだよな…
ブラウザ上でうごくExcelをBlazorで作ってるんなら安心するんだが。

**デフォルトの名無しさん** · 2020/12/18(金) 09:13:03.15

>>88
wasmの話だろうと仮定。
そんな無駄な移植しても意味ないし当然だろう
Excelはweb appとnative appで存在するのに
中途半端なBlazor Wasmで作る意味がない。

Excelに限らない話かもしれない
このままweb appとnative appだけが続き
wasmが普及しない未来はありうる。

**デフォルトの名無しさん** · 2020/12/18(金) 09:16:42.38

pythonが動き出すと話は全く変わってくる

**デフォルトの名無しさん** · 2020/12/18(金) 19:18:46.90

>>89
NativeにしてもWPFやXamarinでは作ってないよね
たしかReactNativeだったかな

技術的な意味がなくても移行をあえてやってみて
Officeで使われた技術です！
って宣伝するだけでその技術への信頼度上がるとおもうんだけどなー

**デフォルトの名無しさん** · 2020/12/18(金) 20:08:20.82

>>91
SPのExcelはReact Nativeなの？
Xamarinじゃなくて？

MSが使ってるかどうかよりも
MSと資本関係ののない多くの会社が使ってるかの方が信頼できるな
MSが使ってても宣伝やしがらみのためだと思われることもある

**デフォルトの名無しさん** · 2020/12/18(金) 20:12:21.48

>>90
Pythonはスクリプトだから遅いし大規模にも向かない。
TSとおなじく、MSのnative appやASP.NETでは
使えない状態のままだとおもう。
主力はC#

PythonはAIとか強いからMSとしてその分野の強化かと

**デフォルトの名無しさん** · 2020/12/18(金) 20:22:53.83

愛の不時着いいよね～ｗ

見たことないけど。

**デフォルトの名無しさん** · 2020/12/18(金) 20:38:35.56

>>92
SPがなにかわからんけど
クロスプラットフォームかということでReactNative使ってるんだと。
https://www.softantenna.com/wp/software/office-in-javascript/

**デフォルトの名無しさん** · 2020/12/18(金) 20:45:25.39

>>92
https://appfigures.com/resources/insights/microsoft-goes-all-in-on-react-native

iOSアプリでは…
Bing Search
Microsoft OneDrive
Microsoft Outlook
Xbox
Microsoft Word
Microsoft OneNote
Microsoft Excel
Mixer - Interactive Streaming
Microsoft SharePoint
Microsoft Teams
Cortana
Microsoft Edge
Office Delve - for Office 365
Microsoft Visio Viewer
Dynamics 365 for phones
PowerApps
MS Executive Industry Summit

続く

**デフォルトの名無しさん** · 2020/12/18(金) 20:45:59.21

>>96 続き

Androidアプリでは…
Microsoft OneDrive
Microsoft Outlook
Microsoft Word
Microsoft Excel
Microsoft PowerPoint
Xbox
Mixer - Interactive Streaming
Microsoft Teams
Xbox beta
Microsoft Edge
Microsoft Cortana - Digital assistant
Microsoft Kaizala
Microsoft SharePoint
Face Swap
Microsoft Selfie
Bing Ads
AltspaceVR - The Social VR App
PowerApps
Mixer - Interactive Streaming Beta
Xbox Game Pass (Beta)

…が、ReactNativeを使うてますねｗ

**デフォルトの名無しさん** · 2020/12/18(金) 21:29:16.49

日本の企業にありがちな
他部署が作ったオレオレフレームワークが他の部署では使われないみたいなやつ。

**デフォルトの名無しさん** · 2020/12/18(金) 22:05:46.36

>>95
SP=Smartphone

MSにしてはけっこう多いな、
別の記事ではMSはXamarin使ってると書いてあった。
MSはMAUIでたらMAUIに移行するんでは。
YouTubeはXamarinらしい。

最近のシェア動向
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
React NativeとFlutterが上位

**デフォルトの名無しさん** · 2020/12/18(金) 22:11:56.09

YouTubeがxamarin？見間違いじゃねえか？

**デフォルトの名無しさん** · 2020/12/18(金) 22:27:08.65

Nativeは置いといて
ブラウザ上で動かすExcelのような複雑なUIのアプリは、jsよりWebAssemblyのほうが向いてると思うんだが。

それでも作り直すメリットがないのであれば
逆にWasmは何に使うのが正解なんだ…？
ゲームのみ？

CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？
BlazorServerの方が生産性高いし。

**デフォルトの名無しさん** · 2020/12/18(金) 23:52:57.38

>>93
全てのアプリが速さを追求するわけじゃない
大規模なアプリも小規模なアプリもある
Pythonの膨大なライブラリがブラウザで動くことが重要

**デフォルトの名無しさん** · 2020/12/18(金) 23:57:26.29

>>101
新規サービスはBlazor一択
VS、C#自体の高生産性、バックエンドとフロントエンドが同じ言語で書けるメリットは大きい
速度も比較すると今はまだ遅いけど、体感ではどんぐりの背比べ、ぜんぜん問題ない
デバッグはまだやりにくいが、テスト書けばいいだけ

**デフォルトの名無しさん** · 2020/12/18(金) 23:59:15.50

>>101
Excelとか既存の大規模アプリは移植のコストが割に合わない

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

つまり遅くてデバッグもしにくくて使い物にならない、と。

**デフォルトの名無しさん** · 2020/12/19(土) 00:25:06.52

>>105
問題ないと言ってる

**デフォルトの名無しさん** · 2020/12/19(土) 00:25:30.46

>>102
AIでPython使うなら速度は大事。
PythonのライブラリはCを多用してるようだし。

スクリプトだと開発生産性も落ちる
Blazor wasmだと現状まともなデバッグできないからさらに生産性落ちる。

**デフォルトの名無しさん** · 2020/12/19(土) 00:30:54.14

>>89
ちゅうか、Blazor Wasmが駄目だからと言ってWasm自体の問題と混同しては
いけない。なぜなら、JS以外でWebページやWebアプリを作りたい需要は
とても多いはずなので、そのためにはWasmしか選択肢が無いから。
Wasmはプログラマが使う言語ではなく裏方で動くマシン語なのでWasmが
仮にどんなに使いにくくても、プログラマが使う言語にはほとんど影響しない。

**デフォルトの名無しさん** · 2020/12/19(土) 00:31:30.10

>>101
＞CRUD中心の企業向けアプリなんてwasm選ぶ必要なくね？

これはそのとおりだがそもそもSEO必要ないならweb appの必要がない。
なんでもブラウザでやろうとするのは思考停止。
native appのほうが生産性も高いし、速度も速いし使いやすい。
wasmよりもMAUI, Flutter, Xamarinなどnativeのほうが流行る可能性が大きい。

Blazor WasmについてはJS interopが遅いという問題もあるし
それとデバッグが解決するまで俺は静観ですわ

**デフォルトの名無しさん** · 2020/12/19(土) 00:40:03.17

>>108
そうはいっても
Blazor 以外のWasmがほとんど使われてないからな

一方でnativeは廃れる気配はない。

Swift, Kotlinでnative appの学習する分には無駄になることはほぼない。
MAUIが流行ったとしてもGoogle/Apple純正ツール開発と
Kotlin, Swiftの知識が役に立つ

**デフォルトの名無しさん** · 2020/12/19(土) 00:43:46.76

BlazorServerはいらない子なのか？

**デフォルトの名無しさん** · 2020/12/19(土) 00:43:58.13

ザマ爺、本命Blazorスレでボコられたからって今さらこっち戻ってくんなよハゲ

**デフォルトの名無しさん** · 2020/12/19(土) 00:50:09.15

>>110
FlutterやXamarine, MAUI, Qtなどと比べてWasmの優位性は、
実行形式が1つしか要らないのでビルドが速く、開発時のバックアップや
バージョン管理が楽と言うこと。
前者でAjail開発を行おうとすると、僅かに修正するたびに全てのターゲット
について再コンパイルして毎回テストしなくてはならない。
iOS/Android/Windows/Mac/Linux用に作る場合、5回、
64BIT版と32BIT版の両方が必要な場合、10回。
これだと開発に時間がかかってしょうがない。
一方、Wasmだと一回ビルドすればよいだけだしテストも1回でもなんとかなる
場合が多い。テストが省略できる理由は、ブラウザ自体がHTML5によって
プラットフォーム間の互換性を維持してくれているため。

**デフォルトの名無しさん** · 2020/12/19(土) 00:51:22.44

>>109
配布やらバイナリの管理やらに手間がかかるから
社内向けのシステムでもデスクトップアプリの応答性能が必要なければWebアプリ使うほうが主流やぞ

**デフォルトの名無しさん** · 2020/12/19(土) 00:54:22.75

>>113
最近、実行形式のサイズが大きくなって、ターゲットプラットフォームが多くなると、
バックアップに時間と容量を必要とする様になってしまった。
差分や増分バックアップでは途中のバージョンの欠損ですべてが失われる危険がある
のでやはり単純コピーしたいが、そうなるとプラットフォーム毎に実行形式が
異なっていることは非常に大問題となる。
その点、Wasmだとあらゆるプラットフォームで実行形式が単一しか要らなくなる
のでバックアップの時間もストレージの消費も少なくなって便利。
もちろんビルド時間も大いに節約でき、生産性も上がる。

**デフォルトの名無しさん** · 2020/12/19(土) 00:58:02.14

>>115
最近驚いたのが、VS2019ではMFCの(Debug,Releaseなどの)ビルドディレクトリ
のサイズが1GB程度に膨れ上がってしまっていることだ。
こんなもの、バックアップをどうしろというのだ。
コピーするだけで大変な無駄な時間が要る。

**デフォルトの名無しさん** · 2020/12/19(土) 00:58:22.58

>>107
学習は別にすればいい
AIも使うだけならそこまでではない
そして仮にAIが駄目だったとしてもそれでpythonの全ての価値を失うわけではない
AIはpythonの極一部の用途でしかない

スクリプトとC#を比べたらC#が勝つのは当たり前
しかしpythonには豊富なパッケージがある
pythonがブラウザで動くならそれは大きな価値がある

デバッグをする必要はない
やるべきことはテストコードを書くこと
テストコードを書けば自然とデバッグをする機会も減る
これはBlazorがどうのこうの以前の問題
テストツールがこれだけ充実してる時代にまだデバッグしてるんですか？

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

>>113
技術的に可能だからといって全部対応する必要はない
web appでIEを切るのと同じようにnativeでMacやLinuxは切る

Linux desktopなんて無視でいい。シェアがない。
Macもシェア小さいので無視。会社でMac無しはふつう
64bitで動けば32bitも普通まずそのまま動く

法人で使うならWindows10 64bitとAndroidとiOSだけで十分
WindowsとSPどちらか片方でもいい

**デフォルトの名無しさん** · 2020/12/19(土) 01:05:15.02

>>114
deployガーっていうのはもうやめてくれ
それは管理者、開発者が無能なだけだ

クリック押すだけのインストーラーつくってもいいし
システム管理ツールでdeployしてもいい。
アプリ開始時にバージョン通知するようにしとけば、
各自のバージョンも把握して強制アップデートもできる。
そういうアイデアがないひとがdeployが、と騒ぐ。

**デフォルトの名無しさん** · 2020/12/19(土) 01:07:02.04

>>118
まあ、言ってることはわかるが、Ajail開発では、テストを小まめにすることが
重要とされる。
例えば、64BITだけでビルドとテストをしつづけて、100回目で32BITでも
やってみたら、駄目、と言う事になる可能性があるが、その場合、不具合の
原因がどの修正によってもたらされたのは分からなくなるので、原因の不具合
の切り分けが難しくなるため、なるべく毎回テストした方が良いと考えられて
いる。ただし、ビルドとテストに時間が掛かって、むしろ開発効率が
悪くなることもあるので絶対ではないが。

**デフォルトの名無しさん** · 2020/12/19(土) 01:07:28.35

>>117
まだデバッグしてるんですかって？え？？
コード書きながら動作確認するのもデバッグなわけだがｗ

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

毎回Nativeをやたら推してくるやつが湧いてくる。。

**デフォルトの名無しさん** · 2020/12/19(土) 01:16:12.58

ID:pyDV0l6z
貴方、MS関連スレでオンプレ爺さんと呼ばれてる人ですか？

**デフォルトの名無しさん** · 2020/12/19(土) 01:20:51.08

Blazor Wasmやりたがってたひとって
wasmだからやりたいってわけじゃない。
ほとんどはただCSSやJSがきらいな人たち。図星だろう？

web appである必要ないのにまわりと一緒になって思考停止していて
生産性の悪いCSSゴミやJSでもがいて開発が進まない。

JSがいらない素晴らしい！と
Blazor Wasmのような成熟してないのもに手を出してしまう。

SwiftとかKotlinを学習してnativeでさくっと開発してリリースしてしまうほうが速い。

**デフォルトの名無しさん** · 2020/12/19(土) 01:27:21.70

速度は少々犠牲にしても開発し易ければ使われる、という歴史を何度も見てきた。
ターゲットが増えても、ビルド回数が一回で済むこと、バックアップのための
ストレージが少なくて住むこと、バイナリの管理が楽なこと、などのメリットが
Webアプリにはあり、なおかつ、好きな言語を使いたい需要が大きい以上、
Wasmが生き残っていく可能性は高いと見ている。

**デフォルトの名無しさん** · 2020/12/19(土) 01:31:03.86

>>125
じゃあBlazorServerで良くないか？

**デフォルトの名無しさん** · 2020/12/19(土) 06:52:39.03

>>116 >>125
バイナリサイズ肥大化はC/C++の問題だろう
C/C++はDLLなどランタイムの互換性も問題になる。

しかしそれらはC#では解決しているのだから関係ない話

あとWeb appはブラウザのバージョンアップでレイアウト崩れたりする。
nativeはブラウザのバージョンに関係ないからリリース後はむしろ楽になる。
昔はIEでしか動かないweb appがたくさん開発されてて企業によっては
いまだに稼働している。
web appにはそういう負の側面もある。

**デフォルトの名無しさん** · 2020/12/19(土) 06:54:57.16

>>126
Blazor Serverは企業内で使うくらいだろう
ステートフルだからスケーラビリティがない。

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

>>128
逆に企業外でwasm使うシーンってある？
ゲーム？

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

>>121
やれやれ
動作を確認するんじゃない前提と結果を確認するんだよ
それはテストだ

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

>>124
C#を使いたい人だよ

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

デスクトップはテストが面倒くさくないか
Seleniumは安定してるけどWinAppDriverは微妙

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

>>127
VS2019のMFCではバイナリサイズが極端に大きくなっていたが、それより十分前の
VSではそんなことはなかった。
なのでバイナリサイズが大きいのはC++そのものが原因ではない。

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

>>127
レイアウトの崩れはWidget類をcanvasにグラフィックで描画している場合は
起きない。

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

デスクトップアプリは未だにFormsの忌まわしい思い出を引きずっててな

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

>>135
どんな思い出？

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

>>116
中間ファイルなんかバックアップとる必要ないだろ

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

>>136
残業、徹夜、バグ地獄
デスクトップが高生産性なんて嘘だ

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

>>138
そういう職場がBlazor使ったところで問題解決にならないだろw

**デフォルトの名無しさん** · 2020/12/19(土) 13:00:34.17

>>137
ちなみに、Debug/Releaseフォルダは中間だけでなく最終バイナリも含んでいる。
また、不具合を発見した時、原因を探ったり、どのバージョンから不具合が起きていた
かを調査することは重要で、そのためには中間ファイルまで残っていたほうが
安全だし便利では有る。
ソースファイルだけ残していた場合、ライブラリやツールキット、ヘッダフィル、
コンパイラのバージョンが変化してしまっていることが多いので、元の
環境に戻すのに膨大な手間と時間が掛かるし、当時の環境にまで完全には戻し
切れないこともある。
毎回毎回、全ての関係ファイルのバージョンをメモすることも不可能に近いし、
古いヘッダフィルやライブラリなどを正確に全て保存しきることも難しい。
古いものをダウンロードしようとしても昔のURLアドレスは無効になっていて
探し出すのに苦労することも多い。
deprecateになっていてダウンロードできなくなってしまっている可能性も有る。
さまざまなライブラリを使っていれば、それら全てについて元に戻す作業が
必要となり、非常に時間が掛かる。
それを避けるためにライブラリ類をハードディスクなどに保存しようとしても、
容量が大きすぎて困ることも多い。
また、インストーラーを保存しても、インストール作業中にネットから
ダウンロードすることが前提になっているものも多く、ちゃんと古いバージョンを
保存することは難しい。

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

>>139
webになって淘汰されたから今は快適だよ
Formsは自然にスパゲッティになるように設計されてるとしか思えん

**デフォルトの名無しさん** · 2020/12/19(土) 13:16:37.65

>>140
開発環境はDockerで作るといいよ
Dockerfileだけで十分だけどもし不安ならイメージをレジストリに保存しておけばまず間違いない

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

>>142
dockerでWindowsコンテナって実用レベルになったの？

**デフォルトの名無しさん** · 2020/12/19(土) 14:21:59.37

>>124
Web開発にふむきな人用の
補助フレームワークですよ。最初から。

**デフォルトの名無しさん** · 2020/12/19(土) 14:33:16.67

>>129
ゲームは開発者が便利なUnityとかのライブラリで作る場合が多い。
Unityは生産性が高い。
一方のwasmは現時点でBlazor wasmはまともなデバッグができない。

あとはゲームといえばアプリ内課金だけど、wasmにすると
課金してもらうハードルがすごいあがってしまう。
SPのnative appだと手数料は高いが簡単に課金できる。

広告収入目当ての無料ゲームならwasmありだとおもうけど
ガチャとかで儲けようと思うとSP native appのが楽だと思うぞ

**デフォルトの名無しさん** · 2020/12/19(土) 14:37:33.55

>>130
俺の言ってるdebugはIDEのメニューのDebugに相当するものでおかしくない。
工程としてのデバッグと技術的なデバッグの違いは文脈でわかると思うんだがな

**デフォルトの名無しさん** · 2020/12/19(土) 14:38:28.43

>>145
ゲームでもなかったら何に使うんだこれってなる
BlazorWasmって最初は夢のような技術だと思っていたが、
俺のような企業向けアプリしか作らないやつにとってはBlazorServerが夢のような技術な気がしてきたぞ。

**デフォルトの名無しさん** · 2020/12/19(土) 14:42:22.79

>>134
グラフィックで描画したらSEO犠牲になるよな
SEOないならweb appでやる意味はないと俺は思う。

**デフォルトの名無しさん** · 2020/12/19(土) 14:48:03.92

>>140
それもC, C++の話でしょ
C#の人はそんな苦労はしてない
DLL地獄などバージョン管理の問題の多くは.NETで解決してる。
ソース保存だけで十分に後日デバッグできる。

**デフォルトの名無しさん** · 2020/12/19(土) 15:17:18.87

>>143
windows？

**デフォルトの名無しさん** · 2020/12/19(土) 15:18:34.03

>>145
テストしろよ
課金は内容次第

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

>>146
そのDebugは必要ない
テストしろ

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

>>147
夢のようだろ
C#でフロント開発できるんだから

**デフォルトの名無しさん** · 2020/12/19(土) 15:23:14.19

>>148
SEO対策が必要な部分だけは、グラフィックでやらずに普通に p や div で
文字列を書く方法も考えられる。

**デフォルトの名無しさん** · 2020/12/19(土) 15:24:00.22

>>150
ID:3Uzrrw/tはMFCをビルドしたいんやで

**デフォルトの名無しさん** · 2020/12/19(土) 15:42:15.72

お前らこの技術を使っていったいぜんたい何を作ろうとしてるんだ？

**デフォルトの名無しさん** · 2020/12/19(土) 15:43:59.93

>>145
一番の問題はiOSだね。
技術的に可能でも、Appleから駄目と言われれば終わってしまう。
とにかくAppleはなんとしてもMacのXCodeを使ってないアプリはiOSでは
動かせないように目を光らしている。
セキュリティーとかいう理由は体のいい言い訳で、実際にはMacを強制的に
買わせるため。
本当は独占禁止法違反。
Macの互換機を作ったところで今度はXCodeを互換機にはインストールできない
ようにされるだろうが、それはEUでは「相互運用性のため」と言われて
独占禁止法違反に当たるが。
というわけでMacの互換機を誰か作るべし。

**デフォルトの名無しさん** · 2020/12/19(土) 15:45:44.06

VirtualPCやVMWareみたいなもののWindowsで動くMac仮想マシンは無いのかな。

**デフォルトの名無しさん** · 2020/12/19(土) 15:48:45.06

>>157
Macだけあれば良いのだから問題ない

**デフォルトの名無しさん** · 2020/12/19(土) 15:50:12.89

>>159
個人的にはそれだけは嫌なのでiOSは無視するよ。