[過去ﾛｸﾞ] Microsoft ASP.NET Blazor #02 (608ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
259: [なかsage] 2020/12/24(木)00:11 ID:61P3AxB9(1/4) AAS
>>258
swaggerの意味間違えてるよ。
それswaggerの役割じゃないから。
260: 2020/12/24(木)00:38 ID:cDdTcWWQ(1/8) AAS
Unityがなんで勝ったか、を考えれば答えは見えてるだろ
261(1): 2020/12/24(木)00:59 ID:z4h3nURn(1/3) AAS
>>257
>Blazorのプロジェクトつくるとそうなってるよね
なるほど、前提として想定してるアーキテクチャが全然違ったのね
>>256の話はBlazorのプロジェクトが別のバックエンドのAPIサーバーにアクセスする必要があるようなケースに
APIサーバーがで定義された型をクラスライブラリとしてBlazorのプロジェクトと共有するかどうかみたいな話ね
Blazorはモノリシックなアプリでいい場合は簡単に作れていいと思うよ
考え方的にはRailsとかと同じだけど裏のところが独自技術な分だけ優れてる
省1
262: 2020/12/24(木)01:05 ID:cu9CRgEK(1) AAS
最近はミクロサービスもやっぱ駄目だったってんでモノリスに回帰してきてるらしいな
263(3): 2020/12/24(木)06:31 ID:qBLsz+9E(1/3) AAS
Docker は、1コンテナに、1アプリのマイクロサービス
今の基幹技術だろw
流行りまくっている
264(1): 2020/12/24(木)08:12 ID:Lxgk3nTO(1/4) AAS
>>263
またにわかのフロントエンドのバカか
流行っているかではなく優れているかで選ばなくてはいけない
大規模やってる大手企業、上級エンジニアはDockerを嫌う
265(2): 2020/12/24(木)08:34 ID:tvAmDhsP(1/6) AAS
>>261
すまん前提が書けてなかった。
うちは企業内アプリをメインに作ってて、他の外部apiには殆どアクセスしない。
バックもフロントも自チーム内で完結する。
横に座ってる奴がサーバー側の型を変更して急用ができて帰ったとする
フロントやってるやつがそのことに気づかずにリリースしてしまうなんてことが起こるようなら本末転倒だなと。
それで原因はテストコードが足りないとか、コミュニケーションが足りないとかいうのもおかしいよねと考えている。
省3
266(3): 263 2020/12/24(木)08:39 ID:qBLsz+9E(2/3) AAS
AWS の構成図を見てみろ。
ほとんど、マイクロサービスだろ
何十もの、Lambda, SQS(Queue), SNS(通知)をつなげてるの、ばっかりだろ
クラスメソッドの動画を見ろ
会社全体で、AWS の資格を800持っていて、
全12資格を持つ・ジェダイマスターが7人もいる！
267: 2020/12/24(木)08:40 ID:BsodnxpD(1) AAS
>>264
零細爺が見栄張って適当言っちゃあかんでしょ
社内でファイルサーバーでもたててSEごっこしてなさい
268: 2020/12/24(木)08:53 ID:Lxgk3nTO(2/4) AAS
>>266
そりゃアマゾンは大手のクラウド事業者だからあたりまえだろ
自社の提供するサービスをそのまま使ってるだけ
サービスの広告にもなる
一般法人がそれを採用することが合理的かは別の話だ。
デメリットを理解せず、流行ってるからいいという
アホな価値観だからそういう思考になる
269: 2020/12/24(木)08:58 ID:nIBEXBhK(1) AAS
こいつはホンマにいつも5chやっとるな
270: 2020/12/24(木)09:04 ID:Lxgk3nTO(3/4) AAS
>>266
おまえいつもKENTAの話ばっかりしてるやつだろｗ
クラスメソッドｗ
俺は初心者向けスクールなんていかない。
会社全体の資格者数なんて何の意味もないし
ベンダー資格なんてすぐに取れるんだよｗ
スクールだから宣伝のために講師に取らせてることも理解できないって
省4
271: 263 2020/12/24(木)09:33 ID:qBLsz+9E(3/3) AAS
クラスメソッドは、AWS パートナー・オブ・ザ・イヤーとか取ってる、最上位の会社
米国年収で、
Ruby on Rails 1,300万円
Node.js 900万
VMware 1,400万
AWS Solution Architect 1,500万
もう、AWS資格が、Railsを超えてる！
272: 2020/12/24(木)09:52 ID:tvAmDhsP(2/6) AAS
ついでに聞いとこ。
クラスメソッドくんは普段なんのフレームワークで開発してるんだい？
273(1): 2020/12/24(木)10:54 ID:cDdTcWWQ(2/8) AAS
>>266
その構成が複雑化しすぎて多くの場合でデメリットがメリットを上回ってしまう
よっぽど巨大で複雑なシステムでもない限りモノリスのほうがシンプルでイイネ
っていうふうにトレンドが移り変わろうとしてるところ
274: 2020/12/24(木)11:28 ID:TzdYJrci(1) AAS
KENTAはコテ付けるべきでは？
275(1): 2020/12/24(木)12:08 ID:tvAmDhsP(3/6) AAS
>>273
これほんとにそうだと思う。
こういうのが必要なのって相当巨大なシステムだけなんじゃないのか
トレンドだからとDockerだか、Kubernetesだかに手を出して
気づかず消耗してるんじゃないだろうか。
クリーンアーキテクチャについてもそうおもうし、
なんならrest apiもそうなんじゃないだろうかと疑っている。
省1
276(1): [なかsage] 2020/12/24(木)12:24 ID:61P3AxB9(2/4) AAS
>>265
サーバー側の型が
クライアント側に漏れでた時点で
設計がおかしい。
もしかして、
クラサバみたいな設計ですか？
277(1): 2020/12/24(木)12:37 ID:tvAmDhsP(4/6) AAS
>>276
漏れ出るって…？
ASP.NET MVCは定義したモデルをビューで参照できるよね？
これは漏れ出てる…？
278: 2020/12/24(木)13:32 ID:FJvlKwaS(1) AAS
>>275
Dockerは別にいいと思う
あれはどんな依存関係でも簡単にパッケージできるのと環境を汚さないで済むという強力なメリットがある
K8Sまで行くとやりすぎで本当にK8Sが必要なのか慎重に考えないといけない
クリーンアーキテクチャは悪くない
モノリスに回帰してきているとは言ってもコードを汚く書いていいわけじゃない
あくまでも悪いのはミクロサービスであってアプリケーション内部をクリーンアーキテクチャで綺麗に構造化するのは依然として良いことだ
省3
279(1): [なかsage] 2020/12/24(木)13:35 ID:61P3AxB9(3/4) AAS
>>277
サービスレベルで設計してないって事ね。
280(2): 2020/12/24(木)13:56 ID:RIrJysKy(1) AAS
単純なマスタメンテみたいなアプリでもなけりゃサーバーとクライアントで扱うモデルって一致しなくない？
セキュリティとかプライバシーに関わるようなデータでも平気でネットワークに流しちゃう感じ？
281: 2020/12/24(木)14:00 ID:VTM9inIm(1) AAS
ドットネッターはコンテナに拒否反応示す人が多いよね
.NET Coreでせっかくモダンなスタイルのデプロイが可能になったと思ったら、
井の中の蛙なユーザーに迎合してIIS統合とかFDD強化とか変なことに力入れてどんどん退行してるし
282: 2020/12/24(木)15:31 ID:GGlRJfww(1) AAS
Windowsコンテナが実用レベルになったら起こしてくれ
283(2): 2020/12/24(木)17:59 ID:tvAmDhsP(5/6) AAS
>>279
そこまでやる必要がないレベルといえばそう。
世にあるMVC系のWebフレームワークはなんか漏れ出してるということなんだろうか
>>280
逆に単純なマスタは一致するんじゃないの
そりゃおっしゃるようなシーンでは一致しないだろうけど
どっちが多いかにもよるんだろうか。
省4
284(1): [なかsage] 2020/12/24(木)18:17 ID:61P3AxB9(4/4) AAS
>>283
反対意見じゃなくてAPIの設計がちがう。
swaggerでopenAPIとして公開するレベルなら、
クライアントの種別、言語は問わない。
285(1): 2020/12/24(木)18:32 ID:z4h3nURn(2/3) AAS
>>265
それってコンパイルエラーになるような変更なら気がつくけど
それ以外の変更なら不具合が起こってても気が付かないてことでしょ？
結局テスト書いてないだけじゃない？
swaggerとかインターフェース定義ファイルからそれぞれのスタブを自動生成するようなやつは
定義が変わればそりゃ検知できるけど検知できて新しい定義に対応したところで
その変更によって不具合が起こってないことはテストしないとわからないよね
286: 2020/12/24(木)18:36 ID:cDdTcWWQ(3/8) AAS
>>280
モデルにも色々ある
ドメインモデルとかビューモデルは当然、共有しない
APIやRPCのI/Oモデルは共有する
Blazorはこれを追加作業なしで完全な形で型安全に共有できるから強い
287: 2020/12/24(木)18:46 ID:PofLudrU(1) AAS
さらにF#の型プロバイダをBlazorで利用すると、バックエンドが.NETでない場合でも、型安全なI/Oモデルを手に入れることができる
インターフェース定義、コード生成要らないので、とても楽ちん
288: 2020/12/24(木)18:53 ID:tvAmDhsP(6/6) AAS
>>284
いろんなデバイスやシステムからアクセスするapiに関してはおっしゃる通りだと思うよ。
でもそんなの限られるんじゃないの？いや俺がそういうの作った事ないからそう思い込んでるだけかもしれないけど。
そうじゃないものまでapi化するのは意味なくて、型は共有した方が嬉しいですよね♪ってことだと解釈してます。
>>285
swaggerはリリース前に自動で変更検知して止めてくれるってこと？
なら安心だな。
省1
289: 2020/12/24(木)19:15 ID:EoOpc5fU(1) AAS
>>283
型共有は工数削減効果が非常に高いので積極的に利用して良いよ
290: 2020/12/24(木)19:26 ID:yLXHVLdF(1/2) AAS
swaggerがどうのこうの言ってる人はミスリードを狙ってそうな気配がする
swaggerはメソッドを定義することはできないからblazorの型共有とはそもそもまったくの別物だよ
291(1): 2020/12/24(木)19:34 ID:yLXHVLdF(2/2) AAS
blazorの型共有は単にAPIのDTOを共有するといったつまらないユースケース留まらない(もちろんDTOとしても非常に便利ではあるが)
例えば単価、税率、個数から消費税込み価格を計算するメソッドがプレゼンテーション層とドメイン層の両方で必要になった場合
blazorならC#で1回だけメソッドを実装すればいい
バックエンドとフロントが異なる言語だと同じ処理を異なる言語で2回実装しなければならない
もちろん仕様変更が発生した場合には両方ともプログラムを修正、テストをしなければならない
テスト定義もバックエンドの言語とフロントエンドの言語で2回書かなければならない
片方の仕様変更を忘れてもテストが更新されなければアラートは鳴らないので
省1
292(2): 2020/12/24(木)20:36 ID:NdJ7CDDg(1) AAS
画面の金額と実際の請求金額に差異が出たりしたら偉い人が顧客に土下座するレベルの重大事故だろ
さすがにそこはサーバーサイドに投げるわ
コード共有などという小手先レベルの共通化は少々バグっても笑って許される程度の機能のちょっとしたUX改善程度にとどめておくべきで、
重要なものはアーキテクチャ上差異が発生しないように作る
293: 2020/12/24(木)20:48 ID:yJIcrLfM(1) AAS
>>292
この例はあくまで一例
実際のシステムでは金額計算以外にも同じような状況は沢山ある
それをいちいち全部バックエンドに問い合わせるのは実行効率も製造効率も悪い
294(1): [なかsage] 2020/12/24(木)20:58 ID:KjzzoxRm(1) AAS
>>291
コピペ？
swaggerを使ってのopenAPIなら
まずはその設計思想を勉強されてみてはどうでしょうか？
googleのAPIとか参考になりますし、
無料で試せますよ。
295(2): [なかsage] 2020/12/24(木)21:06 ID:cW3QBX++(1/2) AAS
>>292
自分の設計だとバリデーション含めて
ロジックは全部（表示フォーマットも）サービス側ですね。
ローカルにあるロジックと応答速度で遜色ないですよ。
サービス側は全部単体テスト対象なんで
安心感もあります。
リリース後にバグ出すと、
省1
296(1): 2020/12/24(木)21:23 ID:IhbSA9yU(1) AAS
>>295
思想としては正しいと思う
.NETな人って表面的なコードの共有は大好きなのにデプロイメントをDRYにするという意識が希薄な人が多くて、
ビジネスロジックのDLLをWebとバッチで安易に共通化したりしてデプロイをミスってトラブル起こすケースが多いんだよね
297(1): [なかsage] 2020/12/24(木)21:32 ID:cW3QBX++(2/2) AAS
View側に業務ロジック混ざると、
コードが読めなくなること多いですからね。
いろんな人が出入りするし。
フロントなんて持って数年、
システムの統廃合やリプレース時にも楽ですよ。
298(1): 2020/12/24(木)21:48 ID:BMlK5S4S(1/2) AAS
Blazor Serverでファイルのアップロード処理をしたいのですが、
アップロード時に、ローカルにファイルが存在するかチェックするにはどうすればよいでしょうか？
299(1): 2020/12/24(木)21:51 ID:zHK1POmy(1) AAS
>>298
ローカル側の処理なんでJavaScript書かないと仕方ないんじゃないの
300: 2020/12/24(木)21:59 ID:BMlK5S4S(2/2) AAS
>>299
ありがとうございます。
該当部分はJavaScirptで作ります。
301: 2020/12/24(木)22:00 ID:cDdTcWWQ(4/8) AAS
>>294
swaggerはblazorの型共有とは違うベクトルの話だよ
ここで話すべき内容ではない
302(1): 2020/12/24(木)22:05 ID:cDdTcWWQ(5/8) AAS
>>295
それはいままで簡単にフロントエンドとバックエンドでロジックを共有できなかったからそうするしかなかっただけ
型共有がなかったからコードを重複させるか些細なことでもバックエンドにリクエストを出すしかなかった
どちらもやりたいことにたいして実装と実行のオーバーヘッドが大きい
型共有が可能なblazorでは無駄なエンドポイント実装、APIコール実装を削減することにより生産性の向上が期待できる
また無駄なラウンドトリップを避けることによりより良いユーザー体験が期待できる
303: 2020/12/24(木)22:08 ID:cDdTcWWQ(6/8) AAS
>>296
昨今ではデプロイメントは自動化されるので間違えることはない
304(1): 2020/12/24(木)22:09 ID:cDdTcWWQ(7/8) AAS
>>297
Viewには業務ロジックは混ざらない
Viewからは業務ロジックを呼び出すだけ
今まではAPIを通じてリモート呼び出ししていたがblazorではその必要なく呼び出せる
305: 2020/12/24(木)22:25 ID:Lxgk3nTO(4/4) AAS
>>304 >>302
「Blazorでは」と書くと正しく伝わらない。
Blazor ServerとBlazor WebAssemblyで全然違う
紛らわしい名前つけたMSが悪いんだが。
306: 2020/12/24(木)22:50 ID:cFK/Qw2G(1/2) AAS
実際どちらのことを書いてるんだろう
Serverかな
しかしwasmとserverでほんと全然ものが違うよな。
共通点はフロントをc#でかけるってだけで。
MSの名前の付け方は本当に適当だと思う。
307: 2020/12/24(木)22:59 ID:z4h3nURn(3/3) AAS
同一言語で作ってる同一プロジェクト内で型を参照することを
”型共有”って言うのは相当違和感あるね
誰が使い始めたのかしらないけど
308: 2020/12/24(木)23:11 ID:F9/YVp9N(1) AAS
では何と言うべきか？
309(1): 2020/12/24(木)23:24 ID:cFK/Qw2G(2/2) AAS
Qiita や個人のブログを貼るのはアレなので
クラスメソッドの記事を…
外部ﾘﾝｸ:dev.classmethod.jp
interfaceを共有することで 型安全な開発ができます
これのことかな。
310: 2020/12/24(木)23:50 ID:cDdTcWWQ(8/8) AAS
Blazorはinterfaceの共有もできるがそれだけに限らない
interface、class、struct、、、何でも共有できる
それらを総称するとなんと言うか？それは型だ
だから型を共有していると言うより適切な表現はないのではないかな
311(2): 2020/12/25(金)00:08 ID:vv0pxJyE(1/3) AAS
>>309
このケースはリポジトリとして定義した型をサーバーとクライアントで共有してるというのは違和感ないな
RESTのAPIで切り離されてるからかな
(APIが返す型情報を元にしてないから微妙なところがあるけど)
ASP.NET MVCで言えば同じビューモデルの定義を参照してるからって
ビューとコントローラーで”型共有”してるとは普通言わないよね？
312: 2020/12/25(金)00:14 ID:K5aqSQYy(1) AAS
>>311
言い回しとして普及してるかどうかは知らんが型を共有してるのは正しい
313: 2020/12/25(金)00:24 ID:Z26lwPgE(1/2) AAS
>>311
Blazor wasmのプロジェクト構成では
Shareプロジェクトにモデルを定義して
ClientプロジェクトのRazorページでShareプロジェクトを参照している
同じくServerプロジェクトのコントローラーでもShareプロジェクトを参照している
これはなんていうんだろう。
どちらにせよサーバーとクライアントで同じ型を使うという目的に対して手段が違うだけであって、別にまずくはないと思うんだけどどうだろう。
314(3): 2020/12/25(金)08:42 ID:uurLZNKt(1/8) AAS
サーバーとフロントで型を共有？できた方が大半はうれしい。
OpanAPIが必要なシステムではそこに固執しなくてもよいということで。
じゃあこの板でもたまにやたらと推してくる奴がいる言語、rubyやpythonって静的型付け言語じゃないよね。
てことは型の共有もくそもないと。
そういう言語で中規模以上のWebシステムを作ろうとするとやはり苦労する？
推してくるやつはその事実をわかっていない？
静的型付け言語しかしらない俺にとってはなんであんな推してくるのかとても気になる。
315(2): 2020/12/25(金)09:13 ID:JfQSa+1c(1/10) AAS
>>314
OpenAPIじゃメソッド(処理)を共有できないよ
フロントエンドとバックエンドで言語を揃えることにより今まで複数言語で書くかリモート実行するしかなかった問題が解決した
OpenAPIは複数言語で書く手間を軽減できるがリモート実行するしかないという問題には未だに無力
316(1): 2020/12/25(金)09:31 ID:UA1/tVeu(1/4) AAS
どんな言語であれフレームワークであれ
データ型は共有しないとクライアントが受け取ったデータを適切に処理できないでしょ
blazor は同じアセンブリを共有できる分開発は楽になるでしょ
クライアントに送るデータはクライアントに必要なデータしか普通は送らないし
サーバ側の型がクライアントに漏れるとか
入門書レベルの開発しかしたことないだろ
317(1): 2020/12/25(金)09:44 ID:uurLZNKt(2/8) AAS
>>315
多種多様なシステムやデバイスが使うapiは仕方がないという認識
318: 2020/12/25(金)10:04 ID:JfQSa+1c(2/10) AAS
>>317
その多種多様なデバイスの上で.NETが動くわけで
319: 2020/12/25(金)10:09 ID:8j4BK9K7(1/3) AAS
ぜんぶ設計者次第だという認識
320(1): 2020/12/25(金)10:16 ID:81Ut/TdK(1) AAS
>>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
321(2): 2020/12/25(金)10:17 ID:JfQSa+1c(3/10) AAS
>>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている
昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
省4
322(1): 2020/12/25(金)10:22 ID:JfQSa+1c(4/10) AAS
>>320
それはどうかな？
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
323: 2020/12/25(金)10:27 ID:JfQSa+1c(5/10) AAS
そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
324(2): 2020/12/25(金)10:32 ID:vv0pxJyE(2/3) AAS
>>314
自分で勉強しろって
ここで言ってる”型共有”はRubyでもPythonでもできてる
>>315
“メソッドを共有”って何なの？
処理を共有するためのAPIなんだけど・・・
それにBlazorもリモート実行してるよ
325(1): 2020/12/25(金)10:35 ID:uurLZNKt(3/8) AAS
>>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない？
しんどくない？しんどくてもその分の見返りがRubyにはある？
いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
326: 2020/12/25(金)10:38 ID:uurLZNKt(4/8) AAS
>>324
あれ、RubyやPythonも型があるのか
失礼しました。
もう自分で触ってみないとわからんな…
327(1): 2020/12/25(金)10:38 ID:UA1/tVeu(2/4) AAS
>>321
そんなこといったら
クライアント側でのデータ検証なんて 何もできない
328: 2020/12/25(金)11:01 ID:bbGDaeBs(1) AAS
静的型チェックを重視するならC#よりF#使えばいいのに
329: 2020/12/25(金)11:08 ID:8j4BK9K7(2/3) AAS
訳わかんない理論がまかり通るスレ
330(1): 2020/12/25(金)11:37 ID:JfQSa+1c(6/10) AAS
>>324
リモート実行は外部処理系に処理を依頼しているだけなので共有ではない
ここでいうメソッドの共有とは異なる処理系が同じ実行コードをそれぞれの内部に持っているということ
331(1): 2020/12/25(金)11:45 ID:JfQSa+1c(7/10) AAS
>>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
332: 2020/12/25(金)11:49 ID:JfQSa+1c(8/10) AAS
>>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている
ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット
フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる
もちろんデータ検証以外の処理もおなじこと
333(1): 2020/12/25(金)12:16 ID:uurLZNKt(5/8) AAS
>>331
そう。その何かしらのメリットを知りたいのだ…
>>245
>>250
はjavascriptの例だが、これがrubyでも起こるとすると
しょーもないCRUDの画面でもテスト書かないといけないのだろうか。
javascript勢がTypeScriptに流れてるってことは
省1
334: 2020/12/25(金)12:24 ID:cyV6b5qO(1) AAS
それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
335: 2020/12/25(金)12:30 ID:uurLZNKt(6/8) AAS
だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
336: 2020/12/25(金)12:31 ID:fU2xV1RD(1) AAS
>>321
明日もお願いします。
337(2): 2020/12/25(金)12:32 ID:uurLZNKt(7/8) AAS
Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし
338: 2020/12/25(金)12:37 ID:JfQSa+1c(9/10) AAS
>>333
動的言語はコード編集から動作確認、テスト実行開始までがとにかく早い
なのでゼロベースの新規プロジェクト、サービス公開までの時間を最優先する場合にはデメリットよりメリットが上回る
339: 2020/12/25(金)13:33 ID:pgbI6Wzr(1/5) AAS
>>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
ＪSやJavaのスレッドはある
Java Web Application Framework総合 ver2
2chｽﾚ:tech
C#は乱立してないから素直にASP.NET使えばいい
省2
上下前次1-新書関写板覧索設栞歴
あと 269 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.022s