X



【本命】Blazor スレ1【真打】
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
垢版 |
2020/07/20(月) 23:36:36.67ID:td0HkrQz
混沌を極めるWebアプリケーション界隈に現れた一筋の光明
型無し言語 JavaScript の悪夢を打ち払い
林立するエコシステムの亡霊を退散
アプリケーション開発者の希望となるMVVMを引っ提げて登場した真のSPA開発環境

Blazorを語る者よ、集え!

ASP.NET Core Blazor の概要
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1
0005デフォルトの名無しさん
垢版 |
2020/07/21(火) 00:11:34.58ID:PmtuV1Mx
ブラザー、そう呼んでいいのかい?
0008デフォルトの名無しさん
垢版 |
2020/07/21(火) 04:28:48.30ID:svlMOeDH
この盛り上がらなさである。
人気がなくて悔しいから、人気のスレに寄生して煩く宣伝するしかない。
だから嫌われる。
C#ガイジはRubyガイジと全く一緒。
C#コミュニティとRubyコミュニティは、これらガイジを生み出して迷惑かけてる責任を取ってもらいたい。
0009デフォルトの名無しさん
垢版 |
2020/07/21(火) 08:00:25.49ID:SJ0RWW6w
>>8
それは日本人の大半が英語がろくにできないからだ
YouTubeの英語動画みてみろ

Blazorの英語の解説動画はたくさんあって
海外では既にかなり人気になってるのがわかる
ただ日本が遅れてる

YouTubeのBlazor動画いろいろみてると
front endの開発でうんこJS使う必要なくなって良かった!
めちゃくちゃ生産性あがった!
ってみんな感激してるわ
0011デフォルトの名無しさん
垢版 |
2020/07/21(火) 10:16:52.89ID:SJ0RWW6w
仕方なく使わされていたJSとは比較できない
JSという罰ゲーム開発から解放されたひとたちは
喜んでC#とBlazorを使っているのだ
0012デフォルトの名無しさん
垢版 |
2020/07/21(火) 14:21:08.45ID:bt9y6mdw
>>8
ホンマこれ。
C# Ruby jQueryは使用者が頭おかしい荒らしばっかだよな
0013デフォルトの名無しさん
垢版 |
2020/07/21(火) 14:38:13.07ID:RakZXNGC
Webのフロントエンドに疎く、これまでReactみたいなクライアントサイドテンプレートに触れたことがなかった.NETerが現代文明に触れて感動している図
0015デフォルトの名無しさん
垢版 |
2020/07/21(火) 16:51:30.11ID:SJ0RWW6w
>>13
JS界隈がレガシーすぎるんだがね
JSは互換性を重視しすぎて化石のようになってる言語

>>12
言語ではないjQueryまでいれてしまう頭のおかしい12なのであった
0016デフォルトの名無しさん
垢版 |
2020/07/21(火) 18:38:49.93ID:aodmvxxX
ESnextも悪くないしPHP8も悪くない
ただ現場見てる人からだとイメージは違うかも
0018デフォルトの名無しさん
垢版 |
2020/07/22(水) 10:50:18.28ID:z+eeQg9W
>>17
最近RubyガイジがおとなしくなってるせいでBlazorガイジが悪目立ちしてるよな
0020デフォルトの名無しさん
垢版 |
2020/07/23(木) 12:32:28.00ID:Eu0fAWmh
ケンカ売って、荒らして、かき回して注目を集める強盗宣伝しかできない。良くて子供のダダっこか。
本スレはこの体たらくwww
人気のなさは隠せない。
こどおじらしい自分本意ないやらしいこといくらしても誰も注目してくれない。
お前と一緒なフレームワーク。
だから親近感覚えたのかな?www
0022デフォルトの名無しさん
垢版 |
2020/07/23(木) 13:08:01.16ID:ai8d9jfq
>>20
確かにBlazorガイジが他スレで暴れ回ってるのに本スレが過疎とか笑えないな。
基地外しかBlazor使ってないのか?
0024デフォルトの名無しさん
垢版 |
2020/07/23(木) 21:50:49.37ID:rEo5oJ86
>>20
せっかく隔離スレ立てたのにお前みたいな嵐が乗り込んで来たらこっちが過疎るわ
お前はあっちのスレも相変わらず荒らしてるしどうしようもないクソだな
0025デフォルトの名無しさん
垢版 |
2020/07/23(木) 22:24:01.06ID:atvy6zMd
>>23
C#がランク外でアホが喜んでるが
おまえの推してたTSもランク入ってないし

ここまで実態を反映しないランキングなどどうでもいい
Pythonは過大評価されすぎ
AI以外であまり使われてない
言語ではないArduinoまで入ってる
0029デフォルトの名無しさん
垢版 |
2020/07/25(土) 06:06:32.47ID:vIjhxGJs
最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。
0030デフォルトの名無しさん
垢版 |
2020/07/25(土) 06:09:41.10ID:vIjhxGJs
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)
0032デフォルトの名無しさん
垢版 |
2020/07/25(土) 14:06:16.60ID:ZlqyHRW3
アンチというかキチガイが他所に喧嘩売りに行ってんだからそらヘイト買うだろ
0036デフォルトの名無しさん
垢版 |
2020/07/25(土) 21:47:14.32ID:blo6HsLG
なぜC#は失敗したのか…
ドトネトのクロスプラットホーム転換があと10年早ければ…
ほんとに残念。
0043デフォルトの名無しさん
垢版 |
2020/07/26(日) 14:58:24.62ID:8c+LEo48
もうEdgeもChromium系になったしなMSもブラウザでそこまで独自規格とかもうやらんのやない?
0046デフォルトの名無しさん
垢版 |
2020/07/26(日) 21:01:56.38ID:8c+LEo48
Windows 10 Mobileも終わったもんな
MSってあんまクロスプラットフォームで売り出すのには向いてないんじゃないかって思う
0049デフォルトの名無しさん
垢版 |
2020/07/27(月) 08:49:28.19ID:xQtC6s1H
>>46
結局プラットフォームで商売してるからね
.NET Core系もAzureとの抱き合わせ戦略の結果だんだんおかしくなってきてるし
0050デフォルトの名無しさん
垢版 |
2020/07/27(月) 09:01:19.90ID:c0Q45HfR
というかソースを見れば分かるがもろscriptタグ使ってる
blaおじはjsオワコンみたいに言ってるからもちろんjsコードは一切書いてないんだろうし
となるとハンドライベントなんかはトランスパイルとは言わないまでも自動生成とかそんな感じなんじゃないの?
0052デフォルトの名無しさん
垢版 |
2020/07/27(月) 09:26:38.30ID:TfnjDE3E
jsコード一切書かないならwasmの読み込みも出来ないなw
あれもjsコードだからw
0053デフォルトの名無しさん
垢版 |
2020/07/27(月) 09:26:43.19ID:c0Q45HfR
クロスプラットフォームを売りにしたCoreも結局他プラットフォームには浸透しなさそうって意味じゃない?
0056デフォルトの名無しさん
垢版 |
2020/07/27(月) 11:04:20.90ID:9Xn50/5g
>>51
IEが駄目になったのも、Javaが流行ったのも、サーバーサイドがUnix一色になったのも、
MobileでMSが駄目だったのも、理由が分からないのはMSのみ。
0057デフォルトの名無しさん
垢版 |
2020/07/27(月) 11:07:42.90ID:9Xn50/5g
>>44
.NET は、亜種が沢山ありすぎる上に、短時間で次から次へと変化して、大混乱中だし、
細かく調べれば調べるほど、誇大宣伝ばかりでMSが言った通りにはなってないので
信用が下がってる。
どれでプログラムしたらいいかもさっぱりわからないから、結局、昔からあるものを
使わざるを得ない。
新しいのに飛びついても、数年でさらに新しいのが出るし。
しかも、変化してるだけで良くなってない。
0058デフォルトの名無しさん
垢版 |
2020/07/27(月) 11:18:11.69ID:9Xn50/5g
WinForms, WPF, UWP, Xamarin.Forms, XAML, Blazor, Razor, .NET MAUI
沢山有りすぎて選べない。
始まったと思ったら、すぐ終わる。
「WinFormsは終わってWPFですよ」
何て言ってもWPFはWinFormsより劣った部分も多くて、結局、下火に。
UWPは見る影も無く。
Xamarinは調べれば調べるほどおかしい。
Blazorもおかしい。
結局、一番最初に出たWinFormsが一番開発し易くて、いろいろな意味で安定している。
0060デフォルトの名無しさん
垢版 |
2020/07/27(月) 12:45:24.48ID:vNtx9fDh
WPFは言うほど悪くない
0062デフォルトの名無しさん
垢版 |
2020/07/27(月) 13:38:17.14ID:7U86HVSX
よく >>58 みたいな体たらくのくせして
「今度は、Blazor は大丈夫!」なんて楽観的に踊れるよな信者は。
過去の経験を記憶する海馬あたりに障害があるんじゃないだろうか?
誇大広告でも、それでも性能で夢見させてくれるのかと思ったら >>28-30 の有り様。もうね…w
0064デフォルトの名無しさん
垢版 |
2020/07/27(月) 13:56:53.50ID:O6ncpH5Z
>>63
用途は関係ないよ
マイクロソフトが普及を諦めてなおざりにしてきたライブラリの歴史だよ
マイクロソフトのことだからBlazorもすぐに捨てるだろってこと
0066デフォルトの名無しさん
垢版 |
2020/07/27(月) 15:07:43.99ID:yFV6PxsL
>>62
xamarinはもうちょっと長生きするかと思ったんだけどなあ。
COCOAで挽回できるかと思ったけどかえってミソつけちゃったね
0068デフォルトの名無しさん
垢版 |
2020/07/27(月) 18:27:52.93ID:q4lb5yU9
.NET MAUIって、.NETまいうーに見える

>>58
いくつか種類があるのは悪いことじゃない
MSはそれだけ長期間サポートしてる証拠でもある

JSのOSSの世界だと破壊的なバージョンアップで仕様変更してるだけ。
MSは長期サポートしないといけないから、名前かえて新しいのを作る

Desktop:
いまさら新規でWinFormsもない。迷わない
WPFは悪いとは思わない。とがってる部分は使わなければいいし。

Cross-platform:
Xamarinの後継が.NET MAUIだからこれも迷わない。
迷わず新しい.NET MAUIにいけばいいんじゃないか
https://qiita.com/nskydiving/items/927b39c2983eb1f2d2b3
0069デフォルトの名無しさん
垢版 |
2020/07/27(月) 18:32:23.46ID:q4lb5yU9
>>64
普及するかはユーザーが選ぶか次第だろう
ちゃんと長期サポートするからこそこうやって選択肢がたくさんある

プラットフォーム、用途、安定性、実績を考えて
新しいものから選べばいいとおもう

Xamarinカオスだったから.NET MAUIは楽しみだ
0071デフォルトの名無しさん
垢版 |
2020/07/27(月) 20:27:01.90ID:Yb4FfF6H
Win7サポートしないとダメだよ
0074デフォルトの名無しさん
垢版 |
2020/07/27(月) 23:57:48.38ID:q4lb5yU9
WinFormsはUIしょぼいじゃないの
WPFで作った後は戻れない
戻ったら負け感があるだろう?

ASP.net MVC(Core)はこのまま開発終了なのかな
Blazor系だけになったら悲しい
0078デフォルトの名無しさん
垢版 |
2020/07/28(火) 15:31:38.53ID:XpAjM/1U
WPF++
0079デフォルトの名無しさん
垢版 |
2020/07/29(水) 16:48:29.82ID:ivzpA7HG
少し前までは何でもUIを求められたけど、RPAやらタスクランナーで業務が回りだすとコンソールアプリでいい気がしてる
あととりあえずjsonで出し入れできるようにしてると困らなくなった
0080デフォルトの名無しさん
垢版 |
2020/07/29(水) 20:18:50.28ID:mK2eufmg
WebAssemblyを批判してる人たちは
GoogleもWebAssemblyに取り組んでるの知ってるのかな?

MicrosofとGoogleが取り組んでて普及しないわけがない
0081デフォルトの名無しさん
垢版 |
2020/07/29(水) 21:00:18.06ID:z6Fnx3oM
wasmは普及するよいずれ。
その時にはblazorなんて滅んでるけどwww
0082デフォルトの名無しさん
垢版 |
2020/07/29(水) 21:52:59.48ID:XelKZAZW
         1年後の世界へ行こう!
