Microsoft ASP.NET Blazor #02

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

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

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

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

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

**デフォルトの名無しさん** · 2021/07/23(金) 16:18:02.69

>>559
それって楽しいか？

**デフォルトの名無しさん** · 2021/07/24(土) 11:02:57.33

楽しくてやってるのか？個人でやる分にはいいが…
おれみたいにデスクトップアプリをWebアプリ化したいが、
チームにC#の経験者が多い、Typescriptの習得に時間を割けない
というネガティブな理由でBlazorを検討するやつは多いはずだ

**デフォルトの名無しさん** · 2021/07/24(土) 13:35:26.86

>>561
それが限定的で超短期的な避難措置ならわかるが
将来を見据えてみんなtsに移行したほうが絶対良い
時間を割けない経営側の判断がおかしいと思う

能力の限界が来て移行できない人はいらない人とまでは言わないがもうアプリレベルの開発はもういいかなと
Blazorって多分後2年持たないと思うのでそんなのを移行先にしてはいけない

**デフォルトの名無しさん** · 2021/07/24(土) 13:44:25.48

tsってc#見たいで
もっと柔軟でc#じゃ出来ないような事も出来て
言語としておもろいですよ

**デフォルトの名無しさん** · 2021/07/24(土) 13:49:24.79

面白いけど基本的にjsの弱点を補うためにおかしな仕様になってる
型が柔軟になってて中で何度も型判定したり意味ねえよって思う

**デフォルトの名無しさん** · 2021/07/24(土) 13:59:20.60

voidとany　nullとundefined

特に受け付けないのが
hoge: string='';
if(hoge)がfalse

C#からの移行はかなり厳しいと思うｗ

**デフォルトの名無しさん** · 2021/07/24(土) 14:00:13.27

といいつつ今はそんなにts触らないので流れが全く分からない

tsの仕様の細かいところまで全部追えてる人間はそういないと思う
思い付きレベルにしか思えない機能を入れたり仕様変更したり忙しかったけど今も同じなのかは知らない

**デフォルトの名無しさん** · 2021/07/24(土) 15:21:34.25

>>564
形無し言語も多い中で
贅沢言わんことだよ

**デフォルトの名無しさん** · 2021/07/24(土) 15:24:29.17

>>565
ui記述言語として書きやすい仕様だが(>_<｡)v

**デフォルトの名無しさん** · 2021/08/22(日) 09:10:39.98

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/09/18(土) 15:36:06.25

ReactというかJSをしばらくやってるんだがC#の非同期に慣れてるとしんどいね

**デフォルトの名無しさん** · 2021/09/24(金) 18:41:54.72

>>570
ほとんど同じじゃね？

**デフォルトの名無しさん** · 2021/09/25(土) 01:28:16.45

だね

**デフォルトの名無しさん** · 2021/09/25(土) 09:44:48.46

キャンセルできない
ライブラリのasync対応が半端
AsyncEnumerableがない

**デフォルトの名無しさん** · 2021/11/03(水) 13:43:09.57

VS2022で何か変わりますか？

**デフォルトの名無しさん** · 2022/04/19(火) 18:34:10.96

なんだこの過疎り具合…
他のASP.NETスレも動いてないみたいだしC#でWebしてる人はよほど少ないのね

**デフォルトの名無しさん** · 2022/04/19(火) 18:54:16.41

APIぐらいじゃね？

**デフォルトの名無しさん** · 2022/04/19(火) 21:04:28.79

次期OfficeやVSCodeがBlazorHybridで作られたら考えるわ

**デフォルトの名無しさん** · 2022/04/22(金) 10:45:57.05

ASP.NETって書籍もWebフォームばっかだな

**デフォルトの名無しさん** · 2022/04/26(火) 22:01:04.82

もうすぐ.NET MAUIの正式リリースがくるってことで...
なんだかんだ.NETが理想的な形に近づいてきてるところ見るとわくわくするんだけれども。

世の中Google主導で、JavaScriptが人権みたいな流れになってるもんだからMicrosoftはこれからどうするんだろうと心配になる。

C#(Microsoft)対JavaScript(Google)な未来がみえるみえる

**デフォルトの名無しさん** · 2022/04/27(水) 06:53:03.08

>>579
JavascriptらMSがTypescriptで覇権を握っているように思うけど…

**デフォルトの名無しさん** · 2022/04/27(水) 11:04:53.32

