20/07/17 01:02:45 d4gKLDNu.net
adobe airのときもsilverlightのときも同じこと言ってたよそいつ。
懲りない奴だｗ
264:デフォルトの名無しさん
20/07/17 01:46:03 OVoiSg0p.net
>>258
何言ってんのこいつw
265:デフォルトの名無しさん
20/07/17 08:38:22.72 Mcc/Kfhl.net
>>258
昔の知識のままの人か？
Blazorも.net Core対応と書いてあるし
.net CoreならLinuxやMacでも動くはずだ
Blazorのhelpにもapacheとかがかいてある
266:デフォルトの名無しさん
20/07/17 08:41:05.93 5L8OAF1I.net
いうてもApacheでASP.NETとか使ってるヤツ居るの？
267:デフォルトの名無しさん
20/07/17 08:50:27.95 wFTyM9Vl.net
今から使い始めるならIISよりはapacheだろ
268:デフォルトの名無しさん
20/07/17 08:58:36.98 Mcc/Kfhl.net
>>262
言い訳する前に知識が古かったのを認めろよ
Linuxでasp.net使いたいニーズがあったからこそ対応したんだろ
ApacheだけでなくNginxもかいてある
URLﾘﾝｸ(docs.microsoft.com)
あとweb frameworkで一番シェア高いのはASP.NETだぞ
WordPressとか間接的にframework使ってるの除いたらシェアトップ
269:デフォルトの名無しさん
20/07/17 09:12:02 HKFGOVIo.net
>>262
うちはnginx, asp.net core api, asp.net core MVC+Vue
270:デフォルトの名無しさん
20/07/17 10:23:29.59 rScYk2f8.net
>>263
この文脈でIISとApacheを比較するのかよ・・・
この文脈でのIISはWebサーバーとしての側面ではなくアプリケーションサーバー（.NETコンテナ）としての話だろ
比較するならApacheやnginxではなくTomcatやGlassFishだと思うが
271:デフォルトの名無しさん
20/07/17 10:32:08.75 Mcc/Kfhl.net
>>266
おまえもApacheやnginxでASP.net Coreが
動かないと思ってるのか？
272:デフォルトの名無しさん
20/07/17 10:36:10.93 4woZuOkK.net
Blazor ServerってSSRだよな
このスレに関係ないじゃん
273:デフォルトの名無しさん
20/07/17 10:37:15.19 Mcc/Kfhl.net
>>265
OSとDatabaseは何使ってるの？
遅いのは最初の読み込みだけ？
Microsoftのデモ動画みたら動作も遅いように見えた場面が
あってパフォーマンスどうなのかなと。
WebAssemblyでいい性能出るならC#で書きたい
JSもTSもめんどくさい
274:デフォルトの名無しさん
20/07/17 11:00:42.67 rScYk2f8.net
>>267
Apacheやnginxでは.NETは動かないだろ？
まさかなーと思って今調べてみたけどやっぱり動かないみたいだぞ
検索してみると出てくるのはdotnet runでポート5000をリッスンさせてApacheやnginxをリバースプロキシとして表に立たせる構成ばかりだ
これはdotnet runプロセス自体がアプリケーションサーバーの役割を担ってるだろ？
Apacheやnginxで.NETが動くのとは程遠い話だ
俺がまだ勘違いしてるのか？
もしApacheで.NETが動くというのならmod名とか教えてくれ
275:デフォルトの名無しさん
20/07/17 11:21:27.37 afn+PT1M.net
>>267
すまんがASPに対しては負の遺産という印象しかない
276:デフォルトの名無しさん
20/07/17 11:26:49.33 afn+PT1M.net
>>270
それ言ったらnginxでphp使う方法と変わらんからASP厨がドヤ顔でえばるだけやぞ
277:デフォルトの名無しさん
20/07/17 11:35:17 rScYk2f8.net
PHPとかnginxのことは知らんのだけど
Apache + PHP だとCGI（別プロセス）で動かすのではなく、Apacheプロセス内で動かす専用modとかあるんでしょ？
そのくらい特化してたらApacheで動くと言ってもいいと思うが
リバースプロキシ立てただけで「Apacheで動く」は恥ずかしいよ
278:デフォルトの名無しさん
20/07/17 12:08:02.38 hTUFpXFi.net
>>273
nginxの場合php-fpmっていう別サービスを立てて
nginxのリバースプロキシでポートもしくはソケット経由でphpのリクエストをphp-fpmに渡す様な形式
279:デフォルトの名無しさん
20/07/17 12:30:36.62 p1TzKNxq.net
>>269
RDBはポスグレ
起動も思ったより早いよ
リクエストはまじで爆速
280:デフォルトの名無しさん
20/07/17 12:36:31.61 rScYk2f8.net
>>274
ありがとう
nginx + PHPにもphp-fpmという専用のFastCGI機構があるのね
ここまで特化してたらnginxでPHPが動くと言ってもいい
だがdotnet runは構成がまったく違う
Apacheやnginxはdotnet runを特別に扱ってないし関知もしてない
やはりApacheやnginxで.NETが動くとは言えないな
281:デフォルトの名無しさん
20/07/17 13:17:03 HR6IsBOl.net
スレタイ読めないのかな？
npm trends
URLﾘﾝｸ(leerob.io)
282:デフォルトの名無しさん
20/07/17 13:23:21 PZ71VWVR.net
>>277
angularと@angular/coreの違いについて頼む
283:デフォルトの名無しさん
20/07/17 14:16:04.30 Mcc/Kfhl.net
>>270 >>273
ASP.net CoreのapplicationはKestrel上で動く。
KestrelはMSが作ったlightweight web server,
そしてopen source、ライセンス料も不要
あなたがdotnet runと書いてるそれはKestrel serverの起動だとおもう
Kestrel単体でもASP.net coreのweb appを動かすことができる。
Kestrelは超軽量で高速なweb serverだけど機能が少ない。
それでIIS, Nginx, Apacheなどと併用することをMSが推奨してるらしい。
Nginxとかにあるセキュリティ機能が使えるようになる
ちなみにASP.net Coreになる前の従来型のASPでは
ApacheとかのModはあったよ
セキュアで高速にASP.net Core動くなら
Kestrel併用方式でもMod方式でｂ烽ﾇっちでもいｂ｢でしょ？
細かい機能いらないなら、Kestrel単体で動かしてもいい
おそらくそれが最速になる
284:デフォルトの名無しさん
20/07/17 14:35:49.91 rScYk2f8.net
kestrel(dotnet run)を否定しているわけじゃないよ
それは単体でHTTPを話す能力を持ってるじゃん
つまりTomcatやGlassFishと同じ位置付け
Apache、nginx等のWebサーバーを手前に追加するもしないも自由
でもそれは「Apacheで.NETが動く」という話にはならない
285:デフォルトの名無しさん
20/07/17 14:45:14.98 Mcc/Kfhl.net
>>273 >>280
従来型のASP.netはModとかFastCGI対応していた。
Linuxでうごくこういうやつがあった
URLﾘﾝｸ(www.mono-project.com)
Monoは互換性がいまいちなので個人的にお勧めしない
ASP.net CoreをKestrel単体またはKestrel+(Nginx or Apache or IIS)
で動かすのが今のMicrosoft推奨のやりかた。
高速に動くなら内部の仕組みはどうでもいい話だろう？
あとは重要なところでLinuxで動いてライセンス無料になってるんだし
Modがあるかなんてどうでもいいよ。
そもそもApacheは高速なWeb serverじゃないの知ってるの？
あえてApache選ぶ理由がないよ。
大規模サイトはNginxが多い
286:デフォルトの名無しさん
20/07/17 14:48:05.03 Mcc/Kfhl.net
>>280
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ
.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから
287:デフォルトの名無しさん
20/07/17 14:49:01.58 bZMoLlJz.net
Apacheに乗せるなんて無駄なことしたくない
Nginx RP + Inproc Httpがスマートで最高
288:デフォルトの名無しさん
20/07/17 14:55:32.14 rScYk2f8.net
静的コンテンツのレスポンス高速化のためだけにリバースプロキシ（Apache, nginx）置くわけじゃないから
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない
289:デフォルトの名無しさん
20/07/17 15:02:52.55 bZMoLlJz.net
最近はApacheを知らない若者も居るようだ
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい
290:デフォルトの名無しさん
20/07/17 15:46:01.13 Q8AVDrqq.net
Nginx は、リバースプロキシ
世界最速は、Ruby on Rails 製の
URLﾘﾝｸ(dev.to)
これよりも速いものは、作れない
291:デフォルトの名無しさん
20/07/17 19:01:29 gHhKsxDc.net
最近JIT対応したPHP8のalpha版が結構いいスコア出してるそうだがな
292:デフォルトの名無しさん
20/07/17 21:28:04.44 LPqky/1r.net
>>278
angularは1系で@angular/coreは2以降じゃないかな
しっかしReact圧倒的だね
293:デフォルトの名無しさん
20/07/17 21:55:04.26 XQc3SgYX.net
1系ってAngularJS表記なんだと思ってたがそうじゃないのか
294:デフォルトの名無しさん
20/07/17 22:04:00.19 5B+Amw9H.net
Reactってjadeと互換性あるの？
HTMLや動的テンプレファイル上に
直で書くとサーバ変数そのままJavaScriptに
埋め込んでコーディングできるから
.jsファイルの外部化は個人的にかなり抵抗感がある
295:デフォルトの名無しさん
20/07/17 23:32:34.52 pbRdpk23.net
フロントエンドのライブラリだというのに
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん
296:デフォルトの名無しさん
20/07/18 00:18:41.79 lkZeEJlA.net
>>287
PHPは言語がうんこすぎて
ベンチマークいくらよくても使う気にならない
297:デフォルトの名無しさん
20/07/18 00:25:43.24 Rz8uT7Q+.net
phpはhtmlに直接サーバーサイド変数を埋め込めるという点で負の遺産を残しすぎた。
wordpressだのsmartyだの吐き気するわ。
298:デフォルトの名無しさん
20/07/18 01:02:58.86 mlew4XCO.net
>>293
それの何が悪いの？
299:デフォルトの名無しさん
20/07/18 01:08:32.40 5AaucbBP.net
バックエンドなんてフレームワークで構成してJSONやり取りするもんだからそんなの別に気にする事じゃないだろ
300:デフォルトの名無しさん
20/07/18 02:09:48.73 lkZeEJlA.net
>>275
PostgreSQLか
爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも
C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？
301:デフォルトの名無しさん
20/07/18 02:21:16.88 N4WthBbf.net
> React+Next.js勉強やめて
勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ
302:デフォルトの名無しさん
20/07/18 02:39:54.52 lkZeEJlA.net
>>297
俺が何時間やったかも書いてないのにそんなレスつけてしまうおまえが頭悪い
あと頭いい人はそうやって文末にwつけないしアンカーをつける
303:デフォルトの名無しさん
20/07/18 04:07:12.10 N4WthBbf.net
なるほどつまり数時間やって分かんなくて嫌になってwasmならできるモン！ってことか。説明ご苦労。
そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ
304:デフォルトの名無しさん
20/07/18 08:45:31.60 5AaucbBP.net
WebAssemblyに夢見過ぎなヤツ多いな
そんなに速度が必要な事をやってるのかと
305:デフォルトの名無しさん
20/07/18 09:04:24.26 lkZeEJlA.net
>>300
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる
夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。
実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う
306:デフォルトの名無しさん
20/07/18 09:10:26.95 huqpRUrM.net
Blazorはサンプル動かすまで超簡単
あれこれ聞く前に自分で試したほうが早いよ
dotnet sdkの最新版を落としてインストールしたら
dotnet new blazorwasm
dotnet run
これだけでBlazorが動く
頭の悪い大量の設定を書く必要はない
小学生やお猿さんでも簡単にできる
ちな↑は完全に静的なサイトを作りたいとき
サーバーサイドAPIも作りたいなら
dotnet new blazorwasm --hosted
dotnet run
これでおｋ
サーバーサイドレンダリングしたいなら
dotnet new blazorserver
dotnet run
これでおｋ
307:デフォルトの名無しさん
20/07/18 09:10:56.66 5AaucbBP.net
>>301
ECでボトルネックになるのは大体の場合サーバーサイドだろ
308:デフォルトの名無しさん
20/07/18 09:13:11.20 lkZeEJlA.net
>>299
根性とかアホじゃないか
C#やJavaで開発してきた人がTSの開発を理解できないわけがない
309:デフォルトの名無しさん
20/07/18 09:28:04.98 lkZeEJlA.net
>>303
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど
速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？
310:デフォルトの名無しさん
20/07/18 09:33:43.74 Zsjd19dY.net
wasmの求人需要ってある？
311:デフォルトの名無しさん
20/07/18 09:41:11.98 a72QTQ2S.net
1ミリもない
312:デフォルトの名無しさん
20/07/18 09:48:13.03 37eL7IOf.net
自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ
313:デフォルトの名無しさん
20/07/18 10:09:29.41 N4WthBbf.net
>>304
根性じゃなきゃやっぱり頭のほうかｗ
数時間かけても理解できずに止めたんだろ？なんかゴメンなｗｗｗ
314:デフォルトの名無しさん
20/07/18 10:18:52.49 5tCG/Slu.net
理解できないことはないんだろうけど
拒否反応を起こす人は結構いるね
JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし
315:デフォルトの名無しさん
20/07/18 11:01:01 fwbEJCvA.net
>>301
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？
今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる
「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？
316:デフォルトの名無しさん
20/07/18 11:07:30 fwbEJCvA.net
>>305
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。
WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い
317:デフォルトの名無しさん
20/07/18 11:20:03 fwbEJCvA.net
WebAssemblyはどんな問題（課題）を解決するのかを答えられないようじゃ
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。
WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ
つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない
318:デフォルトの名無しさん
20/07/18 11:23:08 oiSxLKa2.net
wasmでVM動かしてる状況だとまだ劇的に速いとは言えないのでは
wasmのGC実装もこれからだし流石に時期尚早感がある
319:デフォルトの名無しさん
20/07/18 11:28:21 5tCG/Slu.net
JavaScriptだってネイティブ実行されてるわけじゃなくJITコンパイルしながら実行されてるでしょ
wasmのVMが大きなオーバーヘッドだとは思わないけどな
320:デフォルトの名無しさん
20/07/18 11:29:28 Z+cMIoZ7.net
>>313
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！
321:デフォルトの名無しさん
20/07/18 11:33:48 fwbEJCvA.net
>>316
そんな人もいるんだからって言いたいの？ｗ
322:デフォルトの名無しさん
20/07/18 11:49:48 zDePOjuW.net
jsをwasmにコンパイル出来たら爆発的に普及しそうなんだが、いまだにまともにできないんだよな。
323:デフォルトの名無しさん
20/07/18 11:54:20 Z+cMIoZ7.net
>>317
そうですワタシが変なおじさんです。
応答速度がどうのこうのと言う話の流れを見てますと
WebブラウザのSPAで3次元CADも出来る時代になったのだなあと感慨に老けっております。
324:デフォルトの名無しさん
20/07/18 11:59:32 fwbEJCvA.net
>>319
論点はそこじゃなくて、
「3次元CADやるなら別にブラウザじゃなくていいよね」
だから
なぜわざわざ遅いとわかってるブラウザで動かすのか？
ブラウザで動かさなきゃいけない使命でもあるの？
325:デフォルトの名無しさん
20/07/18 12:07:43.56 OjEg02/9.net
jquery bootstrap Vue React angular
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！
326:デフォルトの名無しさん
20/07/18 12:18:23.75 Z+cMIoZ7.net
>>320
時代はリモートでコラボれーしょんやら？
WebVRで3Dチャット元年ではなかったのかと・・・
327:デフォルトの名無しさん
20/07/18 12:25:07.68 huqpRUrM.net
VS+C#の快適さに比べたらJSやTSなんてゲロ以下でしょ
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー
328:デフォルトの名無しさん
20/07/18 12:27:17.68 a72QTQ2S.net
vscode + js のウルトラ開発体験知らんのか？
329:デフォルトの名無しさん
20/07/18 12:28:49.89 5AaucbBP.net
>>323
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない
330:デフォルトの名無しさん
20/07/18 12:29:31.05 huqpRUrM.net
>>324
VSCodeは不安定すぎて話にならんわ
331:デフォルトの名無しさん
20/07/18 12:31:33.52 huqpRUrM.net
>>325
宗教上の理由でIDEを避けたいならそうすればいい
Blazorも例に漏れずVScodeでもVimでもなんだって開発できる
ま、VSが最強なので他はオススメはせんがね
332:デフォルトの名無しさん
20/07/18 12:33:55.33 cNrPu/ON.net
VSおじさんｗ
Silverlightはどうなりましたかｗ
333:デフォルトの名無しさん
20/07/18 12:40:21.88 fQsuqJMx.net
wasm(たとえばC#)って画面描画どうやってやるの？
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？
wasm詳しい人教えてくれ！
334:デフォルトの名無しさん
20/07/18 12:50:44.89 cNrPu/ON.net
まだ直接DOMいじれない。
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ
335:デフォルトの名無しさん
20/07/18 12:53:18.24 5tCG/Slu.net
え、DOMいじれずC#(WPF)で描画もだきないのか
結局、JavaScript使わないといけないんじゃ微妙ね
ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ
336:デフォルトの名無しさん
20/07/18 12:55:00.61 hYOY3gDK.net
>>328
この返しは恥ずかしすぎる
337:デフォルトの名無しさん
20/07/18 12:55:34.30 hYOY3gDK.net
>>329
Razorマークアップ
338:デフォルトの名無しさん
20/07/18 12:56:00.12 hYOY3gDK.net
>>331
JSは要らんよ
339:デフォルトの名無しさん
20/07/18 12:56:27.32 cNrPu/ON.net
でもそのwasmの外にあるjsへの指示・管理はフレームワーク側の仕事だからあなたが直接dom api叩く必要はない
340:デフォルトの名無しさん
20/07/18 13:00:40.40 fwbEJCvA.net
>>322
> 時代はリモートでコラボれーしょんやら？
> WebVRで3Dチャット元年ではなかったのかと・・・
だからブラウザ使わなくて出来てるでしょｗ
341:デフォルトの名無しさん
20/07/18 13:02:21.10 fwbEJCvA.net
>>329
ブラウザの中に仮想マシンが実装されたと考えれえばいい
表示はブラウザの中の一部分が仮想マシンのウインドウになったようなもの
その中で何でも出来る。その中でしか動かない。
342:デフォルトの名無しさん
20/07/18 13:06:46.63 u6Nb4/2q.net
ブラウザのDeveloperToolでデバッグできる？
343:デフォルトの名無しさん
20/07/18 13:08:43.45 fwbEJCvA.net
JavaScriptもJITとか使うから計算とかならネイティブとほぼ同じ速度で動くんだよ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ
DOMの複雑なレンダリングアルゴリズムが原因だから
それは避けようがない。
しかしもともとは画面表示なんて縦横のビットマップでしかなかったわけで
DOMのレンダリングを避けて、直接描画しましょうっていうのがWebAssembly
DirectXの思想と似てるね。WebAssemblyの目的はレガシー技術の移植だから
DOMは必要ない。なのでWebAssemblyからDOMを直接さわれるようなことはないよ
間接的に触れればOK。
画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ
344:デフォルトの名無しさん
20/07/18 13:39:15.04 5tCG/Slu.net
wasmの画面描画について答えてくれてありがとう
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね
wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ
345:デフォルトの名無しさん
20/07/18 13:42:32.30 fwbEJCvA.net
外部との通信やファイルアクセスやI/OはブラウザのAPIエミュレートされる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる
346:デフォルトの名無しさん
20/07/18 13:44:42.37 fwbEJCvA.net
そういうI/O系はJavaScript APIを使ってエミュレートされるので
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ
347:デフォルトの名無しさん
20/07/18 13:48:10.88 zDePOjuW.net
wasmの画面表示って結局jsと同じDOMかWebGLじゃね？
348:デフォルトの名無しさん
20/07/18 13:58:51.62 fwbEJCvA.net
>>343
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）
だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される
349:デフォルトの名無しさん
20/07/18 14:54:17.15 5tCG/Slu.net
wasmおもしろそうだな
いっちょさわってみるか
350:デフォルトの名無しさん
20/07/18 14:59:20.43 OjEg02/9.net
>>334
そんなものオタクしか興味ねーよ
手軽さとか互換性問題が起きない方がよっぽど大事
351:デフォルトの名無しさん
20/07/18 15:00:47.66 lkZeEJlA.net
>>302
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。
352:デフォルトの名無しさん
20/07/18 15:01:01.32 zDePOjuW.net
ああ、言いたかったのは描画に関しては結局jsと変わらんだろうということ。
Canvas APIやWebGL APIを呼ぶだけだしね。
353:デフォルトの名無しさん
20/07/18 15:03:36.80 lkZeEJlA.net
>>306-307
すぐBlazorやりたければ自分で作った会社で開発してマネタイズすればいい。
今までにC#でASP.netの開発やってる企業なら近いうちにBlazorの案件始めるよ
JSに比べて開発生産性高いのだからBlazorやらない理由がない
>>310
C#になれてるとdynamic languageへの拒否反応はたしかに強い
開発の生産性が低すぎるんだもの
354:デフォルトの名無しさん
20/07/18 15:08:26.33 lkZeEJlA.net
>>311
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ
なぜSPでネイティブアプリがあるかっておもに性能だろう
パフォーマンス重要な用途がわからない？？
開発者でそれが思い浮かばない人っているんだね
ハイパフォーマンスということはわざわざAndroidやiOSの
アプリつくって売上の30%ぼったくられなくても
Blazorでゲーム作って稼ぐようなこともできる。
それくらい思い浮かばないかふつう。
パフォーマンスめちゃくちゃ大事
355:デフォルトの名無しさん
20/07/18 15:28:43.67 fwbEJCvA.net
>>350
> なぜSPでネイティブアプリがあるかっておもに性能だろう
違うよ。ネイティブアプリの自由度の高さと
スマホ標準インターフェースとの統合
356:デフォルトの名無しさん
20/07/18 15:35:33.35 lkZeEJlA.net
>>312
Blazorだとclient, severの両方をC#でかけるから
開発生産性が高い
という当たり前の話が前提としてある
Blazorでは既存のJS libraryは使えるがJS開発はおまけ
自分で開発するのは主にC#
node.jsはbrowserがJSだからserverも同じ言語だと効率がいいっていう
理屈で作られたものだろう
しかしJS自体がうんこなのでnode.jsはserver sideもうんこ言語で
開発することになる
357:デフォルトの名無しさん
20/07/18 15:40:33.50 lkZeEJlA.net
>>313
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる
server sideまでうんこ言語（JS)やその改善版（TS)で
開発する時代がいつまでも続くと思うか？
俺は全く思わない
好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ
358:デフォルトの名無しさん
20/07/18 15:43:26.01 lkZeEJlA.net
>>318
JSってType safetyじゃないだろ
もともとcompileと合わないうんこ言語だからどうしようもない
C#とかに変えればいいだけだ
359:デフォルトの名無しさん
20/07/18 15:47:48.54 lkZeEJlA.net
>>320
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ
wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ
360:デフォルトの名無しさん
20/07/18 15:52:34.71 lkZeEJlA.net
>>328
そういうアホな質問はいたるところで論破されてる
SilverlightとちがってWebAssemblyはstandardなの
普及しない理由がないの
361:デフォルトの名無しさん
20/07/18 15:54:43.54 VwC7Y7IV.net
まあなんにせよいつまでもJS、TSにしがみついてるのはエンジニアとしてリスキーだよね
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た
362:デフォルトの名無しさん
20/07/18 15:54:46.28 lkZeEJlA.net
>>329
URLﾘﾝｸ(docs.microsoft.com)
363:デフォルトの名無しさん
20/07/18 16:41:05.47 5tCG/Slu.net
>>358
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね
ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い
364:デフォルトの名無しさん
20/07/18 16:44:31.11 fwbEJCvA.net
なんでクライアントとサーバーで同じ言語で作ったほうが
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？
365:デフォルトの名無しさん
20/07/18 16:44:51.36 fwbEJCvA.net
>>357
お前は何の言語にしがみついてるんだ？ｗ
366:デフォルトの名無しさん
20/07/18 16:51:43.65 5tCG/Slu.net
>>360
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
おれはSQL併用するけどSQL使わない勢も実際にいるよ
ORMの自動生成クエリーだけでなんとかするっていう
逆にSQLでビジネスロジック全部やりたい勢もいるストアド大好きな人達
ソフトウェアって自由でいいな
367:デフォルトの名無しさん
20/07/18 16:53:18.15 fwbEJCvA.net
>>3
368:59 UIをコードで書くならDOMベースが一番適してるんだよ HTMLかXMLかそれに近いマークアップ言語 その例外がゲームとかCADとか点や線ベースでの インターフェースを持っているもの 具体的に言えば、点や線が目まぐるしく変わるもの
369:デフォルトの名無しさん
20/07/18 16:56:29.69 fwbEJCvA.net
>>362
> JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
RubyやPython使ってるだろ
目的に応じて適切な言語使ってるんだよ
370:デフォルトの名無しさん
20/07/18 17:11:56.84 UMJ4s/bl.net
nodeは立ち上がりが軽くて速くてスケール時に使い捨てしやすいからだろう。
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
URLﾘﾝｸ(levelup.gitconnected.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
.NET遅っそｗｗｗ重っもｗｗｗｗ
371:デフォルトの名無しさん
20/07/18 17:32:39.93 vLQD9afh.net
>>344
WebGLでもDOMのように階層持たせることはできるの？
俺は3Dゲーム作っていたんだが、あんな感じでポリゴンみたいにして作るのかな
今イチわからん
372:デフォルトの名無しさん
20/07/18 17:43:52.38 lkZeEJlA.net
>>359
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ
WPFはXAMLだっけ、あれはXMLの方言みたいなやつだよね
Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう
373:デフォルトの名無しさん
20/07/18 17:46:29.08 vfrpqE6H.net
>>366
WebGLはDOMの一要素canvasを仮想的なディスプレイと見立てて
その中にOpenGLの命令で自由に描画するもの
374:デフォルトの名無しさん
20/07/18 18:54:17.02 162OGkYI.net
>>359
WPFじゃないけどXamlでWeb開発可能らしいね
個人的にはよく知らんけどWinUIとかいうやつ
375:デフォルトの名無しさん
20/07/18 18:56:30.00 162OGkYI.net
間違えたWinUIじゃなかったUnoだ
376:デフォルトの名無しさん
20/07/18 19:26:35.55 5AaucbBP.net
>>336
あーもうそれこのスレ関係ないって事だよね
専用スレ立てればいいのにね
377:デフォルトの名無しさん
20/07/18 19:30:44.95 5AaucbBP.net
あんじゃん
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
ｽﾚﾘﾝｸ(tech板)
378:デフォルトの名無しさん
20/07/18 20:42:52.64 Rz8uT7Q+.net
wasmで処理速度が上がるのか知らんけどコンパイルされるわけだからネイティブコードよりも転送量増える理屈だよな。
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？
379:デフォルトの名無しさん
20/07/18 21:47:01.74 5tCG/Slu.net
そうですね
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる
380:デフォルトの名無しさん
20/07/18 22:58:32.39 lkZeEJlA.net
>>373
コンパイルされたものがBrowserに配られる
本番環境用にサイズを小さくするオプションもあるし
browser にcacheされるから2回目以降は速い。
demoみてもその辺は考慮されて設計されてるかんじ
最初は遅いのはPWAとかSPAでも同じでしょ
>>374
VMまるごと転送するなんてどこにも書かれてないし
そんなことやるとは思えない
Wasmで共通のバイナリはBrowser updateのときに入るでしょ
381:デフォルトの名無しさん
20/07/18 23:16:25.72 lkZeEJlA.net
>>373
速度はあがるし目的としても書かれてる
URLﾘﾝｸ(webassembly.org)
Efficient and fast
The Wasm stack machine is designed to be encoded in a size- and
load-time-efficient binary format. WebAssembly aims to execute
at native speed by taking advantage of common hardware capabilities
available on a wide range of platforms.
>>331 ではDOMいじれないとか書いてるし誤解しすぎ
DOMいじれないWeb UI Frameworkなんてあるわけないだろうｗ
382:デフォルトの名無しさん
20/07/19 00:48:48.05 xggXZiaY.net
URLﾘﾝｸ(qiita.com)
> WebAssembly側から直接Domを操作することは出来ない。そのため、WebAssemblyにコンパイル出来る各言語にJavaScriptのAPIを呼び出すWasm用のライブラリが開発されている。
URLﾘﾝｸ(github.com)
> To realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to:
>
> reference DOM and other Web API objects directly from WebAssembly code;
> call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript; and
> efficiently allocate and manipulate GC objects directly from WebAssembly code.
これ↓が未実装なんだから現状DOM操作はJSさんお願いしますしてるだけだぞ。
> call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript; and
383:デフォルトの名無しさん
20/07/19 02:34:09.44 ktD9w8qF.net
とりあえずBlazorのsampleいっこだけ動かしてみた
>>377
「直接いじれない」と「いじれない」では全然違うでしょ
JavaScript Interopの存在は知ってるし
>>376はちゃんと「DOMいじれない」というのを否定してる。
384:デフォルトの名無しさん
20/07/19 03:24:25.64 Xo5fmFzm.net
完全にスレチじゃん？
385:デフォルトの名無しさん
20/07/19 04:14:25.27 VuyFWk7z.net
blazor-serverはともかくblazor-wasmは深刻なパフォーマンス問題があって、
[Blazor WebAssembly] Serious performance issues
URLﾘﾝｸ(github.com)
その対策は進行中↓
Blazor performance optimizations #22432
URLﾘﾝｸ(github.com)
つまりまだ全然安定しておらず、スレタイなんかと成熟度は比べるべくもない。
トラブルが起こったときアセンブリレベルでデバッグしたいならどうぞ。
blazor-serverのほうは実用レベルに到達してるけど、それこそスレチだしphpあたりと勝負してきてどうぞｗ
386:デフォルトの名無しさん
20/07/19 05:20:39.95 VEGN/NtA.net
WebAssembly自体が期待されるほど速くないから、今のままだと廃棄物になることがわかりきってるもんなあ。
ある日突然爆速になったら状況は全然変わってくるだろうけど
387:デフォルトの名無しさん
20/07/19 05:28:36.09 W3hSYpRn.net
WebAssemblyの目的は既存アプリ（特にゲーム）の移植なんだって
他の言語で開発できるって言うけど、
サーバーサイドは昔から他の言語で開発できたのに
遅いはずのスクリプト言語を使っていただろ
速度ははやければ良いねぐらいの扱いで、誰も期待してないんだよ
それに脆弱性につながるからブラウザのセキュリティ能力を超えることはできない
JavaScriptでもできることを他の言語でできるだけ
388:デフォルトの名無しさん
20/07/19 05:33:59.05 x6eBp0n6.net
Webはやはり描画がクソ重いよなあ
ゲームの超複雑な計算でも60fps出るだろ
DOM構築ごときに処理かかりすぎなんだよ
389:デフォルトの名無しさん
20/07/19 07:47:59 tFAvgvCU.net
>>375
wasmはVM転送しないの？
仕組みを見るとwasmは仮想アセンブラのバイトコードを実行するみたいに見える
たとえばC/C++をコンパイルする場合、完全スタティックリンクが必要になるのでは？
つまり依存libcもwasmにして転送されるのではないですか？（全体ではなく必要な関数だけとはいえ）
同様にC#はVM部分をwasmにしてブラウザに転送する必要があるように見える
違うの？
libcやVMなどはブラウザ側の更新で増えていくものなの？
390:デフォルトの名無しさん
20/07/19 07:53:19.22 tFAvgvCU.net
やっぱり数MBのVM(mono.wasm)を転送するじゃないか！
391:デフォルトの名無しさん
20/07/19 08:02:41.88 PEwdaGfT.net
libcもmono.wasmもどっちもVMじゃないから。そういうライブラリのことを聞きたかったのだとしたら
使う言葉を間違えてる。
392:デフォルトの名無しさん
20/07/19 08:10:57.60 tFAvgvCU.net
.NETが現実的な選択肢になりえないことは分かったのでもういいですよ
393:デフォルトの名無しさん
20/07/19 08:26:55.45 W3hSYpRn.net
>>385
wasmは転送量増えるよね。
小規模なコードならJavaScriptの方が小さくなる
だからwasmが対象としてるのは過去の比較的大規模なアプリを
そのままブラウザで動かすためのもの
それは大体ゲームｗ
394:デフォルトの名無しさん
20/07/19 08:45:06.05 nXJK1voh.net
ブラウザでゲームやるならクラウドでええやんってなるに決まってるだろ
395:デフォルトの名無しさん
20/07/19 08:45:29.98 PIkW4oBq.net
>>380
LOHじゃん
よっぽど馬鹿なプログラム書かなきゃ問題にならんよ
396:デフォルトの名無しさん
20/07/19 08:47:06.11 W3hSYpRn.net
>>389
クラウドが何を言ってるのかわからんけど、
ここで言ってるゲームっていうのは過去PC用でリリースしたものの話だよ
移植を楽にしてくれるのがwasm
397:デフォルトの名無しさん
20/07/19 08:48:50.35 PIkW4oBq.net
>>388
業務系
398:デフォルトの名無しさん
20/07/19 08:50:00.32 j+IrtB5e.net
>>385
キャッシュされるからそれは無視していいよ
399:デフォルトの名無しさん
20/07/19 08:53:37.36 tFAvgvCU.net
>>393
気になるかならないか決めるのは開発者ではなく利用者だから
400:デフォルトの名無しさん
20/07/19 08:57:28.54 W3hSYpRn.net
>>393
jQueryなどは複数のサイトで同じライブラリを使うから
あるサイトでキャッシュされたら他のサイトでも早くなることがある。
CDNが使われることも多い
でもwasmはそうならんやろ？使われてる例自体も少ないし。
401:デフォルトの名無しさん
20/07/19 08:59:03.14 PIkW4oBq.net
>>394
ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
Gmailとか起動遅いけどみんな普通に使ってるだろ
まあ遅いといってもデスクトップアプリよりは速いし
開発者が過剰に神経質になってるだけだ
402:デフォルトの名無しさん
20/07/19 08:59:45.80 W3hSYpRn.net
>>392
業務系にwasmは使い物にならんよね。HTMLで簡単にUIをつかえるのに
wasmだとそこから作らなければいけない
ゲームならそこから作るのは当たり前だけど
業務系はすでにある使いやすいコンポーネントを再利用するのが普通
速度も業務系だと結局サーバーサイドでやることが多いし
403:デフォルトの名無しさん
20/07/19 09:01:44.02 W3hSYpRn.net
>>396
> ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
> Gmailとか起動遅いけどみんな普通に使ってるだろ
速度とかよりも手軽さ重視だからね
ブラウザでもアプリでも気にしないし
wasmの価値は移植を楽にしてくれる所というのはそういう話
404:デフォルトの名無しさん
20/07/19 09:02:52.10 tFAvgvCU.net
>>396
もういいって
遅くても我慢して使ってくれるから大丈夫！
とかなんなの？
あなたとは話す価値がないと判断した
405:デフォルトの名無しさん
20/07/19 09:02:58.39 PIkW4oBq.net
>>395
時間が解決する問題だな
つか別に複数サイトで共有しなくてもキャッシュされるし
つか.NETは単一バイナリのビルドとモジュールのトリミングを研究してるからデカイランタイム問題もすぐ解決するよ
406:デフォルトの名無しさん
20/07/19 09:04:20.16 W3hSYpRn.net
> 時間が解決する問題だな
「使う理由がない」は時間が解決してくれないよ
時間が解決するのは、今実際に起きている課題だけ
407:デフォルトの名無しさん
20/07/19 09:04:23.55 tFAvgvCU.net
時間が解決する問題ってことは
やはり現時点では.NETは現実的ではないってことね
成熟したらまた教えて
408:デフォルトの名無しさん
20/07/19 09:05:40.29 W3hSYpRn.net
>>399
> 遅くても我慢して使ってくれるから大丈夫！
> とかなんなの？
誰もそんな話はしていない。
遅いのだろうが許容範囲なのでみんな使ってくれているので大丈夫
使ってくれるはずという希望じゃないんだよ。
実際に使ってるんだよ。だからこの程度であれば大丈夫であることは証明済み。
409:デフォルトの名無しさん
20/07/19 09:06:25.23 PIkW4oBq.net
>>397
まるごと再利用しか頭にないのか？
業務系ではレガシーなシステムの移植とかいくらでもあるんだが
業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい
410:デフォルトの名無しさん
20/07/19 09:06:59.87 W3hSYpRn.net
> 業務系ではレガシーなシステムの移植とかいくらでもあるんだが
移植で作り変えるならブラウザ版を作りますって（笑）
411:デフォルトの名無しさん
20/07/19 09:08:44.46 W3hSYpRn.net
> 業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい
苦手なやつがC#使ったからって克服できるわけ無いやろｗ
苦手なら得意な人がやればいいだけだし
分業できる方が良いよ
412:デフォルトの名無しさん
20/07/19 09:09:00.50 PIkW4oBq.net
>>399
お前も話す価値ないよ
速度なんてこれからいくらでも最適化で改善していく部分だから現状で少しビハインドでも全く問題にならねえんだよね
逆にそこしか否定できないってことはもうBlazorを無意識化では認めちゃってるってことだよ
413:デフォルトの名無しさん
20/07/19 09:09:48.38 PIkW4oBq.net
>>401
時間が経てば使う理由も増えるわけだが
414:デフォルトの名無しさん
20/07/19 09:10:04.29 W3hSYpRn.net
JavaScriptの速度も随分と改善しましたしね。
十分実用レベルに達している。
さらにCPUの性能は上がり続けてる。
415:デフォルトの名無しさん
20/07/19 09:10:20.89 PIkW4oBq.net
>>402
十分実用的、で、時間が経てば更によくなる
416:デフォルトの名無しさん
20/07/19 09:10:39.96 W3hSYpRn.net
>>408
増えないよ。お前がネット始めてから20年ぐらい立つだろうが
普段やってることは大して変わってねーだろ？ｗ
417:デフォルトの名無しさん
20/07/19 09:11:54.71 tFAvgvCU.net
Blazor勢 必死すぎるだろw
もういいんだって
418:デフォルトの名無しさん
20/07/19 09:12:03.15 W3hSYpRn.net
そもそもな。デスクトップアプリとして以前からできることを
ブラウザでわざわざやる理由がないんだよ
アプリ版を作ればいいだけなんだから
419:デフォルトの名無しさん
20/07/19 09:12:19.58 PIkW4oBq.net
>>405
移植でブラウザ版を作るから業務系開発者が得意なC#で開発できること価値が大きいんだろ
420:デフォルトの名無しさん
20/07/19 09:14:29.32 W3hSYpRn.net
>>414
だからサーバーサイドは以前からC#で開発できてますってｗ
421:デフォルトの名無しさん
20/07/19 09:15:20.05 m5eV0pvm.net
追うのめんどいから誰か論点整理して貼って
422:デフォルトの名無しさん
20/07/19 09:18:02.57 PIkW4oBq.net
>>406
克服できてしまうんだなぁこれが
つか.NETとVisualStudioが優秀だからなんとなくで作れるようになる
得意なやつがやればいい、なんてのはコスト意識のない下っ端の考え方なのではっきり言って論外
業務系はWeb系みたいなホビーじゃねえんだよ
423:デフォルトの名無しさん
20/07/19 09:19:09.28 W3hSYpRn.net
コスト意識があったら、適材適所って言葉を知ってるはずだがなｗ
なぜ苦手な人がフロントを作るのか
424:デフォルトの名無しさん
20/07/19 09:20:43.25 W3hSYpRn.net
C#で業務系と言うとASP.NETを使います。
UI込ですでに実現できてるんですよ。
wasmで一体なんのUIを作るんですか？
425:デフォルトの名無しさん
20/07/19 09:22:19.43 PIkW4oBq.net
>>411
ユーザー目線では特に変わってない
ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ
�
426:}イクロソフトの提供する開発体験はいつも素晴らしいものだ Blazorがもたらす開発体験にも当然、期待していいだろう 今では誰もが使ってるVSCodeもTypeScriptもそういやマイクロソフトだよなぁ 次のビッグウェーブが来てるんだろうな
427:デフォルトの名無しさん
20/07/19 09:24:05.39 PIkW4oBq.net
>>415
フロントエンドでもC#を使えるようになるのが大きいんだって話だろ
428:デフォルトの名無しさん
20/07/19 09:24:15.27 W3hSYpRn.net
> ユーザー目線では特に変わってない
> ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ
どういう理屈？言ってみただけの中身がない言葉は要らないよ
429:デフォルトの名無しさん
20/07/19 09:26:11.82 W3hSYpRn.net
>>421
> フロントエンドでもC#を使えるようになるのが大きいんだって話だろ
だからサーバーサイドの開発にフロントエンドも含まれてるんだってｗ
C#の面倒な実装じゃなくて、テンプレートエンジンを使った簡単な方法で
フロントエンドを作成できる
繰り返すが、C#で一体なにを実装するの？
すでにユーザーインターフェースは揃っている。
430:デフォルトの名無しさん
20/07/19 09:26:37.05 PIkW4oBq.net
>>418
やっぱホビーだなあんた
安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
大規模なチームで仕事をするなら絶対に必要なスキルだ
それをシラナイということは個人開発か、少数精鋭で作れるおもちゃみたいなスタートアップしかやったことないんだろ
431:デフォルトの名無しさん
20/07/19 09:27:14.26 W3hSYpRn.net
> 安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
だからフロントはHTMLが得意な安い人材を使います。
432:デフォルトの名無しさん
20/07/19 09:31:34.04 PIkW4oBq.net
>>419
SPAを作るんだよ
既存のASP.NET(Core)でも開発はできるがデスクトップアプリと比べると操作性が悪いことは否めない
複雑怪奇な業務に適応するためにSPAの導入は今後不可避になるだろう
しかしSPAをやるには今まではクソッタレJSやらポンポン入れ替わるWebフレームワークを学ぶ必要があって学習コストが高すぎた
業務系の主力である安い人材では習得が難しいのでSPAはずっと見送られてきた
しかしBlazorならその問題を一挙にカイケツすることができる
433:デフォルトの名無しさん
20/07/19 09:32:22.28 PIkW4oBq.net
>>422
君、プログラム下手でしょ
インターフェイスと実装の分離ができないタイプと見た
434:デフォルトの名無しさん
20/07/19 09:32:58.15 PIkW4oBq.net
>>423
>>426
435:デフォルトの名無しさん
20/07/19 09:37:55.76 PIkW4oBq.net
>>425
フロントエンド特化人材は高えんだよ
私、フロントエンドなんてぜんぜんできませんよ～
って具合の人材を
ふ～ん、なら少し安めのお値段で雇ってもいいよね？
大丈夫、大丈夫、こっちでうまいことレール敷くんで、安心して手だけ動かしてください
ってな具合で格安で調達すんの
できない奴でも、できるようにすんの
436:デフォルトの名無しさん
20/07/19 09:38:44.30 W3hSYpRn.net
>>426
お前フレームワークもなしに独自でSPA作るの？ｗ
URLﾘﾝｸ(codezine.jp)
ASP.NET Core 2.0でのSPAサポート
ASP.NET CoreではView層にSPAを使用するための機能が用意されています。
クライアントサイドとサーバサイドでそれぞれJavaScript、
C#が得意なメンバーのいるチームや、既にASP.NET Coreを使っていて
UIやUXを改善したいといったユースケースに適用できるかと思います。
また、SPAにおける問題点のいくつかを解消するサーバサイドレンダリングも
サポートしています。サーバサイドレンダリングについては後ほど説明します。
ASP.NET Core 2.0からは、Angular（バージョン4）、React、Reduxといった
SPAフレームワークがプロジェクトテンプレートとして新しく追加になりました。
これらのプロジェクトテンプレートを使用すると、SPAフレームワークと
ASP.NET Core MVCを連携したアプリケーションを素早く開始することができます。
437:デフォルトの名無しさん
20/07/19 09:39:23.07 W3hSYpRn.net
>>429
> フロントエンド特化人材は高えんだよ
ならフロントエンドに特化してない人を使えば？
バカなのかなこいつ
438:デフォルトの名無しさん
20/07/19 09:42:08.97 W3hSYpRn.net
なんかC#を使ってWindows Formsとかでデスクトップアプリを作れば
それがそのままSPAになるって思ってそうなんだよなｗ
URLどうするんのよって感じだ
439:デフォルトの名無しさん
20/07/19 09:45:34.17 W3hSYpRn.net
URLじゃ話通じないですかね？ｗ
SPAはデスクトップアプリとは違ってURLがあって
ブラウザの進むや戻るがつかえるんですよ
440:デフォルトの名無しさん
20/07/19 09:47:19.12 PIkW4oBq.net
>>430
意味不明な切り返しすんな
SPAでやると決まったらフレームワーク使うに決まってんだろ
お前が得意げに挙げた.NETの従来のSPAテンプレートは各種JSフレームワークのテンプレートを生成するだけだ
おまけ程度にC#のAPI開発テンプレートも生成してくれるがJSフレームワークを隠蔽するようなものじゃない
だからそれらを使ってもフロントエンド特化人材を雇わないと開発なんてできねえぞ
441:デフォルトの名無しさん
20/07/19 09:49:53.45 PIkW4oBq.net
>>431
オメーがバカ
特化した人材は高い
特化してない人材ではJSフレームワーク使った開発は生産性が低い
安いには安いなりの理由があるんだよ
だがBlazorならそんな安い連中でもC#とVSを使って簡単に開発できるようになる
442:デフォルトの名無しさん
20/07/19 09:50:41.48 PIkW4oBq.net
>>432
誰もそんな話はしてねー
そんな理解になるってお前の頭どういう構造してんだ
443:デフォルトの名無しさん
20/07/19 09:51:14.00 W3hSYpRn.net
> フロントエンド特化人材を雇わないと開発なんてできねえぞ
普通にフロントエンド開発者を使えばいいだけでは？ｗ
いないんですか？
444:デフォルトの名無しさん
20/07/19 09:52:08.96 PIkW4oBq.net
>>437
高えつってんだろ
鳥頭か
445:デフォルトの名無しさん
20/07/19 10:52:37.38 5Si5cYu0.net
そろそろwasmの話は別スレでやってくれないか？
446:デフォルトの名無しさん
20/07/19 10:58:54.20 x6eBp0n6.net
実際フロントエンドまともにできないゴミエンジニアばかりだからな
以前某エンジニアリクルート系の検索システムでフロントエンドエンジニアを検索したら全エンジニアの0.5％しかいなかった
その0.5％も自称だからガチで少ない
447:デフォルトの名無しさん
20/07/19 11:04:27 jXwWFSFG.net
>>440
Blazorはゲームチェンジャーになりうる
なんたって雑魚カスC#erでも超お手軽にSPAを開発できてしまうんだから
JS系のエンジニアの市場価値は相対的に下がるだろうね
448:デフォルトの名無しさん
20/07/19 11:18:11.07 AjlQmunT.net
Blazor-wasmまとめ
重い>>385
遅い>>380
有名クラウドサービス採用実績ゼロ
（React/Angular採用多数は言わずもがな）
C#以外覚えられなくなった年寄りを再利用するための介護フレームワーク。
449:デフォルトの名無しさん
20/07/19 11:20:10.35 m5eV0pvm.net
よっぽど高度なことするわけじゃない限り、C#書けるならReactとか2週間もあれば書けると思う
450:デフォルトの名無しさん
20/07/19 11:34:57.86 x6eBp0n6.net
>>441
バックエンドゴミエンジニアが何を使ったってゴミのようなフロントしか作れないぞ
絶望的に才能がない
目ん玉はただの飾り
こいつら（＝おまえら）に良い筆を持たせても無意味
451:デフォルトの名無しさん
20/07/19 12:02:35.96 Xo5fmFzm.net
いい加減専用スレ立ててそっちでやれよ
452:デフォルトの名無しさん
20/07/19 12:11:33.06 kmbJyWa5.net
数年後にwasmだらけになって涙目になるJSキッズが目に浮かぶ
453:デフォルトの名無しさん
20/07/19 12:14:17.72 kmbJyWa5.net
>>443
2週間�人数の教育工数が無駄
454:デフォルトの名無しさん
20/07/19 12:16:36.81 kmbJyWa5.net
>>442
重さは、遅さは現状でも十分実用に堪えうる
というか既存のSPAも体感はほとんど変わらんレベル
ゴリッゴリに最適化された既存フレームワークと比較してだから、最適化の余地があるwasmのほうが将来的には優位
採用実績はまだ正式発表されたばかりだから、比較しても意味がないことは小学生でもわかるはずだが君はどうだ？
455:デフォルトの名無しさん
20/07/19 12:17:49.08 PEwdaGfT.net
そこで振り落とされるような奴は今のJSフロントエンドすら無理。
456:デフォルトの名無しさん
20/07/19 12:20:18.80 BU8dfNcw.net
blazor厨もそれに付き合うやつも
よそでやれよ
そんなんだからいつまでたっても
そんなんなんだぞ
457:デフォルトの名無しさん
20/07/19 12:28:01.28 ZFRvNo6R.net
次スレはvs Blazorも入れたほうがいいな
458:デフォルトの名無しさん
20/07/19 12:46:08.93 YlpileWs.net
なんでこんな迷惑なBlazor厨に合わせてスレタイ変える必要があるのか
Blazor厨も相手してる連中もどっか行ってよ、ウザイ
459:デフォルトの名無しさん
20/07/19 12:46:49.46 n0f5aqSv.net
>>442
ついこないだRTMになったばかりのものを実績で批判しちゃうおばかさん
460:デフォルトの名無しさん
20/07/19 13:08:12.92 PQF4JxAh.net
それだけBlazorを恐れてるんだろうな
まあ自分の市場価値が下がるわけだから恐れて当然なんだけど
461:デフォルトの名無しさん
20/07/19 13:27:13.14 Xo5fmFzm.net
単純にスレチな話題を延々と展開するヤツが煩わしいだけ
どの道Microsoft系とは層は被らんよ
462:デフォルトの名無しさん
20/07/19 13:32:43.99 ktD9w8qF.net
>>382
大規模サイトのserver sideはJavaやC#が多かった。
社員しか使わないしょぼい業務系web appのことだけ考えていてはいけない。
あと大規模になるとtype safetyが必須になる
type safeでなければ開発生産性ががた落ちだ
速度も大事だがビジネスとしてみると開発生産性、コストもとても大事なわけ
463:デフォルトの名無しさん
20/07/19 13:54:52.10 Nf0PDjLy.net
GAFAでは使ってないし大手SNSでも使ってないけどな
464:デフォルトの名無しさん
20/07/19 14:00:36.02 DFSJX5gq.net
>>455
ほんそれ
465:デフォルトの名無しさん
20/07/19 14:20:55.19 ktD9w8qF.net
>>384
最小限のファイルだけbrowserに転送されるし
cacheされるから2回目以降は読み込みもはやい
ほとんどの人は5秒未満で初回読み込み終わるんでは
2回目以降速いのにそんなにガタガタ騒ぐ理由がわからない
いまどきトップページ読んだだけで数MB消費のサイトたくさんあるだろ
mobileでYouTube見てる人とかたくさんいる時代に
初回だけ数MBの読み込みって問題になるとは思えない
466:デフォルトの名無しさん
20/07/19 14:25:37.40 ktD9w8qF.net
>>385 >>387
初回はデータ読み込み多いのはAngularとかのSPAも同じだから
このスレに来ないほうがいいと思うぞ
いつまでも古い開発に固執していればいい
そもそもwebでC++とか普通使わないだろ、開発生産性が低い
client sideにロジックが増えるという事は
それだけユーザーは快適に使えるようになるってことだ。
メリットとデメリットのトレードオフ
467:デフォルトの名無しさん
20/07/19 14:29:43.28 ktD9w8qF.net
>>455
TypeScriptの開発がMicrosoftなのも知らない人か
MSアンチやアップル信者の人ってこういう知識ない人が多い感じ
468:デフォルトの名無しさん
20/07/19 15:10:43.98 x6eBp0n6.net
もうここはBlazorスレだな
Reactとか微塵にも話題に出ない
469:デフォルトの名無しさん
20/07/19 15:18:33.36 Xo5fmFzm.net
>>461
ああ、知ってるが導入するコストと比べて型があるって事にメリットがそれほど感じられなかったから導入を見合わせたよ
470:デフォルトの名無しさん
20/07/19 15:23:00.55 m5eV0pvm.net
絶対ts入れた方がいいぞ
471:デフォルトの名無しさん
20/07/19 15:27:00.79 n0f5aqSv.net
>>457
どこの世界の話だろうか
472:デフォルトの名無しさん
20/07/19 15:35:58.18 3+L828Di.net
仕事で扱ってるドメインがショボいと型安全性のありがたみはわからねえだろうな
473:デフォルトの名無しさん
20/07/19 15:41:47.27 RfQaIH9f.net
Blazorの話は過疎ってるxamarinスレでやってくれないか
474:デフォルトの名無しさん
20/07/19 16:10:02.58 n0f5aqSv.net
>>467
スレチ
475:デフォルトの名無しさん
20/07/19 16:59:27.91 ktD9w8qF.net
>>457
大規模サイトのback endはJavaとC#だらけなの知らないのか
Twitterは過去にRuby遅すぎて捨ててるし
476:デフォルトの名無しさん
20/07/19 17:05:03.82 xggXZiaY.net
nodeは立ち上がりが軽くて速くてスケール時に使い捨てしやすいからだろう。
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
URLﾘﾝｸ(levelup.gitconnected.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
.NET遅っそｗｗｗ重っもｗｗｗｗ
Java遅っそｗｗｗ重っもｗｗｗｗ
477:デフォルトの名無しさん
20/07/19 17:36:47.16 lVLELK+9.net
.NET優秀やん
478:デフォルトの名無しさん
20/07/19 17:48:38.32 +/vqE4Sh.net
Javaや.NETは基本サーバーは決められた台数立てっぱなしが当たり前の時代に設計されたからな。
最近のコンテナ単位・ラムダ単位で負荷に合わせてスケールアウト・スケールインするアーキテクチャは想定外だったんだろう。
479:デフォルトの名無しさん
20/07/19 19:13:15.19 x6eBp0n6.net
もうjsでいいじゃん
使えないバックエンドゴミクズエンジニアがヒーヒー言ってるだけだろ
480:デフォルトの名無しさん
20/07/19 19:25:21.82 c7cY5EYc.net
Why I Converted from Vue to React
URLﾘﾝｸ(dev.to)
> The purpose of this post was not to say that Vue is bad
ワロタ
481:デフォルトの名無しさん
20/07/19 21:20:08.98 ktD9w8qF.net
>>377 >>470
これ記事かいたやつもそれ張り付けてるおまえもアホすぎ
.net2とかいう言語はない。
.netが言語だと思ってる時点で相当レベル低い
あとcold startだけのbenchなんてほとんど意味ない。
しかもcloud環境で計測してるというバカっぷり
そんなのその時のserver混雑状態で変わるってのｗｗ
482:デフォルトの名無しさん
20/07/19 21:51:47.75 xggXZiaY.net
hot startなんだから対象言語の実行に必要なVM・環境のロード時間含まれるの当たり前じゃんｗ
lambdaなんだからクライアントから測るの当たり前じゃんｗｗ
本番でユーザーに遅い言われたときサーバで測ったら速いです言うの？ｗｗｗ
バカ過ぎワロタｗｗｗｗおとなしくサーバサイドだけやっとけや老害ｗｗｗｗｗ
483:デフォルトの名無しさん
20/07/19 21:52:18.36 xggXZiaY.net
*cold
484:デフォルトの名無しさん
20/07/19 22:25:34.23 aWdyr5NP.net
世界最速は、このサイト。Ruby on Rails 製
URLﾘﾝｸ(dev.to)
Rails + React + Bootstrap + (Node.js + Webpack) の組み合わせには勝てない。
このエコシステムを超えるのは、無理
Rails: webpack(er)に乗り換える25の理由（翻訳）
URLﾘﾝｸ(techracho.bpsinc.jp)
485:デフォルトの名無しさん
20/07/19 22:34:28.77 KAosLxZz.net
ｶﾞｲｼﾞ大集合ｗｗｗｗｗ
486:デフォルトの名無しさん
20/07/19 23:23:56.46 PIkW4oBq.net
Rubyって遅い言語代表格じゃん
487:デフォルトの名無しさん
20/07/20 00:48:26.56 PYo76fqp.net
>>470
なんでgoがこんなに遅いかね
488:デフォルトの名無しさん
20/07/20 05:20:10.55 AOg6xuBm.net
>>476
ほんとバカだな
ベンチマークなんて負荷なしの状態でかけないと正確な値がわからない。
プログラミングやらないやつでもそんなこと知ってると思うわ
多くのユーザーが使ってるサーバーで言語ごとのベンチマークとるとか馬鹿すぎ
それを何度も張ってるおまえも同レベル
もし言語ごとにやるならオンプレミスでやらないといけない
その環境をつくれないバカだから混雑してるクラウドでやるとする
Front endのスクリプトしかできない奴はやっぱりレベル低い
489:デフォルトの名無しさん
20/07/20 06:01:17.63 uvZgkaZD.net
>>482
lambdaがどういう運用されるか知らないの？ｗ
やはり老害は立てっぱなしの旧来アーキテクチャしか理解できないようだなｗｗ
言語と同じで信者もスケール出来ない産廃ｗｗｗ
490:デフォルトの名無しさん
20/07/20 06:44:08.94 f45H4Kz0.net
Blazor信者の声でかいからBlazor調べてみたけどHTML構文のきもさとか実行の遅さとかファイルサイズのでかさがやばいな
これむしろBlazorアンチだろ
信者だとしたらずっとBlazor触ってて欲しいな。デメリットも享受出来ないで持ち上げる人は大海を知らないでほしい
491:デフォルトの名無しさん
20/07/20 06:58:19.08 AOg6xuBm.net
>>483
C#できない低能のおまえは何の言語使えるつもりになってるの？
で、おまえがベンチマークだとおもってるそれは
何を計測してると思ってるの？
まともなベンチマークですらないのに言語の速さと勘違いしてるし
>>481
それまともなベンチマークじゃないから無視でいい
492:デフォルトの名無しさん
20/07/20 07:00:16.28 eYf0BG4n.net
C#ってJavaScriptよりも簡単やろ？
JavaScript使えるなら誰でも使えるで
だからC#の給料は安い
493:デフォルトの名無しさん
20/07/20 07:06:07.22 AOg6xuBm.net
>>484
htmlじゃなくてRazor syntaxな
ReactのJSXより綺麗だろ
ASP.net系やってるひとはわかるsyntax
AssemblyファイルをダウンロードしないBlazor Serverっていうのもある
その辺は要件によって使い分けること
性能もC#だから速い。遅いと言ってる人はコードの書き方が悪い
494:デフォルトの名無しさん
20/07/20 07:12:17.48 AOg6xuBm.net
>>486
JSしか使えない人はオブジェクト指向理解できてなくて
大規模なプログラムや効率的なコード書けない人ばっかり
能力が違いすぎる
JavaやC#使える人はスクリプト言語はどれでも理解できる
逆は無理
スクリプト野郎はType(型)がなんなのかすらわかってない人が大半
このlogのすこしまえにもTSのtype safetyのメリットがわからなかったと
かいてる>>463がそういう人が典型的
495:デフォルトの名無しさん
20/07/20 07:33:47.37 nNe9l9zE.net
とか言ってるヤツに限ってぐちゃぐちゃなクラス設計してそう
496:デフォルトの名無しさん
20/07/20 07:35:20.55 eYf0BG4n.net
>>488
え？JavaScriptでクラスが普通に使われてることを知らないの？
そんな人がJavaScriptはーって言った所で説得力無いよ
497:デフォルトの名無しさん
20/07/20 07:48:26.03 nNe9l9zE.net
Reactの場合昔はクラス使ってたけど最近はクラス使わない方向にシフトしてきてるけどね
「JavaやC#使える人は～」とかこの二つを同列に見てるヤツは全然信用に値しない
この二つの言語は外見が似てるだけで設計ポリシーが全然違う
498:デフォルトの名無しさん
20/07/20 08:11:34.46 GbixlCCw.net
Javaしか知らない新卒に、JSとSPA FWで作れって命令したら、泣きそうになって、開発環境構築で詰まってしまった
けどBlazorでやれって命令したら、あ、これならなんとか、Javaに似てるんでC#なんとなくわかります、VSってすごい簡単ですね、Razorマークアップシンプルで直感的でわかりやすいです♪って目に光が戻ってきた
Blazorが道に迷った若者を救ったのだ
499:デフォルトの名無しさん
20/07/20 08:15:44.07 nNe9l9zE.net
＞Javaしか知らない新卒に、JSとSPA FWで作れって命令したら、泣きそうになって、開発環境構築で詰まってしまった
指示側が無能な典型やろそれ
500:デフォルトの名無しさん
20/07/20 08:21:27.85 f45H4Kz0.net
>>487
MSILになるからどっちみち書き方関係なく遅いってよ
現実から目を背
501:けるなw
502:デフォルトの名無しさん
20/07/20 08:40:16.63 0IQp/a0j.net
もうそろそろJava Appletに回帰しようよ
503:デフォルトの名無しさん
20/07/20 08:52:13.46 ud2z2M50.net
Java AppletとSilverlightはなんで死んでしまったんだろうな
最近のSPAの流行を見るに需要はあったようにも思う
やはり事前のプラグインインストールが受け入れられなかったかね
504:デフォルトの名無しさん
20/07/20 08:56:55.30 sx2uO44l.net
>>496
オープンソースじゃない
505:デフォルトの名無しさん
20/07/20 09:00:44.43 ERnHN44b.net
今までJava、Flashとセキュリティホールの温床として排除されてきたけど何れwasmもそうならんとも限らんのよな
506:デフォルトの名無しさん
20/07/20 09:01:20.39 ERnHN44b.net
Javaっつーかappletね
507:デフォルトの名無しさん
20/07/20 09:22:37.04 eYf0BG4n.net
>>498
JavaScriptと他の言語との決定的な違いは
JavaScriptはブラウザの外にアクセスできない言語としてできたということ
他の言語がファイルの読み書きやネットワーク通信が
出来るのに比べてJavaScriptはそれらが全くできない
常識ではファイルアクセスやネットワーク通信などの機能は
言語としてできて当たり前のことが、JavaScriptはできない
その貧弱さがセキュリティのもとでは逆にメリットに変わった
そこからセキュリティを考慮しつつ、それらの制限に
限定的に対応できるようにしてきた。
wasmも最終的にはJavaScriptでできることしか
外部リソースへのアクセスができないからセキュリティ的には問題ない
ただ外部リソースヘアクセスする場合、wasmの速度が速いなどの副次的な
メリットはなくなる。当初の目的通り既存のアプリの移植を容易になるだけ
508:デフォルトの名無しさん
20/07/20 09:30:40.37 Whe6j3l/.net
Silverlightはまあまあいい出来だったんだがな
Java applet、ActiveXのせいでPluginの印象が下落してSLも風評被害を受けた
509:デフォルトの名無しさん
20/07/20 09:31:32.50 AOg6xuBm.net
>>492
これ作り話くさいな
混沌としたFront endなのだから何を使ってどういう構成
にするのか具体的に指示しないと伝わるわけがない。
雑な指示したおまえが無能
本当に泣きそうになったとしたら言語うんぬんよりも
会社や上司に絶望してたのだろう
>>491
C#は生産性優先でJavaほど頑固なオブジェクト指向でないことは理解してる
510:デフォルトの名無しさん
20/07/20 09:34:46 feiQG4ht.net
>>502
混沌としてるのはフロントエンドじゃなくJS ecosystemな
Blazorにすれば混沌とはおさらば
511:デフォルトの名無しさん
20/07/20 09:36:11.74 AOg6xuBm.net
>>496
Silverlight
pluginなことと
web standardじゃなかったこと
512:デフォルトの名無しさん
20/07/20 09:36:38.68 feiQG4ht.net
かつて猛威を奮ったFormsほどではないが
Blazorならバカでもチョンでも簡単にSPAを作れてしまう
ジャバスク職人はもういらないのだよ
513:デフォルトの名無しさん
20/07/20 12:02:07.86 H88IF2ph.net
どっちでもええわ。くだらね。
514:デフォルトの名無しさん
20/07/20 19:43:34.23 myn6SOC5.net
知識ゼロからASP.NET+Blazorの開発環境を立ち上げるのとNode.js+Reactの環境を立ち上げるの
どっちが簡単なんだろうね。
515:デフォルトの名無しさん
20/07/20 19:45:36.00 VgLz71J8.net
そりゃBlazorだろ
マイクロソフトはそのあたりは抜け目がない
516:デフォルトの名無しさん
20/07/20 19:50:06.26 NVl0pT7f.net
jQueryおじさんがマシに見えるな
517:デフォルトの名無しさん
20/07/20 19:50:21.00 huUvJ5to.net
$ sudo apt install -y nodejs
$ npm install -g create-react-app
blazorもこのレベルで行けるん？
518:デフォルトの名無しさん
20/07/20 19:54:20.34 AOg6xuBm.net
>>507
勝負にならない。
Blazorならコマンド2個打つくらいで動く
トータル3分くらいで終わる
ここのをやってみな
URLﾘﾝｸ(dotnet.microsoft.com)
SDKインストールして、Power shellひらく
dotnet new blazorserver -o BlazorApp --no-https
cd BlazorApp
これだけでprojectが作成される。1秒で終わる。
dotnet run
でweb serverが立ち上がる
519:デフォルトの名無しさん
20/07/20 19:56:32.75 AOg6xuBm.net
>>510
create-react-appは
出来が悪くすごい待たされるが
Blazorならproject は1秒で完成する
Blazor使ったことない人は>>511やってみるべき
520:デフォルトの名無しさん
20/07/20 19:57:20.85 NVl0pT7f.net
それVirtualstudioのインストールを完全に無視してんじゃん
521:デフォルトの名無しさん
20/07/20 20:01:30.36 VgLz71J8.net
VisualStudioはあったほうが快適だけど必須じゃ無いよ
VSCodeでもVimでもなんでも使えばいい
522:デフォルトの名無しさん
20/07/20 20:05:06.33 P4NHzaw9.net
jQueryおじさんの次はBlazorおじさんか
523:デフォルトの名無しさん
20/07/20 20:09:37.67 0dEIDg/a.net
>>511
それは単に自動生成してるだけやろ？
全てのリンクをスムーススクロールにするコード書いてみ
524:デフォルトの名無しさん
20/07/20 20:18:35.66 AOg6xuBm.net
>>513
webの開発者ならVS Codeくらいいれてるだろふつう
notepadだとさすがにまずいが通常のtext editorでも問題ない
C#やるならVisual Studioいれたほうがいいけどな
525:デフォルトの名無しさん
20/07/20 20:21:47.90 AOg6xuBm.net
>>516
プロジェクト作成なんて自動生成でつくられるべきだろ
create-react-appは時間かかりすぎでダサい
526:デフォルトの名無しさん
20/07/20 20:25:36.55 0dEIDg/a.net
>>518
自動生成で作れるのは
価値がないコートだけだよ
誰でも同じものが手に入るんだから
527:デフォルトの名無しさん
20/07/20 20:26:17.04 nNe9l9zE.net
自演じゃないならBlazorの話してるヤツ３人以上居そうだし専用スレ立てても十分やっていけるだろ
いい加減専用スレ立てろよ
528:デフォルトの名無しさん
20/07/20 20:51:47.51 VgLz71J8.net
括りとしてはモダンSPAフレームワークなんでここでいいだろ
529:デフォルトの名無しさん
20/07/20 21:00:07.53 myn6SOC5.net
>>511
なるほど面白い。ただ、このチュートリアルはSPAじゃないんだな。
create-react-appというよりexpress-generatorっぽい。
530:デフォルトの名無しさん
20/07/20 21:03:22.07 CRMcSYFf.net
コマンド数回打つだけでこんなに簡単にプロ品質のものが
作れるのはBlazorしかないよ
素晴らしいアイデアだと思う
531:デフォルトの名無しさん
20/07/20 21:08:55.51 nNe9l9zE.net
>>521
フロントエンドJavaScriptフレームワーク総合
ｽﾚﾘﾝｸ(tech板)
532:デフォルトの名無しさん
20/07/20 21:09:23.40 GbixlCCw.net
他の言語でもwasmベースのフレームワークが増えるといいね
JavaScriptを駆逐してやりたい
533:デフォルトの名無しさん
20/07/20 21:18:56.24 ObeGkch+.net
まあ無理だね。
好むと好まざるとに関わらず残り続けるよ。
最低シナリオでもグルー言語として残り続ける。
そのころにはC#は滅んでるだろうがねｗ
TypeScriptと比べても設計古すぎなんだよこのクソ言語ｗ
WASMもプライマリ言語はRustになっちゃってるし。
クソ言語はその他有象無象の一つとしてしか立場はない。
ま、C#バカはJSすら覚えられずに恨み節なんだからRustなんて覚えられるわけないわなｗ
老害産業廃棄物としてゴミ箱行きｗｗｗ
534:デフォルトの名無しさん
20/07/20 21:19:24.12 CRMcSYFf.net
ははｗそれは無理やろ
ただでさえjQueryのシェアは年間1%以上（今年はすでに1.8%）増えてるなか
一番頑張ってるVue.jsででさえ年間0.1％しかシェアが増えてないんだから
URLﾘﾝｸ(w3techs.com)
僅かなパイを奪い合ってる状態だぞ
535:デフォルトの名無しさん
20/07/20 21:25:14.51 CRMcSYFf.net
俺の予想ではwasmは最終的に
JavaScriptを駆逐するのではなく
JavaScriptを強化するために使われるだろうな
ウェブサーバーにキャッシュ機能の一つとして組み込まれ
開発者は普通にJavaScriptを置くだけで
自動的にコンパイルされて配信される
サーバーの設定をちょいといじるだけで
今までのJavaScriptの開発を変えずに
wasmの恩恵が受けられる
536:デフォルトの名無しさん
20/07/20 21:27:28.81 uvZgkaZD.net
>>527
酷ぇ調査だなこれ。カテゴリ分けずにJSライブラリでいっしょくたか。
一緒に使うライブラリでシェア割っちゃってるし。
例えばjQueryとBootstrapが競合だなんて業界にいたら誰も思わんだろ。
w3techはこれ作ったやつ即刻クビにしたほうがいい。
537:デフォルトの名無しさん
20/07/20 21:30:35.73 td0HkrQz.net
C#は設計古いところはどんどん改善して変化し続けてるけどな
次バージョンじゃMainいらなくなるしValueObjectを言語レベルでサポートする
538:デフォルトの名無しさん
20/07/20 21:34:58.90 CRMcSYFf.net
>>529
なんか問題があるの？
合計してみればわかるように100%を超えている
競合の有無は関係なく、それぞれのJavaScriptライブラリが
どれだけ使われてるかって数値だよ
539:デフォルトの名無しさん
20/07/20 22:08:06.12 0IQp/a0j.net
Blazorスレ立てちゃえよ
540:デフォルトの名無しさん
20/07/20 22:09:43.57 KSBahjfS.net
UI関連フレームワーク連敗記録は何処まで伸びるかね
541:デフォルトの名無しさん
20/07/20 22:18:25.68 myn6SOC5.net
MSなら<canvas>にWPFをレンダリングするくらいできそうなもんだがなぁ。
やったらやったで反発がすごそうだが。
542:デフォルトの名無しさん
20/07/20 22:21:04.66 GbixlCCw.net
老害JSerが猛反発しそうだなｗ
543:デフォルトの名無しさん
20/07/20 22:34:15.86 AHuh7I72.net
おれJavaScript書いて10年だけど、型のメリットなんて全く理解できないし、わざわざC#みたいなダメ言語触ってるやつの気がしれん
544:デフォルトの名無しさん
20/07/20 22:55:19.66 Bh1lIXcR.net
オモチャ作って遊ぶだけならそれでもいいんだろうけどねえ
ビジネスでは型なしはちと厳しい
545:デフォルトの名無しさん
20/07/20 23:37:20.53 td0HkrQz.net
立てたぞ
【本命】Blazor スレ1【真打】
ｽﾚﾘﾝｸ(tech板)
546:デフォルトの名無しさん
20/07/20 23:46:47.95 AOg6xuBm.net
>>522
いや、>>511のMSのsampleはちゃんとSPAになってる
Blazor WebAssemblyだからぜんぶBrowser上で動いてる
左側のメニューでクリックするとカウンターが増えていくけど
それがSPAになってる
page全体がreloadされずにcounterだけ増えるでしょ
URLﾘﾝｸ(dotnet.microsoft.com)
547:デフォルトの名無しさん
20/07/20 23:52:02.28 HW7ZwNx6.net
URLﾘﾝｸ(redmonk.com)
JavaScript 1位
C# 5位
548:デフォルトの名無しさん
20/07/20 23:57:06.64 AOg6xuBm.net
>>528
jQueryおじさんまだいたか
速度と生産性を追求したらtype safeな言語にいきつく。
wasm時代はJS縛りがなくなるわけだから
大手は生産性の高い言語で開発を始めるようになる。
549:デフォルトの名無しさん
20/07/21 00:02:33.34 SJ0RWW6w.net
>>532
そんなに分裂させても過疎るとおもうけどな
フロントエンドJavaScriptフレームワーク総合
も過疎ってる。
Blazorの話題でるまではこのスレも超過疎だったし
次からスレタイにvs Blazorも追加しちゃえばいいよ
550:デフォルトの名無しさん
20/07/21 00:04:18.19 erxA5kbn.net
GitHub の人気プログラミング言語では、C#の人気は、うなぎ登り。
なんとあの最強言語、Rubyにも勝っている！
PHPには、負けてるけど…
URLﾘﾝｸ(octoverse.github.com)
URLﾘﾝｸ(leerob.io)
551:デフォルトの名無しさん
20/07/21 00:07:56.12 SJ0RWW6w.net
>>536
Visual StudioでWindows appをつくってみろ
C#でな
それやるとtype safeのありがたみがわかる
開発スピードが別次元になる
そしてスクリプトの無力さに気付くだろう
型のメリットがわからないようなレベルのやつが
C#ダメ言語とかいったら笑われるぞｗ
スクリプトだとPerl, PHP, JSが世界3大クソ言語
552:デフォルトの名無しさん
20/07/21 00:11:09.12 SJ0RWW6w.net
>>540
それはJSがbrowserで動く唯一の言語だったからだ。
仕方なく使っていただけで人気なわけではない。
wasmの時代は好きな言語つかえるから
もうJSは終わりに向かってる
553:デフォルトの名無しさん
20/07/21 00:15:37.07 erxA5kbn.net
漏れは、UIPathで、RPAのプログラムを書いたけど、
操作するアプリから、取ってくる値も、
書き込む値も、両方、文字列なのに、いちいち変換させられるのが、大変で、困った！
数字を取ってきたときも、計算するために、文字列から、数値に変換させられるのは、分かるんだけど、操作してるアプリに、書き込むときは、文字列以外、あり得ないのだから、いちいち変換させられるのは、意味が分からなかった！