/'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
  `ーー'       γ⌒ヽ/ブレキチ\    /'⌒⌒ヽ、
  ,-ーー-、     .||~ ̄~|/-O-O-ヽ|.   (     ┃  ⌒ヽ
 /  ┃  )   ||  6| . : )'e'( : . |9   \ ━┛    )
.(.   ┃   )  ||    `‐-=-‐ '     \___,ノ
 ヽ、__,ノ    ||  _(つ¶¶と)__
          /||'''''|  三  |    |'(⌒)
       /    '―――――`  ̄ \
       `============'
0083デフォルトの名無しさん
垢版 |
2020/07/29(水) 22:06:33.85ID:XelKZAZW
 ̄ ̄ ̄| |     llヽ _|      ヽ  
      | |     |l ̄| |       l Blazorって未来ではどうなってんの?
      | |    /  ´\     /        
      | |     ヽ、_   `^イ          
二二二 」 _ __ lニ二二l、           ____
─┴┐ ⊆フ_)__./   ┌ヽ ヽ┐   /´       `\
二二二二二二l  /    |  |   | |.  /             ヽ
_l_____| /`ー─‐|_|   |_| /             ヽ
  |       /`ヽ__, ─ 、ノ |─l  l               l   
  |───/  /lニ/  /二ニluul.  |                 !    え?そんなゴミないよ
  |    ___| ̄ |  |  |_|.      l                /
 └─(    )(ニ|  ̄|./二ニ)     ヽ              /
      ̄ ̄  /   )            >━━━━━━ く
            `ー ´            /               ヽ
0084デフォルトの名無しさん
垢版 |
2020/07/30(木) 04:41:03.42ID:rEfqRs7F
WebAssemblyのプロジェクトを作ると、サーバーも同時に作られちゃうけどさ
これWebAssembly部分だけ作るにはどうすりゃいいの?
0090デフォルトの名無しさん
垢版 |
2020/07/31(金) 02:16:03.14ID:F84TbMHr
MS社員が金貰ってここに書いているからさ。
0091デフォルトの名無しさん
垢版 |
2020/07/31(金) 02:16:03.16ID:F84TbMHr
MS社員が金貰ってここに書いているからさ。
0094デフォルトの名無しさん
垢版 |
2020/07/31(金) 15:25:11.73ID:MVdwX9C7
例えば迷惑な信者って声優関係ではめっちゃあるあるなんよね
無駄に別の声優やファンに余計な喧嘩売ったり
0097デフォルトの名無しさん
垢版 |
2020/08/03(月) 05:08:55.52ID:qdvto+rV
遅いという評判しか聞かないな…
反面、速いという話しは信者の「一年後には最速になる!」といった希望的観測ばかり。
韓国の「10年後には日本を追い抜く!」と同じ精神を感じる。
0099デフォルトの名無しさん
垢版 |
2020/08/03(月) 06:13:35.68ID:gnTaw2rH
>>95-96
らしい、らしいって試したこともないバカが他人の
コメントで知ったかぶり
C#を理解できないから自分で試すこともできない。無能

Blazor Serverはserver遅ければ遅くなるのは当たり前
スケールしにくいアーキテクチャだ
社内利用など人数がわかってる場合は爆速で使える

WebAssemblyの初回ロードは決して大きくないし
2回目以降は通常のwebサイトよりも相当小さい
GmailやAmazonのほうがはるかにデータ転送量が多い。
0100デフォルトの名無しさん
垢版 |
2020/08/03(月) 07:23:08.27ID:qdvto+rV
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
0102デフォルトの名無しさん
垢版 |
2020/08/03(月) 10:16:55.32ID:9/tK9gy1
>>99
>WebAssemblyの初回ロードは決して大きくないし
Blazorの場合は、かなり大きい。

>GmailやAmazonのほうがはるかにデータ転送量が多い。
大嘘。
0105デフォルトの名無しさん
垢版 |
2020/08/03(月) 10:22:00.59ID:gnTaw2rH
>>102
使ったことないだろ?
MS demoなんて2回目は400kb程度しかない

Amazonはトップページで15MB近くある。
それくらいは許容される時代になってるし
Wasmが初回のみ1-2MBとかあったとしても何も問題ない
0106デフォルトの名無しさん
垢版 |
2020/08/03(月) 10:25:38.81ID:gnTaw2rH
>>104
1-2MBというのは最初のランタイム込みだろうが、
2回目は激減するからどうでもいい
wasmではないweb appよりもcacheが効いている。
ランタイムはブラウザ同梱にしてしまう手もある
0107デフォルトの名無しさん
垢版 |
2020/08/03(月) 10:35:03.61ID:qdvto+rV
だれも使ってないEdgeにかw
いつか来て潰れた道だなwww
0108デフォルトの名無しさん
垢版 |
2020/08/03(月) 10:43:30.96ID:0nT8uF8W
サイドバイサイドが売りだったはずの.NETをWin同梱にしたらバージョン上げにくくなってインプレースでアップデートをやりはじめて
そしたらまたサイドバイサイドを売りにした.NET Coreが出てきたと思ったら今度はASP.NET Coreの同梱とかISSへの統合とかやりはじめて依存関係地獄へ逆戻り
.NETって延々同じ失敗を繰り返してるよな
0110デフォルトの名無しさん
垢版 |
2020/08/03(月) 11:04:22.51ID:oRu+bRIB
そもそもSPAはアプリケーション、つまり長時間開きっぱなしが前提
だから開くのに数秒かかるぐらいはユーザーは全く気にしない
起動に数秒かかるVSCodeでもみんな大好きだろ、そういうこと
それより重要なのは、開いたあとに安定して速度を出せるかどうか
その点についてはJSよりwasmのほうが高性能って結果がすでに出てる

開くまでの速度が重要ならそもそもSPAを使わずz従来の非SPAの静的サイトあるいはASPNET Core MVCを始めとしたFWが最速なのでそっちにすればいい
0111デフォルトの名無しさん
垢版 |
2020/08/03(月) 11:20:54.86ID:qdvto+rV
二回目から速いから初回訪問は遅くて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
0115デフォルトの名無しさん
垢版 |
2020/08/03(月) 12:10:15.24ID:qdvto+rV
>>114
それはすごい!さすがBlazor!!
モバイル6,399,199 URLの中央値1.9MBだから、画像含むコンテンツをあと100KB内に納めると、速くもなく遅くもない、ちょうど中間のサイトができるな!
さすがBlazorすごい!!
0116デフォルトの名無しさん
垢版 |
2020/08/03(月) 12:14:16.80ID:oRu+bRIB
>>111
だからSEOが気になる、初速が重要なサイトにはSPAなんてそもそも必要ないんだよ
SPAの必要がないサイトにむりやりSPAを通そうとしてるからおかしなことになる
銀の弾丸はないっていい加減学ぼう
0117デフォルトの名無しさん
垢版 |
2020/08/03(月) 12:20:15.28ID:qdvto+rV
そう、Blazorは銀の弾丸ではない。
遅くて重いがWebがワカラナイC#業務ソフトおじさんを再利用できる介護フレームワークなのだ!
0118デフォルトの名無しさん
垢版 |
2020/08/03(月) 12:35:01.57ID:grXRK/j3
再利用大いに結構
偏屈で高い割に柔軟性がないJSユーザーより一緒に仕事しやすい人材が多いから
0119デフォルトの名無しさん
垢版 |
2020/08/03(月) 12:46:59.56ID:9/tK9gy1
>>105
1MBのDLに12秒くらいかかる環境でも、amazon.co.jp は、初回でも
数秒以内に利用できる状態になる。
ということは、300KB位しかなく、15MBなんてとんでもない。
0122デフォルトの名無しさん
垢版 |
2020/08/03(月) 13:37:44.02ID:U3N5AFk/
開発者ツールで見てみたけど、最終的には9MBダウンロードするが、1〜2MBでページは完成してるしスクロールもできる
0124デフォルトの名無しさん
垢版 |
2020/08/03(月) 15:22:07.53ID:gnTaw2rH
>>112 >>119
アマゾンは広告が変わるから日時によってサイズは変わる。
今見たらアマゾンのトップは10MB程度ある。
おまえが調べ方知らないだけだろ
Firefox developer tool使え

>>121
それCache無効化してないだろ
Firefoxの場合は
Shift押しながらreloadしないとcacheを読んでしまう

Twitterのtimelineとかも画像多いから10MB程度いくこともある。
フォローしてる人、画像にもよるがけっこう食う。
それ考えたらBlazor Wasmの初回のみ2MB程度なんてたいしたことない。
0126デフォルトの名無しさん
垢版 |
2020/08/03(月) 15:33:35.80ID:qdvto+rV
twitterは無限スクロールでどんどんロードしてくんだから当たり前。
それともBlazorでは無限スクロールは

 実 装 で き な い

のかなぁ…?
だって実装したら同じように10MB20MB簡単に行っちゃうからね。

フォローしてる人、画像にもよるがけっこう食う。
それはフォローしてる人の投稿内容、画像というコンテンツがあるから。

一方Blazorはなんにもない。
なんにもなくて2MBwww

なんにもコンテンツなくて既に全サイト中真ん中のパフォーマンスwwww

さて内容カラッポで2MBwwwここからコンテンツ足したら重くなるのでしょうか軽くなるのでしょうか?wwwww
0127デフォルトの名無しさん
垢版 |
2020/08/03(月) 15:35:46.53ID:9/tK9gy1
>>125
今見てみたら、やはり、主要部分は300KB程度で、あとは、商品の画像ファイル
の読み込みが続き、最上部の映画などの宣伝動画がずっと続く。
商品の画像は大体、見てる範囲が先にDLされ、すべてがDLし終わらなくても
見られるから、余りDLの遅さを感じない。
宣伝動画が8MBくらいあるようだが、ストリーミングで再生されているので、
全部 DL されなくても見られる。

これは、Blazor/Wasmが、最初に2MBくらいをDLし終わらないと全く実行できない
のとは全く異なる。
0128デフォルトの名無しさん
垢版 |
2020/08/03(月) 15:41:14.36ID:gnTaw2rH
2MB弱で騒いでるアホは
アナログ回線でダイヤルアップ接続でもしてるの?
クソ回線自慢にしかなってないんだがw
0129デフォルトの名無しさん
垢版 |
2020/08/03(月) 15:48:10.28ID:9/tK9gy1
>>128
そうやって、相手のハードウェア環境を馬鹿にしたりするのはソフトウェア失格。
そんなこと言い出したら、もともこもない。
如何にハードウェアの性能を出し切るかがソフトウェア。
0130デフォルトの名無しさん
垢版 |
2020/08/03(月) 16:03:26.85ID:0MenM/I/
>>126
そういや去年くらいの当時のAngular最新版の実装の新機能で挙がってた機能だかスクロールで表示範囲外になった部分の内容がアンロードされる仕様今のTwitterに入ってるね
0131デフォルトの名無しさん
垢版 |
2020/08/03(月) 16:14:50.85ID:9/tK9gy1
>>126
通常のサイトは、たとえ 2MB と言っても、ページを表示してから時間を掛けてDL
しているものが多い。
まず、タイトルと文書が見られるようになって、上から順に画像がDLされていくような。
だから、実際には最初の100KBくらいDLされた時点でページ事態は見られる状態になっている。

一方、Blazor/Wasmの場合は、2MBが完全にDLしきらない限りは、全くページが見られない。
この差は大きい。
0132デフォルトの名無しさん
垢版 |
2020/08/03(月) 16:19:29.41ID:hyEwWuLa
すぐに改善される部分にしかイチャモンつけられない時点でアンチの敗北なんだがわかってないのかねぇ
0136デフォルトの名無しさん
垢版 |
2020/08/03(月) 18:20:54.60ID:qdvto+rV
名前はマイクロソフトなのにwww
0137デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:10:07.71ID:ukM+b7An
起動が遅いアプリの場合、スプラッシュウインドウを表示するべし。
大昔からの言い伝えだ。
0138デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:27:54.68ID:VfthWC1J
楽天のトップページが20MBあるから。

リアクトで100kbに減らせるなら美味しい。
0139デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:33:39.76ID:VfthWC1J
まあただ同じ低価格帯ならリゴルよりシグレントのほうが歪み少ないね。
テクトロは別格だけど100万するからね。

まあプロならLinux使っとけってことだよね。
0140デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:35:13.78ID:VfthWC1J
最近のオシロはどれもUSB接続できるけど、シミュレータ含めてアプリがWindowsに対応していないからね。

Ubuntuに慣れておくべきだよね。
0141デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:42:24.02ID:VfthWC1J
アナログプローブがWindowsに対応していないのが痛い。

デジタルだけならWindowsでも良いんだけど、結局デジタルも突き詰めて言えばアナログの一部なので、Ubuntuが必要になる。

富岳に対応していないのも使いにくい。
業務だから。
0142デフォルトの名無しさん
垢版 |
2020/08/03(月) 21:46:26.66ID:VfthWC1J
富岳はさすがに日本の技術の粋を集めただけあって速かったね。

Windowsで一時間かかるプログラミングが、富岳なら30分で終わる。


これはイケルと思いました。
0143デフォルトの名無しさん
垢版 |
2020/08/03(月) 23:47:54.57ID:9/tK9gy1
MSは、サイズに関しては小さく出来たためしがない。
0144デフォルトの名無しさん
垢版 |
2020/08/04(火) 00:28:38.33ID:vydsY05j
名前はマイクロソフトなのにwww
0146デフォルトの名無しさん
垢版 |
2020/08/04(火) 09:56:23.74ID:CK7AS0VE
MSの悪口を言われた雇われエバンジェリストが、任された仕事を全うするため
全く関係ないオシロスコープの話題を出して、ごまかそうとしている。
0147デフォルトの名無しさん
垢版 |
2020/08/04(火) 19:11:18.47ID:CLCPvHjf
Blazorなんか業務システム用途だろ
朝に一度立ち上げるだけなんだから
ダウンロードの量とか大した問題じゃないわ


開発の生産性あがる方が大きい
0148デフォルトの名無しさん
垢版 |
2020/08/04(火) 19:30:17.89ID:eB3iNrrw
だよな。
遅すぎ重すぎでとてもコンシューマーには見せられないよな。
0149デフォルトの名無しさん
垢版 |
2020/08/04(火) 19:34:29.20ID:FHqpkUfc
最初おそかったけど気付いたら最速になっていた程度の認識でいいと思います
0150デフォルトの名無しさん
垢版 |
2020/08/04(火) 19:40:44.55ID:cWgQ3xfc
Linux板だとLAMPとWindows Serverを比較してああだこうだ言う人が居るんだけどね。
0151デフォルトの名無しさん
垢版 |
2020/08/04(火) 19:46:42.53ID:pID3dDUo
赤帽で動いてる既存システムをとりあえずなるはやでdockerizeしたいときに便利そう←SYSTEMD
0152デフォルトの名無しさん
垢版 |
2020/08/04(火) 20:18:53.10ID:9595nKGY
>>147
Blazor Wasmはブラウザ閉じて立ち上げ直しても
アプリがちゃんとキャッシュされてる。

全部のダウンロードは本当に最初の1回だけ。
朝だろうが関係ない、翌日以降含めてずっとサイズ小さい
0153デフォルトの名無しさん
垢版 |
2020/08/04(火) 20:21:26.90ID:9595nKGY
https://youtu.be/ctSqiD8BGPM?t=170

ASP.NET coreはnode.jsより7倍速い。
node.jsはオワコン。低速・開発生産性も低い
0154デフォルトの名無しさん
垢版 |
2020/08/05(水) 01:35:29.29ID:zbDytttg
最初の一回って、オンラインアップデートが常に高速にできることがWebアプリ
のいいところでもあるのに、それができなくなるってことじゃん。
それに最初の一回でも20秒もかかるのは駄目だ。
0155デフォルトの名無しさん
垢版 |
2020/08/05(水) 10:57:38.43ID:s8pcBT+O
まぁどんなことでもそうだけど
要はバランスだからな

向く用途と向かない用途がある
どんな技術でも

自分の目的用途で最適だと思うのを選べばいいだけ
0156デフォルトの名無しさん
垢版 |
2020/08/05(水) 13:10:16.99ID:tll6+bZl
>>154
ダウンロードするwasmのコードに変更あったら
アップデートされるだろう
それなかったら変更のたびにエラーが出る
0158デフォルトの名無しさん
垢版 |
2020/08/05(水) 14:10:26.08ID:zbDytttg
Yモバ、UQ、Rakuモバなどだと、Blazorでは、HelloWorldの初回起動に20秒以上かかるだろう。
0159デフォルトの名無しさん
垢版 |
2020/08/05(水) 14:11:17.80ID:zbDytttg
>>158
なお、その環境でも、amzon.co.jpのページは、2秒くらいで使えるようになる。
0160デフォルトの名無しさん
垢版 |
2020/08/05(水) 14:49:38.22ID:6NzwAzCO
今後は遅延ロードがカギになんのかな
Blazorの場合どうなってんだろ
メソッド呼び出し時にまだアセンブリがロードされてなかったらそこでダウンロード開始なのか
メイン開始時にバックグラウンドでダウンロード開始なのか
どちらにしても今のDIコンテナはエントリポイントでアセンブリを全部読み込む必要があるから再検討が必要かもしれんな
0161デフォルトの名無しさん
垢版 |
2020/08/05(水) 15:03:31.53ID:O3zNF1qA
ランタイム部分だけはせめて、全サイトで共用になって欲しいな
0162デフォルトの名無しさん
垢版 |
2020/08/05(水) 15:45:23.00ID:eyNhEtAe
>>159
これ言っとかないとBlazorおじさんが「Amazonも〜」とか捏造し出すからなw
0163デフォルトの名無しさん
垢版 |
2020/08/05(水) 16:09:49.60ID:PkhzukNe
>>161
Blazorの同一バージョンが効果的にキャッシュヒットするほどBlazorが普及するというありえない仮定のもとでは同意
0164デフォルトの名無しさん
垢版 |
2020/08/05(水) 16:15:30.76ID:tll6+bZl
>>159
GmailやAmazonは実際のデータ量は大きいだろう
backgroundで落としてるから気になりにくいだけ。

見かけの速さではなく実データのダウンロードサイズを見るべきだ

>>158
MNOやサブブランドは速いしそんなに時間かからない。
0165デフォルトの名無しさん
垢版 |
2020/08/05(水) 16:23:58.96ID:tll6+bZl
Blazorに文句つけてるやつの大半が
激遅いスクリプト言語つかってるんだよな
0167デフォルトの名無しさん
垢版 |
2020/08/05(水) 18:53:20.54ID:zbDytttg
形態の格安キャリアだと一ヶ月5GBを過ぎると1Mbit/s位に速度が落ちる。
5GBだと、まともな画質でYouTubeを見るとなると、2時間もたないだろう。
となると、一ヶ月の内の大部分の日は、1MBbit/sの状態で過ごすことになるだろう。
ならば、Blazorの2MBのDownloadに20秒かかるのはあながち間違いではない。
0169デフォルトの名無しさん
垢版 |
2020/08/05(水) 19:47:21.31ID:tll6+bZl
>>167
低速1Mbpsは格安SIMとは呼ばない。それは
サブブランドかMNOの低速モードだ。
格安と呼ばれるMVNOは、低速200kbps以下

200kbpsの人たちは切り捨てでいいだろ
IE対応と同じで切り捨てていく
光回線も持たずに動画見まくってギガ不足になって追加課金も
しないような事例だされても知らんがなで終わり
0170デフォルトの名無しさん
垢版 |
2020/08/05(水) 19:47:34.12ID:GhYHD/aN
SSRとWASMのスイッチングをサポートするのが現実的な落としどころかも
デフォルトはSSR
気に入って起動コストが無視できるぐらい利用時間が増えたらWASMに乗り換え
0172デフォルトの名無しさん
垢版 |
2020/08/05(水) 20:46:00.88ID:yvhpxJsg
もうすでにLazy Loadingは実装されてるみたいだね

https://isc30.github.io/blazor-lazy-loading/

コンポーネント単位で、依存アセンブリが未ロードならダウンロードって感じのようだ
React.lazyと似たような感じかな
これで最初にロードしなきゃいけないのはキャッシュしやすいランタイムだけになった
ほとんど待たされずに最初のページが表示される
0173デフォルトの名無しさん
垢版 |
2020/08/05(水) 21:38:13.46ID:DmZXfViQ
>>164
GMail、CPUが1コアとかだとメッチャ遅いな
0174デフォルトの名無しさん
垢版 |
2020/08/05(水) 22:09:28.38ID:eyNhEtAe
> これで最初にロードしなきゃいけないのはキャッシュしやすいランタイムだけになった

ゴチャゴチャと屁理屈捏ねた結果…
>>126 >>131 から状況は何も変わっていないwwww

Blazorはなんにもない。
なんにもなくて2MBwww

なんにもコンテンツなくて既に全サイト中真ん中のパフォーマンスwwww

さて内容カラッポで2MBwwwここからコンテンツ足したら重くなるのでしょうか軽くなるのでしょうか?wwwww
0175デフォルトの名無しさん
垢版 |
2020/08/05(水) 22:58:40.83ID:ReXZMZda
ウェブブラウザーから派生して、アプリブラウザーというものが出来るなら、Blazorが標準かもしれないんだよな。

そういう未来もあり得るからな。
0176デフォルトの名無しさん
垢版 |
2020/08/05(水) 22:59:21.28ID:ReXZMZda
むしろ、アプリブラウザーが存在しない状態のほうが、不思議に感じるが。
0177デフォルトの名無しさん
垢版 |
2020/08/05(水) 23:00:25.00ID:ReXZMZda
HTMLの代わりにXAMLを標準とするアプリブラウザがあっても良いはずだよな。
0178デフォルトの名無しさん
垢版 |
2020/08/05(水) 23:36:44.84ID:pVYMqErl
そうだな。Silverlightと名付けよう。流行らない理由がない!
0179デフォルトの名無しさん
垢版 |
2020/08/05(水) 23:39:24.63ID:ReXZMZda
Silverlightはフラッシュを意識しててちょっと違うんだよな。
俺たちが欲しいのはそういうものじゃない。
0180デフォルトの名無しさん
垢版 |
2020/08/05(水) 23:40:01.71ID:ReXZMZda
俺たちが欲しかったのはBlazorですよ。
0181デフォルトの名無しさん
垢版 |
2020/08/06(木) 00:13:22.81ID:YI93igBY
ページにはjQuery、アプリにはBlazorという使い分けだろね。

これは良い考え。
0183デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:07:45.39ID:S0Cut7WY
>>174
もうここだけがアンチの希望なんだな
こんなのすぐに最適化されて小さくなる
あっという間にダウンロードできる
2回目からキャッシュされてダウンロード時間ゼロ
ほとんど全員が不快感を感じることなく受け入れられるパフォーマンスだね
0184デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:10:06.47ID:3k5Zhdnk
格安SIMを使ってる人が沢山いる以上、2MBはウェブページにはもちろん、
ウェブアプリにも適さない。
0185デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:12:08.78ID:3k5Zhdnk
>>183
いや、Windows Updateなんかも最悪なのに、OSにWindows以外の選択肢が
実質存在しないのでみんな仕方無しに使ってるだけで、2MBが少ないなんて
ことはない。1.4MBのFDにOSもCコンパイラもゲームも入っていた時代もあるし、
ファミコンゲームなんてもっと小さかったわけだし。
0188デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:20:47.53ID:3k5Zhdnk
>>186
Reactもかなり遅いが、Blazorは、未だに起動できない、全く問題外の遅さ。
こんなに遅いWebページ見たことない。
0189デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:22:57.61ID:3k5Zhdnk
Wasmが本質的にこんなに遅いならまだしも、遥かに起動が速いものもあるから。
0192デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:26:15.47ID:3k5Zhdnk
50秒は待ったが起動できないので、不良品と判断した。
0193デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:26:15.61ID:3k5Zhdnk
50秒は待ったが起動できないので、不良品と判断した。
0194デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:33:17.61ID:WGshixPb
こっちはどっちとも1秒で開くぞ
遅いっていってたのはパソコンの故障が原因だったのか?
人騒がせな
0195デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:36:08.13ID:3k5Zhdnk
>>194
それは、通信環境が速いだけ。
自分が速い環境にいると、遅い環境の事が分からない。
だから、わざと遅い環境で試すことも重要。
0196デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:38:44.73ID:3k5Zhdnk
言っておくが、この環境でも、Yahoo、livedoor、amazon.co.jp、5ch/2ch
などは1秒くらいで開く。
Googleも問題ないし、ほとんどのサイトの閲覧も問題ない。
ReactとBlazorは異常。Reactは、まだ30秒くらい待てば開いたが、
Blazorは50秒は待ったが開かない。
0197デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:41:11.25ID:YI93igBY
楽天はどうだ?
0198デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:42:14.58ID:YI93igBY
Googleのシンプルなトップページが600kb程度だけどな。
0199デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:42:18.30ID:WGshixPb
>>195
ごく普通に一般向けに提供されてる回線だよ
無線だから回線全体から見ればむしろ遅い部類だ
0200デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:45:20.84ID:WGshixPb
つまり帯域制限された後の異常に遅い回線とかだと使用に耐えられないが
普通に使ってる分にはなんの問題もないということか
それがわかっただけでもよかった
遅いという意見は無視してもいい特殊なケースだったということだ
0201デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:45:45.51ID:YI93igBY
Blazorの時代が来てるな。

キチガイアンチの湧き具合で判断できる。
0202デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:46:47.63ID:YI93igBY
楽天のトップページが20mbあるんだよ。
2mb程度で重い言うても仕方ないだろ。
アプリなんだから。
0203デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:47:13.14ID:3k5Zhdnk
>>197
楽天の場合、上の方の検索ボックスが数秒後に表示され、しばらくすると、
下の方の画像以外の枠類が表示されてきて、なんとなく「待てる」。

>>198
キャッシュが全く無い状態からでも、600KBと6秒程度で表示できるのでなんとかなる。
OSを最初に使い始めたとき以外には、Googleのページはキャッシュに乗っているので
遅さを感じない。
0205デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:50:42.30ID:YI93igBY
いや、これは完全に来てる。
0206デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:51:15.94ID:Zl4XeqTl
https://www.rakuten.co.jp/

これか
Blazor、Reactのデモより遅いじゃん
でもみんななんとも思わず普通に使ってるんだろ
SPAの初回負荷はユーザー目線ではそんなに気にならないってことだな
0207デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:52:20.80ID:3k5Zhdnk
>>202
個人的には楽天は大嫌いで、ほとんど使ったことが無い。
ごちゃごちゃして、めちゃくちゃ使いにくい店に感じる。
文字の大きさがめちゃくちゃで、落書きみたいだ。
0208デフォルトの名無しさん
垢版 |
2020/08/06(木) 02:54:53.12ID:3k5Zhdnk
>>206
いや、実際に遅い回線だと、Blazorの方がずっと遅いぞ。
Blazorは、全く表示されずにグルグルが回っているだけで全く使い物にならないが、
楽天は、まだ、5秒後くらいに検索ボックスが使える状態になり、しばらくすれば、
なんとなくサイトの構造が見える状態になるから、まだ、操作も出来そうだし、
心理的にも待てる。
Blazorは、何にも出来ない状態で数分間待たされることになるので、役に立たない。
0209デフォルトの名無しさん
垢版 |
2020/08/06(木) 03:09:47.08ID:Zl4XeqTl
>>208
極端に遅い回線ではそういうことも稀にあるんだろうね
SPAってそういう回線で使うようなものじゃないから気にしなくていいよ
0211デフォルトの名無しさん
垢版 |
2020/08/06(木) 03:12:26.87ID:Zl4XeqTl
一連のレスにより一般的なシチュエーションではなんの問題もなくBlazorが使えることがわかった
楽天のような規模のサイトと比較すると逆に早く表示される場合もあるということがわかった
今日はいい収穫があったね
0212デフォルトの名無しさん
垢版 |
2020/08/06(木) 03:18:09.49ID:3k5Zhdnk
>>211
あんたは実際に遅い環境で試してないから間違ってる。
楽天は、遅い回線でも、現実的にはなんとかなる。
Blazorは、同じ回線でも、全く起動すらしない。
前者では、全部読み込まなくても使える/見える状態になるのに対し、
後者は、全部読み込まなくては、全く文字すら見えないから。
楽天は画像以外は、割と早い段階で見えるのでなんとかなってる。

>>210
アンチが多いものとしてデスクトップのLinuxがあるが、未だに普及できてない。
5ch以外でもBlazorはアンチが多いので、デスクトップLinuxと同じ運命をたどる
かも知れない。
逆に、Rubyは初期のころはアンチが少なく、使っているうちに問題点が見えてきて、
アンチが多くなるにしたがって、シェアも激減した。
だから、アンチが多いことと優れていることの相関は低いどころか、逆相関で、
アンチが多いことは、そのままそれが劣っていると言うことだ。
0214デフォルトの名無しさん
垢版 |
2020/08/06(木) 07:55:49.60ID:Z0IRQC5l
遅い遅い言ってるのって、VisualStudioか何かのスレで、いまだにADSL使ってるくせにアップデートでかすぎ!ユーザのことを考えてない!とか騒いでいた奴と同一人物かも。
0216デフォルトの名無しさん
垢版 |
2020/08/06(木) 08:52:46.83ID:Zl4XeqTl
>>212
一般的にみて比較的遅い回線でためした
結果、なんの問題もなかった
楽天よりデモのほうがはやかった

アンチはお前だけだ
現実を直視しろ
0217デフォルトの名無しさん
垢版 |
2020/08/06(木) 11:33:18.20ID:3k5Zhdnk
じゃあ、あなたの思う普通の人向けをターゲットにして、
貧乏人には見てもらえないページを作ってればいいさ。
それで結果がどうなろうとあなたの自由だ。
0218デフォルトの名無しさん
垢版 |
2020/08/06(木) 11:42:41.08ID:QzF98GH4
極々少数の極細回線を無視してもビジネス的には全く問題ない
逆にサポートするためのコストを考えると無視しないほうがマイナスになりかねない
0219デフォルトの名無しさん
垢版 |
2020/08/06(木) 11:45:09.00ID:3k5Zhdnk
>>218
そうか。
だから、Win10のUpdateも、普通の人々だと数分くらいに済む程度に軽くなって
いるから、世界の普通の人々は何の問題もなく快適に行えており、
MS人気は高止まりだからWindowsは売れ続けているんだよね。
株価もなんといっても、アメリカ3位だし。
0220デフォルトの名無しさん
垢版 |
2020/08/06(木) 11:57:02.63ID:QzF98GH4
「ブラウザなら環境に依存しない」という謳い文句を真に受けて「あらゆる環境をサポートすべきだ」
と考えを飛躍させてしまう初心者は少なくない
しかしこれは全く持って現実的ではない
どんなアプリでも必ずサポート対象範囲は有限にしなければならない
どこまでサポートするかはアプリの特性や客層を分析してアプリごとに最適解を導かなければならない
0221デフォルトの名無しさん
垢版 |
2020/08/06(木) 12:23:55.72ID:3k5Zhdnk
うん。だから、Blazorは、Blazorの遅さを許容できる普通の人々だけを
ターゲットにするから、何の問題もないね。
お前の中ではな!
0222デフォルトの名無しさん
垢版 |
2020/08/06(木) 12:26:23.67ID:QzF98GH4
>>221
そうだね
一般的なレベルの回線を使ってるふつーのユーザーなら2M程度、なんのストレスもないね
これは一般的な感覚だよ
0223デフォルトの名無しさん
垢版 |
2020/08/06(木) 12:27:58.50ID:CNjpcpEJ
深夜と真っ昼間にID真っ赤にして発狂してるお前暇すぎだろ。無職なの?
無職で金がなくて、2MBで発狂してるの?
0224デフォルトの名無しさん
垢版 |
2020/08/06(木) 12:38:04.39ID:YI93igBY
しかしこれは凄いぞ。
C#でデスクトップアプリを書くかの如くウェブアプリが書ける。
0225デフォルトの名無しさん
垢版 |
2020/08/06(木) 12:59:15.34ID:Dywe59yG
まとめると、楽天みたいに重くてゴチャゴチャしたサイトをさらに重くてゴチャゴチャさせたいときに使えるのがblazor ってことか
0226デフォルトの名無しさん
垢版 |
2020/08/06(木) 14:00:03.20ID:QzF98GH4
まとめると、複雑なサイトを高生産、高速動作にしたいときに使えるのがBlazorということだよ
0227デフォルトの名無しさん
垢版 |
2020/08/06(木) 14:31:10.67ID:B2JhCKKC
クライアントサイドはデバッグがむずいんよねー
Mauiでなんか進展あればいいんだけど
0228デフォルトの名無しさん
垢版 |
2020/08/06(木) 14:44:14.38ID:PW5B5ZEe
>>186
そのweb appをひらくまでの時間

Blazorは3秒、Reactは10秒だった
application serverの遅さ、
node.jsの遅さ、どれが原因か不明だが、
Blazor、実用的な速さだよな
0229デフォルトの名無しさん
垢版 |
2020/08/06(木) 14:49:18.78ID:PW5B5ZEe
>>208
どんなクソ回線使ってんだよ
MVNOなかでも低品質なSIMか低速モードだろ

光回線やまともなSIMなら>>186 のBlazorは
3秒以内に開く。
2回目以降はcacheあるから爆速
0230デフォルトの名無しさん
垢版 |
2020/08/06(木) 14:57:22.20ID:Dywe59yG
>>186
このblazorの激遅クソアプリ、
69リクエスト、
7.6MB(圧縮転送6.2MB)、
表示されるまで38.93秒www
その間ポケモンボールみたいなのが白っぺっぺの画面上でグールグル(^-^;)
なーんにも表示されないww
なーんにも操作できないwww
何このゴミwwwww
0232デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:03:37.94ID:Dywe59yG
>>230 とまったく同じ環境で今度は >>186 のreactのほうを開く。
15リクエスト、
3.0MB(圧縮転送809kB)、
表示されるまで10.35秒
0233デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:06:58.59ID:Dywe59yG
>>230>>232によるまとめ

ブレカスはReactに比べ、
8 倍 の転送帯域を消費し、
表示までに 4 倍 の時間がかかるwww
ファーwwwww
0234デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:09:49.76ID:buA5WS3+
wasmって圧縮効かねえのな。
ま、そりゃそうか…
0235デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:12:14.29ID:QzF98GH4
何倍というと大げさに聞こえるが
一般的なレベルの回線ではどちらも体感であっという間におわるので無視していい差でしかない
巨人からみたらアリの大小なぞ見分けがつかないということだね
0236デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:12:45.98ID:Dywe59yG
最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。


4倍ならまだマシなほうだなwww
0237デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:14:08.96ID:QzF98GH4
しかも提示されたデモサイト内容はBlazorのほうが複雑だ
ハンディキャップありでほとんど体感できる差がないというのはBlazorの優秀さの証明である
0238デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:14:59.64ID:QzF98GH4
>>236
JSユーザーを哀れんで言ってるだけ
実際にはBlazorはまあまあ速い
そしてこれからもっと速くなる
0239デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:24:03.21ID:PW5B5ZEe
>>231
ADSLはそこまで遅くないだろう
ゴミみたいなMVNO SIMでテザリングしてるんじゃないかな

>>233
その遅すぎなハードウェアと回線を書いてみろ
Speedtestの結果もな
0240デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:24:44.76ID:Dywe59yG
>>186
環境を合わせた客観的評価のため、両者のlighthouseスコアを取ってみた。

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

Reactのデモ
http://react-spa-demo.herokuapp.com/
のlighthouse結果:
https://lighthouse-metrics.com/one-time-tests/5f2ba0374e51450009eff8d2

Blazorこんな酷い点数初めて見たwwwww
0241デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:30:04.93ID:buA5WS3+
>>240
フィルムストリップがポケモンボールで埋まっててワロタw

しかしGoogleのスピードアップデートを控える今、こんな体たらくでは誰も使わないだろうね。
さすがにパフォーマンス23点ではスピードアップデート後は検索に出てこなくなるだろう。
0242デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:45:48.96ID:PW5B5ZEe
lighthouseってあんまり信用できないだろ
楽天市場で試すと
遅すぎて半分以上が測定不能になってる
0243デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:50:20.19ID:Dywe59yG
信用しないならそれでもいいけどGoogleのスピードアップデートの指標に採用されてるから低いとGoogle八分にされるねw
Bingで頑張ってねw
0244デフォルトの名無しさん
垢版 |
2020/08/06(木) 15:52:03.23ID:buA5WS3+
こうやってMS製品に囲われていくのね…
0246デフォルトの名無しさん
垢版 |
2020/08/06(木) 16:01:41.13ID:NJ3rQ1gR
こういう計測サービスって最も重要なユーザーの体感速度を全く考慮してないから参考にもならんよ
実際に目で見るとBlazorはすぐに表示されてるんだからなんの問題もない
0247デフォルトの名無しさん
垢版 |
2020/08/06(木) 16:04:26.37ID:Dywe59yG
Blazor教とでも言いましょうかwww
0248デフォルトの名無しさん
垢版 |
2020/08/06(木) 16:06:13.83ID:3k5Zhdnk
>>232
圧縮後のバイト数で考えれば、Blazorが、38.9秒というのはむしろ速すぎで、
75秒くらいになってもおかしくない。

>>229
光回線で3秒と言うのは、使い物にならないほど遅いことを意味する。
0249デフォルトの名無しさん
垢版 |
2020/08/06(木) 17:58:43.22ID:Q3sPU8QA
もうキチガイは相手しない方がいいんじゃないの
時間の無駄

.net 使えないのが悔しいとかそんなんだろ
あほくさ
0250デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:15:10.53ID:PW5B5ZEe
>>245
lighthouseで楽天市場、計測不能だよなw?

>>246
lighthouseは実態とかけ離れてるね
かなり昔のスマートフォンの性能を前提に計算してるのかも

>>244
wasmはweb standardだし
C#も .NETもオープンソース
囲い込みとか関係ない
0251デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:21:08.91ID:Dywe59yG
現実
>>230
>>232

Lighthouse
>>240

まったくかけ離れてない。むしろ甘いくらい。
0252デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:24:47.43ID:3k5Zhdnk
実際に、この環境では、楽天の方がBlazorのデモより早く開く。
さらに、amazonはもっとずっと早く開く。
これは、Blazorを貶めるために嘘を言っているとかではなく、本当の話。
事実だ。
0253デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:25:02.49ID:NJXhghnv
アンチが必死になる気持ちもわからないでもない
フロントJSに一点集中して必死に勉強して、JS好きじゃない(苦手とは言ってない)バックエンドエンジニアにマウントをとろうとするフロントエンドエンジニアは少なくない
けどC#でバックエンドエンジニアがフロントもストレスなく開発できるようになったら、非生産的なJSはすぐに用済みとなる
必死に学んできた知識は無価値となり、フロントエンジニアの市場価値が大暴落する可能性が高い
彼らが生き残る為にはBlazorが普及してしまう前に難癖つけて、フォーラムを荒らし回って、流行る前に潰さなきゃならない
まあアンチの考えは、だいたいこんなところだろう
0254デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:28:52.63ID:Dywe59yG
別に必死にならなくても勝手に気付いたら死んでるだろww
SilverlightもXamarinもそうだったwww
俺は貶してるんじゃなくて、客観的事実書いてるだけ。
信者にとっては事実がアンチwww
でもそれがBlazorなんだよねwwww
0255デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:30:37.19ID:NJXhghnv
客観性ゼロのアンチしつけー
まあ消えるのも時間の問題だ
断末魔の叫びと思えば多少は許せるかな
0256デフォルトの名無しさん
垢版 |
2020/08/06(木) 18:33:43.69ID:Z0IRQC5l
>>252
遅いと騒いでるのがお前の環境での話だけで、お前の環境なんてみんなどうでもいいと思ってるというのも、また本当の話。
0259デフォルトの名無しさん
垢版 |
2020/08/06(木) 19:16:23.92ID:w37A/f7u
ID:3k5Zhdnk
ID:Dywe59yG
普通の人が仕事してる時間に発狂する200kbps回線の無職。
スレ立て荒らしもやらかしてるキチガイですね。
0260デフォルトの名無しさん
垢版 |
2020/08/06(木) 19:21:28.18ID:Dywe59yG
ID:QzF98GH4 ID:PW5B5ZEe のことかな?平日昼間からお暇なことでwww

>>259
おやぁ?単発なのはもしかしてwwww
0261デフォルトの名無しさん
垢版 |
2020/08/06(木) 20:08:56.58ID:YOMmAvu6
アンチニート暴れすぎだろ
専用のアンチスレ立ててそっちで思う存分やれって
0263デフォルトの名無しさん
垢版 |
2020/08/06(木) 21:23:10.95ID:PW5B5ZEe
デモサイトみてBlazorが問題ないスピードっていう認識の
人は増えた感じだな
まだ批判してるのは200kbpsおじだけ
0266デフォルトの名無しさん
垢版 |
2020/08/06(木) 23:33:09.91ID:YI93igBY
ウェブサイトはjQuery、ウェブアプリはBlazorという住み分けが出来てくるのでは。
0267デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:15:39.12ID:ts5R835r
>>264
阿部寛サイトは今は亡きフレームタグ(iframeじゃないぞ)使ってるからだろうな。
これは昔からあるサイトだからいいけど今から作るサイトでフレームタグなんて使ってたらグーグルにガン無視喰らうだろう。
0269デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:35:00.10ID:mqghv/47
怪しかろうがGoogleはパフォーマンスアップデートでLighthouseの値を使ってサイトをランク付けする。
0270デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:49:20.23ID:DPYPUDuy
そもそもアプリだからグーグルのランクは関係ないのでは。
0271デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:50:44.50ID:mqghv/47
Googleからの流入を期待しないのであればそれでいいと思うよ。
0272デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:54:30.17ID:ZSkLfYsp
高ランクとれるサイトからアプリに誘導するからアプリ自体のランクはどうでもいい
こういった常識を知らないのだろうね
0273デフォルトの名無しさん
垢版 |
2020/08/07(金) 00:57:00.97ID:DPYPUDuy
そもそも、アプリに流入というのが少々キチガイっぽい。
0274デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:03:41.81ID:ts5R835r
主張がコロコロ変わるんだよな。
今は、アプリなんだから激重・激遅で何の問題ないだろ!って主張?
それならいんじゃね?
今後変えんなよw
0276デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:10:28.54ID:ts5R835r
ああじゃあ軽快というのは嘘だからBlazorは誇大広告フレームワーク、信者は嘘吐きだな。
0278デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:15:56.56ID:DPYPUDuy
楽天のウェブサイトがトップページ20MBの時代に、アプリが2MBというのは、軽量な部類に入るはずだけど。
入力欄一つのグーグルのトップページですら600KBあるのに。
0279デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:40:03.24ID:ts5R835r
写真コンテンツテンコ盛りの楽天と違って、
コンテンツなーんにも無しのガワだけBlazorで2MB
ショボいメニュー付いた >>186 のBlazorで7.5MB
これに楽天並みの写真コンテンツ載せたらどうなっちゃうのwww
表示までに日が暮れそうwwww
0280デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:55:53.05ID:0IZ7x6pd
>>278
そもそも、楽天を実際に使う場合、トップページからではなく、
Googleで商品を検索してたままた楽天にたどり着くので、
トップページの遅さは関係ない。
0281デフォルトの名無しさん
垢版 |
2020/08/07(金) 01:57:29.33ID:0IZ7x6pd
それに、楽天は苦戦中で、amazonよりずっと使用者数が少ないと聞いている。
楽天のページは、表示し終わるまでに閉じる。
0282デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:00:55.12ID:DPYPUDuy
しかし、既存フレームワークがこれだけビビってるところを見ると、ルールそのものを変える可能性があるのでは?

アンチの湧き具合から、大きな可能性が見える。
0283デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:08:52.33ID:0IZ7x6pd
>>282
ルールを変えるのはWasmそのものであって、Blazorではない。
Wasmは、Blazorの占有物ではない。
0284デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:09:41.65ID:ts5R835r
アンチではなく、事実を書いてるだけ。
Blazorが激重・激遅という事実を。
信者にとっちゃ事実はアンチらしいw
0285デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:25:43.00ID:DPYPUDuy
そりゃ「こんなものウェブサイトには使えないぜ!!」と延々と主張するのは、アンチでは?
0286デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:28:32.59ID:DPYPUDuy
グーグルのランクが云々言ってるようでは、おそらくMicrosoftに追い付くのは難しい。
まともなウェブアプリを提供できているのは、事実上Microsoftだけに見える。
0287デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:45:55.74ID:0IZ7x6pd
>>286
何言ってるの?
Blazorのデモは、「まともな」でも「提供」でもない。
一方、Wasmには、Qtのデモ、AutodeskのCADのデモなどで、ウェブアプリのデモがある。
ウェブアプリ全般としては、HTML5ゲームがある。
0288デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:49:42.96ID:DPYPUDuy
ビビッドアーミーをグーグルで測定するとどうなるかやってみろ。
0289デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:50:57.31ID:0IZ7x6pd
>>285
最初から貶すのが目的で決め付けてかかるのが「アンチ」。
実験した事実に基づいて非難するのは科学的批判。
0290デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:52:07.92ID:DPYPUDuy
じゃあやっぱりアンチだろ。
0291デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:53:08.02ID:0IZ7x6pd
>>288
Blazorは、ビビッドアーミーのレベルには全く達してない。
他のやり方では100KBも必要ないようなものでも、2〜7.5MBも必要となる。
0292デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:54:27.92ID:DPYPUDuy
ビビッドアーミーは1GBあるぞ。
0293デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:55:15.25ID:0IZ7x6pd
>>290
科学的実験が出来ていると思いこんでいる人と、本当に出来ている人の違いだ。
アメリカのIT企業は、客観的評価をすれば、どこも技術力は低い。
騙された馬鹿な女子高生がiPhoneを買いまくっている。
Win95もそうだった。
0294デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:57:07.93ID:0IZ7x6pd
>>292
そんなにはない。
それだと、遅い環境では初回起動するのに三時間くらいかかるはずだが、実際には、
10分程度だった。
0295デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:59:11.50ID:DPYPUDuy
10分かけてゲーム起動する人は居ないんだよ。
おまえに合わせて製造してたら会社がつぶれる。

つまり、おまえの意見なぞきくだけ無駄。
0296デフォルトの名無しさん
垢版 |
2020/08/07(金) 02:59:45.95ID:ts5R835r
ついにビビッドアーミーと戦いだしたBlazor信者www
0297デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:01:45.25ID:DPYPUDuy
>>296
俺の考えではビビッドアーミーをはじめとする中国のH5アプリは本質をつかんでいる。
もちろんMicrosoftのウェブアプリも。

日本勢はちょっと駄目だな。
ユーザー目線が無いから。
0298デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:03:01.94ID:DPYPUDuy
SSRなんて最悪の事態だからな。
「SSRしてしまいましたか」
「やっちゃいましたね」
「反省してます」
これが本来の姿なんだけどな。
0299デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:05:23.90ID:DPYPUDuy
俺は中国に学べと何度も言ってるはずだが。

中国は凄いぞ。

俺たちより10年先を行ってる。
0300デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:06:25.14ID:ts5R835r
Amazon→楽天→ビビッドアーミーwww
Blazor信者の藁人形は一体どこまで後退していくのかwwww
0301デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:08:16.61ID:DPYPUDuy
中国のビビッドアーミーを馬鹿にしてるが、日本勢がこれを製造するのは無理だぞ。
0302デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:09:28.06ID:DPYPUDuy
Blazorを使えば、中国勢と同じようなものが作れる。

これは日本にとって朗報だ。
0305デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:15:57.24ID:DPYPUDuy
Blazorはビビッドアーミーのようなアプリを作るためのもの。
ウェブサイトを作るものではない。

ここが理解できていないのが、日本人のダメなところ。

これでは世界で戦えない。
中国人に教えを請うべき。
0306デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:20:06.85ID:DPYPUDuy
MicrosoftのGithubが開発したElectronというものがあるのだが。
0307デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:21:03.19ID:DPYPUDuy
MicrosoftのGithubがBlazorionを作る可能性もある。
0308デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:27:33.08ID:DPYPUDuy
まあビビッドアーミーなんてMixiの農業と大して変わらんシステムだけどな。

Mixiの農業も中国だったな。
0310デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:38:54.53ID:DPYPUDuy
全世界に8カ所あるMSRのうち2箇所が中国にある。
日本には一つも無い。

なぜか?
本質を理解するものが日本には存在しないからだ。
0311デフォルトの名無しさん
垢版 |
2020/08/07(金) 03:39:57.93ID:DPYPUDuy
Blazorを見て、グーグルの点数などと言い出す始末。

これじゃ日本が見捨てられたのも納得。
0313デフォルトの名無しさん
垢版 |
2020/08/07(金) 04:19:30.98ID:DPYPUDuy
>>312
わからないならそれまでだろ。
0314デフォルトの名無しさん
垢版 |
2020/08/07(金) 06:25:02.46ID:DPYPUDuy
わざわざ完全論破されにやってきて何がしたいんだコイツラ。
0315デフォルトの名無しさん
垢版 |
2020/08/07(金) 07:44:56.56ID:aE46K+QX
ReactなんかのSPAフレームワークに乗り遅れた人が、Blazorを先取りすれば
上に立てると勘違いしてるんだろう。
他の人はBlazorが使い物になったらキャッチアップするだけ。
0317デフォルトの名無しさん
垢版 |
2020/08/07(金) 09:20:30.97ID:H4iYPSAO
ヤフーでひどいことになってる。
他人の個人情報が見れたり、他人のデータが書き換わる事態

https://www.asahi.com/amp/articles/ASN86721MN86ULFA02Z.html
https://about.yahoo.co.jp/pr/release/2020/08/06b/

Wappalyzerで検出するとヤフーの登録情報変更のページは
Vue, Nuxt, node.jsを使っているようだが
おまえらはどういうバグだと推測する?
0318デフォルトの名無しさん
垢版 |
2020/08/07(金) 09:38:48.94ID:xwYl4FUW
BlazorはC#とVisualStudio(or Code)でフロント系スキルが低い非フロント専門職でもリッチなフロントを安く作れる
それで浮いた金をバックエンドに投資できるからその分だけセキュリティ事故も減るだろうね
まあバックエンドに金かければ確実に事故を防げるというわけでもないが確率は減らせるだろう
0319デフォルトの名無しさん
垢版 |
2020/08/07(金) 10:24:49.82ID:fkN1xMt5
>>317
常識的に考えて純粋にバックエンドの問題だろう
さすがにそんな事故はフロントエンドがどれだけバグってようが改竄されようが発生しないように作るものだ
むしろフロントエンドが関係あると思ってる君もかなりヤバいから人を笑う前に気をつけたほうがいい
0320デフォルトの名無しさん
垢版 |
2020/08/07(金) 10:52:28.88ID:H4iYPSAO
>>319
フロントとバックの境界ははっきりしていないし
フロントエンド担当者の問題でなければいいと
考えてるおまえのがレベル低いだろう。
そういうバックエンドの知識がないフロントが関与してるからこういう不具合が起こる。
0321デフォルトの名無しさん
垢版 |
2020/08/07(金) 10:59:09.74ID:xwYl4FUW
>>319
フロントエンドのコストが高いからバックエンドへの投資が減ってセキュリティがおろそかになったんじゃないの?
資金は有限だからフロントエンドのコストが増えるほどバックエンドに使える費用が減るのは自明ではないかな
あと1人日でもバックエンドへの投資を増やしてレビューとテストを増やしていれば起こらなかった事故かもしれない
0322デフォルトの名無しさん
垢版 |
2020/08/07(金) 11:59:29.42ID:DPYPUDuy
結局、アンチのおかげでBlazorの素晴らしさが理論づけられたな。

アンチもたまには役に立つ。

しかし、何がしたかったんだコイツラ。
叩かれるのが好きなのか?
0323デフォルトの名無しさん
垢版 |
2020/08/07(金) 12:05:57.36ID:UPopDVdK
まあそうだな
アンチも含めスレがこれだけ勢いよく伸びてるのはBlazorに関心のある人が多いってことだし
いまはまだアンチの人もBlazorに興味は持ってるわけだ
0324デフォルトの名無しさん
垢版 |
2020/08/07(金) 12:21:38.09ID:DPYPUDuy
アンチのフリしたステマじゃないだろうな。
0325デフォルトの名無しさん
垢版 |
2020/08/07(金) 12:40:18.99ID:xwYl4FUW
アンチも内心で焦りがあるんだろうな
JSがオワコンになったら乗り換えないと仕事がなくなる
自分達の生活を脅かす新技術に憤りを示すと同時に
、迎合して自分を変えなきゃならないという事も頭では理解してる
その葛藤を5chで喚き散らしてどうにか発散しようともがいてる
0326デフォルトの名無しさん
垢版 |
2020/08/07(金) 12:46:56.38ID:xwYl4FUW
革命的な技術の黎明期ってのはいつもこうなんだ
クラウドが現れた時のインフラ技術者とかも同じだね
0327デフォルトの名無しさん
垢版 |
2020/08/07(金) 13:06:25.05ID:DPYPUDuy
>>321 なんか見ても、HTMLエンジニアのコストが高いとか書いてるし。
そんなもん時給1000円で良いだろ。
0328デフォルトの名無しさん
垢版 |
2020/08/07(金) 13:24:54.57ID:DPYPUDuy
HTMLエンジニアなんてむしろこっちが金貰いたいくらいだ。
0329デフォルトの名無しさん
垢版 |
2020/08/07(金) 13:37:59.61ID:WWExzNx7
セッション情報の共有について全然出てこないんだけどさ
認証を使った場合って、Blazorの機能としてクラスタリングには対応してないの?
0331デフォルトの名無しさん
垢版 |
2020/08/07(金) 14:24:20.24ID:LzLmm+cl
ロードバランサやらフェールオーバーやらでサーバー切り替わったときに
セッション引き継ぎたいとかそういうやつだろ
0332デフォルトの名無しさん
垢版 |
2020/08/07(金) 14:31:53.44ID:DPYPUDuy
それはそもそもウェブサイトなんだろうなあ。
0333デフォルトの名無しさん
垢版 |
2020/08/07(金) 14:33:10.39ID:DPYPUDuy
ユーザーの立場で言わせてもらうと、ウェブサイトのアプリ化は、イラっとするだけでメリットなにも無いからな。
0334デフォルトの名無しさん
垢版 |
2020/08/07(金) 14:34:28.09ID:DPYPUDuy
グーグルのランキング云々言ってるのは、ウェブサイトだからよ。
ホームページエンジニアは間抜けしかいないのか。
0335デフォルトの名無しさん
垢版 |
2020/08/07(金) 16:55:24.32ID:xwYl4FUW
>>329
それはフロントエンドじゃなくてAPIサーバーの責務
APIサーバー側で暗号化プロバイダのキーファイルを同じものにすればいい
React、Vueも同じこと
0336デフォルトの名無しさん
垢版 |
2020/08/07(金) 20:27:29.93ID:aE46K+QX
>>325
そうなったらそうなってから乗り換えりゃいいだけの話だと思うが、なんでそんな発想になるのか不思議。
フレームワークを1つしか使えない縛りがあるのか、それともは頭のキャパがそれしかないのかね。
0337デフォルトの名無しさん
垢版 |
2020/08/07(金) 21:24:13.18ID:e87DFkxv
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もつけると何故か連動するようになる
どういう仕組みで動いてんだこれ
0338デフォルトの名無しさん
垢版 |
2020/08/08(土) 00:10:44.92ID:hEengG0x
>>337
俺は分からんがILSpyで見てみたら?
0344デフォルトの名無しさん
垢版 |
2020/08/08(土) 09:55:50.82ID:f+HIJ1ud
プレゼンテーションがRazorのうちは、ロジックをC#で書けるだけじゃそんなに美味しくないよなぁ。
早いところWPF/MVVM実現してもらいたいところ。
0346デフォルトの名無しさん
垢版 |
2020/08/08(土) 10:44:10.28ID:yLRwfWOD
Razorはシンプルで使いやすいとおもうがな
WPFは記述量が多くなりがちですきじゃない

テンプレートエンジンの是非は置いておいて
JSからC#に移行できるだけでもありがたい
特にValidationが共通化できるから凄い楽になった
0348デフォルトの名無しさん
垢版 |
2020/08/08(土) 11:38:10.03ID:noFfmCPy
>>317
リリース後にテストしてればすぐ発覚したのにな
客が使い始めて何時間も経ってから客からの報告で気付くとか情けない
システム設計とか管理職のバグやろ
0350デフォルトの名無しさん
垢版 |
2020/08/08(土) 11:49:36.15ID:noFfmCPy
>>317
>6.再発防止策
>再発防止策として「実際のアクセス規模などを想定した事前検証の強化」「問題の早期発見に向けたシステムの監視強化」などを行なってまいります。

これが原因のヒントになってると考えると
ID重複とか初歩的なミスっぽいな
64bitのデータを32bitの変数に描き込んだとかもあり得るな
0352デフォルトの名無しさん
垢版 |
2020/08/08(土) 13:54:07.65ID:yLRwfWOD
サーバーサイドのバリデーションを忘れたってミスで大事なデータ壊す事故は信じられないがたまにあるらしい

なんでそうなるかというと

・フロントエンドでバリデーションを書いたからサーバーサイドは要らないとおもった
・バリデーションを別の言語で2回も実装するだけの工賃をもらってない

ということなんだそうだ

BlazorならバリデーションをC#コードで共通化できるので
追加の工数なしにバリデーションの多重化ができるようになるので
バリデーション不足が原因のセキュリティ事故が減ると期待できる

何よりもまず安全でメンテナンスしやすいシステムを作ることが大事だ
その上でパフォーマンスはじっくり改善していけばいい
Blazorはそんな堅実な開発スタイルによく合う
0353デフォルトの名無しさん
垢版 |
2020/08/08(土) 18:10:35.58ID:mkOodFIn
>>352
client sideでは改ざんできるからserver sideでのvalidationは
必須に決まってるのにそんな主張するアホ会社があるんだな

Blazorの前のASP.NET MVCのころから
validationとかdata bindingはめちゃくちゃ楽で良くできてると思うわ
0354デフォルトの名無しさん
垢版 |
2020/08/10(月) 00:25:31.81ID:phEjuxr2
WebAssembly版のBlazorはそろそろ使いもんになってきたの?
スマホ対応も考えた場合
0355デフォルトの名無しさん
垢版 |
2020/08/10(月) 00:43:18.94ID:2j6ruGmJ
>>354
今はまだダメだ
.NET Core 5 まで待て
その時点でダメだったらもう見込み無い
0357デフォルトの名無しさん
垢版 |
2020/08/10(月) 00:47:41.67ID:lJp+wmfa
23点www
0361デフォルトの名無しさん
垢版 |
2020/08/12(水) 18:07:41.59ID:5K5oOtYu
WPFならViewModelを普通にユニットテストするだけでいい
しかしBlazorだとどうすればいい?

@codeブロックに書いたコードをユニットテストしたい
WASMでxUnitって動くのか…?
Seleniumを使えばテストはできそうだけど量が多くて大変だ

Reactではコンポーネントのユニットテストどうやってんだろ
0362デフォルトの名無しさん
垢版 |
2020/08/12(水) 21:06:48.85ID:q4xTlvo3
Reactのコンポーネントは単なる関数だから普通にユニットテストすればいい。
好きなテスティングフレームワーク使えばいいけど人気なのはJest + React-testing-libraryの組み合わせかな。
Blazorは俺も知らん。
0363デフォルトの名無しさん
垢版 |
2020/08/12(水) 21:35:02.58ID:ZXfBm5lP
>>361
Code BehindとかPartial ClassつかえばViewModelみたいなもんだから普通にテストできる
0367デフォルトの名無しさん
垢版 |
2020/08/13(木) 14:16:19.59ID:nWdcBay4
ほっときゃそのうち速くなるよ
.NETコミュニティはパフォーマンスにはうるさいから
0368デフォルトの名無しさん
垢版 |
2020/08/13(木) 14:59:22.07ID:t3ZZI+Wm
探したらbUnitというのはあるようだが
しかしこれも結局は開発マシンのランタイムで実行してんだろ?
wasmでテストしたいんだが
0375◆QZaw55cn4c
垢版 |
2020/08/13(木) 19:17:44.60ID:P/jo0Y4p
>>374
でも Windows 自身は C/C++ なんでしょ?
0376デフォルトの名無しさん
垢版 |
2020/08/13(木) 19:28:38.86ID:fIst59ZG
>>375
コンパイラが対応してないから途中でC++に自動変換されるだけの話
開発してる言語は実質的にC#だ
おまえのロジックでいうとC/C++もだめでマシン語以外不可になる

プログラマーが書く言語がC#ならそれでいい
0378◆QZaw55cn4c
垢版 |
2020/08/13(木) 19:59:54.96ID:P/jo0Y4p
>>376
>コンパイラが対応してないから途中でC++に自動変換
???
意味不明ですね
C# から C++ に変換?どういう意味ですか?
0383◆QZaw55cn4c
垢版 |
2020/08/13(木) 20:40:38.29ID:P/jo0Y4p
>>380
cs2cpp、そんな便利なトランスレータがあったら欲しいですね‥‥
0385デフォルトの名無しさん
垢版 |
2020/08/13(木) 20:59:39.34ID:NfsR0Ozp
マイクロソフトの主力製品はいまだにC++
Windows、Office、Visual Studio、・・・
Visual Studioはたしかに遅いとこあるな
いまだに32ビットプロセスのままでメモリ節約に四苦八苦してるので

SQL ServerのGUI(Management Studio)が.NETで作られてるっぽかったけど遅いね
0388◆QZaw55cn4c
垢版 |
2020/08/13(木) 22:02:24.29ID:P/jo0Y4p
>>380
C# はガベージコレクタを内蔵していますが、C++ には GC はない
いったいどうしているのですか?
0390デフォルトの名無しさん
垢版 |
2020/08/14(金) 00:59:35.70ID:iHOfggUW
>>387-388
OSSでもC#からC++に変換するものはある。
もっと洗練されたものをMSが自社開発してても不思議はないだろ。
C#作ったのもMSだし、MSには天才エンジニアがたくさんいる。
0391◆QZaw55cn4c
垢版 |
2020/08/14(金) 01:07:04.54ID:txNZsWd8
>>390
>OSSでもC#からC++に変換するものはある。
恥ずかしながら聞いたことがありません
よろしければ github のレポジトリを教えてください
0393◆QZaw55cn4c
垢版 |
2020/08/14(金) 01:36:14.92ID:txNZsWd8
>>392
検索しても出てきませんでした
検索キーワードのヒントを教えてください
0397デフォルトの名無しさん
垢版 |
2020/08/14(金) 11:08:10.33ID:NBYQVIjm
blazorよりxamarinの方が良くねえか?
てか統一してくれるとC#使いとしては有り難いんだけど
0399デフォルトの名無しさん
垢版 |
2020/08/14(金) 12:12:33.73ID:USzXHOg9
いまspy++で調べた
まじで Visual Studioが.NETになっとる
Microsoft.VisualStudio.PlatformUIという.NETアセンブリが使われてた
こらがWPF上に構築されてるのかはよく分からんかった
プロパティウィンドウなど一部にはWinFormsも使われてるっぽいな
0402デフォルトの名無しさん
垢版 |
2020/08/14(金) 12:17:16.40ID:970Aew80
>>400
2005でも使ってたんじゃない?
2010でいきなり重くなって、2015まで次々に悪化。2017、2019で逆に軽くなってきているように感じるね。
0403デフォルトの名無しさん
垢版 |
2020/08/14(金) 12:39:06.50ID:A3xYyH1g
VS 2019は、Core i5 3.4GHz (4 cores)だとどのくらいで起動しますか?
当方は、もっと力の弱いCPUを使っており、デスクトップアイコンをクリックしてから、
IDEが起動し、マウスカーソルがくるくる回る状態から脱するのに、23秒くらいかかり
ます。
0405デフォルトの名無しさん
垢版 |
2020/08/14(金) 13:16:11.33ID:iHOfggUW
>>403
CPUは型番で書かないと伝わらない
似たような名前でも世代とかモバイルとか省電力版とか種類がたくさんある

23秒ってHDDじゃないか?
IDE起動はランダムアクセス重要だからSSDは必須。SSDなら数秒
0406デフォルトの名無しさん
垢版 |
2020/08/14(金) 13:19:58.33ID:iHOfggUW
WPFは凝ったUI作れるしいいだろう

>>397
Xamarinは廃止されてMAUIに変わるの確定してる。
BlazorもMAUIに統合されるという噂もある
0411デフォルトの名無しさん
垢版 |
2020/08/14(金) 14:12:14.64ID:A3xYyH1g
>>405
LGA1155, SSD 500B, Memory: 4GB x 2枚挿し、
の Core i5 3.4GHz
だとVS 2019の起動速度はどれくらいでしょう?
CPU以外は同じ環境で、現在、実測すると 23秒でした。
0413デフォルトの名無しさん
垢版 |
2020/08/14(金) 14:29:50.43ID:iHOfggUW
>>410
同じBlazorが他の開発製品とだぶって存在するようになるのはありえない

MAUIでBlazorがサポートされるってのはBlazorの位置づけが
変わることを意味する。
MAUIの範囲の一部になるってことだ
統合という表現が不適切とは思わない
0417デフォルトの名無しさん
垢版 |
2020/08/14(金) 17:44:24.03ID:iHOfggUW
>>414-415
アホ発言禁止
それはありえない。native appからwasmに変更なら劣化するだけだ

>>416
>>408でわざわざURL探してやったのに感謝のひとこともないのかよ
いつからそんなカス人間になった
0418デフォルトの名無しさん
垢版 |
2020/08/14(金) 17:46:20.29ID:sgFs/qSh
散々イキっておいてMAUIに統合とかワロタwww
はい泡沫局所技術終了w
MAUIスレ立ててそこで壮大な話ししようぜw
0419デフォルトの名無しさん
垢版 |
2020/08/14(金) 17:55:28.02ID:iHOfggUW
>>418
バカすぎだろ
MAUIに入るってことは位置づけが上になるってことだ。
ブラウザ用のnative appの代表としてBlazorが入ることになる

今はASP.NET Coreのたくさんある技術のひとつでしかない。
0420デフォルトの名無しさん
垢版 |
2020/08/14(金) 17:59:31.32ID:DBriI1p6
たしかにMAUIでマルチプラットフォームアプリ作ればブラウザでも動くようになるってことだもんな
実現したらすごいけどホントにできるんかな?
0421デフォルトの名無しさん
垢版 |
2020/08/14(金) 18:04:25.09ID:iHOfggUW
MAUIでBlazorが使えるようになると
Android, iPhone appなどと共通コードベースで
Web appを開発できるようになるってことだ

おそらくAndroidやiPhone, Windows appで成功した後だと思うが
実現したらすごいことがおこる
開発は楽になりそうだがエンジニアの案件、仕事が急激に減りそうでこわい
生産性があがりすぎてしまう
0422デフォルトの名無しさん
垢版 |
2020/08/14(金) 18:08:46.90ID:sgFs/qSh
日本の話題扱うのに「岡山県」ってスレでやるか?って話。
MAUIのいちパーツの分際で身の程をわきまえろよwww
0424デフォルトの名無しさん
垢版 |
2020/08/14(金) 18:40:34.87ID:RiCFkycp
>>420
もうすでにUnoがデスクトップ、スマホ、ブラウザで動作するクロスプラットフォームXAMLエンジン実装してるよ
MAUIでUnoを吸収するのか新しく作り直すのかは知らんが技術的には楽勝ムード

BlazorはBlazorで生き残ると思う
MAUIがwasmサポートしても十中八九XAMLだからHTML/CSSフレンドリではない
HTML/CSSを使いたいって需要は確実にある
0426デフォルトの名無しさん
垢版 |
2020/08/14(金) 20:27:26.43ID:DBriI1p6
>>424
HTML/CSS使いたいというのはWebアプリ屋の発想じゃない?
XAMLで普通にアプリ作ってそれがそのままブラウザで動くならそのほうがいいよ
だってマルチプラットフォームアプリだよ?
ブラウザで動かすときだけHTML/CSSで細かく制御したいなんて思わないよ
0428デフォルトの名無しさん
垢版 |
2020/08/14(金) 22:01:52.41ID:0frcuPYu
MAUIはXamarinの後継であってBlazorとは交点ないでしょ
0429デフォルトの名無しさん
垢版 |
2020/08/14(金) 23:14:28.35ID:iHOfggUW
>>428
BlazorはMAUI陣営に入る可能性あり
Browserで動くnative appなんだからおかしくない
>>408

Blazor Serverはnative appじゃないし
Blazor Serverはどうなるかよくわからないがね
0430デフォルトの名無しさん
垢版 |
2020/08/14(金) 23:23:30.75ID:iHOfggUW
>>426
web appはHTML+CSSがめんどくさすぎ、さらにJSがめんどくさい。

GUIはwindows appみたいにコントロール張り付けて開発したい
0431デフォルトの名無しさん
垢版 |
2020/08/14(金) 23:29:58.30ID:0frcuPYu
> 将来的には Blazor(Web)のサポートも計画されているようです。

この一文をもって鬼の首を取ったような騒ぎをしているけど
qiitaのこの人以外にこれ言ってる人いる?

blazorはblazorで垂直展開計画してるからmauiの一部門になるような規模のものじゃないんだが
https://www.publickey1.jp/2020/blazorwebassembly502.gif
0434デフォルトの名無しさん
垢版 |
2020/08/14(金) 23:49:29.36ID:imhDOcA9
>>424
Unoができているからと言って、どうして技術的に楽勝ムードなのか理解に苦しむが。
どうして他の組織が出来ていれば、MSでは楽勝で出来ると思ってしまうのか。
むかしから、MSは技術では「一番」ではなかったのに。
MSにも優秀な人は集まるが、小さな会社でももっと優秀な人がいないとは限らない。
何の根拠で他の会社が出来れば、MSは楽勝だと思っているのだろうか。
頭がおかしいのではないか。
0437デフォルトの名無しさん
垢版 |
2020/08/15(土) 00:02:57.44ID:rYbYnicx
BlazorはMAUI陣営に入る?

それもうBlazorじゃないw

まぁなんであろうとBlazorはないと思うが。
0438デフォルトの名無しさん
垢版 |
2020/08/15(土) 00:05:04.90ID:4kdfZtEz
>>435
でも、いくら金の有る大企業であっても、他の小企業が出来たことが容易に出来る
とは限らないと思うけどね。
アメリカの大手IT企業で典型的に問題なのは、サイズや速度。
機能の量は多いけれど、それは通常では考えられないほど大量の社員が
プログラムしているから。
富豪的プログミングすれば、サイズや速度は無視すれば、大量の人がいれば、
機能自体は実装できてしまう。
しかし、今までは、OSのインストール時間やUpdate時間は、独占的立場で
不平不満にも関わらず最悪の状態でも続けられていたが、ひとたび競争原理
が働き始めれば、果たしてどうなるであろうか。
0439デフォルトの名無しさん
垢版 |
2020/08/15(土) 00:56:32.93ID:C+8YsEI5
>>432
GUIまわりは特にマウスが生産性高いだろう
editorで数値でサイズ指定しても思った通りにならず
何度も数字を入れなおす羽目になる
0440デフォルトの名無しさん
垢版 |
2020/08/15(土) 01:04:16.32ID:C+8YsEI5
>>431
なんだよ、Blazor5種類にパワーアップするのかよ
想像以上のスケールだわ

Blazor NativeとBlazor Hybridやりたい
0441デフォルトの名無しさん
垢版 |
2020/08/15(土) 05:09:48.00ID:KV0ftL1X
Net界のPHPがRazor、Net界のReactがBlazor、Net界のQtがMAUI。
0442デフォルトの名無しさん
垢版 |
2020/08/15(土) 05:12:18.01ID:KV0ftL1X
Net界は少なくともAndroidに侵食しないといけないし、iOSにも浸食したほうが良いだろう。
Linuxはオマケだろう。
0443デフォルトの名無しさん
垢版 |
2020/08/15(土) 05:16:00.98ID:KV0ftL1X
Net界は会社用なのでウェブ浸食は無いと思うけど、会社専用でも結構なシェアを取れるのはJavaが証明した。
0445デフォルトの名無しさん
垢版 |
2020/08/15(土) 09:46:19.69ID:5cqy/wf6
>>438
マイクロソフトを甘く見すぎ
そこらの並の企業とは技術者の層が違いすぎる
OSSの成功例が既にあってマイクロソフトにできないわけがない
百歩譲って仮にできなかったとしても出来る技術者を雇うか買収すりゃいい
0448デフォルトの名無しさん
垢版 |
2020/08/15(土) 11:00:27.91ID:aVj/WLsm
技術力とビジネスの成功は直結しないからなあ
マイクロソフトもGoogleも世界屈指の技術力を持っているのは確か、それでもいくつものプロダクトを失敗させ破棄している
いくら技術力があってもユーザー(開発者コミュニティ)の支持を得られないとダメなのさ
0453デフォルトの名無しさん
垢版 |
2020/08/15(土) 17:24:57.59ID:2Son4Hrg
個人的にはSilverlightがwasmにトランスパイルされる+今風な認証を付加してくれるだけで十分なんだけどね
0455デフォルトの名無しさん
垢版 |
2020/08/16(日) 11:42:16.95ID:5EzRC1Sr
.net coreで既にクロスプラットフォームなのになんでelectronかます必要あるんだ?意味わからん技術
0458デフォルトの名無しさん
垢版 |
2020/08/16(日) 19:23:10.22ID:k/QA8A3q
>>454
Blazor Hybrid だね
0459デフォルトの名無しさん
垢版 |
2020/08/17(月) 22:13:54.22ID:tKPkylNV
Razor pagesとBlazorって何がどう違うんや?
MSは似たような名前の派生多すぎやろー
0460デフォルトの名無しさん
垢版 |
2020/08/17(月) 22:28:52.98ID:ZexFMvlX
Razor Pages の後継が Blazor だと思っていい
記法としては Razor記法
0462デフォルトの名無しさん
垢版 |
2020/08/18(火) 01:10:45.68ID:Krx5Shi1
>>459-460
たしかに紛らわらしい
日本人はRとLの区別が苦手なのでなおさら紛らわしい

Razor pagesとRazor syntaxは別物
Razor syntaxは現役なので覚える必要ある

たしかRazor pagesはMVCに比べて制限があって
MVC覚えればRazor pagesの知識はいらないはず
0463デフォルトの名無しさん
垢版 |
2020/08/18(火) 01:14:19.34ID:Krx5Shi1
BlazorのBはもともとBrowserのBだった。

しかしブランドが拡大してBlazor DesktopとかBrowserと
関係ないものまで出てきてきた。
0468デフォルトの名無しさん
垢版 |
2020/08/18(火) 17:52:17.41ID:j9Dh5QV8
少し待てばすぐにパフォーマンスアップするだろ
JavaやNodeじゃねえんだから遅いままなんてこたない
0469デフォルトの名無しさん
垢版 |
2020/08/18(火) 19:42:24.05ID:qcPz7PQN
スピードってブラウザ次第じゃないの?
どのみち再コンパイルが必要なんだろ?
0471デフォルトの名無しさん
垢版 |
2020/08/19(水) 01:13:46.03ID:x2lHzzgW
そもそも、DesktopのC#は、AOTでどのくらい速くなるの?
特にサイズはどのくらい変化する?
小さくなるの?
なるとしたら何分の一になる?
0475デフォルトの名無しさん
垢版 |
2020/08/19(水) 01:49:44.55ID:x2lHzzgW
>>474
Blazorとは関係なく、もともとのWindows環境のWinFormsやWPFなどで、
AOTを使った場合が、使わない場合と比べてどのくらい速くなるか、ということ。
0480デフォルトの名無しさん
垢版 |
2020/08/19(水) 02:04:57.56ID:vMi8bMi7
あ、というよりサイズが小さくなるって言ってる人はlinkerのことを言いたかったのかな?
0481デフォルトの名無しさん
垢版 |
2020/08/19(水) 02:07:11.31ID:x2lHzzgW
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.
0482デフォルトの名無しさん
垢版 |
2020/08/19(水) 02:13:43.95ID:vMi8bMi7
ReadyToRunならもう既にWinformsやWPFでも普通に試せるからやってみたら?アセンブリのサイズがでかくなることもすぐわかるはず。まあこれは余計なILも含んでいることが大きいけど…
0483デフォルトの名無しさん
垢版 |
2020/08/21(金) 23:16:12.00ID:iv5n66QG
>>475
デスクトップではVMにJITがあるからAOTしなくても致命的ては無い
でもブラウザで動くVMはJITが無い原始的なインタプリタなので、AOTしないとちょー遅い
0490デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:05:46.42ID:fPcZe606
最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
(BlazorはJSよりも10倍遅く、スピード競争に勝つことはない)
と述べた。
0491デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:07:52.50ID:fPcZe606
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)
0492デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:09:59.61ID:fPcZe606
         1年後の世界へ行こう!
/'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
  `ーー'       γ⌒ヽ/ブレキチ\    /'⌒⌒ヽ、
  ,-ーー-、     .||~ ̄~|/-O-O-ヽ|.   (     ┃  ⌒ヽ
 /  ┃  )   ||  6| . : )'e'( : . |9   \ ━┛    )
.(.   ┃   )  ||    `‐-=-‐ '     \___,ノ
 ヽ、__,ノ    ||  _(つ¶¶と)__
          /||'''''|  三  |    |'(⌒)
       /    '―――――`  ̄ \
       `============'