フロントエンドはTSで開発環境はVSCで
メインストリームだよ

**デフォルトの名無しさん** · 2022/04/27(水) 12:42:11.57

でもBlazorやMAUI、WinUIは流行る気がしない。
Reactのように企業が実際使っているフレームワークのほうが信頼度高いから。

**デフォルトの名無しさん** · 2022/04/27(水) 12:44:51.74

特に日本記号は新しいもの使わないからな

**デフォルトの名無しさん** · 2022/05/01(日) 10:44:21.22

WinUIは特にWindows App SDKがまだまだ未完成状態だから流行る流行らない以前に普及できないよ

Microsoftはきちんと動くようになってから宣伝してほしい

**デフォルトの名無しさん** · 2022/05/03(火) 03:04:06.38

あのさ、ちょっとわいReactの経験無いから聞きたいんやけど、
Asp.netMVCでRazer使ってSSRしながら作ったらVisualStudioだけで全て完結してまるっと統一感でるとおもうんだけど
なんでフロントはReact、サーバーサイドはAsp.netって分けて作ってるところがそこそこあるの？

Razerだけで自作コントロール的なものからなにから用意できるからAsp.netだけで作ったほうが絶対にいいとおもうんだけど

**デフォルトの名無しさん** · 2022/05/03(火) 06:37:39.20

うちは
React + Asp.net Web API

**デフォルトの名無しさん** · 2022/05/03(火) 08:01:49.35

SPA作らないんならReactいらないんでないの

**デフォルトの名無しさん** · 2022/05/04(水) 11:07:52.23

>>585
ASP.net MVCではSSRと言わないはず。
SSRはSPA関連で使うワード

統一感ないのはほとんどのweb appは
フロントエンドとバックエンドで担当が分かれてるからでしょ。
言語を統一する必要があまりない。
言語の統一よりも、フロント、バックそれぞれのフレームワークの良いものを
選んだほうがいいってことかと。
動的言語をバックエンドで使ったら生産性も低いし性能も落ちる。
バックエンドやAPIをC#でやるのは理にかなってる。

フロントエンドはブラウザがJS縛りなのだからTSでやるのが合理的
BlazorならフロントもC#にできるがパフォーマンスが落ちる。
あとフロントエンドのひとたちはOOP、C#の理解できない人が多い。
データベースの知識も浅い。
フロントエンドしかできない人にはasp.net MVCは学習コストが高い。

**デフォルトの名無しさん** · 2022/05/04(水) 11:12:21.42

>>585
587も書いてるけど
まずSPAがいいのか、MVCのような従来型がいいのか、を考える必要ある。

SPAにもデメリットある。
なんでもかんでもSPAではだめ

SPA使わないとなるとASP.NET MVCは今でも最強フレームワークだと思う
SPA使わないとしてもAPIでASP.NET MVC使うのはぜんぜんいいと思うし

SPAである必要ぜんぜんないのにSPAでやってるサイトが増えてる感じはする。
戻るボタンつかえないクソサイトね

**デフォルトの名無しさん** · 2022/05/04(水) 16:05:04.80

>>588
なるほどなー
うちはフロントとバック別れてないからReact使うメリットがまったく分からなかったのか
たしかに分かれてたらフロント専門にやってるような人たちも混ざれるもんなー
でもさ、
ぶっちゃけさ、どっちも同じ人が担当したほうが結局のところ無駄な伝達とか無くてはやいよな

**デフォルトの名無しさん** · 2022/05/04(水) 23:18:33.72

Ruby on Rails ではデフォルトで、Turbolinks のPjax で、History 履歴を管理する

Rails 7, Elixir のPhoenix 1.6 から、脱Webpack でesbuild へ

RailsのHotwire, PhoenixのLiveView で、
websocket による、JSON ではなく、HTML 片のリアルタイム通信。
脱JavaScript

ここ数年、SPA で、React に奪われたシェアを回復すべき戦略

他には、Bootstrap よりも、Tailwind が多くなってきた

**デフォルトの名無しさん** · 2022/05/05(木) 00:54:03.75

>>591
日本語で頼む

ブラウザはJS縛りなのに脱JSとは？
フロントエンドのコードをRubyで書いてJSに変換できる技術ってこと？

**591** · 2022/05/05(木) 01:43:56.90

JSON API を定義して、JavaScript(JS)・Ajax でやり取りする必要がなくなる

サーバー側で、HTML 片を作って送って、
受け取ったブラウザ側で、その部分を置換する

