実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.3
https://mevius.5ch.net/test/read.cgi/tech/1560333895/
★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
Vue vs React vs Angular Part.4
■ このスレッドは過去ログ倉庫に格納されています
2020/06/11(木) 19:01:45.26ID:uGsh0NQC
281デフォルトの名無しさん
2020/07/17(金) 14:45:14.98ID:Mcc/Kfhl >>273 >>280
従来型のASP.netはModとかFastCGI対応していた。
Linuxでうごくこういうやつがあった
https://www.mono-project.com/docs/web/aspnet/
Monoは互換性がいまいちなので個人的にお勧めしない
ASP.net CoreをKestrel単体またはKestrel+(Nginx or Apache or IIS)
で動かすのが今のMicrosoft推奨のやりかた。
高速に動くなら内部の仕組みはどうでもいい話だろう？
あとは重要なところでLinuxで動いてライセンス無料になってるんだし
Modがあるかなんてどうでもいいよ。
そもそもApacheは高速なWeb serverじゃないの知ってるの？
あえてApache選ぶ理由がないよ。
大規模サイトはNginxが多い
従来型のASP.netはModとかFastCGI対応していた。
Linuxでうごくこういうやつがあった
https://www.mono-project.com/docs/web/aspnet/
Monoは互換性がいまいちなので個人的にお勧めしない
ASP.net CoreをKestrel単体またはKestrel+(Nginx or Apache or IIS)
で動かすのが今のMicrosoft推奨のやりかた。
高速に動くなら内部の仕組みはどうでもいい話だろう？
あとは重要なところでLinuxで動いてライセンス無料になってるんだし
Modがあるかなんてどうでもいいよ。
そもそもApacheは高速なWeb serverじゃないの知ってるの？
あえてApache選ぶ理由がないよ。
大規模サイトはNginxが多い
282デフォルトの名無しさん
2020/07/17(金) 14:48:05.03ID:Mcc/Kfhl >>280
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ
.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ
.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから
283デフォルトの名無しさん
2020/07/17(金) 14:49:01.58ID:bZMoLlJz Apacheに乗せるなんて無駄なことしたくない
Nginx RP + Inproc Httpがスマートで最高
Nginx RP + Inproc Httpがスマートで最高
284デフォルトの名無しさん
2020/07/17(金) 14:55:32.14ID:rScYk2f8 静的コンテンツのレスポンス高速化のためだけにリバースプロキシ（Apache, nginx）置くわけじゃないから
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない
285デフォルトの名無しさん
2020/07/17(金) 15:02:52.55ID:bZMoLlJz 最近はApacheを知らない若者も居るようだ
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい
286デフォルトの名無しさん
2020/07/17(金) 15:46:01.13ID:Q8AVDrqq287デフォルトの名無しさん
2020/07/17(金) 19:01:29.04ID:gHhKsxDc 最近JIT対応したPHP8のalpha版が結構いいスコア出してるそうだがな
288デフォルトの名無しさん
2020/07/17(金) 21:28:04.44ID:LPqky/1r289デフォルトの名無しさん
2020/07/17(金) 21:55:04.26ID:XQc3SgYX 1系ってAngularJS表記なんだと思ってたがそうじゃないのか
290デフォルトの名無しさん
2020/07/17(金) 22:04:00.19ID:5B+Amw9H Reactってjadeと互換性あるの？
HTMLや動的テンプレファイル上に
直で書くとサーバ変数そのままJavaScriptに
埋め込んでコーディングできるから
.jsファイルの外部化は個人的にかなり抵抗感がある
HTMLや動的テンプレファイル上に
直で書くとサーバ変数そのままJavaScriptに
埋め込んでコーディングできるから
.jsファイルの外部化は個人的にかなり抵抗感がある
291デフォルトの名無しさん
2020/07/17(金) 23:32:34.52ID:pbRdpk23 フロントエンドのライブラリだというのに
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん
292デフォルトの名無しさん
2020/07/18(土) 00:18:41.79ID:lkZeEJlA293デフォルトの名無しさん
2020/07/18(土) 00:25:43.24ID:Rz8uT7Q+ phpはhtmlに直接サーバーサイド変数を埋め込めるという点で負の遺産を残しすぎた。
wordpressだのsmartyだの吐き気するわ。
wordpressだのsmartyだの吐き気するわ。
294デフォルトの名無しさん
2020/07/18(土) 01:02:58.86ID:mlew4XCO >>293
それの何が悪いの？
それの何が悪いの？
295デフォルトの名無しさん
2020/07/18(土) 01:08:32.40ID:5AaucbBP バックエンドなんてフレームワークで構成してJSONやり取りするもんだからそんなの別に気にする事じゃないだろ
296デフォルトの名無しさん
2020/07/18(土) 02:09:48.73ID:lkZeEJlA >>275
PostgreSQLか
爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも
C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？
PostgreSQLか
爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも
C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？
297デフォルトの名無しさん
2020/07/18(土) 02:21:16.88ID:N4WthBbf > React+Next.js勉強やめて
勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ
勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ
298デフォルトの名無しさん
2020/07/18(土) 02:39:54.52ID:lkZeEJlA299デフォルトの名無しさん
2020/07/18(土) 04:07:12.10ID:N4WthBbf なるほどつまり数時間やって分かんなくて嫌になってwasmならできるモン！ってことか。説明ご苦労。
そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ
そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ
300デフォルトの名無しさん
2020/07/18(土) 08:45:31.60ID:5AaucbBP WebAssemblyに夢見過ぎなヤツ多いな
そんなに速度が必要な事をやってるのかと
そんなに速度が必要な事をやってるのかと
301デフォルトの名無しさん
2020/07/18(土) 09:04:24.26ID:lkZeEJlA >>300
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる
夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。
実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる
夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。
実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う
302デフォルトの名無しさん
2020/07/18(土) 09:10:26.95ID:huqpRUrM Blazorはサンプル動かすまで超簡単
あれこれ聞く前に自分で試したほうが早いよ
dotnet sdkの最新版を落としてインストールしたら
dotnet new blazorwasm
dotnet run
これだけでBlazorが動く
頭の悪い大量の設定を書く必要はない
小学生やお猿さんでも簡単にできる
ちな↑は完全に静的なサイトを作りたいとき
サーバーサイドAPIも作りたいなら
dotnet new blazorwasm --hosted
dotnet run
これでおｋ
サーバーサイドレンダリングしたいなら
dotnet new blazorserver
dotnet run
これでおｋ
あれこれ聞く前に自分で試したほうが早いよ
dotnet sdkの最新版を落としてインストールしたら
dotnet new blazorwasm
dotnet run
これだけでBlazorが動く
頭の悪い大量の設定を書く必要はない
小学生やお猿さんでも簡単にできる
ちな↑は完全に静的なサイトを作りたいとき
サーバーサイドAPIも作りたいなら
dotnet new blazorwasm --hosted
dotnet run
これでおｋ
サーバーサイドレンダリングしたいなら
dotnet new blazorserver
dotnet run
これでおｋ
303デフォルトの名無しさん
2020/07/18(土) 09:10:56.66ID:5AaucbBP >>301
ECでボトルネックになるのは大体の場合サーバーサイドだろ
ECでボトルネックになるのは大体の場合サーバーサイドだろ
304デフォルトの名無しさん
2020/07/18(土) 09:13:11.20ID:lkZeEJlA305デフォルトの名無しさん
2020/07/18(土) 09:28:04.98ID:lkZeEJlA >>303
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど
速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど
速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？
306デフォルトの名無しさん
2020/07/18(土) 09:33:43.74ID:Zsjd19dY wasmの求人需要ってある？
307デフォルトの名無しさん
2020/07/18(土) 09:41:11.98ID:a72QTQ2S 1ミリもない
308デフォルトの名無しさん
2020/07/18(土) 09:48:13.03ID:37eL7IOf 自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ
なんで求人探すなんて面倒くさいことするんだ
309デフォルトの名無しさん
2020/07/18(土) 10:09:29.41ID:N4WthBbf310デフォルトの名無しさん
2020/07/18(土) 10:18:52.49ID:5tCG/Slu 理解できないことはないんだろうけど
拒否反応を起こす人は結構いるね
JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし
拒否反応を起こす人は結構いるね
JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし
311デフォルトの名無しさん
2020/07/18(土) 11:01:01.72ID:fwbEJCvA >>301
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？
今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる
「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？
今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる
「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？
312デフォルトの名無しさん
2020/07/18(土) 11:07:30.53ID:fwbEJCvA >>305
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。
WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。
WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い
313デフォルトの名無しさん
2020/07/18(土) 11:20:03.68ID:fwbEJCvA WebAssemblyはどんな問題（課題）を解決するのかを答えられないようじゃ
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。
WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ
つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。
WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ
つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない
314デフォルトの名無しさん
2020/07/18(土) 11:23:08.49ID:oiSxLKa2 wasmでVM動かしてる状況だとまだ劇的に速いとは言えないのでは
wasmのGC実装もこれからだし流石に時期尚早感がある
wasmのGC実装もこれからだし流石に時期尚早感がある
315デフォルトの名無しさん
2020/07/18(土) 11:28:21.15ID:5tCG/Slu JavaScriptだってネイティブ実行されてるわけじゃなくJITコンパイルしながら実行されてるでしょ
wasmのVMが大きなオーバーヘッドだとは思わないけどな
wasmのVMが大きなオーバーヘッドだとは思わないけどな
316デフォルトの名無しさん
2020/07/18(土) 11:29:28.75ID:Z+cMIoZ7 >>313
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！
317デフォルトの名無しさん
2020/07/18(土) 11:33:48.46ID:fwbEJCvA >>316
そんな人もいるんだからって言いたいの？ｗ
そんな人もいるんだからって言いたいの？ｗ
318デフォルトの名無しさん
2020/07/18(土) 11:49:48.36ID:zDePOjuW jsをwasmにコンパイル出来たら爆発的に普及しそうなんだが、いまだにまともにできないんだよな。
319デフォルトの名無しさん
2020/07/18(土) 11:54:20.16ID:Z+cMIoZ7320デフォルトの名無しさん
2020/07/18(土) 11:59:32.49ID:fwbEJCvA321デフォルトの名無しさん
2020/07/18(土) 12:07:43.56ID:OjEg02/9 jquery bootstrap Vue React angular
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！
322デフォルトの名無しさん
2020/07/18(土) 12:18:23.75ID:Z+cMIoZ7323デフォルトの名無しさん
2020/07/18(土) 12:25:07.68ID:huqpRUrM VS+C#の快適さに比べたらJSやTSなんてゲロ以下でしょ
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー
324デフォルトの名無しさん
2020/07/18(土) 12:27:17.68ID:a72QTQ2S vscode + js のウルトラ開発体験知らんのか？
325デフォルトの名無しさん
2020/07/18(土) 12:28:49.89ID:5AaucbBP >>323
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない
326デフォルトの名無しさん
2020/07/18(土) 12:29:31.05ID:huqpRUrM >>324
VSCodeは不安定すぎて話にならんわ
VSCodeは不安定すぎて話にならんわ
327デフォルトの名無しさん
2020/07/18(土) 12:31:33.52ID:huqpRUrM328デフォルトの名無しさん
2020/07/18(土) 12:33:55.33ID:cNrPu/ON VSおじさんｗ
Silverlightはどうなりましたかｗ
Silverlightはどうなりましたかｗ
329デフォルトの名無しさん
2020/07/18(土) 12:40:21.88ID:fQsuqJMx wasm(たとえばC#)って画面描画どうやってやるの？
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？
wasm詳しい人教えてくれ！
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？
wasm詳しい人教えてくれ！
330デフォルトの名無しさん
2020/07/18(土) 12:50:44.89ID:cNrPu/ON まだ直接DOMいじれない。
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ
331デフォルトの名無しさん
2020/07/18(土) 12:53:18.24ID:5tCG/Slu え、DOMいじれずC#(WPF)で描画もだきないのか
結局、JavaScript使わないといけないんじゃ微妙ね
ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ
結局、JavaScript使わないといけないんじゃ微妙ね
ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ
332デフォルトの名無しさん
2020/07/18(土) 12:55:00.61ID:hYOY3gDK >>328
この返しは恥ずかしすぎる
この返しは恥ずかしすぎる
333デフォルトの名無しさん
2020/07/18(土) 12:55:34.30ID:hYOY3gDK >>329
Razorマークアップ
Razorマークアップ
334デフォルトの名無しさん
2020/07/18(土) 12:56:00.12ID:hYOY3gDK >>331
JSは要らんよ
JSは要らんよ
335デフォルトの名無しさん
2020/07/18(土) 12:56:27.32ID:cNrPu/ON でもそのwasmの外にあるjsへの指示・管理はフレームワーク側の仕事だからあなたが直接dom api叩く必要はない
336デフォルトの名無しさん
2020/07/18(土) 13:00:40.40ID:fwbEJCvA337デフォルトの名無しさん
2020/07/18(土) 13:02:21.10ID:fwbEJCvA338デフォルトの名無しさん
2020/07/18(土) 13:06:46.63ID:u6Nb4/2q ブラウザのDeveloperToolでデバッグできる？
339デフォルトの名無しさん
2020/07/18(土) 13:08:43.45ID:fwbEJCvA JavaScriptもJITとか使うから計算とかならネイティブとほぼ同じ速度で動くんだよ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ
DOMの複雑なレンダリングアルゴリズムが原因だから
それは避けようがない。
しかしもともとは画面表示なんて縦横のビットマップでしかなかったわけで
DOMのレンダリングを避けて、直接描画しましょうっていうのがWebAssembly
DirectXの思想と似てるね。WebAssemblyの目的はレガシー技術の移植だから
DOMは必要ない。なのでWebAssemblyからDOMを直接さわれるようなことはないよ
間接的に触れればOK。
画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ
DOMの複雑なレンダリングアルゴリズムが原因だから
それは避けようがない。
しかしもともとは画面表示なんて縦横のビットマップでしかなかったわけで
DOMのレンダリングを避けて、直接描画しましょうっていうのがWebAssembly
DirectXの思想と似てるね。WebAssemblyの目的はレガシー技術の移植だから
DOMは必要ない。なのでWebAssemblyからDOMを直接さわれるようなことはないよ
間接的に触れればOK。
画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ
340デフォルトの名無しさん
2020/07/18(土) 13:39:15.04ID:5tCG/Slu wasmの画面描画について答えてくれてありがとう
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね
wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね
wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ
341デフォルトの名無しさん
2020/07/18(土) 13:42:32.30ID:fwbEJCvA 外部との通信やファイルアクセスやI/OはブラウザのAPIエミュレートされる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる
342デフォルトの名無しさん
2020/07/18(土) 13:44:42.37ID:fwbEJCvA そういうI/O系はJavaScript APIを使ってエミュレートされるので
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ
343デフォルトの名無しさん
2020/07/18(土) 13:48:10.88ID:zDePOjuW wasmの画面表示って結局jsと同じDOMかWebGLじゃね？
344デフォルトの名無しさん
2020/07/18(土) 13:58:51.62ID:fwbEJCvA >>343
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）
だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）
だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される
345デフォルトの名無しさん
2020/07/18(土) 14:54:17.15ID:5tCG/Slu wasmおもしろそうだな
いっちょさわってみるか
いっちょさわってみるか
346デフォルトの名無しさん
2020/07/18(土) 14:59:20.43ID:OjEg02/9347デフォルトの名無しさん
2020/07/18(土) 15:00:47.66ID:lkZeEJlA >>302
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。
348デフォルトの名無しさん
2020/07/18(土) 15:01:01.32ID:zDePOjuW ああ、言いたかったのは描画に関しては結局jsと変わらんだろうということ。
Canvas APIやWebGL APIを呼ぶだけだしね。
Canvas APIやWebGL APIを呼ぶだけだしね。
349デフォルトの名無しさん
2020/07/18(土) 15:03:36.80ID:lkZeEJlA350デフォルトの名無しさん
2020/07/18(土) 15:08:26.33ID:lkZeEJlA >>311
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ
なぜSPでネイティブアプリがあるかっておもに性能だろう
パフォーマンス重要な用途がわからない？？
開発者でそれが思い浮かばない人っているんだね
ハイパフォーマンスということはわざわざAndroidやiOSの
アプリつくって売上の30%ぼったくられなくても
Blazorでゲーム作って稼ぐようなこともできる。
それくらい思い浮かばないかふつう。
パフォーマンスめちゃくちゃ大事
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ
なぜSPでネイティブアプリがあるかっておもに性能だろう
パフォーマンス重要な用途がわからない？？
開発者でそれが思い浮かばない人っているんだね
ハイパフォーマンスということはわざわざAndroidやiOSの
アプリつくって売上の30%ぼったくられなくても
Blazorでゲーム作って稼ぐようなこともできる。
それくらい思い浮かばないかふつう。
パフォーマンスめちゃくちゃ大事
351デフォルトの名無しさん
2020/07/18(土) 15:28:43.67ID:fwbEJCvA352デフォルトの名無しさん
2020/07/18(土) 15:35:33.35ID:lkZeEJlA >>312
Blazorだとclient, severの両方をC#でかけるから
開発生産性が高い
という当たり前の話が前提としてある
Blazorでは既存のJS libraryは使えるがJS開発はおまけ
自分で開発するのは主にC#
node.jsはbrowserがJSだからserverも同じ言語だと効率がいいっていう
理屈で作られたものだろう
しかしJS自体がうんこなのでnode.jsはserver sideもうんこ言語で
開発することになる
Blazorだとclient, severの両方をC#でかけるから
開発生産性が高い
という当たり前の話が前提としてある
Blazorでは既存のJS libraryは使えるがJS開発はおまけ
自分で開発するのは主にC#
node.jsはbrowserがJSだからserverも同じ言語だと効率がいいっていう
理屈で作られたものだろう
しかしJS自体がうんこなのでnode.jsはserver sideもうんこ言語で
開発することになる
353デフォルトの名無しさん
2020/07/18(土) 15:40:33.50ID:lkZeEJlA >>313
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる
server sideまでうんこ言語（JS)やその改善版（TS)で
開発する時代がいつまでも続くと思うか？
俺は全く思わない
好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる
server sideまでうんこ言語（JS)やその改善版（TS)で
開発する時代がいつまでも続くと思うか？
俺は全く思わない
好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ
354デフォルトの名無しさん
2020/07/18(土) 15:43:26.01ID:lkZeEJlA355デフォルトの名無しさん
2020/07/18(土) 15:47:48.54ID:lkZeEJlA >>320
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ
wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ
wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ
356デフォルトの名無しさん
2020/07/18(土) 15:52:34.71ID:lkZeEJlA357デフォルトの名無しさん
2020/07/18(土) 15:54:43.54ID:VwC7Y7IV まあなんにせよいつまでもJS、TSにしがみついてるのはエンジニアとしてリスキーだよね
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た
358デフォルトの名無しさん
2020/07/18(土) 15:54:46.28ID:lkZeEJlA359デフォルトの名無しさん
2020/07/18(土) 16:41:05.47ID:5tCG/Slu >>358
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね
ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね
ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い
360デフォルトの名無しさん
2020/07/18(土) 16:44:31.11ID:fwbEJCvA なんでクライアントとサーバーで同じ言語で作ったほうが
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？
361デフォルトの名無しさん
2020/07/18(土) 16:44:51.36ID:fwbEJCvA >>357
お前は何の言語にしがみついてるんだ？ｗ
お前は何の言語にしがみついてるんだ？ｗ
362デフォルトの名無しさん
2020/07/18(土) 16:51:43.65ID:5tCG/Slu >>360
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
おれはSQL併用するけどSQL使わない勢も実際にいるよ
ORMの自動生成クエリーだけでなんとかするっていう
逆にSQLでビジネスロジック全部やりたい勢もいるストアド大好きな人達
ソフトウェアって自由でいいな
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
おれはSQL併用するけどSQL使わない勢も実際にいるよ
ORMの自動生成クエリーだけでなんとかするっていう
逆にSQLでビジネスロジック全部やりたい勢もいるストアド大好きな人達
ソフトウェアって自由でいいな
363デフォルトの名無しさん
2020/07/18(土) 16:53:18.15ID:fwbEJCvA >>359
UIをコードで書くならDOMベースが一番適してるんだよ
HTMLかXMLかそれに近いマークアップ言語
その例外がゲームとかCADとか点や線ベースでの
インターフェースを持っているもの
具体的に言えば、点や線が目まぐるしく変わるもの
UIをコードで書くならDOMベースが一番適してるんだよ
HTMLかXMLかそれに近いマークアップ言語
その例外がゲームとかCADとか点や線ベースでの
インターフェースを持っているもの
具体的に言えば、点や線が目まぐるしく変わるもの
364デフォルトの名無しさん
2020/07/18(土) 16:56:29.69ID:fwbEJCvA365デフォルトの名無しさん
2020/07/18(土) 17:11:56.84ID:UMJ4s/bl nodeは立ち上がりが軽くて速くてスケール時に使い捨てしやすいからだろう。
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
https://levelup.gitconnected.com/aws-lambda-cold-start-language-comparisons-2019-edition-%EF%B8%8F-1946d32a0244
https://miro.medium.com/max/3000/1*9sCYX6qNP2_v4h65dAXldQ.png
https://miro.medium.com/max/2100/1*yRoptbhiLIc8pcSkhKAWmA.png
https://miro.medium.com/max/3000/1*CTR45urzK4_gz177XyyWew.png
.NET遅っそｗｗｗ重っもｗｗｗｗ
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
https://levelup.gitconnected.com/aws-lambda-cold-start-language-comparisons-2019-edition-%EF%B8%8F-1946d32a0244
https://miro.medium.com/max/3000/1*9sCYX6qNP2_v4h65dAXldQ.png
https://miro.medium.com/max/2100/1*yRoptbhiLIc8pcSkhKAWmA.png
https://miro.medium.com/max/3000/1*CTR45urzK4_gz177XyyWew.png
.NET遅っそｗｗｗ重っもｗｗｗｗ
366デフォルトの名無しさん
2020/07/18(土) 17:32:39.93ID:vLQD9afh367デフォルトの名無しさん
2020/07/18(土) 17:43:52.38ID:lkZeEJlA >>359
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ
WPFはXAMLだっけ、あれはXMLの方言みたいなやつだよね
Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ
WPFはXAMLだっけ、あれはXMLの方言みたいなやつだよね
Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう
368デフォルトの名無しさん
2020/07/18(土) 17:46:29.08ID:vfrpqE6H369デフォルトの名無しさん
2020/07/18(土) 18:54:17.02ID:162OGkYI370デフォルトの名無しさん
2020/07/18(土) 18:56:30.00ID:162OGkYI 間違えたWinUIじゃなかったUnoだ
371デフォルトの名無しさん
2020/07/18(土) 19:26:35.55ID:5AaucbBP372デフォルトの名無しさん
2020/07/18(土) 19:30:44.95ID:5AaucbBP373デフォルトの名無しさん
2020/07/18(土) 20:42:52.64ID:Rz8uT7Q+ wasmで処理速度が上がるのか知らんけどコンパイルされるわけだからネイティブコードよりも転送量増える理屈だよな。
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？
374デフォルトの名無しさん
2020/07/18(土) 21:47:01.74ID:5tCG/Slu そうですね
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる
375デフォルトの名無しさん
2020/07/18(土) 22:58:32.39ID:lkZeEJlA376デフォルトの名無しさん
2020/07/18(土) 23:16:25.72ID:lkZeEJlA >>373
速度はあがるし目的としても書かれてる
https://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なんてあるわけないだろうｗ
速度はあがるし目的としても書かれてる
https://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なんてあるわけないだろうｗ
377デフォルトの名無しさん
2020/07/19(日) 00:48:48.05ID:xggXZiaY https://qiita.com/ShuntaShirai/items/3ac92412720789576f22
> WebAssembly側から直接Domを操作することは出来ない。そのため、WebAssemblyにコンパイル出来る各言語にJavaScriptのAPIを呼び出すWasm用のライブラリが開発されている。
https://github.com/WebAssembly/proposals/issues/16
> 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
> WebAssembly側から直接Domを操作することは出来ない。そのため、WebAssemblyにコンパイル出来る各言語にJavaScriptのAPIを呼び出すWasm用のライブラリが開発されている。
https://github.com/WebAssembly/proposals/issues/16
> 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
378デフォルトの名無しさん
2020/07/19(日) 02:34:09.44ID:ktD9w8qF379デフォルトの名無しさん
2020/07/19(日) 03:24:25.64ID:Xo5fmFzm 完全にスレチじゃん？
380デフォルトの名無しさん
2020/07/19(日) 04:14:25.27ID:VuyFWk7z blazor-serverはともかくblazor-wasmは深刻なパフォーマンス問題があって、
[Blazor WebAssembly] Serious performance issues
https://github.com/dotnet/aspnetcore/issues/21085
その対策は進行中↓
Blazor performance optimizations #22432
https://github.com/dotnet/aspnetcore/issues/22432
つまりまだ全然安定しておらず、スレタイなんかと成熟度は比べるべくもない。
トラブルが起こったときアセンブリレベルでデバッグしたいならどうぞ。
blazor-serverのほうは実用レベルに到達してるけど、それこそスレチだしphpあたりと勝負してきてどうぞｗ
[Blazor WebAssembly] Serious performance issues
https://github.com/dotnet/aspnetcore/issues/21085
その対策は進行中↓
Blazor performance optimizations #22432
https://github.com/dotnet/aspnetcore/issues/22432
つまりまだ全然安定しておらず、スレタイなんかと成熟度は比べるべくもない。
トラブルが起こったときアセンブリレベルでデバッグしたいならどうぞ。
blazor-serverのほうは実用レベルに到達してるけど、それこそスレチだしphpあたりと勝負してきてどうぞｗ
■ このスレッドは過去ログ倉庫に格納されています