0493デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:12:17.96ID:fPcZe606
 ̄ ̄ ̄| |     llヽ _|      ヽ  
      | |     |l ̄| |       l Blazorって未来ではどうなってんの?
      | |    /  ´\     /        
      | |     ヽ、_   `^イ          
二二二 」 _ __ lニ二二l、           ____
─┴┐ ⊆フ_)__./   ┌ヽ ヽ┐   /´       `\
二二二二二二l  /    |  |   | |.  /             ヽ
_l_____| /`ー─‐|_|   |_| /             ヽ
  |       /`ヽ__, ─ 、ノ |─l  l               l   
  |───/  /lニ/  /二ニluul.  |                 !    え?そんなゴミないよ
  |    ___| ̄ |  |  |_|.      l                /
 └─(    )(ニ|  ̄|./二ニ)     ヽ              /
      ̄ ̄  /   )            >━━━━━━ く
            `ー ´            /               ヽ
0494デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:14:21.35ID:fPcZe606
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
0495デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:16:27.13ID:fPcZe606
>>230>>232によるまとめ

ブレカスはReactに比べ、
8 倍 の転送帯域を消費し、
表示までに 4 倍 の時間がかかるwww
ファーwwwww
0496デフォルトの名無しさん
垢版 |
2020/08/22(土) 10:18:46.22ID:fPcZe606
Blazorのデモ
https://isc30.github.io/blazor-lazy-loading/
のlighthouse結果:
https://lighthouse-metrics.com/one-time-tests/5f2b9fddee28bd0008f6ab20

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

うちのサイトはGoogle経由でなんかアクセスされたくない!
資本主義反対!!
そんなコミュニストに最適なマイクロソフト最先端フレームワークBlazorをどうぞヨロシク!!!
0501デフォルトの名無しさん
垢版 |
2020/08/27(木) 10:02:14.96ID:WGrlRrGq
23点取ったのがそのlazy loadingのデモサイトです
0502デフォルトの名無しさん
垢版 |
2020/08/27(木) 11:27:39.94ID:HhOi/7k5
LazyLoadComponentじゃなくLazyLoadAssemblyが来たか
これがあれば、最初はミニマムなランチャだけロードして素早く表示、ユーザーが操作を始める間にバックグラウンドでdllを落とす、ユーザーがルーティング操作を行う時には既にロード済、といったシナリオができるわけだ
いいねぇ
これなら最初にロードしなきゃいけないアセンブリを削減できるから、ランチャ自体のダイエットも捗りそうだな
サイズ問題はこれで解決の目処がっ立ったね
0503デフォルトの名無しさん
垢版 |
2020/08/27(木) 12:21:11.65ID:5+gXjQyY
全然目処なんて立ってないと思うが。
そんなモンじゃすまないほど大きいから。
0509デフォルトの名無しさん
垢版 |
2020/09/06(日) 22:57:19.13ID:JN9nGzDN
>>508
WebAssemblyなのにHTML使っといて
Dom操作の操作もC#で出来ないんじゃ
javascript撤廃出来ないじゃん。
0512デフォルトの名無しさん
垢版 |
2020/09/07(月) 00:54:40.90ID:pAtokO1N
>>510
js通すというより
js側に処理を委譲するんじゃ...

ドラッグしつつ、
辿った背景を変更してくみたいな
良くある処理も上手く書けないじゃね?
0515デフォルトの名無しさん
垢版 |
2020/09/07(月) 03:28:26.60ID:pAtokO1N
ReactとかVue.js使える人だと、パフォーマンスも悪いんじゃ
使うメリットが全くなさそうだ。

そもそも、Webassemblyなら HTML/CSS使わないと思ってたんだけど、
使ってるあたりが Blazorの癌なのかもね。
0517デフォルトの名無しさん
垢版 |
2020/09/07(月) 08:38:18.69ID:R/8abHxo
Blazorの本質はC#が使えること自体ではなく、Webフロントエンドに弱め(全く分からないとは言っていない)な業務系ドットネッターに対して
ReactやVueのような仮想DOM系フレームワークを提供しSPAをキャッチアップさせることにある
もちろんReactやVue使えるんなら全く用はないよ
0518デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:18:35.41ID:xj7DdlIE
>>515
開発のパフォーマンス(生産性)が劇的にあがる
JS不要で開発できるのは大きい
0520デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:24:59.55ID:pAtokO1N
>>517
自分が資料みて感じた事と一致します。
C#だけで出来る事が少ない。Dom側の操作がJs頼みならそうなっちゃいますね。

Webassemblyという点につられてる人多そう。
やはりUno Platformが本命ですかね。
0521デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:25:44.72ID:sybwZ+D6
ReactやVueを使っていてサーバーサイドもNode.jsならわざわざ切り替える意義はないかな。サーバーサイドがC#ならそれなりに恩恵は大きいはず。
0522デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:27:15.52ID:pAtokO1N
>>519
それがVue.jsとか簡単なんですよ。
新規で学んでも簡単でパフォーマンスも良いです。
正直、UI凝り始めるとWPFより使いで良いです。
0523デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:27:38.77ID:CCEjOt0h
どうしたらHTMLとCSSがいらないなんて発想にたどりつくのか…だってRazorでしょw
0524デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:37:14.11ID:pAtokO1N
>>523
Razorは記法だし、
結果を自前でレダリングしてるのかと思いますね。
0526デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:43:29.84ID:xj7DdlIE
node.jsが超低速だから
web frameworkとして、React系のNextとか Vueを
使わないほうがいいと思う
サーバーサイドでJSを使うというのが遅いしダサい

web frameworkとしてみるとnode系よりも
ASP.net Coreのがはるかに高速
0527デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:50:16.63ID:zpdoSB45
>>522
JS、TSって時点で酷しい
JSは単純に生産性が低い
TSはC#の作者と同じだけあって優れた言語だが
コストパフォーマンスの良い要員が集まらない
0528デフォルトの名無しさん
垢版 |
2020/09/07(月) 09:57:58.91ID:pAtokO1N
>>527
Jsって頭の良い人が書いたら、
一般人には理解不能な凄いものが書けますからねwww
0529デフォルトの名無しさん
垢版 |
2020/09/07(月) 10:12:27.38ID:qk/9c7gK
>>528
頭がいい人は複雑で高度なことも他人(当然ある程度の前提知識はあるものとする)が読めるように書ける
頭の悪い人が難しいことをやろうとすると、他人に理解できない酷いコードになる
0530デフォルトの名無しさん
垢版 |
2020/09/07(月) 10:36:24.94ID:pAtokO1N
>>529
自分言ってるのはそれとは違うやつの事ですね。
一般人なんで説明できないですけどwww
0531デフォルトの名無しさん
垢版 |
2020/09/07(月) 12:07:46.81ID:zpdoSB45
>>528
本当に頭のいい人は理解しやすいコードを書くものだけどね

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

C#は優れたIDEによるコーチングがあるからバカでも及第点のコードが書ける
0532デフォルトの名無しさん
垢版 |
2020/09/07(月) 12:12:26.47ID:K0kNn/Cs
日本テレビの子供向けプログラミング教育ω番組
今こそ知りたい!めざせ!プログラミングスター
で映ってた画面が jquery だったわωωω
0533デフォルトの名無しさん
垢版 |
2020/09/07(月) 13:25:47.78ID:ocp9ke30
>>512
あ、そういう意味ね
JS側からC#側のメソッドを呼び出せるから一応はできるはず
ただオーバーヘッドは半端ない気がするし
ガッツリJS書く必要はある
0541デフォルトの名無しさん
垢版 |
2020/09/08(火) 18:07:26.14ID:8rtOALpS
苦労してWeb appを作るのは時代遅れなのかもしれない
https://gigazine.net/news/20200907-reddit-app-downloads-miserable-web/

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

>>540
ごちうさ難民
0543デフォルトの名無しさん
垢版 |
2020/09/08(火) 21:16:43.61ID:scYxt6FH
>>542
残念ながらネイティブアプリageの流れはスマホの話
PCは一貫してWebファーストが普通だし、ネイティブアプリ化するにしてもSlackみたいにWebアプリのガワだけネイティブにするのが今時は多いよ
0544デフォルトの名無しさん
垢版 |
2020/09/19(土) 11:24:45.44ID:QFC7K9+q
マウスポインターの位置に
コンテキストメニュー表示したいんだけど、
JS使わずに可能?
0545デフォルトの名無しさん
垢版 |
2020/09/19(土) 12:03:44.03ID:ATAk2qRK
コンテキストメニューって言葉がわかってるなら
blazor context menu でぐぐればいいだろ
0549デフォルトの名無しさん
垢版 |
2020/09/20(日) 20:15:19.21ID:B8GhM1mv
コード(C#)でDom Treeの任意の位置に
オブジェクトを足したり削除したり出来るって事??
0552デフォルトの名無しさん
垢版 |
2020/09/21(月) 12:30:35.11ID:mc/SlMom
>>550
速度も問題ないね
結局、体感でサクサクならベンチマークとかどうでもいいんだよな
開発生産性が高いメリットを享受できる

ハード性能あがればさらにJSで書く人は減るだろう
0555デフォルトの名無しさん
垢版 |
2020/09/21(月) 14:30:28.63ID:a0iBHw//
そうだね
フロントエンドのパフォーマンス的な観点で言えば、100%普通のJSで動いていると言って差し支えない
そもそもWebAssemblyじゃなくてBlazor Serverだしな
0556デフォルトの名無しさん
垢版 |
2020/09/21(月) 14:38:45.50ID:2HL9jfi3
Chart.js使った時点で、
Blazorの出番ないし
最初から全部JSで書いたほうが
楽だし、簡単だよね。

クライアントサイドでC#で動かしたいライブラリーが無かったら
何の価値が有るんだろう。
0557デフォルトの名無しさん
垢版 |
2020/09/21(月) 17:14:00.32ID:mc/SlMom
Blazor Serverだったのか
それなら少人数なら快適に動いて当たり前か

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

アクセス多い場合はWebAssemblyとかHybridとかnative appとかほかの技術使う
0560デフォルトの名無しさん
垢版 |
2020/09/21(月) 19:27:13.31ID:KqbH7J4b
WebFormsで作られた業務システムの移行先に考えてるんだけど、
何でもかんでもblazorで作ると開発コストがかさみそうで…。

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

いいプロジェクトの構成が思いつかない。
0561デフォルトの名無しさん
垢版 |
2020/09/21(月) 20:03:05.36ID:Cgyr/Ih0
MVCか Blazor Server でいいんちゃうの
Blazor でも WebAssembly使うとプロジェクトも二つになるし
考えないといけないことも増えるかな

SPAにしたくってでもJavaScript/TypeScript極力使いたくないならBlazorかな
0562デフォルトの名無しさん
垢版 |
2020/09/21(月) 21:52:08.52ID:zwx+QOMY
>>559
全部サーバーサイドだとスケーラビリティがない

これに
は?
以外どんなレスが付くと思った?
0563デフォルトの名無しさん
垢版 |
2020/09/21(月) 22:47:24.40ID:7dDEGXG6
サーバーサイドのは
signalRでクライアントと
Websocketでセッションを張る。
この時点で社内システム程度の運用が限界。
0564デフォルトの名無しさん
垢版 |
2020/09/21(月) 23:03:25.83ID:mc/SlMom
>>562
558のアホか?
初心者のくせに上から目線、ウザすぎ
反論、質問があるなら伝わるように具体的にかけ

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

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

これが理解できないのはサーバー増やせばスケールアウトすると
考えてるような初心者かバカだ
0566デフォルトの名無しさん
垢版 |
2020/09/21(月) 23:38:03.42ID:FE12ttrt
リアルタイムリアルタイムってバカの一つ覚えわろた

株価の情報配信するわけでもないだろうに
0567デフォルトの名無しさん
垢版 |
2020/09/22(火) 00:11:30.38ID:kylJSQdV
>>566
何も表示しない画面でも
Websocketのセッションを張るんだよ。
不得意多数の要件には使えない。

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



多分Webassembly版が出せない時代の
お茶濁しだろうけどね。
0568デフォルトの名無しさん
垢版 |
2020/09/22(火) 00:14:57.89ID:kylJSQdV
あ!

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

いらんけど。ね。
0569デフォルトの名無しさん
垢版 |
2020/09/22(火) 00:24:35.49ID:j70U2+kl
>>567
566はろくにコード書けない上に上からのアホだから
ほとんどレスを理解できてないぞ

Blazor Serverの数少ないメリットはセキュリティ。
コードをclientに極力見せずに作れる。
スケーラビリティを犠牲にしてでもセキュリティが
重要な社内用途とかなら使いどころになりうる
0570デフォルトの名無しさん
垢版 |
2020/09/22(火) 00:42:48.24ID:epkmWxIb
>>567
うん、セッション張るのは Signal-r使ったことあるからわかるよ
っていう今もある業務システムで使ってるわ

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

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

結局どういうアプリ次第なんだよ
0571デフォルトの名無しさん
垢版 |
2020/09/22(火) 01:17:58.77ID:kylJSQdV
>>569
ソース漏は
Webassemblyなら大丈夫でね?
なのでサーバーサイドの使い道は
殆ど思いつかん。
0573デフォルトの名無しさん
垢版 |
2020/09/22(火) 01:40:46.22ID:GCixYKXo
>>564
あ、はい
0574デフォルトの名無しさん
垢版 |
2020/09/22(火) 08:14:13.81ID:KxwePHxM
>>561
ありがとう
あなたのレス以降Blazor Serverがディスられてて複雑な心境。。

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

不特定多数が使うウェブアプリならWebAssemblyがベターなんでしょう。
0575デフォルトの名無しさん
垢版 |
2020/09/22(火) 09:07:26.70ID:j70U2+kl
>>574
同時使用ユーザー数次第だが1000人って規模としては大きめ
基幹業務のシステム?

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

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

俺はパフォーマンスでない技術だけは選ばないわ
Blazor Serverでなければならない理由もないのに選ぶ理由がわからん
0577デフォルトの名無しさん
垢版 |
2020/09/22(火) 09:31:32.20ID:j70U2+kl
サラリーマンなら特に重要だろ
プロジェクト失敗したら上流設計やったやつらは
完全に無能扱いされるし
社員からもあいつが上流設計したせいでって陰口叩かれるわw
0578デフォルトの名無しさん
垢版 |
2020/09/22(火) 10:42:28.47ID:KxwePHxM
>>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.

とあるけどこれまさかあのクリックするたびにカウントアップしますよアプリで試してるんだろうか…
複雑な画面でやるとダメダメなんだろうか…
0579デフォルトの名無しさん
垢版 |
2020/09/22(火) 11:37:42.85ID:epkmWxIb
WebSocketのセッションが5000までいけるってことなんじゃないの
VPSなんかだとサーバの設定もあるから
きちんと設定できないとすぐに制限いっぱいになっちゃうんでしょ

どこにサーバーおくかも考えて決めたら
0580デフォルトの名無しさん
垢版 |
2020/09/22(火) 14:43:37.98ID:epkmWxIb
ローカルの環境でIIS Express使ってテストしたら
5000コネクション余裕で張れたわ
0582デフォルトの名無しさん
垢版 |
2020/09/22(火) 16:27:39.02ID:j70U2+kl
>>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経由でもアクセスするならネットワークのパフォーマンスも問題になる
結局、パフォーマンス絡みは稼働後に問題が発覚することが大半
採用するなら徹底的にパフォーマンスは事前検証したほうがいい
失敗したら確実に無能の烙印おされる
0583デフォルトの名無しさん
垢版 |
2020/09/22(火) 17:07:46.37ID:1XqBBY/l
サーバでテンプレートエンジンを動かして、HTMLを生成
必要なところだけ部分的に、AJAXで更新

結局のところ、それだけでよかったんだ
SPAもSSRも最初から失敗だった
0585デフォルトの名無しさん
垢版 |
2020/09/22(火) 23:40:57.68ID:UXy6Yo2i
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
0587デフォルトの名無しさん
垢版 |
2020/09/23(水) 00:08:25.99ID:BblF/Ts1
>>584
個人的にはこっちのほうが嫌だな

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


負荷分散装置やらプロキシサーバーやらでいつも苦労する
0588デフォルトの名無しさん
垢版 |
2020/09/23(水) 02:33:18.98ID:2MH3im7L
結論的だけど、
Blazorてjsすら使えないエンジニアの為の
救世主ぐらいしか価値を見いだせない。

Blazorだって学習コストかかるのに
その分JS学んだ方が将来的な
メリットは計り知れないと思うけど。
0589デフォルトの名無しさん
垢版 |
2020/09/23(水) 12:28:24.15ID:TJRuGaHL
>>581
アンチと決めつけうざい
じぶんはずっと前からからC#とASP.net推してきてる
スケールしないといってるのはBlazor Serverだ。
Blazor WebAssemblyについてはスケールしないといっていない

>>584にも
MSのサイトにスケーラビリティの欠点かいてあっただろ
前にはなかったが追加された
0590デフォルトの名無しさん
垢版 |
2020/09/23(水) 12:33:56.41ID:TJRuGaHL
>>588
JSのほうが将来性ないのになにいってんだ
Wasmが普及したらメインの開発言語でJSを選ぶ人はいなくなる

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

Blazor使う層はC#が使える
JSは使えないのではなく、生産性が低いから使いたくないのだ
0591デフォルトの名無しさん
垢版 |
2020/09/23(水) 13:46:42.94ID:aXGalhzK
JavaScriptとセキュリティーについては、紙教材ベースでは学習してはいるけど・・・・
どっかで実務経験を積まないことには、素人サービスであっても実戦投入なんて危なくてできないな
0592デフォルトの名無しさん
垢版 |
2020/09/23(水) 17:06:15.80ID:2MH3im7L
>>590
開発生産性は
VS code + Hot Relode の
vuejsとかreactの方が高いですよ。
言語もTypescriptとか使えば死角がなくなります。
0593デフォルトの名無しさん
垢版 |
2020/09/23(水) 17:22:32.14ID:TJRuGaHL
>>592
ありえない
reactはframeworkじゃないし関係ない
静的言語は速度も生産性もC#に勝てない

C#やasp.netを知らない人の意見とすぐわかる
必要なコードの量が全く違う
0594デフォルトの名無しさん
垢版 |
2020/09/23(水) 17:27:33.88ID:WMt34WtD
Javaの方が早く死にかけてるのに驚いてる
古くからのC#erですよ。
ASP.NETの前のASPのベータ版から親しんでる
爺です。
0595デフォルトの名無しさん
垢版 |
2020/09/23(水) 18:44:41.10ID:jsSlKDJf
>>584
Blazor WebAssemblyと比較しての欠点でしょ
シンクライアントとファットクライアントを比べたら当然のことが書いてあるだけ
0596デフォルトの名無しさん
垢版 |
2020/09/24(木) 08:05:11.98ID:g1jGyjzk
技術選定するにあたって、
Blazorの対抗馬としてReactやらVueやら最近流行りのフレームワークは当然候補に上がってくる。

しかしこの手の技術、実際手を動かして作ってみたことがない…
本当のところ生産性ってどうなんだろう。
両方使いこなせてる人に生産性の違いを教えてもらいたい。

以前なんかのブログに、
TypeScriptは型が使えるんですよ。するとIDEでコード補完やリファクタリング機能が使えるんですよ!これは便利!
と書いてあるのを見た。
実はWeb系の人たちってこれまでものすごい苦行を強いられてきていたのでは…
0597デフォルトの名無しさん
垢版 |
2020/09/24(木) 08:47:14.39ID:xLAA4wLj
>>596
server-sideの生産性はasp.net coreが格段に上
UI component作るだけならJS/C# どちらの言語に慣れているかで
変わるかもしれない。

流行ってるかどうかではなく、優れているかどうか、
自分のスキル、好みで決めればいいよ
PHPみたいにそこそこ流行っていてもクソみたいな言語もある
0598デフォルトの名無しさん
垢版 |
2020/09/24(木) 09:31:02.38ID:g1jGyjzk
>>597
チームで開発してるからなかなか自分の好みだけでは決めれなくて…

Blazorつかいます!ってなったら
そんなのよりVueを使いたまえとか言ってくる偉い人が必ず出てくる。
若い子も流行りのtsやReact、Vueをマスターしたいってなると思う。

そのとき、君たちの憧れの言語やフレームワークはこんな苦行を強いられるのですよと言えるようにしておきたい。
0599デフォルトの名無しさん
垢版 |
2020/09/24(木) 10:04:58.46ID:xLAA4wLj
>>598
流行りで決めるほうがよっぽど論理的でないだろう

server-sideのbenchmark見てみりゃわかる
node.js系はasp.net coreよりかなり遅い。
それだけでJS系frameworkを使わない理由になる。

同じ言語C#でclient-sideも開発できればコストも削減できる。
Vueなんて個人ベースで作ってるものだろ
長期サポートされないしnode系だから速度も遅い。
0600デフォルトの名無しさん
垢版 |
2020/09/24(木) 10:15:36.19ID:xLAA4wLj
流行ってるかどうかでいったら普及率ナンバーワンの
web frameworkはWordPressなわけだけど、
本格的なweb appをそんなゴミで開発しようとはならないでしょ。
シェアで技術を選ぶのは完全に間違いってこと
0602デフォルトの名無しさん
垢版 |
2020/09/24(木) 12:43:26.88ID:glrQYFrS
JavaScript は改良が続くんだろうし
いつかTypeScriptとの違いもなくなっちゃうのかもしれんね

そうなったらクライアントサイドがJavascriptでもいいのかもしれない
0603デフォルトの名無しさん
垢版 |
2020/09/24(木) 13:12:22.54ID:xLAA4wLj
>>602
JSは互換性重視だから大幅には変わらない。
wasm普及したらJSの役割はおしまいだろ

PCとSPで動くnative appを開発できるツールが
でてきてweb appが下火になる未来も来ると思うわ
AppleもMAC向けARM系独自プロセッサ開発する。
最後はcross platform対応のnative appに向かう
0604デフォルトの名無しさん
垢版 |
2020/09/24(木) 18:26:57.96ID:BAyxlToW
中途半端Bootstrapより、なんかまともなもんを一つ移植して欲しいな
0605デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:48:01.41ID:ipSsIIJF
WebAppは、下火になるとしても、独特の面白さがある。
ビビッドアーミーなんかも、Webからすぐに始められるから、インストール型
のゲームよりも罪悪感が少ないため、ヒットした可能性がある。
0606デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:51:18.25ID:I6ftHOh5
>>596
最近までasync/awaitもなかったんやで・・推して知るべし
自分は最近仕事で使ったからReactはギリ推せる
なぜかというとhooksが導入されたり関数コンポーネントが主流になったりで
React周りの記述量が大幅に減ったから
Reduxなんか挫折する人が出るくらい記述量が無駄に多かったらしい
それもRedux-Toolkitでずいぶん楽になったようだ
調べているうちに新旧のコードを見かけるけど
旧Reduxで組んでた人はよく発狂しなかったと感嘆した
まだまだ記述量が減る余地はあると思うから期待したい
BlazorはRedux-Toolkit以上の使いやすい状態管理が提供されれば
仕事でも使ってみたい
ReactとVueは選定するとき迷ったが、サポートしているのが
FaceBookとコミュニティでは巨人の肩に乗るほうがよいと判断した
Augularは構文デザインになぜか吐き気を覚えたので選定から外した
0607デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:22:47.35ID:nbhc13gU
みなさん貴重なご意見ありがとう。

Web系のひとたち、俺たちは最先端のことやってるぜ感出してるけど、
昔のVBAみたいな、あとで誰も手をつけれてないようなシロモノを職人技で苦労しながら作ってるような気がしてて…
そういうのは仕事では使いたくない…

あとBlazorに望むこととしては、
WinFormsやWebFormsみたいに標準のコントロールを充実させてほしい。
DataGridViewやTreeViewが海外のサードパーティ製にしかないのはこれまたお仕事では困る…
ぼちぼちGrapeCityあたりが出してくれそうだが…
0608585
垢版 |
2020/09/24(木) 21:43:39.63ID:80+YcRw8
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 を抑えておけばよい
0609デフォルトの名無しさん
垢版 |
2020/09/24(木) 22:08:01.62ID:BrtCX/UE
サーバー版Blazorのシステム納品間近
サーバーサイドとクライアントサイドをC#同一ソースコードで記述できるから開発効率高いね
0610デフォルトの名無しさん
垢版 |
2020/09/24(木) 23:51:59.19ID:xLAA4wLj
>>609
Blazor ServerのApplication Serverは何台構成?
同時使用ユーザー数の規模はどれくらい?

良い言語C#でclient-server両方かけるっていうメリットは大きい
0611デフォルトの名無しさん
垢版 |
2020/09/25(金) 10:34:56.50ID:4ovx1Tzj
>>607
web系はアホが多い

過去に失敗した経験に学ばず同じことを繰り返してるし
0612デフォルトの名無しさん
垢版 |
2020/09/25(金) 12:17:21.21ID:0u8f+Kls
ウェブ系は雇用の安定感が無いから新しい事やってます感をアピールしないと次がないのよ
だから同じようなことを言い方や見せ方を変えながら繰り返してる
0613デフォルトの名無しさん
垢版 |
2020/09/25(金) 14:05:33.75ID:YUW4E6Ob
>>607
サードパーティ製コントロールって
JS & CSSのラッパーコントロールですよ。C#の。

なので、コントロール欲しければ、普通の配置して、
JSをC#から interopすればよろし。
0614デフォルトの名無しさん
垢版 |
2020/09/25(金) 14:43:52.18ID:48PJbryO
俺的にはまず、Blazor Serverside + Blazor Webassemblyの組み合わせで使えるようにして欲しいな
これができないことには、いつまで経ってもJavaScriptから逃げられん
Blazor Serversideでログイン関連等の基本的な部分を作り、Blazor Webassemblyでウィジェットのようなものを作るような、そういう組み合わせができるように改良して欲しい
0618デフォルトの名無しさん
垢版 |
2020/10/04(日) 06:42:57.11ID:hlVRy1T+
業務アプリならsilverlightを温めとけばよかったのよ
ria service も廃止してAzure売り出す始末でタチ悪すぎるわ

どうせまた3年でオワコンになり、再開発させられる羽目になるんだよな
wcfとかどうなるんだよ
0621デフォルトの名無しさん
垢版 |
2020/10/04(日) 13:26:23.01ID:ceP54wF6
Silverlight はFlashと一緒で消える運命でしょ

Blazorは Server版は既存の記述組み合わせたものだし
WebAssembly もマイクロソフトが単独でやってるわけでもないし
すぐには消えなさそうだけど
それも世の中の技術の進歩とトレンド次第かな
0622デフォルトの名無しさん
垢版 |
2020/10/04(日) 13:39:56.64ID:hibiyDxp
全く性質が違うからねー
Blazorがいつまで続くかはわからないがクライアントサイドC#はずっと残ると思う
Webasm自体が続く限りは
0624デフォルトの名無しさん
垢版 |
2020/10/04(日) 14:22:11.82ID:S53suDDq
ASP.NET CoreのRazor Pagesと
ASP.NET CoreのMVCと
Blazor WebAssemblyの使い分けがよくわからない。

ページ単位でURLを持たせたい場合は
Blazor WebAssemblyは使えない?
0626デフォルトの名無しさん
垢版 |
2020/10/04(日) 16:06:30.15ID:k2QVBKjJ
ポストバックを多用する昔ながらの単純なウェブアプリならPages
ビューを開いた後にクライアントサイドでゴリ押しする少し複雑なウェブアプリならMVC
MVCでクライアントサイドが管理しきれない規模の高難易度ウェブアプリならBlazor

MVCが一番バランスいい
Blazor、というかSPAにするほど複雑なウェブアプリが滅多にない
SPAはPgadmin、CodeServerみたいなガチめのアプリのための技術
0628デフォルトの名無しさん
垢版 |
2020/10/04(日) 16:37:36.76ID:k2QVBKjJ
そうかな
テンプレートは1回表示して終わりだからMVCのほうがシンプルでいいと思う
ポストバックするならPagesのほうがやりやすいけどね
0631デフォルトの名無しさん
垢版 |
2020/10/04(日) 16:57:59.06ID:XxJyPnkf
少し規模が大きくなると、MVCはどこでどのエンドポイントが呼ばれているかカオスになるからね…
0635デフォルトの名無しさん
垢版 |
2020/10/04(日) 23:12:02.56ID:XxJyPnkf
>>634
.NET Frameworkでは使えるし、Windowsが生きている限りサポートされ続けるから「終わった」は言い過ぎやろ
0636デフォルトの名無しさん
垢版 |
2020/10/04(日) 23:50:16.30ID:hlVRy1T+
今、wpfをクライアントとしてサーバーのsqlserverにcrudするには何が主流なの?
wcf?asp.net mvc?
0638デフォルトの名無しさん
垢版 |
2020/10/05(月) 03:23:01.66ID:xLtRIUFK
>>635
新しく立ち上げるプロジェクトで使用できないなら「終わった」でいい
VB6は終わった技術じゃないというならそれでもいいが
0641デフォルトの名無しさん
垢版 |
2020/10/05(月) 19:08:30.24ID:xLtRIUFK
>>639
言葉足らずですまん
.NET Core で使えない==新しく立ち上げるプロジェクトで使用できない
とすっ飛ばして書いた。
.NET Frameworkの保守で使う新規プロジェクトなら使えるね
0644デフォルトの名無しさん
垢版 |
2020/10/15(木) 21:39:41.60ID:tKmwyqG6
Blazor WebAssemblyをテンプレートからいろいろいじってみたけど、
もうちょいテンプレートしっかり作ってほしい。
せめてCRUDのテンプレ欲しかったなあ。
あとClient側、trycatchくらい書いとけよと。

あととにかくデバッグがうまくいかない
ctrl+shift+iだったかな、これ押すと一応デバッグできるようになるんだけど、そんなん分かるか!ってかんじ。
0647デフォルトの名無しさん
垢版 |
2020/10/18(日) 16:09:45.98ID:EBpdGRvy
Blazor使って作られたサービスってある?
調べても使ってみたとかばっかでる
0648デフォルトの名無しさん
垢版 |
2020/10/18(日) 17:03:18.35ID:Yx1P9/Gs
>>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で十分ってことかもしれない
0650デフォルトの名無しさん
垢版 |
2020/10/18(日) 19:22:38.17ID:cFA8jjUJ
ユーザー名+パスワードのハッシュの入った既存のデータベースを、Blazorのユーザー認証に使い回す方法ってどっかに紹介されてない?
0652デフォルトの名無しさん
垢版 |
2020/10/18(日) 21:49:08.25ID:cFA8jjUJ
>>651
ありがとう!これは便利だ!
クッキー発行前に自分のやりたい認証コードを書けば、なんでも使いまわせちゃうぜ!
0653デフォルトの名無しさん
垢版 |
2020/10/19(月) 11:41:11.48ID:32Wztry8
>>651
そのサイトはいいかんじにまとまってるサンプルがあるね
ブックマークしておいた
0654デフォルトの名無しさん
垢版 |
2020/10/19(月) 13:14:16.03ID:IuaIFexr
俺は逆に、Blazorで登録してもらったユーザー情報で他のnode等で作ったページにログインできるような技が知りたいな
先の技と似た方法でASP.Net Coreでクッキーだけ発行してnodeでも同じクッキーを使うのもいいけど、データベースを使い回す方法も見てみたい
だけどデータベースを見たところ、パスワードハッシュらしきものはすぐ見つかるもののソルト等がどこにあるのかよくわかんない
もしかしてハッシュに見える一部分がソルトなのか?パスワードハッシュらしきものは、どうやって生成されてる値なんだろう・・・・
0656デフォルトの名無しさん
垢版 |
2020/11/02(月) 05:11:15.47ID:mSt0AvyI
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でかなり速くなるんだな
楽しみ
0657デフォルトの名無しさん
垢版 |
2020/11/02(月) 12:21:12.29ID:U50fzrLu
Blazorで作ったうちのサイトに、大量のユーザ登録をする奴が出てきた
掲示板みたいなものがあるので、宣伝の書き込みに使いでも使うんだろうか?よくわからないけど不気味で仕方がない
大量登録を防いだり、ユーザーの行動をスコア化したりBANしたり、何かBlazorでできる手軽な対策ってない?
0658デフォルトの名無しさん
垢版 |
2020/11/02(月) 13:05:27.82ID:mSt0AvyI
>>657
しっかりやるならSMS認証だろうけど手軽ではないね。
手軽なのはメールアドレスとIPアドレスベース

登録時のメールアドレス認証はやってる?

同じIPから一定日数は登録できないようにすれば、
固定回線からの登録はある程度防げると思う
ISP次第で固定でもIP変更できちゃうけど
ただの宣伝目的ならそういうめんどうな
手順必要なところは避けてほか行くんじゃないか
0660デフォルトの名無しさん
垢版 |
2020/11/02(月) 22:47:48.58ID:mSt0AvyI
>>659
そうなのか
全部クラウドでやるのは高すぎて避けたい。
認証だけAzure AD使うのってありなのかな
0663デフォルトの名無しさん
垢版 |
2020/11/04(水) 23:24:27.00ID:QiewC8QL
Blazorに限る話ではないかも知れないけど…

ServerにWeatherForecastController作って、
ClientからアクセスするときはGetFromJsonAsync<WeatherForecast>(“WeatherForecast”)とControllerの名前を「文字列」で引数に入れる。

これがせっかくここまでC#の型を使えてるのになんか無駄だなあと。
Shareにあるクラスは参照できてるのに、
なんでServerへのアクセスは文字列なのか。

ここタイプミスしたらオジャンじゃん。

外部のAPIならわかるけど、同じソリューション内のプロジェクトなんだから
WeatherForecastContoroller.GetAll WeatherForecast() でええやんと思ってしまう。

gRPCとか使ったらSOAPチックなことできるの?
0664デフォルトの名無しさん
垢版 |
2020/11/05(木) 00:12:14.94ID:kkWOG+/P
>>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.
0665デフォルトの名無しさん
垢版 |
2020/11/05(木) 00:15:02.65ID:kkWOG+/P
>>663
上みたいな感じで
Controllerの名前もなんらかのmethodでstringとして取得できるんじゃないかな
0667デフォルトの名無しさん
垢版 |
2020/11/05(木) 08:21:04.21ID:+cvvBSkt
>>664
nameofありだね
スペルミス減りそう

>>666
Attribute Routing調べたけど
API側でルーティングを文字列で指定してる。
文字列をやめたいんだけど…
メソッド名があるんだからメソッド名をそのまま使いたい。

そもそもREST APIの原則に囚われすぎな気がする。
毎回あんなURIを考えるのって大変じゃないか?

汎用性を考えるならわかるけど。
0668デフォルトの名無しさん
垢版 |
2020/11/05(木) 08:27:25.47ID:/DSStsR5
>>663
それコントローラー名じゃなくてUriでしょ

DefaultRoute使えばuriとコントローラー名は一致するからそれでいいけど
プロジェクトの都合で
URIとコントローラー名異なるようにすることはあるでしょ。
0669デフォルトの名無しさん
垢版 |
2020/11/05(木) 08:33:38.65ID:+cvvBSkt
>>666
言ってることが分かったかも
API側で
[Route(“GetHogeData”)]
public Hoge GetHogeData(){}
にするってことかいな?
0670デフォルトの名無しさん
垢版 |
2020/11/05(木) 08:34:41.52ID:+cvvBSkt
すまんリロードせずに書き込んでしまった
そゆことね
0671デフォルトの名無しさん
垢版 |
2020/11/05(木) 08:41:56.35ID:/DSStsR5
よくおぼえてないまま書くけど
ルーティングの機能でコントローラー名とアクション名から
アドレス作れたはずだから
それを渡せばいいんじゃないの
それだとnameofも利用できると思うし
カスタムルーティングの場合でも問題なくいけると思う
0672デフォルトの名無しさん
垢版 |
2020/11/05(木) 23:38:47.81ID:xnSUjXs4
razorファイルに書いたC#がバリバリ動くのは感動すら覚えるが
最初に作られるサンプルサイトがショボショボすぎてこれは普及しないだろうなあ…とおもう。

入力もできるグリッド、DateTimePicker、TreeView、モーダル
こういうのをサンプルに組み込んでもらわないと
いちいちググるはめになる。
0674デフォルトの名無しさん
垢版 |
2020/11/05(木) 23:49:29.95ID:nJQizfvu
そんな複雑なUI作られても使う側が困るしなぁ
シンプルイズベストですわ
MVCでいいじゃないの
0676デフォルトの名無しさん
垢版 |
2020/11/06(金) 00:03:35.28ID:2c+qTMiR
いろんなGUIサンプルはGitHubに置いておいてくれればいいね
Wizardで生成されたら困る
0677デフォルトの名無しさん
垢版 |
2020/11/06(金) 08:08:26.77ID:IN01S+R+
テンプレートでもサンプルでもどっちでも良くて、
MSがそういうものを用意しないと流行らないと言っている。
そんなことをこんなところで言っても仕方ないけどな。
0678デフォルトの名無しさん
垢版 |
2020/11/06(金) 11:00:07.02ID:PZBOyE9X
コピペしかできない人なんだろう
0681デフォルトの名無しさん
垢版 |
2020/11/06(金) 12:30:57.02ID:IN01S+R+
MSはWebFormsの代替としてBlazor使えって言ってる。
使いたいがこれではハードル高いだろ。
外部の会社が作ってるUIコンポーネント集入れないと使い物にならん。

仕組み上ポトペタは無理としても、それに代わる何かがないと、学習コストがかかって採用されないよという話。

ウィザードでゴリゴリの画面が作られのもまずいというのはわかるが、さすがにシンプルすぎやせんか。
0682デフォルトの名無しさん
垢版 |
2020/11/06(金) 12:39:05.16ID:weK94EqQ
単に自分の能力が足りてないだけじゃないの

まー言うとするなら
WebFormsのように基本的なコントロールは入れてほしい
って感じ?

サンプル云々の話じゃないよね

たぶん
0683デフォルトの名無しさん
垢版 |
2020/11/06(金) 12:42:45.58ID:hgF+gIaZ
WebFormsってそんなに便利だったっけ?
あっという間にMVCに置き換えられたからわからねえや
0685デフォルトの名無しさん
垢版 |
2020/11/06(金) 13:11:07.93ID:2c+qTMiR
>>681
リッチUIを最速で作りたいならWPF使えばいい
外から使い人にはWindows tabletとか持たせるだけ。
Bootstrapでだいぶ敷居さがったがCSSベースのデザインはめんどくさい

>>683
HTML, CSSをよく知らない人、デザイン苦手な人には便利だったんだと思う
ただ細かいデザイン制御ができない、吐き出すhtmlが汚いから
ASP.NET MVCにとってかわられた
0686デフォルトの名無しさん
垢版 |
2020/11/07(土) 22:13:36.96ID:fFUf4t5z
Entity Framework使ってる人、Migration機能は使ってる?

Migration使うほうが複雑になる気がするんだけどどうだろう
Migrationのメリットが見えてこない

PostgreSQLのpgAdminとか
RDBの管理ツールで直接、スキーマの作成や変更をしてる。
0687デフォルトの名無しさん
垢版 |
2020/11/07(土) 23:04:04.86ID:/xSkaoCp
Ruby on Rails では、SQLite, PostgreSQL, MySQL の3大DB を、1つのファイルで定義できる(抽象化)。
Migration 用のファイルも、自動的に作られる

Roll Back もできる

Scaffold という魔法の呪文で、CRUD アプリが自動的にできる
0689デフォルトの名無しさん
垢版 |
2020/11/07(土) 23:33:27.49ID:z61Fk2tn
>>686
アプリでSqliteなどのローカルDBでは凄く有効だが、サーバー弄れる場合は手動でいいと思うわ
0690デフォルトの名無しさん
垢版 |
2020/11/08(日) 05:36:39.88ID:t+zVbDF+
>>687
rollbackもできるというけどそれがMigrationの主要機能だし
rollbackできなかったら意味ないでしょ
Entity FrameworkのMigrationにもrollbackある。もちろんScaffoldもある

Rubyのコマンド見てみたがEFのMigrationと似てる気がした。
ORMが履歴を持つことでrollbackできるようになる半面、長ったらしいコードが
生成されその記述を理解しないといけなくなる。

DB側のカラムに制約とかデータ型とか細かく設定するべきだが
ORM使わずにpgAdmin, SQL Workbenchでやるほうが速いしわかりやすい。
さらにORM経由は操作できる範囲が限定される。
SQL使ってできる操作>ORM使ってできる操作。
0691デフォルトの名無しさん
垢版 |
2020/11/08(日) 05:42:09.04ID:t+zVbDF+
>>687
RubyおじはASP.NET Coreは使えてるのか?
ASP.NET Core使えるなら低速なRails, Rubyなんて使わなくていいだろ

>>689
Sqlite以外ではMigration使ってないのか
本当にMigrationは誰得の機能かわからないわ
0693デフォルトの名無しさん
垢版 |
2020/11/08(日) 10:00:24.59ID:SqlrOE3Q
あー、SQL自動生成だけでも意義はあるか

まぁ、単に開発中のコードとデータベース同期を楽にする機能でしかないから
使いたければ使えばいいし
データベース熟知してて自分でDBスキーマ決めたいのならそうすればいいだけの話
0694デフォルトの名無しさん
垢版 |
2020/11/08(日) 11:17:03.03ID:+pLcijcy
いちいち手作業でDBにつないで順番を間違えないように慎重にSQL実行して…
後で困らないようにどんなSQLを実行したかリリース履歴台帳に記入して…
手作業だからテストという概念もなくて…
これちょっとアナログすぎだしめんどくさいし間違えやすいんじゃねえか?って疑問を持つところがスタート地点
疑問すら持てないなら開発者として必要なセンスが欠けてる
紙とハンコのほうが性に合うオールドタイプならそのまま手作業を続けてどうぞ
ここは未開の原始時代

実行するSQLはファイルにしよう
SQLファイルのアップロードと実行はshellで自動化しよう
shellをソースコードと同じ所でバージョン管理したら便利だな
shellがバグってたらやばいから本番レプリケーションで事前にテストしよう
同じshellを間違えて実行したらやばいから実行履歴もテーブルで管理して多重実行を避けよう
これ全部1つのコマンドでできるように整備しよう
このように不便さを自動化で解消できたならすこしマシになった段階
産業革命の始まり
便利だけど色々と拙くまだまだコスパが悪い

shellは便利だけどオレオレ感が強くて属人生が高く保守しにくいな
なにか開発者間で共通認識となるフレームワークがあれば便利だろうな
MigrationをC#で書きたい場合もあるよな
そもそもshellの実行すらめんどくさいんじゃないか
などなど細かい不満点を解消していって出来上がったのがMigration系フレームワーク
ここがひとまずのゴール
より洗練されてエコな現代テクノロジの集大成
0695デフォルトの名無しさん
垢版 |
2020/11/08(日) 11:27:42.43ID:ywUIYUdi
ORM全般に言えることだけど、複雑になってくると使い物にならなくなる。
sansanもEFをDapperに置き換えたって発表してた。

正規化するのが正解じゃない時もあるし、サロゲートキーで対応
0696デフォルトの名無しさん
垢版 |
2020/11/08(日) 11:32:46.67ID:ywUIYUdi
途中で書き込んでしまった。
サロゲートキーだけではうまくいかない場合もある。
0697デフォルトの名無しさん
垢版 |
2020/11/08(日) 11:52:36.61ID:+pLcijcy
>>695
CQRSのCではEFのほうが遥かに洗練されてる
Qでは高速で複雑なSQLを書きたくなる場合が増えてくるのでDapperが有利になる

多くの開発者が複雑化したQのせいでEFは使えないと思い込んでいるがEFはDapperと共存可能だ

更にいうと昔と違ってEFは随分と速くなった
ネイティブSQLもサポートしている
Dapperに頼らなくてもQを上手く実装することができるようなってる
0699デフォルトの名無しさん
垢版 |
2020/11/08(日) 12:11:09.24ID:uTVwuNgX
>>697
もう全然Blazor関係ない話で恐縮だけど…

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

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

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

Dapperはパラメータで勝手にマッピングしてくれるから助かる。
0700デフォルトの名無しさん
垢版 |
2020/11/08(日) 12:42:48.71ID:QCCK7Xg4
>>699
postgresqlは特殊な仕様だからハマりやすいね
なのでNpgsqlのEFにはUseSnakeCaseNamingConventionというオプションがある
他のDBは特にハマった記憶がない
0701デフォルトの名無しさん
垢版 |
2020/11/08(日) 12:54:19.78ID:t+zVbDF+
>>692-693
逆だよ。CRUDにEF使うのは便利だから意味がある。
C#のコードが短くなるし直感的にかける

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

スキーマが自動生成のものでいいってのはDB知らない奴だな
てきとうにつくるとパフォーマンス劣化する
0702デフォルトの名無しさん
垢版 |
2020/11/08(日) 12:57:37.72ID:WJSuSySW
めんどくさいことになりそうな時は、RubyやRailsを勧めよう!
0703デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:03:31.26ID:t+zVbDF+
>>694
原始時代って履歴台帳なんて古臭い言葉つかってるおまえだろう

スキーマ変更したら直後にテストしてるに決まってる
あと間違いやすいのは複雑な手順をとるMigrationのほうだ
0704デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:08:46.91ID:QCCK7Xg4
>>701
最近のEFは良くなってる
ほぼ想像どおりのスキーマを出力してくれる
とはいえ完璧とも言えない

完璧を求めるならMigrationを生SQLで手書きすることもできる
SQLを手書きしたいという要求のためにMigrationの全機能を手放すのは惜しい
0705デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:11:07.00ID:t+zVbDF+
>>695
パフォーマンスの面でDapperは昔は意味あったとおもうけど
いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。

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

>>697
たしかにEF Core速くなってるね
あとストレージがSSDになったのも超大きい
0706デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:15:04.98ID:QCCK7Xg4
>>703
いやいやスキーマを変更したあとにテストじゃ遅いだろ
Migrationをしてからテストするんじゃない
テスト済のMigrationを適用するんだ

ちなみにMigrationはアプリケーションをデプロイするだけなので手順ミスは最小化される
手作業でSQLを実行するとSQL数に比例してミスが増える
0707デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:17:19.61ID:t+zVbDF+
>>704
ORM、DBのベンチマークたまに見てるし速くなってるのは知ってるよ。

ただstringとかの最適なデータサイズは開発者じゃないとわからないから
最適なスキーマ作ろうと思うとやっぱりSQLでスキーマ作成、変更したほうが
いいってのは今後も変わらないと思う
0708デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:25:09.54ID:t+zVbDF+
>>706
根本的に会話になってない
俺の言ってるスキーマ変更するってのは決定事項なんだよ
既に正常に動くプログラムがあってそれをスキーマ変更するんだから
スキーマ変更した後にテストしないと意味ない。

Migrationでrollbackすることもない
動くようになるまで必要ならばC#側を変更するからだ。
なんかうまく動かないからスキーマ変更やめましょうということにはならない。
0709デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:33:40.14ID:QCCK7Xg4
>>707
EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ

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

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

更に加えてMigrationとして.NETのカスタムコードを実行することが可能だ
例えば今まで保護されていなかった個人情報をC#で暗号化して保存し直すといったことも可能だ
手作業でSQLを実行する
0711デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:38:33.92ID:QCCK7Xg4
>>708
決定事項だろうがなんだろうがテストは必要だ

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

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

もちろん適用したあとに最終チェックとしてテストを行うことはこちらとしても全く否定していない
0712デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:39:48.71ID:uTVwuNgX
>>700
そんなのあるのか。EFにもどろうかなあ。
あとはバルクインサートやバルクアップデートができたら完璧。
0713デフォルトの名無しさん
垢版 |
2020/11/08(日) 13:47:17.26ID:QCCK7Xg4
なおMigrationとその後のテストのどちらかが失敗した場合は
途中まで適用したMigrationをロールバックしなければならない
ロールバックはEFの機能で行うかDBバックアップをリストアするかどちらかだが
EFの機能で実施したほうが圧倒的に速い
リストアは最後の手段と考えよう

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

バグがあったらロールバックを行い
Migrationとアプリケーション双方を見直し修整しテストする
テストした後にまたMigrationを適用する
これが現代人の働き方だ
0714デフォルトの名無しさん
垢版 |
2020/11/08(日) 14:14:26.86ID:jcyTFABg
そういやMigrationって、データベースのデータの移行とかはできるもんなの?
できるのなら素人保守のSQLServerからPostgreSQLのマネージドデータベースに変えたいんだけど・・・・
0715デフォルトの名無しさん
垢版 |
2020/11/08(日) 15:17:40.45ID:SqlrOE3Q
>>714
自分でコードを書けば柔軟できると思うけど
あるクラスのあるプロパティを別のクラスに移したいみたいなのは
自動生成では無理だと思う。

個人的にはmigrationは本番環境で使うものじゃなくて
開発中のコードとそれテストするときのデータベースの同期を楽にするもの程度で認識してる
0716デフォルトの名無しさん
垢版 |
2020/11/08(日) 15:20:50.04ID:t+zVbDF+
>>714
Entity FrameworkのMigrationはそういう機能はないよ
スキーマ変更の履歴を保持してロールバックとかができるだけ
俺はロールバックしたことないからめんどくさくなってMigration使ってない

Managedの維持費のがSQL Serverのオンプレミス維持費より高いんでは?
SQL Serverなんてバックアップ、リカバリできれば運用かんたんでしょう
DBの種類変更したらデータ型互換性なくなるから慎重にテストしないといけない。
よほど問題ない限り安定稼働してるDBはいじらんほうがいいとおもうよ
0718デフォルトの名無しさん
垢版 |
2020/11/09(月) 22:46:28.72ID:FJFkj8NC
朝は動いていたStateHasChangedメソッドが、
昼になったら動かなくなった。
こんなセリフは一生使わないと思っていたが使わしてもらう。
何もしてないのに壊れた。
0721デフォルトの名無しさん
垢版 |
2020/11/10(火) 13:07:54.58ID:XgTQB9rm
長時間動かしてたんだったら、ゴミだと間違われてGCに回収されちゃったんじゃないの?
0723デフォルトの名無しさん
垢版 |
2020/11/10(火) 20:49:01.81ID:qdwPUA+1
Nuget使って気付いたけど.NET 5.0来てるな

RCなの知らずにNugetでUpdateしてしまった
0724718
垢版 |
2020/11/10(火) 21:35:46.33ID:MSfr+cVE
処理済み件数/全件数のパーセンテージ出してたんだけど
数値の型変えたり、全件数のカウントを変数に入れたりしたら出るようになったわ。
なんだったろうなあ…
なんらかの呼吸が悪さしたんだろうな…
0725デフォルトの名無しさん
垢版 |
2020/11/10(火) 21:42:11.59ID:qdwPUA+1
リリースノート見ると.NET 5.0 RC2けっこう前にでてたようだ
EFとかはNugetのPackageで5.0対応のがでてそれで気付いた。
バグ人柱になりたくないのでもう少し.NET Core3.1でいくわ

.NET Coreという名前ももうおしまいみたいだし
0727デフォルトの名無しさん
垢版 |
2020/11/11(水) 07:22:02.02ID:euPQaLy/
デバッグに至るまでになかなか時間がかかるんだが、皆さんPCのスペックどれくらい積んでますか
会社のパソコンSSDは積んでるけど、メモリが8GBしかない。
0728デフォルトの名無しさん
垢版 |
2020/11/11(水) 07:47:11.57ID:PR+fp9tK
>>727
8GBあれば仮想化以外は余裕でしょ
遅いならCPUがへぼすぎるんじゃないかな?
CPU型番とPassmarkスコアは?
Dockerとかの仮想化つかってる?
仮想化つかうと滅茶苦茶おもいのは仕方ない

あとVisual Studioの中のSQL Server Object Explorer
あれは重すぎるな
DB専用の管理ツール使うほうが快適
0729デフォルトの名無しさん
垢版 |
2020/11/11(水) 12:45:25.01ID:z8u+cv+u
新規開発をするに当たってフロントの言語選定に悩む
Blazorを選択したいところなんだけどSilverLightのハシゴ外をされた件が怖すぎて
0730デフォルトの名無しさん
垢版 |
2020/11/11(水) 12:47:54.87ID:z8u+cv+u
クライアント版で開発すればサーバー側の実装まで一緒に死ぬことはないと思われるんだけど…
ReactじゃなくてBlazorを選ぶのか?と言われると揺らぐ
0731デフォルトの名無しさん
垢版 |
2020/11/11(水) 13:30:01.83ID:7A3xK0xJ
>>729
あれはブラウザー内にデスクトップアプリ
動かすようなレベルのもんだから
何もってきても無理じゃね?
0733デフォルトの名無しさん
垢版 |
2020/11/11(水) 14:55:53.43ID:PR+fp9tK
>>729
Silverlightと違ってWasmはstandardだから無くならない。

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

Blazor WebAssemblyならば、
server-sideをASP.NET MVC + Web APIsで作るわけで
これ以上、安心できるserver-sideはないだろう。
速度も速いし長期サポートあるしC#使えるし。
もしBlazor廃れたらWeb UI frameworkだけ入れ替えればいい
0734デフォルトの名無しさん
垢版 |
2020/11/11(水) 16:54:13.95ID:zCFWfmOs
速度が速いとウソをつく

激遅の現状を突っ込まれる

速度など問題じゃないと強がる
0736デフォルトの名無しさん
垢版 |
2020/11/11(水) 17:34:11.90ID:RGkWwZkF
ドキュメントを読んでいて、コンポーネント間コミュニケーションのパラメーターやカスケードパラメーターが出てきたんだけどさ
便利そうだけど、これって使ったらコンポーネント同士が強固に依存しちゃうんじゃないの?
ファイルの編集・差し替えを繰り返すうちにスパゲティー化してきたり、いつか破綻しちゃわないか気になるな
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
0737デフォルトの名無しさん
垢版 |
2020/11/11(水) 18:34:49.69ID:z8u+cv+u
>>733
MSのLTSはあまり期待してないなぁ
ソース管理についてもTFSがフェードアウトしてる感あるよね?
かと言って、Githubにデータ移行はできないし
MSはこういう所が横暴でロックインし難い
0738デフォルトの名無しさん
垢版 |
2020/11/11(水) 18:50:22.79ID:iQgtLl5J
>>736
上位コンポーネントからパラメータで渡す分には問題ないと思う
通常のプログラミングでいうと関数的な使い方

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

パラメータで渡さない場合は状態を管理するクラスを1個作ってInjectするといい
コンポーネントからはこのクラス経由でしか状態にアクセスしない
これはインメモリリポジトリのようなもの
0739デフォルトの名無しさん
垢版 |
2020/11/11(水) 19:05:28.34ID:PR+fp9tK
>>734-735
backendのベンチマークだ
JavaやC#が動的言語より速いのは常識
知らないやつは初心者

>>735
また計測不能ばかりのクソサイト張る無能
楽天も計測不能
0740デフォルトの名無しさん
垢版 |
2020/11/11(水) 19:07:30.66ID:PR+fp9tK
>>737
LTSは同類のほかのソフト出さないって意味じゃないだろ
セキュリティパッチ出てるならサポートしてるってこと
Googleとか他社はそれすらできてない
0741デフォルトの名無しさん
垢版 |
2020/11/11(水) 19:23:06.81ID:TxKdQIKG
遅さに関してはMSの責任者が10倍遅いと言ってるし、
実際使うとともっさりしてんだよな。
サーバサイドのよりましだけど。
0742デフォルトの名無しさん
垢版 |
2020/11/11(水) 19:32:33.32ID:PR+fp9tK
>>741
10倍遅いというその発言も捏造
JS interopは.NET 5でかなり高速化したと発表されてる

wasmはよほどしょぼいハードの人以外は問題ないスピードになってる
0743デフォルトの名無しさん
垢版 |
2020/11/11(水) 19:46:14.98ID:TxKdQIKG
でも実際使うとともっさりしてんだよ。
JS interopの影響なのだろうけど、
処理概要を聞いたら感覚的に卒倒しとうなアーキテクチャだ。

サーバサイドのよりましだけど。
0744デフォルトの名無しさん
垢版 |
2020/11/11(水) 20:34:50.42ID:PR+fp9tK
むやみにevent呼ばなければ遅くならない
高速化のtipsも書かれてる
Blazor Serverの名前も出てこないようだしまともに
ドキュメント読んでるとは思えない
0745デフォルトの名無しさん
垢版 |
2020/11/11(水) 20:39:05.32ID:zCFWfmOs
>>734 の予言、当たってしまうwwww
速度が速いとウソをつく ( >>733 )

激遅の現状を突っ込まれる ( >>735,741,743 )

速度など問題じゃないと強がる ( >>742 )
0747デフォルトの名無しさん
垢版 |
2020/11/11(水) 20:48:31.47ID:PR+fp9tK
>>745
おまえアーキテクチャ全然理解してないのがバレバレ
backendとfrontendの違いも
WasmとBlazor serverの違いもわかってない

おまえはjQueryおじかweb app作れない奴だろうな
0748デフォルトの名無しさん
垢版 |
2020/11/11(水) 20:51:59.41ID:TxKdQIKG
Blazorはもともと高性能を目指したものではないからなーー。

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

開発者自身も了解している事じゃないの?
開発スタートの経緯を聞いてもそう思う。
偶然の産物なんだよ。このプロダクトは。
0750デフォルトの名無しさん
垢版 |
2020/11/11(水) 22:17:54.32ID:PR+fp9tK
EdgeだけでもC#がnativeで動くようにしちゃえばいいのにな
MSがブラウザの独自エンジン開発放棄したのは失敗だった

まさかのIE12でもいいよ
C# native実行できちゃうやつな
0751デフォルトの名無しさん
垢版 |
2020/11/11(水) 22:59:52.25ID:y64JAG21
メジャーフレームワークの事前ダウンロードオプションはそのうちサポートするんじゃないの
それか単にブラウザ拡張を作ればいい
事前キャッシュするだけだから簡単だろう
0752デフォルトの名無しさん
垢版 |
2020/11/12(木) 00:16:11.70ID:5db75by5
フロントは使い捨てと書いてる人いるけど
フロント側でC#がガンガンうごくので、
APIがデータベースの土管になって、データ加工して表示するロジックとかrazor側にガリガリ書いちゃってる。これまずいのかな。
いやでもそれがwasmのメリットだよな…
0753デフォルトの名無しさん
垢版 |
2020/11/12(木) 01:50:40.38ID:NTmEPJN8
いいよ
UIにまつわるダーティな処理はクライアントでやろうがサーバーでやろうがUI入れ替えとともに消える運命
0754デフォルトの名無しさん
垢版 |
2020/11/12(木) 03:08:04.23ID:1tLZbmtr
>>752
クライアント(View)は表示のみですね。
クライアントなくても、Curl等でAPI直叩きで業務が流せればOKです。

それが出来ないような実装なら、単体テスト出来ないでしょ。
0755デフォルトの名無しさん
垢版 |
2020/11/12(木) 05:45:40.02ID:VInW0j8K
>>752
データ表示に関するコードはwasm内でやるべきでしょ
なるべくclient-sideでやってserver-sideをスケールしやすくする。
0757デフォルトの名無しさん
垢版 |
2020/11/12(木) 10:03:52.41ID:a1NEuwV/
>>752
それC#だからとか関係なくね?
業務ロジックはサーバーサイドで、データが取得できたあと表示に関する部分はどうぞご自由に、というのが手離れの良い設計だと思う
0758デフォルトの名無しさん
垢版 |
2020/11/12(木) 10:30:35.87ID:NTmEPJN8
ドメインモデルとプレゼンテーションモデルの変換はプレゼンテーションで行うのが正解

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

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

Blazorなら変換処理もC#で快適に実装できるのでいちいちバックエンドにやらせる必要はない
バックエンドはドメインモデルをJSONで返すだけでよい
これが世界中の開発者が本当に求めていたものだ
0764デフォルトの名無しさん
垢版 |
2020/11/12(木) 11:34:11.07ID:VInW0j8K
>>760
アホだ。最適化が終わってないだけは安定してないとはいわない。

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

深刻なのはコピペしかできない>>760の頭の悪さ
>>756 でゲームデモで論破された
0766デフォルトの名無しさん
垢版 |
2020/11/12(木) 12:15:23.47ID:50stAN1W
5の次がLTSだっけ
Blazorもそこに合わせて仕上げてくるだろうね
いよいよだ
さよならJavaScript
0767デフォルトの名無しさん
垢版 |
2020/11/12(木) 13:32:02.28ID:uK53dAw4
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)
0770デフォルトの名無しさん
垢版 |
2020/11/12(木) 14:11:17.34ID:uK53dAw4
エッ!一年前から遅い遅い指摘されてたのに、まだ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: :♯|     ((・|・))   !    「延期!」
  ヽ: : /^ヽ、 _ ノっ _ ノ−、
   |: :|   \_/^\/^\_:ノ
   |: :|               \
 /⌒\ヽ (⌒ヽ⌒)   ))
 |    \\_/^\_/ノ _____
 |     \─┬─ ´ |        |_
 |.  \.   \ |   \  |   延期 (_)
 |     \     \./ ̄ ̄)       (_)
        \   /     ̄)        |
0771デフォルトの名無しさん
垢版 |
2020/11/12(木) 14:16:03.74ID:1tLZbmtr
遅さはAOTだけで改善出来るもんじゃないと思う。
WASMと期待させておきながら、
画面描画を全部JSでやるという仕様が回避できなければ、
永遠に遅いままかと。
0772デフォルトの名無しさん
垢版 |
2020/11/12(木) 15:12:17.29ID:BTLciJco
>>754
この人だけ意見が違う…
取得するデータごとに違うapi用意しだしたら、業務システムとか大変なことになるんだが…
0773デフォルトの名無しさん
垢版 |
2020/11/12(木) 20:31:18.84ID:T/ltJ8kq
サーバーサイドと言語を揃えれるのがいいね
.NET5でLinuxデスクトップもサポートされるようだし
これでC#大統一理論にまた一歩近づいた
0774デフォルトの名無しさん
垢版 |
2020/11/12(木) 21:39:57.08ID:VInW0j8K
やっぱり.NET5の正式版でてた
https://dotnet.microsoft.com/download/dotnet/5.0

>>723 >>725
でNuGetにだけ.NET5出てきて混乱したが
webの更新が遅れていただけのようだ
さっそく.NET5.0に入れかえよう
0776デフォルトの名無しさん
垢版 |
2020/11/13(金) 17:22:02.50ID:0SZnzCKt
「Python」生みの親グイド・ヴァンロッサム氏、マイクロソフトに入社 - CNET Japan:
https://japan.cnet.com/article/35162404/

MSがPython開発者もとりこんできたぞ
どうなるんだこれ
0778デフォルトの名無しさん
垢版 |
2020/11/13(金) 20:05:27.67ID:0SZnzCKt
静的言語じゃないからASP.NETやwpfはpython対応しないだろうな
0780デフォルトの名無しさん
垢版 |
2020/11/14(土) 21:54:51.97ID:so9GdEvw
純粋Pythonの話
IronPythonは良く知らない

.NET5でF#もバージョンアップしてるようだけど
あまり流行ってる気がしない
0781デフォルトの名無しさん
垢版 |
2020/11/16(月) 10:49:42.55ID:avD8L72D
Blazor WebAssembly、難しすぎる
Identyと
ASP.NET CorehostedありでProject作ると
counterのデモすら動かない。
Authorizingがでたまま止まる。
ブラウザ下にはunhandled exception。unhandledは現状デバッグできないらしい

dotnet v3.1でも.NET 5.0でも同じ。
Identity Serverのしっかり学習して設定しないとデモすら動かないのかな?
hostedのWasm、これどうやって動かすの
0782デフォルトの名無しさん
垢版 |
2020/11/16(月) 11:00:59.37ID:avD8L72D
wasmはunhandled exceptionが対応するまでハードル高い気がした
どこが間違ってるのか見当がつかないので大変だわ
0783デフォルトの名無しさん
垢版 |
2020/11/16(月) 12:23:29.18ID:Ud7NUROw
デバッグはちょっとしんどいよな
普通にC#で開発するときの生産性を期待するとガッカリする
まあそのへんもまだ黎明期ってことで時間が解決するだろうけど
0784デフォルトの名無しさん
垢版 |
2020/11/16(月) 12:51:41.00ID:xbUtcVVl
ほんまそれ
try catchで飛ばしても
エラー内容が改行されてないから見づらい。
0786デフォルトの名無しさん
垢版 |
2020/11/16(月) 22:44:17.44ID:avD8L72D
WebAssemblyはガチでやる前に挫折した
Wasmはunhandled exceptionとか機能が充実するまで待つとする

Front何で作ろうかな
Blazor Serverは人数増えたらスケールしなくて破綻しそうだし
ReactはJS/TSでだるいし。
XamarinかFlutterでも始めるかな
Flutter for Web使ってる人いるかな
0788デフォルトの名無しさん
垢版 |
2020/11/17(火) 08:39:28.22ID:cTR5hN6k
何を作るかによるけど、サーバーサイドと型の共有ができないと色々めんどくさい

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

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

ホットリロードそのうちできるみたいな記事を海外のTwitterかなんかで見た気がするんだけどどうなったんだろう。
0790デフォルトの名無しさん
垢版 |
2020/11/17(火) 09:32:33.92ID:cTR5hN6k
.NET6が出たら起こしてくれ
0791デフォルトの名無しさん
垢版 |
2020/11/17(火) 10:07:43.97ID:WUYxAqUP
スレ違い宣伝爆撃で荒らし回ってたのってやっぱりMSの工作員だったんだな。
MSKK社員はコーディングできないしステマしか仕事ないんだろうなw
0792デフォルトの名無しさん
垢版 |
2020/11/17(火) 11:43:25.58ID:tHQku81F
>>787
そのふたつちょっと調べてみたがJSへtranspileする言語だな
transpileで我慢するならTSのがましな気がする
0794デフォルトの名無しさん
垢版 |
2020/11/17(火) 11:54:00.50ID:tHQku81F
>>790
1年後の.NET6の前にベータで機能追加くるだろうし
たまにリリースノートとかチェックすればいいんじゃないか
0795デフォルトの名無しさん
垢版 |
2020/11/17(火) 11:57:26.47ID:cTR5hN6k
>>794
いや、起こしてくれ
0796デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:03:11.01ID:tHQku81F
.NET6はLinux desktopも対応予定らしい。
Blazor WebAssemblyいじって気づいたけど
実はXamarion.Forms最強じゃないか?

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

Windows, iOS, Androidで動くなら手間かけてweb appにする意味なくない?
0797デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:09:39.89ID:tHQku81F
>>795
Hot reloadはXamarin.FormsやFlutterにあるようだぞ
0798デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:18:47.63ID:OuU2HSO4
C#大統一理論、もしかして現実的な話だったのか
世界最高シェアのwindowsと相性抜群
主要デスクトップ、サーバーで動く
モバイルも簡単、ゲームもUnityがある
ブラウザでも動く
今後増えてくるWasmエッジ環境でも動く
これらが圧倒的高生産性のVS、VSCodeで開発可能
0799デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:29:20.42ID:cTR5hN6k
他は知らんけどBlazorに関してはその高い生産性とやらが出せてから言えって感じ。

自分もC#好きだからMSには頑張ってほしいけど、こうも中途半端だと、
世間には悪い印象しか与えないんじゃないかな。

何でもかんでも手を出してる&早くリリースすることが悪い方向に行っている気がするなあ。
0800デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:40:15.42ID:cTR5hN6k
>>796
Nativeアプリは配布が一手間だからWebアプリで済むならWebアプリで済ましたいわけですよ
0802デフォルトの名無しさん
垢版 |
2020/11/17(火) 12:59:14.17ID:d47VTbpo
>>801
関係なくない?
何回かこの議論さてる気がするけど…
結局作ったシステムを納品する先の環境に左右される
お客さんによってはネイティブアプリ禁止なところも最近増えてきている。
特に事務系のシステムはWebじゃないとはねられることが多い。
0803デフォルトの名無しさん
垢版 |
2020/11/17(火) 13:13:53.11ID:tHQku81F
>>802
利用者がだれなのかは決定的に大事なとこだ
法人なら一括でかんたんにインストールできる

Deployを理由にweb appにしてくれというなら
その企業のシステム部門が無能なだけ
かんたんにdeployする方法を教えてやれば方針も変わる。
web appはnativeに比べて従業員の生産性も落ちる。
開発の納期も延びてコストも増える
0804デフォルトの名無しさん
垢版 |
2020/11/17(火) 13:22:55.71ID:K5jaH1V5
いまのBlazorは生産性最悪ですよ。
でたばっかの製品版なんでしょうがないちゃそうなんですけど、
MSが言ってる通りはなからJS使えないWebForm向けのエンジニア救済用と思えました。
0807デフォルトの名無しさん
垢版 |
2020/11/17(火) 13:36:36.60ID:aCu5ED3V
Webアプリっていってもなぁ
社内オンプレに納品だとSSL通信が厳しい。
やろうとすると色々めんどい上に高くなるし。
0808デフォルトの名無しさん
垢版 |
2020/11/17(火) 14:02:12.68ID:d47VTbpo
>>803
そのシステム部門に合わせるのも大事
少なくともWebアプリよりハードルが高いのは確かなんだから、楽な方選んでくるでしょ。

Blazorの登場によって生産性も高くて配布も不要になる!
と思ったがそうでもなかったって話だな。
0809デフォルトの名無しさん
垢版 |
2020/11/17(火) 16:32:14.62ID:tHQku81F
>>804 >>806
生産性問題あるのは「Blazor WebAsssemblyは」じゃないのか?
Blazor Serverは楽だと思ったよ

Blazor Serverはスケールしないから不特定多数には向かないが
人数が予測できる社内利用ならありだとおもう
0810デフォルトの名無しさん
垢版 |
2020/11/17(火) 16:39:05.00ID:tHQku81F
>>808
Web appよりもXamarinのが楽だよ
YouTubeでXamarinのtutorial, 入門動画見てみなよ
C#使える人ならすんなりはいっていけるし
UIまわり超楽だからひとりでフルスタックやるのも無理はない。

特にReactやBlazor WebAssemblyいじった後なら天国と思えるはず
0811デフォルトの名無しさん
垢版 |
2020/11/17(火) 18:15:41.07ID:d47VTbpo
>>809
社内ツールをwasmで作ったが、作り替えよかな…

>>810
Blazorを使う=何かしらネイティブアプリが使えない事情があるんだろう。その誘導は的外れでは?
0812デフォルトの名無しさん
垢版 |
2020/11/17(火) 19:04:47.83ID:/SVnFee8
BlazorはServerでもWasmでも
ウェブ配信でもバイナリ配信でもフレームワーク前提の配信でも
なんでもOK
おそらく今最も配信しやすいフレームワーク
0813デフォルトの名無しさん
垢版 |
2020/11/17(火) 20:13:50.48ID:d47VTbpo
早速BlazorSeverためしてみたが
確かにこれは生産性高そう。
api設計もいらないし。

スケーラビリティの問題はあるが、百人前後で使うような
業務システム系はこれでいいんじゃなかろうか

しかし…

SignalRで動くというのがなんとも気持ち悪い…
他の言語でもSignalRみたいな仕組みで動いてるアプリとかるのかな…

あとStartupでひたすらAddSingletonしてるのも気になる…
Serviceが数十〜百とかになっても耐えれるのだろうか。
0814デフォルトの名無しさん
垢版 |
2020/11/17(火) 20:28:32.57ID:tHQku81F
>>811
前半
何から何への作り替え?既に安定稼働してるならいいのでは。

後半
システム管理の知識ないひとはdeploy大変と思い込んでる場合多いし
なんとなくまわりにあわせてweb appにしちゃってるところがほとんどだと思う。
0815デフォルトの名無しさん
垢版 |
2020/11/17(火) 21:52:47.55ID:d47VTbpo
>>814
前半
Blazor wasmからBlazor Severへ作り替え。
小さなシステム&Blazorの実験なので作り替えることは苦ではない。
それよりwasmの生産性の低さがつらい。


後半
他のシステムがWebでそこにネイティブアプリ入れるほうが逆にハードルが高かったりする。

そのシステム管理の知識をお客さんの情報部門に強要できないしな。

自分もなんでもWebシステムであることに懐疑的で、これまではWebではなくてネイティブを選択してきた。
しかし、近年フロントの仕組みが成熟してきた(ネイティブに比べたらまだまだだけど)ので
逆に配布の手間がネックになりつつあるなあと。

よっぽど複雑なシステム(医療系?)であればWebは選ばないけどね…
0816デフォルトの名無しさん
垢版 |
2020/11/17(火) 22:38:10.95ID:zxVBZ18I
前言撤回
やはりBlazorServerはなんか邪道な気がする
そのうちMSが
新規プロジェクトで選択しないでくださいとか言い出しそう
一年なんてあっという間だし.NET6まで待ちますかね。
0817デフォルトの名無しさん
垢版 |
2020/11/18(水) 01:18:37.94ID:a0JYJX3/
>>816
だから最高の生産性ならWPFかXamarinだって。
速度も速いし使いやすい。
本来、業務用ならばWeb appなんて消去法で
最後に仕方なく選ぶものだと思ってる。

deployなんてかんたん。
管理者が無能で一括でdeployができなければ
2,3回クリックするだけでインストールできるようにすればいい。
0820デフォルトの名無しさん
垢版 |
2020/11/18(水) 08:28:53.23ID:zyZ9fm9I
完成したら最強になる候補ならUNO Plathomeだろ
UWPで開発してそのまんまBlazorとxamarinに翻訳して実行できる
0821デフォルトの名無しさん
垢版 |
2020/11/18(水) 09:45:23.20ID:a0JYJX3/
>>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の未来というテーマで共通してる
0822デフォルトの名無しさん
垢版 |
2020/11/18(水) 10:05:51.21ID:a0JYJX3/
>>820
UNO platform、こんなのもあるのか

https://platform.uno/how-it-works/
ここみるとUNOはC# + XAMLで開発とある。
Xamarin. Formsと一緒だ
結局、生産性を考えたらUIをHTML + CSSでやるのはゴミだってことだろうな。

>>819
MAUIのブラウザ対応といいたいのかな
XAMLで書いてHTML, CSSの世界との変換も自動でやるわけ?
WebAssemblyが難航してるの見ても簡単に行くとは思えない
0825デフォルトの名無しさん
垢版 |
2020/11/18(水) 19:24:39.13ID:a0JYJX3/
>>824
いつ頃のバージョン?失望したところは?

FlutterのがXamarinやReact Nativeより満足度高いらしいな
俺もさわっては見るつもりだ

ただFlutterはWindowsの対応予定ないのが難点
Flutter webもbetaだからwindows対応が問題になる
0827デフォルトの名無しさん
垢版 |
2020/11/19(木) 09:57:21.01ID:/BwiR0R4
>>826
すばらしい
FlutterもWindows appいけるようになるのか、いいね
早くweb appの必要のない世界が来て欲しいわ

Compose for Desktopはまだ時間かかりそう

クロスプラットフォーム開発では現時点ではXamarinとFlutterが抜け出ている感じかな
React Nativeはもうだめそう
0828デフォルトの名無しさん
垢版 |
2020/11/19(木) 10:25:28.40ID:IwXUzkye
ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www
0830デフォルトの名無しさん
垢版 |
2020/11/19(木) 10:48:15.14ID:/BwiR0R4
>>828
それはFlutterのが新しいからだ
FlutterやってるひとはReact Nativeやってた人が多く、
React Nativeはゴミだといってる
バグが多い
JSを使うから生産性が低い
ホットリロードも対応してない

Facebookが作る開発ツールってたいていゴミだな
ほぼすべて消える
0832デフォルトの名無しさん
垢版 |
2020/11/19(木) 11:05:49.18ID:IwXUzkye
>>830
ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www
0833デフォルトの名無しさん
垢版 |
2020/11/19(木) 11:10:40.94ID:/BwiR0R4
>>831
https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/
ここみると2020年のFlutterの伸びがすごい
来年はトップになるのは確実に見える

これ見るとXamarinは人気落ちてるのか
C#慣れてるし好きだからXamarinいいかなと思ったんだけど
いま開発者に人気なのはFlutterっぽいんだよな

C#使いにとってはReact NativeはJSってだけで候補外だろう
0834デフォルトの名無しさん
垢版 |
2020/11/19(木) 11:14:46.79ID:IwXUzkye
>>833
ほーん?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww
Xamarinは?www
Flutterは?www

恥ずかしがってないで書けよwww
まさかひとつも無いなんてことはないだろwww
0836デフォルトの名無しさん
垢版 |
2020/11/19(木) 11:56:56.84ID:/BwiR0R4
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でもいいけど
0837デフォルトの名無しさん
垢版 |
2020/11/19(木) 11:59:58.77ID:IwXUzkye
ほーん?www
で?www
どんな素晴らしいアプリが出てるの?www
React Nativeは
Facebook
Instagram
Uber Eats
Tesla
Skype
Pinterest
SoundCloud Pulse
Walmart
Bloomberg
Discord
等々で使われてるけどwww

Xamarinは?www
Flutterは?www

一つくらい挙げたら?www
0838デフォルトの名無しさん
垢版 |
2020/11/19(木) 12:41:54.16ID:Bk7N6279
お前らが他の技術との比較を始めるから変なの呼び込むんやで
ここではblazorに集中せいよ
xamarinとflutterの話は専用スレでやれ
0839デフォルトの名無しさん
垢版 |
2020/11/19(木) 12:58:45.72ID:E4v7ecNJ
vs+C#に慣れすぎた身からすると、vscode+tsが苦行にしか見えなくて、手を出したくない。

でもこんなにjs界隈が盛り上がってるということは
自分が知らないだけで、いざバリバリ使い出したら新しい世界が広がって実は素晴らしいものなのかもしれない。

今の自分は、かつてコボラーがJavaに手を出さなかったのと同じことなのかもしれない。
0840デフォルトの名無しさん
垢版 |
2020/11/19(木) 13:06:03.37ID:6wV8xy2P
C#erこそTSへの移行じゃねえの?
アンダースヘルスバーグ入魂の一刀やで。

C#で出来んかった事を
ここでやらんとしていることが垣間見えるぞい。
0841デフォルトの名無しさん
垢版 |
2020/11/19(木) 14:01:29.27ID:E4v7ecNJ
TSって金融系の大規模システムにも使えるんだろうか
0844デフォルトの名無しさん
垢版 |
2020/11/19(木) 15:02:26.21ID:ghw9ch45
相変わらずフカシこいてんなwww
Blazor serverでjsのコーディング量が減る?wwww
今までサーバーでnodeでも使ってたのか?wwwww
適当なインチキ宣伝ばっかだなこいつwwwwww
0847デフォルトの名無しさん
垢版 |
2020/11/19(木) 16:16:17.03ID:E4v7ecNJ
そら減るんじゃないの
それが目的のフレームワークなんだし
ゼロにはならないだろけど
0848デフォルトの名無しさん
垢版 |
2020/11/19(木) 16:19:41.58ID:E4v7ecNJ
>>846
大規模だけじゃなくて
金融系とかかっちりしたやつ
大量データのお金や税の計算するやつ
0849デフォルトの名無しさん
垢版 |
2020/11/19(木) 16:30:42.57ID:/BwiR0R4
>>841
嘘つきに騙されるなよ
金融といってもいろいろあるが
金融の勘定系のバックエンドでそもそもスクリプトが使われない
速度と信頼性から静的言語が使われる
COBOL, Java, C#, Cなどだ
Angularなど実績の少ないものは使われない

金融は保守的だから新しい技術を避けたがる
0850デフォルトの名無しさん
垢版 |
2020/11/19(木) 16:35:25.87ID:/BwiR0R4
COBOLは言語としてはゴミだが
昔からCOBOLが多いから保守的な企業は
いまでもCOBOLでやりたがる
0852デフォルトの名無しさん
垢版 |
2020/11/19(木) 17:05:37.36ID:IwXUzkye
>>849
↑バックエンドとフロントエンドの区別もつかない糞ザコナメクジwww

> COBOL, Java, C#, Cなどだ
> Angularなど実績の少ないものは使われない

サーバ側言語とフロントエンドフレームワーク比べてなにがしたいんだこのカスwwwww

何がどこで動くのかもわからんのかwwwww
0853デフォルトの名無しさん
垢版 |
2020/11/19(木) 17:09:16.62ID:L0C3WtGE
>>851
「blazor serverにしたらjsの記述量がゼロになった」ということは、
今までのサーバーはnodejsだったということでOK?w
サーバー側にjsの記述があったから、
「ゼロになった」んだよね?ww
0854デフォルトの名無しさん
垢版 |
2020/11/19(木) 17:29:20.86ID:/BwiR0R4
>>852
>>846がAngularなんて書いてるから上げてる
区別がついてないわけないだろ
英語読めずに的外れなコピペしてるおまえみたいな無能と一緒にするな
0859デフォルトの名無しさん
垢版 |
2020/11/19(木) 18:58:23.04ID:/BwiR0R4
FlutterとXamarinはスレ立ってたのでリンクはっておいた
ただその話題を排除したらこのスレ過疎るよな

Wasmまだデバッグ的に使うの難しい状態だし
Blazor Serverは使いどころが限られる。
個人的にスケールしにくい技術は使わない
0860デフォルトの名無しさん
垢版 |
2020/11/19(木) 19:25:56.56ID:E4v7ecNJ
>>852
バックエンドでもts動くのでは?
やるならフロントとバックの言語は合わせたい

C#erなのでBlazorに手を出したい一方で
tsに鞍替えしようと言う案もある
やってる業務が金融系なんだけど、耐えれるのかなあと。。
0863デフォルトの名無しさん
垢版 |
2020/11/19(木) 20:13:51.56ID:E4v7ecNJ
>>862
そこもなやみどころですよ
そりゃwasmにしたいけど、生産性に難あり、api設計地獄にはまりそう。

Serverは既存資産が活かせそうだけど
スケーラビリティに難あり。負荷分散装置挟んだらセッション管理で地獄を見そうだ。
結局やってることは画面転送型のシンクライアントと変わらん気もする。

いまやるならServerかな…
.NET6になってwasmの生産性がマシになってたらwasmかな
0864デフォルトの名無しさん
垢版 |
2020/11/19(木) 20:27:30.61ID:E4v7ecNJ
あと機能数が100超えるようなプロジェクトになっても絶えれるのかも気になるところだな
0865デフォルトの名無しさん
垢版 |
2020/11/19(木) 20:34:37.76ID:/BwiR0R4
>>863
Blazor Serverでスケールしなくて失敗したら
無能のレッテル貼られるぞw
SignalRは単純にロードバランサーでスケールさせることはできない。

今やるならASP.NET MVCかXamarinかFlutterだろ
0866デフォルトの名無しさん
垢版 |
2020/11/19(木) 20:51:11.28ID:6wV8xy2P
>>849
なんでバックエンドにangularがあんのよ。
バックエンドは大半がJavaでしょ。
新規はしらんけど。
0868デフォルトの名無しさん
垢版 |
2020/11/19(木) 21:14:08.18ID:oD3ERJjk
>>867
言語ってサーバーとクライアントで同じ方がメリット多いと思うんだけど…
0869デフォルトの名無しさん
垢版 |
2020/11/19(木) 21:21:44.76ID:/BwiR0R4
>>866
だから6行目は話が別だっての
読解力ないな
>>854を嫁
Angularが使われてるとか嘘ついてる人いたから
そもそも勘定系は保守的でスクリプトではなく
型のある言語でやるって話だ
0871デフォルトの名無しさん
垢版 |
2020/11/19(木) 21:27:10.31ID:/BwiR0R4
>>866
なんだ、最初にAngularとかずれたこと言い出したアホはおまえじゃないかよw
大規模とかいってるんだからふつうserver-sideの話ととらえるわ
client-sideだけのAngularなら規模は関係ないし
スクリプトしかできない奴なのがバレバレだぞ
0873デフォルトの名無しさん
垢版 |
2020/11/19(木) 21:36:09.88ID:oD3ERJjk
なんかごじれてるな…改めて聞くけど、
大規模、お堅い系業務システムで
バックエンドもフロントエンドもjs系の言語、フレームワークを使うのは現実的なんだろうか。
0875873
垢版 |
2020/11/19(木) 22:05:29.50ID:oD3ERJjk
だよね

>>828に挙げられているようなアプリでは適してるんだろうけど
>>873のような要件では使うべきではない。

俺が書いた>>841に対する回答の>>846は、大規模というキーワードだけ注目しただけっぽい。
大量のユーザーが使うアプリもある意味大規模だからまあ分からんでもない。
ただ>>873のような要件で使えるかは改めて回答してほしい。
0876デフォルトの名無しさん
垢版 |
2020/11/19(木) 22:57:09.23ID:uhtBmVv9
なんで何処にでもアンチって湧くんだろうな
アンチの活動なんてこういう情強がいるスレではなんの効果も無いのに
0877デフォルトの名無しさん
垢版 |
2020/11/19(木) 23:12:00.90ID:6wV8xy2P
>>868
大体バックエンドとフロント同じメンバーでやってるケースは小規模なシステムだけだろ。
 
打ち合わせでサーバーサイドのAPIの仕様にはガンガン突っ込むが、
なんで作ってるかなんて範疇外だし
ノウハウで秘密なザービスあって
呑み会ネタだよ。
0879デフォルトの名無しさん
垢版 |
2020/11/19(木) 23:25:30.74ID:ad/G+6fF
>>877
同じメンバー?同じ言語であってバックエンドとフロントが同じメンバーとは限らないよ。
でも、人の募集かけるときに複数の言語で募集かけずに済むし、バックエンドの人が余ったらフロントに回すとかもできるのはメリットかもしれない。

そこじゃなくて、言語が同じなら型の共有ができるとかそういうメリットがあるのでは?

>>877はバックエンドの経験なし?
そういう体制で作るのってゲームとか?

飲み会でwebassemblyの話題とかあがったりする?
0880デフォルトの名無しさん
垢版 |
2020/11/19(木) 23:43:39.31ID:fjzDtjlY
まさにフロントエンドとバックエンドを分けずに開発できるのは本当にいいね
0883デフォルトの名無しさん
垢版 |
2020/11/20(金) 00:12:34.09ID:b0yT42N3
フロントとバックの境目なく開発できるのが効率よすぎる
工数かなり削減できる
0884デフォルトの名無しさん
垢版 |
2020/11/20(金) 00:29:16.50ID:cjGOVOB+
>>878
このスレ眺めてると、いろいろアレすぎて
父ちゃん情けなくて涙が出てくらぁ
ですわ。
0885デフォルトの名無しさん
垢版 |
2020/11/20(金) 00:30:05.58ID:cjGOVOB+
うそです。独身です。
0886デフォルトの名無しさん
垢版 |
2020/11/20(金) 00:37:53.99ID:cjGOVOB+
>>880
>>883
あれだ。ね。
>>879
型の共有ってあれだ。設計がwww
>>バックエンドの経験なし?
大・中規模はなけいど小規模は沢山ある。
大・中規模はクラウド全盛であんたらの考えてるのとはレベルが違うぞい。
言語なんて依存するサービスによって使い分けるわーー。って感じ。

>>webassemblyの話題
あるねーー。おれ初?
0888デフォルトの名無しさん
垢版 |
2020/11/20(金) 08:23:03.67ID:SrYJCS3X
とりあえずバックエンドの経験はあまりなさそうだな
>>873の質問に答えて欲しかったが…

メガバンクや地銀が基幹システムをtsで作りました
みたいな事例は聞かないしな…
0890デフォルトの名無しさん
垢版 |
2020/11/20(金) 09:42:04.51ID:CQfd4Gtb
C#で作りました、なんて話は確かに聞かないな。COBOLからJavaの話ばかりだ。
あるというなら銀行名を挙げてみたまえw
0891デフォルトの名無しさん
垢版 |
2020/11/20(金) 09:49:41.56ID:SrYJCS3X
それもそうだな
まあとにかくスクリプト系言語では作られてないと言うことだな
向き不向きはあって当然だ。
0892デフォルトの名無しさん
垢版 |
2020/11/20(金) 09:57:20.62ID:1FMuX9Ox
COBOLからJavaにしたところは失敗だったな
ORACLEのせいでJavaは死んだ
C#にしておけばよかったのにな
0893デフォルトの名無しさん
垢版 |
2020/11/20(金) 10:08:18.94ID:cjGOVOB+
>>888
なんでそう極端な事になんの
0894デフォルトの名無しさん
垢版 |
2020/11/20(金) 10:11:09.55ID:cjGOVOB+
>>892
”ORACLEのせいでJavaは死んだ”
どんな状況ですか?
UIまわりはSwiftにシフトしてきてますが
0896デフォルトの名無しさん
垢版 |
2020/11/20(金) 10:21:52.03ID:YhokOqrJ
Javaが死んでSwiftにシフト?wwww
何いってんだこいつww
Swift使われてるiOSはJVMじゃねーよカス
JVM上でアプリ動くのはAndroidだボケwww
なんでJavaが死んでSwiftにシフトすんだこの嘘吐きウンコなすびがwwwww
0897デフォルトの名無しさん
垢版 |
2020/11/20(金) 10:28:43.39ID:yqtcV1e0
セキュリティ厳しい分野で有名なのだとパスワード管理のオープンソースで急速にシェアを伸ばしてるBitwardenがあるな
サーバーサイドC#、モバイルC#、ウェブTS、デスクトップTS、コマンドラインTS、データベースMS SQL Server
マイクロソフトにベッタリだけど、オープンソースでクロスプラットフォーム対応が完璧
クロスプラットフォームやるならマイクロソフトがGood、なんて少し昔なら信じられない時代が来たのかもしれん
0898デフォルトの名無しさん
垢版 |
2020/11/20(金) 10:44:07.34ID:1FMuX9Ox
>>894
死んだのはバックエンドの話な
Javaが実質有料化したから使う人減っただろう。
例えばJavaでもっとも流行っていたweb frameworkのSpringがシェア1%しかない。
https://www.wappalyzer.com/technologies/web-frameworks/

バックエンドJavaの代替言語としてC#の存在意義が高まっている
0899デフォルトの名無しさん
垢版 |
2020/11/20(金) 11:13:05.45ID:cjGOVOB+
>>898
”Javaの代替言語としてC#の存在意義が高まっている”
これまじ?C#やってると肩身が狭い思いをする事多々だったけど。

>>897
MSは開発環境に力いれてた時代はおわりましたよ。
MSの名前が前面にでると流行らないのでオープンソースでひっそりと。
MS直下の案件でもAngulr、Backbone.js、Knockout.js とか多かったですね。
そもそも今はクラウドで儲ける会社ですから。
0900デフォルトの名無しさん
垢版 |
2020/11/20(金) 11:25:04.53ID:yqtcV1e0
マイクロソフトってその絶大な人気のおかげでアンチも多いから人気がないって勘違いしちゃう人が居るんだろうね
アンチは往々にして人気に比例するものさ
0901デフォルトの名無しさん
垢版 |
2020/11/20(金) 11:36:45.70ID:cjGOVOB+
>>900
アンチ多いです。
飲み会とかだと非常に露骨なので、非常に肩身が狭いです。
通常会議の席でも、MSは...みたいな発言してくる人たまにいます。(苦笑)

tsとかはMSの影がチラつかなったから流行ったのだと思ってます。
つられてVS Codeがオープンソース界隈で天下とった感じ。
MacでもVS Code使ってる人多いですよ。
0902デフォルトの名無しさん
垢版 |
2020/11/20(金) 11:48:07.82ID:oV8KONP9
最強開発環境 VS
最強エディタ VSCode
最強型安全OOP言語 C#
最強型付スクリプト言語 TS
最強サーバーサイドWebフレームワーク ASP.NET(Core)
最強Wasmフレームワーク Blazor
最強モバイルフレームワーク Xamarin
最強ソース管理 GitHub
最強共同作業ツール Teams
最強クラウド Azure

全部マイクロソフトじゃんw
0903デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:06:12.55ID:CjY1gACz
>>902
最強共同作業ツール Teams
最強クラウド Azure

これは絶対に違うわ
TeamsはGithubとの親和性がいまいちなのでJiraの方がいい
クラウドサービスはAWS>>>>>>>Azureくらい差があるな
0904デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:06:39.52ID:SrYJCS3X
MSといえば最強OS Windowsでしょうが!

冗談はさておき、坊主憎けりゃ袈裟まで憎いな精神でMS嫌う人多いよね
どの企業もいいとこもあれば悪いとこあるのに。
いいとこ取りしたらいいんですよ。
0906デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:26:56.67ID:WciP5EDn
Javaの有償化でJava離れがあるにしても、なんでそれがC#に流れると思うんだろう
0907デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:27:44.94ID:cjGOVOB+
>>906
そうおもいますwww
0908デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:37:42.38ID:SrYJCS3X
JavaでもC#でもどっちでもいいんだけど、
俺がずっと聞いてるお堅い金融系とか基幹システムでスクリプト系言語つかわれないよねって質問はYesなんだよね?

言っておくけど俺は静的言語最強とか言わないよ
それぞれ適材適所があって、どの言語フレームワークも銀の弾丸ではないのだ。

使われるシステムや要件の前提条件なしに、お互いの言語をディスり合うのはもうやめるのだ
これでいいのだ…
0909デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:47:12.70ID:cjGOVOB+
>>908
スレちですので。
0910デフォルトの名無しさん
垢版 |
2020/11/20(金) 12:50:55.42ID:SrYJCS3X
>>909
そうだな
じゃあワシとBlazorの話をするのだ
BlazorServerってロードバランサー挟んだらもう完全にダメなのだ?回避策もないのだ?
0911デフォルトの名無しさん
垢版 |
2020/11/20(金) 15:08:34.53ID:aIIASwAX
>>908
金融系のソフトを作っている人は恐らく限られているので、ここには僅かしか
来ていないかも知れない。
以前調べてみたら、日本のプログラマで多くを占めるのは、Webプログラマと
企業向けのカスタマイズソフトウェア。
後者は推定だが、一番多いのは顧客管理と在庫管理、勤怠管理のようなものらしい。
なお、金融系は、少し前まではJavaが多かったが、だんだんとC#に移るものが
増えていると聞いた気がする。
スクリプト言語は余り使われてないかもしれない。
これも金融系ではない一般的な話として、バイナリまたは仮想コードに直さないと
安定性に不安が残るから、と聞いたことがあるい。
なぜかと言われても答えるのは難しい問題だが。
よくある感覚は、WindowsプログラミングでもDLLを使った動的リンクもプログラマには
嫌われていた。MS的には厳密に管理しているからstaticリンクと変わらないと言うが、
多くのプログラマは不安を抱えていた。
インタプリタ言語にも似た感覚があると思う。
作者の判断で何でも変えてしまうことが多いから。
そもそも、スクリプト言語では動的に型を変えることが多いことが一番の原因かも知れないが。
0912デフォルトの名無しさん
垢版 |
2020/11/20(金) 15:15:57.64ID:aIIASwAX
>>911
感覚的には、x=y; とソースコードに書いたとして、コンパイルすると、
アセンブリ言語レベルでは、
mov eax,[_x]
mov [_y],eax
となるが、Javaの場合でもこれに類する仮想コードになると考えられる。
ところが、インタプリタ言語だと、こう単純にはならずに、xやyの中に
入っているオブジェクトの種類を調べたり、さまざまなグローバルな設定に
依存してインタプリタがさまざまに「いじくってしまう可能性」も残っている。
それがまず怖い。
現実的にもっと怖いのは関数呼び出しが、例えば64BITモードに変わったら
エラーも無く勝手な変換をインタプリタが行ってしまって何事も無く
過ぎ去るが、そことは全然別の場所でそのことが原因で原因の特定が難しい
とんでも無い不具合を引き起こすとか。
コンパイル型の言語なら、このような場合は大抵の場合、警告くらいは出して
くれる可能性が高い。
0913デフォルトの名無しさん
垢版 |
2020/11/20(金) 15:18:59.70ID:1FMuX9Ox
>>906 >>899
Javaとの共通点に気付かないのか?
もともとJava対抗で作られたのがC#だ。

Static
Javaと同等のスピード
中間言語
大手ベンダーのサポート
OOP

Javaが死んだら自然と代替のC#が使われるようになる。
web frameworkで実際にASPが人気になってるだろう
Javaやってたひとはスクリプトでは納得できない。遅い
0914デフォルトの名無しさん
垢版 |
2020/11/20(金) 15:23:40.07ID:1FMuX9Ox
>>902
最強Wasmフレームワーク Blazor
これは同意しかねる。debugがまだ弱い

最凶ブラウザ IEもあるぞ
0915デフォルトの名無しさん
垢版 |
2020/11/20(金) 15:48:12.39ID:1FMuX9Ox
>>908
金融じゃなくても基幹業務のサーバーサイドでスクリプトは極力避けるもの
メンテのコストがかかる
0916デフォルトの名無しさん
垢版 |
2020/11/20(金) 17:14:03.59ID:a0YavFxO
フロントはまだ決定的じゃないけどサーバーサイドはもうC#以外でやりたくない
俺的にはC#9.0でOOP言語の決定版となった
0917デフォルトの名無しさん
垢版 |
2020/11/20(金) 17:57:31.10ID:WciP5EDn
>>913
Javaが有償化して離れた人が有償のC#に流れるという不思議。OpenJDKの方がまだ理屈が通るな。
0921デフォルトの名無しさん
垢版 |
2020/11/20(金) 18:16:45.66ID:1FMuX9Ox
>>919
情弱はWindowsでしか使えないと思ってるんだろうね

>>918
草はやしてるいつものアホもやっぱりC#なにも知らなかった
C#できないやつはこのスレ来るなよ
0922デフォルトの名無しさん
垢版 |
2020/11/20(金) 18:28:56.12ID:p7R0DfKn
普段スクリプトしか触らない「ホビー」の子達が紛れ込んでそうだね
彼らにガチの業務系バックエンドやらせたら
泣いちゃうんじゃないか?
0923デフォルトの名無しさん
垢版 |
2020/11/20(金) 18:44:23.66ID:cjGOVOB+
>>910
スケールアウトできるんじゃないですか?
インフラはSignalRですから。

>>914
Blazorは(Wasm+JS)のフレームワークですからね。
自分のWebAssemblyの定義には含まれないです。
0925デフォルトの名無しさん
垢版 |
2020/11/20(金) 19:15:17.77ID:1FMuX9Ox
>>923
Blazor Serverはスケールアウトは要注意。
ドキュメントにも注意点かかれてる。

サーバー増やすとSignalRで再接続した場合に同じサーバーにつながるとは限らない
がっつりステートフルだからきつい

Blazor Serverは多くの処理がサーバーに投げられてハードリソースを浪費する。
レスポンス良くしようと思うとかなりハイスペックなサーバー構成が必要になるはず

サーバー側のリソース良く使うからAzureで儲けたいMicrosoftに
とっては都合のよい仕組みなんだろうけど。
Azureで儲けるために作ったと信じてる。
大規模はステートレスにするっていう流れと逆行してるからな
0926デフォルトの名無しさん
垢版 |
2020/11/20(金) 19:28:10.70ID:SrYJCS3X
>>923
>>925
二人ともありがとう
今回作ろうとしてるシステムは社内で使うだけだからセッション維持ができるロードバランサーを使えば大丈夫なのかなと思ってる
しかし客先に入れようとすると、ロードバランサーの設定が大抵の場合他社任せになるから辛いんだよな…


ともかく、二人とも仲良くするんだぞ
0927デフォルトの名無しさん
垢版 |
2020/11/20(金) 19:38:22.22ID:cjGOVOB+
>>925
ステートサーバー立ててください。宜しく。
0929デフォルトの名無しさん
垢版 |
2020/11/20(金) 20:53:03.38ID:1FMuX9Ox
>>927
ステートフルでめんどくさそうで調べてない

>>926
なるほど、そういう機能で解決する手もあるか
社内利用なら利用者数が想定できるし
悪くないね、Blazor Server

標準的なスペックでBlazor Server同時接続どれくらいさばけるんだろう
実験した人いるかな
0930デフォルトの名無しさん
垢版 |
2020/11/20(金) 21:39:38.50ID:zQ2HjQc0
>>929
HelloWorldと多機能なグリッドで全然変わるんじゃないか
ページ数とかは影響しないんだろうか
仕組みがわかるようでわからんので想像がつかない
0931デフォルトの名無しさん
垢版 |
2020/11/21(土) 01:54:11.45ID:uoIuzy5x
>>925
>サーバー側のリソース良く使うからAzureで儲けたいMicrosoftに
>とっては都合のよい仕組みなんだろうけど。
>Azureで儲けるために作ったと信じてる。
>大規模はステートレスにするっていう流れと逆行してるからな
今までと違ってクラウドは珍しく競争原理が働いているように見えるので
殿様商売をやってきた成功経験豊富なMSが今後どうなるか見物。
コストパフォーマンスの良いサービスに流れるはずだから、無意味に
サーバーリソースを食いまくるようなフレームワークは淘汰されていく可能性が高く、
MSは今までの成功体験とは勝手が違って混乱していくかもしれない。
0932デフォルトの名無しさん
垢版 |
2020/11/21(土) 01:58:27.18ID:uoIuzy5x
>>901
>tsとかはMSの影がチラつかなったから流行ったのだと思ってます。
>つられてVS Codeがオープンソース界隈で天下とった感じ。
>MacでもVS Code使ってる人多いですよ。
VS Codeを喜んで使っている人の大部分は、Webプログラマ系の人達なんだそうだ。
なぜならそれ以外のプログラマは、本物のVSを普段から使っているので敢えて
VS Codeを使おうとしないからと書いてあった。
なお、MSがVS Codeを作った理由は、それで一儲けできるかも知れないと思ったから
と考えられるそうだ。
0933デフォルトの名無しさん
垢版 |
2020/11/21(土) 02:00:35.64ID:uoIuzy5x
MSは今までから他の人がやって成功したものを模倣することで成功してきたそうだが
クラウドの場合、その成功体験とは異なる結果となる可能性が少しある。
そうなることに期待している。
0934デフォルトの名無しさん
垢版 |
2020/11/21(土) 02:08:15.26ID:uoIuzy5x
MSはナデラが就く前まで上手く行かなくなってきたので
破壊的創造などと言って社内で多様なものを作らせる方針に変更した。
結果としてさまざまなフレームワークが登場してきた。
しかし、それを使う開発者目線で見ればそういう多様性は混乱の原因ともなる。
あちらでできる事がこちらでは出来ない。組み合わせることが出来ない。
すべてを含んだものがない。
せっかく慣れてきたと思ったらすぐに非推奨になり全く異なる流儀のものを学び直さなければ成らない。
(それもどれを選んでも結局、数年後には全てが非推奨になる。)
統一感が無いため汚く感じる。
0935デフォルトの名無しさん
垢版 |
2020/11/21(土) 02:12:20.97ID:uoIuzy5x
>>934
いろいろな物が出てきて「あれもできますこれもできます」ということが謡われるが
試して見ると中途半端で謡われているほどにはちゃんとできていない。
そして後先考えずに社員達に作らせるから、長い目で見れば自社の他製品と競合し、
結果的に大事な主力製品を衰退させることにつながっていく。
つまり、多様性といえば聞こえがいいが、大黒柱の製品の衰退を招きかねないが
MSが衰退した方がハッピーになる大部分の国々の人々にとっては高みの見物である。
0936デフォルトの名無しさん
垢版 |
2020/11/21(土) 02:18:19.66ID:uoIuzy5x
MS製品では既に、WinForms, WPFが非水晶になった苦い経験を積んだ人が多い。
結果としてFlutterやUno,Embarcadero製品,Qtなどだと苦しまずに済むのではないかと
思われる様になった。
人は経験から学び同じ轍を踏む危険を回避しようとするが、MSが今までやってきた
酷い仕打ちは人々の心の中にしっかりと記憶されているので今後は苦しくなってくる
可能性がある。今までは選択肢が無いため不買運動も出来なかったが、今後、
選択肢が出てくれば。
0938デフォルトの名無しさん
垢版 |
2020/11/21(土) 09:40:03.15ID:7FWFz+g3
>>932
会社がVS買うお金がないから仕方なくVSCode使ってると思ってた。

一方、個人でVSCode使う人たちは、イケてるWebプログラマのブログを盲信してしまって、他のIDEを使おうとしない…ということなんだろうか。

VSが対応してない言語やMarkdownのドキュメント作るためにVSCode使うのはわかるんだが
tsとかはVS対応してるよね…?
0939デフォルトの名無しさん
垢版 |
2020/11/21(土) 10:08:49.98ID:uoIuzy5x
BlazorがAzureで儲けるために開発されたのは多分その通りで
だとすればBlazorの存在を脅かすことになるMAUIはAzureの存在も
脅かすことになる。
0942デフォルトの名無しさん
垢版 |
2020/11/21(土) 12:46:57.02ID:Dx6bYomK
>>940
別スレだったかで聞いた話だが、
VSCodeとtsの生産性をVS+C#並にあげようとMSが頑張ってるらしいよ
ほんとかどうかはわからんが、もし本当ならなんで生産性低いやり方を選んだってことになる

なんか別の魅力があるんだろうけど。
お金かからないとか。
0943デフォルトの名無しさん
垢版 |
2020/11/21(土) 12:52:12.55ID:Dx6bYomK
>>941
なるほどそういう使い方したいとなるとvsでは無理なのか
でもなんでわざわざそんな環境選ぶの?
無償だから?
0944デフォルトの名無しさん
垢版 |
2020/11/21(土) 13:23:28.07ID:uA84MfqB
VSというのは開発のフレームワークで
有ることを理解してない人が多い。

マイクロソフトがオープンソースに舵をきった時点で
VSからcodeへの移行が始まりました。
VSはオープンソース扱えませんので...
0945デフォルトの名無しさん
垢版 |
2020/11/21(土) 13:25:44.19ID:btCpo2jd
VS使えるけどVS Codeのが軽いから好きっていう人はいるみたいだぞ
特にスクリプトで開発してる人にはVS Codeで十分なのかもしれない。
0946デフォルトの名無しさん
垢版 |
2020/11/21(土) 13:29:00.61ID:uA84MfqB
Javaのエンジニアからよく
VSでの開発はお気楽でいいーっていわれてました。

暗にVSがなければビルドすら出来ない
低レベルのエンジニアだろ?て言う嘲笑を込めて...
0948デフォルトの名無しさん
垢版 |
2020/11/21(土) 13:38:14.48ID:uA84MfqB
>>944
開発のフレームワークを強要すると言うこともあります。

VSプロジェクトのテンプレ構成がどうなっているか理解してる人は少数でしょう。

SDKだけ取得してVSに頼らずに
“ハローワールド!“
すら表示させることが出来ないエンジニアにされてしまいます。

昔VSは低レベルエンジニア量産マシーンだと
言われた事があります。
否定は出来ません...
0949デフォルトの名無しさん
垢版 |
2020/11/21(土) 13:43:57.74ID:7FWFz+g3
>>947
なるほど!
そういうメリットがあるのね
ためになります
生産性とトレードオフだと思うけど、高い生産性をキープできつつそう言う環境であれば最強だな。
0950デフォルトの名無しさん
垢版 |
2020/11/21(土) 14:33:34.32ID:7FWFz+g3
>>948
低レベルは否定はしないけど、そんなSDKだけ取得してプログラム組まなきゃいけない状況なんかある…?

ソフトウェアを作るのは目的があるわけで、早く間違いのないプログラムを組む必要があるわけじゃん?
そのために不要な作業を無くしてくれてるのがIDEなのでは。
0951デフォルトの名無しさん
垢版 |
2020/11/21(土) 15:15:00.19ID:uA84MfqB
>>950
不具合時に対応出来ない。

そもそもVSpjテンプレが
どの様なライブラリを利用していて
それをどう動かしてるのかわからないと。

仕事中にデプロイヤーが自席にやってきて
CIに載せるからビルド方法を教えろとかいわれて
オロオロする光景が目に浮かぶ。

そんな事も出来ないと思われると、
以後、まともな評価を受けられなくなる。
0952デフォルトの名無しさん
垢版 |
2020/11/21(土) 16:05:06.62ID:Dx6bYomK
>>951
そのために生産性を落としてまで普段からIDEを使うなと?
災害時にMT車使うかもしれないから普段からAT車に乗るなみたいな感じかな
0953デフォルトの名無しさん
垢版 |
2020/11/21(土) 16:11:47.22ID:uA84MfqB
>>952
生産性とか下がらない。
VSが不便なのでVS Coceを使う。
VSで開発してるとイライラの連続になる。
0955デフォルトの名無しさん
垢版 |
2020/11/21(土) 16:39:34.64ID:Dx6bYomK
>>954
いや元はなんでVS使わずにVSCode使うのかという疑問
しかしVSそんな不便なのか…?
開発するものによるのかな
0956デフォルトの名無しさん
垢版 |
2020/11/21(土) 16:49:45.37ID:uA84MfqB
>>955
同時に両方つかってます。
出来るだけVScodeに移したいのですが...

VScodeをメインにしてから
オープンソースをガンガンに使うようになりました。
0960デフォルトの名無しさん
垢版 |
2020/11/21(土) 17:29:46.40ID:nT3dqwl+
>>951


VS使ってればデプロイ用にビルドできるから
テンプレートがどんなライブラリ使ってるかなんて考える必要すらないでしょ

あー.C++で作ったものとかはしらねーけど
0963デフォルトの名無しさん
垢版 |
2020/11/21(土) 18:30:14.24ID:tUj1IEm5
VSはちょっとオーバースペックだよな
C#でMVC作りたいなと思ったらdotnet new mvcだけで始められるVSCode+SDKの構成は悪くない選択肢だ
これならインストールしっぱなしでも重くないし環境汚染も最小限で済む
VSは色々とブチこまれて気持ち悪いから本当に必要になった時に仮想マシンにインストールして使う
0965デフォルトの名無しさん
垢版 |
2020/11/21(土) 20:40:53.54ID:uA84MfqB
>>963
ですね。
イラン機能てんこ盛りなんで...
あとNuGetが使えなさすぎる...

Bland側にデザイナー機能だけ集約してくれれば、
(Projファイルなしで起動できるようにして、、)
VSCode+Blendでイイ感じには出来そうなんですが...
0966デフォルトの名無しさん
垢版 |
2020/11/21(土) 20:45:22.52ID:FNDs1N2a
VSはバナナが欲しいだけの時にも毎回ジャングルまで付いてくる感じ。
ゴリラ大暴れ。
0967デフォルトの名無しさん
垢版 |
2020/11/21(土) 21:11:43.33ID:VNLbvbCf
>>966
普段の開発はVSでやってちょっとファイル確認したいだけのときにはテキストエディタ起動すればいいだけだね
0968デフォルトの名無しさん
垢版 |
2020/11/21(土) 21:13:18.27ID:lNbsItg4
ページ内リンクにジャンプする機能つけてくれないかしら
jsでscrollToElement使えば良いんだけど、C#で統一したいお
0971デフォルトの名無しさん
垢版 |
2020/11/22(日) 04:01:21.29ID:kDrPKY9d
>>970
それならASP.NET 4.0以降と1に書いておけばいいだけの話
本命とか真打とか主観的な言葉はいらない
0972デフォルトの名無しさん
垢版 |
2020/11/22(日) 04:51:59.64ID:723Q6HfQ
>>969
Blazorに興味のある人は「Blazor」で検索かけるんだから今のスレタイで検索に引っかからないとかあり得ないだろ
0973デフォルトの名無しさん
垢版 |
2020/11/22(日) 05:12:34.36ID:kDrPKY9d
>>972
ASP.NETはやっているがBlazorはまだ未経験のひとは
たいていBlazorで検索しない。
BlazorはASP.NETのごく一部の機能や名称でしかない。

ASP.NETとかMicrosoftとかのキーワードはないとまずい
BlazorだけでなくASP.NETの今と未来の話題も多い
0977デフォルトの名無しさん
垢版 |
2020/11/22(日) 08:20:58.44ID:kDrPKY9d
>>976
>>974のスレで大丈夫だよ

今までもあったし新しめの.NETの話題ならだいたいOK
それはっきり書くと反対意見がうるさくなりそうだからあえて書かなかった。
Blazorの話題だけでは単独スレとして維持できないほど過疎る
0978デフォルトの名無しさん
垢版 |
2020/11/22(日) 08:27:33.56ID:kDrPKY9d
>>976
cross-platformのnative appsなら
Xamarinスレッドでもいいと思う。
MAUIはXamarinの進化系なんでね
あとはC#が好きな住人がいる

MAUIはベータでもいいから実用レベルになったら
単独スレッド立てればいいんでは
0981デフォルトの名無しさん
垢版 |
2020/11/22(日) 10:34:54.40ID:bLh5qcao
>>963
dotnet new mvc で作ったものと
Visual Studio のテンプレートで作ったものは
全く一緒なんだけどな

Visual Studio も今では裏で dot net new 使ってるだけだから。


ホントあほやな
0982デフォルトの名無しさん
垢版 |
2020/11/22(日) 10:52:02.89ID:HCtRnQNZ
>>981
主にVSインストール時に
何でもかんでもつっ込まれる
いらんライブラリーの事含めてるのでは?

VScodeはVSより使いこなし必須なので人によるが、
サクッと短時間ではじめるには最良かと。
0983デフォルトの名無しさん
垢版 |
2020/11/22(日) 10:58:57.20ID:WQzVWV9G
>>981
同じだったらコマンドのほうが圧倒的に早くていいじゃんw
え?なんでdotnet newで済むことを超ヘビー級のVSインストールしてやらなあかんのwww
0985デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:14:34.94ID:kDrPKY9d
>>979
Microsoftが正式版といって出したなら実用レベルなんだな

wasmもdubugが困難というだけで動作は問題ないし
Blazor Serverはなにも問題がない。
0986デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:14:41.92ID:WQzVWV9G
VSのコーディング体験は確かに素晴らしいものだが、環境汚染とリソース消費は無視できない問題だ
数カ月から数年渡ってC#のコーディング”のみ”に集中する予定があり、その間、他のプロジェクトには参加しない
そんな時なら流石に自分もVSで開発する
そうでないなら、SDKとVSCodeでカジュアルに開発したほうが負担が少ないんだな
0988デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:24:10.54ID:uJX0FfO+
>>986
そもそも与えられてるPCが開発用なんだからVS入れると環境汚染だという考えが理解できないんだよな
そのためのPCだもん
0989デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:28:37.13ID:kDrPKY9d
>>980
そういうのはっきり境界決めようとすると荒れるからこれでいいんだよ
MSの技術の話題ならあまりうるさく反対するひといないよ
0990デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:35:01.52ID:kDrPKY9d
>>983
>>981に論破されてるし。
コマンドだとパラメーターを覚えて一字一句、正確に打たないといけない
覚えるのが無駄。
ファイルからコピペするならファイル探してる間にウィザードなら終わってるわ
0991デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:36:13.79ID:pRccuIbb
>>988
うんだからそれだけに集中していい簡単なお仕事ならそれでいいんじゃないの
俺は複数案件持ってるし、1つの案件でも使う言語は1つじゃない
様々なミドルウェア、サーバー、ツールを組み合わせて使ってる
そしてそれらをDockerでまとめ上げて環境汚染を回避してる
最近だとこういう構成のほうが多いんだよ
C#のコーディングだけやっとけばOKなんてことは稀
0992デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:37:34.75ID:pRccuIbb
>>990
入力補完もヘルプもあるから問題ない
そもそもそれぐらい覚えることができない低スペック脳でIT従事したらだめだろw
0994デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:44:31.95ID:HCtRnQNZ
現場でコマンド叩けなないと恥かきますよ。
リモートでターミナルしか繋がってなくて
コマンドでgitからソース落としてビルドなんて結構普通。

いつもVSだから出来ませんします?
0996デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:50:27.55ID:bLh5qcao
dotnet new はインストールされているSDKの最新バージョンがデフォルトで適用されるのに対して
VisualStudioではまだ.NET Core 3.1 をターゲットとして作成されるし
コマンドの方がオプションは豊富だから最初から作りたい構成に近づけて作ることはできるかな

でも一度作ってしまった後はVISUAL
STUDIO使った方が全体として楽

まぁ企業で VisualStudio買ってもらえないところは
目をつぶってVSCodeマンセーッイワナイト
やってられないんだろうけど
0997デフォルトの名無しさん
垢版 |
2020/11/22(日) 11:57:57.83ID:kDrPKY9d
>>996
ターゲットは最後に選んだのが出てくるだけでは?
SDK .NET5.0いれてwizardで最初に.NET5選んでからは
wizardで5.0が選択された気がするよ
1000デフォルトの名無しさん
垢版 |
2020/11/22(日) 12:02:08.78ID:bLh5qcao
>>997
あー、asp.net core ではバージョン選択できたわ

この間Consoleapp作ったときに選べなかったから
勘違いしてた
10011001
垢版 |
Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 124日 12時間 25分 32秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。

ニューススポーツなんでも実況