Rails + React + Bootstrap みたいに、2つのアプリが必要なくなった。
JSを受け取って処理する、部分が無くなった

この方法で、ここ数年SPA で、Reactに奪われたシェアを回復する

**591** · 2022/05/05(木) 01:58:11.05

猫でもわかるHotwire入門 Turbo編
https
://zenn.dev/shita1112/books/cat-hotwire-turbo

たぶん、Ruby on Rails 7 のHotwire, Elixir のPhoenix 1.6 のLiveView も、
似たような感じなんだろう

**デフォルトの名無しさん** · 2022/05/05(木) 07:25:39.82

Blazor serverの類似技術ってことかいな

**デフォルトの名無しさん** · 2022/05/05(木) 12:12:39.76

>>594
Thanks. 594のリンク先でHotwireの概要読んだ。
実際Hotwireで、どのくらい開発時間が削減できるのかは気になるわ

気になるところは、htmlのブロックをやりとりすることのデメリットだな
JSONでデータ渡すからこそ、PC, SPの両方でサーバーサイドを共通化できるってのが
メリットだったんじゃないのかね
Hotwireで部分的な更新はできるようになったけどクロスプラットフォーム対応はしにくいと思う。

web frameworkごとに内部の動きもぜんぜんちがうとか、
相変わらずweb appはカオスだな
転職のとき大変そう

**591** · 2022/05/05(木) 23:32:46.84

KENTA

未経験からのエンジニア転職の必須教養【技術知識編】
https
://www.youtube.com/watch?v=Q1c09rrhTjo

転職・学習環境は、Ruby on Rails 1強

Railsチュートリアル・Rails Guide、
パーフェクト Ruby on Rails・黒田努の本などの、多くの教科書がある。
Dean などのYouTube 動画も多い

キャリアパスも、Rails → Go だけ

**デフォルトの名無しさん** · 2022/05/06(金) 06:05:59.50

なんだKENTAの人か
解散

**デフォルトの名無しさん** · 2022/05/06(金) 06:52:21.72

>>597
KENTAはレベル低いから動画みないほうがいいぞ
同じことばっかり言ってる。技術的に浅いからネタがない。
自分のコード、ほとんど晒してない。

**デフォルトの名無しさん** · 2022/05/06(金) 07:02:04.16

>>597
あと教科書などいらない
ふつう、新しい技術学ぶのは英語。英語の情報をみたほうがはやい

Rubyは低速だから大手ITはRails捨てたところ多いし。
KENTAみたいに技術ないむかしの人がいまだにRubyとかRails推して
英語できない初心者がまたRails始めるという日本の悪循環
スクールもそんな感じ
情弱相手のビジネス

**デフォルトの名無しさん** · 2022/06/10(金) 20:43:37.92

DBなどへの接続文字列とかって実際の案件や現場でどーしてるんですか？
２，３方法があるみたいでも、なんか定番のこれって感じの記事も少ないし
そもそもサーバー上に配置したappsetting.jsonを見られてる時点で
鯖に侵入されててそれどこじゃないってことなんでしょうか？

**デフォルトの名無しさん** · 2022/09/26(月) 22:47:25.10

Blazorでこれやっとけみたいな教本とかありますか？
ねこジョーカーさんのやつとか？

**デフォルトの名無しさん** · 2022/09/26(月) 22:49:15.04

作りたいものはWikiみたいなDBと連動してボディの文字を修正したりコメント欄を追加したりしたい

**デフォルトの名無しさん** · 2022/10/06(木) 08:17:39.29

DevExpress のサンプルでも見とけば？

**デフォルトの名無しさん** · 2022/11/13(日) 15:46:36.25

WEB開発はMacの人が多いから、まずはASP.NET CoreがMacでも開発できるよってことを
みんなに広める必要がある

**デフォルトの名無しさん** · 2023/02/12(日) 20:28:01.91

>>578
え(笑)

**デフォルトの名無しさん** · 2023/05/29(月) 05:56:19.80

ASP.netで作ったポートフォリオを転職時に提出したいのですが
PHPではレンタルサーバーを借りてアップロードしますが
ASP.netの場合は自身でサーバーを立てる必要があるのでしょうか？

**デフォルトの名無しさん** · 2023/05/29(月) 08:50:20.39

コードビハインドで取得したバイナリデータをJavaScriptの関数に渡したいんだけど、常套手段はありますか？