Vue vs React vs Angular Part.4

■ このスレッドは過去ログ倉庫に格納されています
2020/06/11(木) 19:01:45.26ID:uGsh0NQC
実際どうなん？
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房が書き込んでも無視してください
279デフォルトの名無しさん
垢版 |
2020/07/17(金) 14:16:04.30ID:Mcc/Kfhl
>>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単体で動かしてもいい
おそらくそれが最速になる
2020/07/17(金) 14:35:49.91ID:rScYk2f8
kestrel(dotnet run)を否定しているわけじゃないよ
それは単体でHTTPを話す能力を持ってるじゃん
つまりTomcatやGlassFishと同じ位置付け
Apache、nginx等のWebサーバーを手前に追加するもしないも自由

でもそれは「Apacheで.NETが動く」という話にはならない
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が多い
2020/07/17(金) 14:48:05.03ID:Mcc/Kfhl
>>280
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ

.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから
2020/07/17(金) 14:49:01.58ID:bZMoLlJz
Apacheに乗せるなんて無駄なことしたくない
Nginx RP + Inproc Httpがスマートで最高
2020/07/17(金) 14:55:32.14ID:rScYk2f8
静的コンテンツのレスポンス高速化のためだけにリバースプロキシ（Apache, nginx）置くわけじゃないから
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない
2020/07/17(金) 15:02:52.55ID:bZMoLlJz
最近はApacheを知らない若者も居るようだ
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい
2020/07/17(金) 15:46:01.13ID:Q8AVDrqq
Nginx は、リバースプロキシ

世界最速は、Ruby on Rails 製の
https://dev.to/

これよりも速いものは、作れない
2020/07/17(金) 19:01:29.04ID:gHhKsxDc
最近JIT対応したPHP8のalpha版が結構いいスコア出してるそうだがな
2020/07/17(金) 21:28:04.44ID:LPqky/1r
>>278
angularは1系で@angular/coreは2以降じゃないかな
しっかしReact圧倒的だね
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ファイルの外部化は個人的にかなり抵抗感がある
2020/07/17(金) 23:32:34.52ID:pbRdpk23
フロントエンドのライブラリだというのに
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん
2020/07/18(土) 00:18:41.79ID:lkZeEJlA
>>287
PHPは言語がうんこすぎて
ベンチマークいくらよくても使う気にならない
2020/07/18(土) 00:25:43.24ID:Rz8uT7Q+
phpはhtmlに直接サーバーサイド変数を埋め込めるという点で負の遺産を残しすぎた。
wordpressだのsmartyだの吐き気するわ。
2020/07/18(土) 01:02:58.86ID:mlew4XCO
>>293
それの何が悪いの？
2020/07/18(土) 01:08:32.40ID:5AaucbBP
バックエンドなんてフレームワークで構成してJSONやり取りするもんだからそんなの別に気にする事じゃないだろ
2020/07/18(土) 02:09:48.73ID:lkZeEJlA
>>275
PostgreSQLか

爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも

C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？
2020/07/18(土) 02:21:16.88ID:N4WthBbf
> React+Next.js勉強やめて

勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ
2020/07/18(土) 02:39:54.52ID:lkZeEJlA
>>297
俺が何時間やったかも書いてないのにそんなレスつけてしまうおまえが頭悪い

あと頭いい人はそうやって文末にwつけないしアンカーをつける
2020/07/18(土) 04:07:12.10ID:N4WthBbf
なるほどつまり数時間やって分かんなくて嫌になってwasmならできるモン！ってことか。説明ご苦労。

そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ
2020/07/18(土) 08:45:31.60ID:5AaucbBP
WebAssemblyに夢見過ぎなヤツ多いな
そんなに速度が必要な事をやってるのかと
301デフォルトの名無しさん
垢版 |
2020/07/18(土) 09:04:24.26ID:lkZeEJlA
>>300
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる

夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。

実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う
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
これでおｋ
2020/07/18(土) 09:10:56.66ID:5AaucbBP
>>301
ECでボトルネックになるのは大体の場合サーバーサイドだろ
2020/07/18(土) 09:13:11.20ID:lkZeEJlA
>>299
根性とかアホじゃないか
C#やJavaで開発してきた人がTSの開発を理解できないわけがない
2020/07/18(土) 09:28:04.98ID:lkZeEJlA
>>303
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど

速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？
2020/07/18(土) 09:33:43.74ID:Zsjd19dY
wasmの求人需要ってある？
2020/07/18(土) 09:41:11.98ID:a72QTQ2S
1ミリもない
2020/07/18(土) 09:48:13.03ID:37eL7IOf
自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ
2020/07/18(土) 10:09:29.41ID:N4WthBbf
>>304
根性じゃなきゃやっぱり頭のほうかｗ
数時間かけても理解できずに止めたんだろ？なんかゴメンなｗｗｗ
2020/07/18(土) 10:18:52.49ID:5tCG/Slu
理解できないことはないんだろうけど
拒否反応を起こす人は結構いるね

JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし
2020/07/18(土) 11:01:01.72ID:fwbEJCvA
>>301
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？

今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる

「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？
2020/07/18(土) 11:07:30.53ID:fwbEJCvA
>>305
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。

WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い
2020/07/18(土) 11:20:03.68ID:fwbEJCvA
WebAssemblyはどんな問題（課題）を解決するのかを答えられないようじゃ
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。

WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ

つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない
2020/07/18(土) 11:23:08.49ID:oiSxLKa2
wasmでVM動かしてる状況だとまだ劇的に速いとは言えないのでは
wasmのGC実装もこれからだし流石に時期尚早感がある
2020/07/18(土) 11:28:21.15ID:5tCG/Slu
JavaScriptだってネイティブ実行されてるわけじゃなくJITコンパイルしながら実行されてるでしょ
wasmのVMが大きなオーバーヘッドだとは思わないけどな
2020/07/18(土) 11:29:28.75ID:Z+cMIoZ7
>>313
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！
2020/07/18(土) 11:33:48.46ID:fwbEJCvA
>>316
そんな人もいるんだからって言いたいの？ｗ
2020/07/18(土) 11:49:48.36ID:zDePOjuW
jsをwasmにコンパイル出来たら爆発的に普及しそうなんだが、いまだにまともにできないんだよな。
2020/07/18(土) 11:54:20.16ID:Z+cMIoZ7
>>317
そうですワタシが変なおじさんです。
応答速度がどうのこうのと言う話の流れを見てますと
WebブラウザのSPAで3次元CADも出来る時代になったのだなあと感慨に老けっております。
2020/07/18(土) 11:59:32.49ID:fwbEJCvA
>>319
論点はそこじゃなくて、
「3次元CADやるなら別にブラウザじゃなくていいよね」
だから

なぜわざわざ遅いとわかってるブラウザで動かすのか？
ブラウザで動かさなきゃいけない使命でもあるの？
321デフォルトの名無しさん
垢版 |
2020/07/18(土) 12:07:43.56ID:OjEg02/9
jquery bootstrap Vue React angular
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！
2020/07/18(土) 12:18:23.75ID:Z+cMIoZ7
>>320
時代はリモートでコラボれーしょんやら？
WebVRで3Dチャット元年ではなかったのかと・・・
2020/07/18(土) 12:25:07.68ID:huqpRUrM
VS+C#の快適さに比べたらJSやTSなんてゲロ以下でしょ
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー
2020/07/18(土) 12:27:17.68ID:a72QTQ2S
vscode + js のウルトラ開発体験知らんのか？
2020/07/18(土) 12:28:49.89ID:5AaucbBP
>>323
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない
2020/07/18(土) 12:29:31.05ID:huqpRUrM
>>324
VSCodeは不安定すぎて話にならんわ
2020/07/18(土) 12:31:33.52ID:huqpRUrM
>>325
宗教上の理由でIDEを避けたいならそうすればいい
Blazorも例に漏れずVScodeでもVimでもなんだって開発できる
ま、VSが最強なので他はオススメはせんがね
2020/07/18(土) 12:33:55.33ID:cNrPu/ON
VSおじさんｗ
Silverlightはどうなりましたかｗ
2020/07/18(土) 12:40:21.88ID:fQsuqJMx
wasm(たとえばC#)って画面描画どうやってやるの？
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？

wasm詳しい人教えてくれ！
2020/07/18(土) 12:50:44.89ID:cNrPu/ON
まだ直接DOMいじれない。
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ
2020/07/18(土) 12:53:18.24ID:5tCG/Slu
え、DOMいじれずC#(WPF)で描画もだきないのか
結局、JavaScript使わないといけないんじゃ微妙ね

ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ
2020/07/18(土) 12:55:00.61ID:hYOY3gDK
>>328
この返しは恥ずかしすぎる
2020/07/18(土) 12:55:34.30ID:hYOY3gDK
>>329
Razorマークアップ
2020/07/18(土) 12:56:00.12ID:hYOY3gDK
>>331
JSは要らんよ
2020/07/18(土) 12:56:27.32ID:cNrPu/ON
でもそのwasmの外にあるjsへの指示・管理はフレームワーク側の仕事だからあなたが直接dom api叩く必要はない
2020/07/18(土) 13:00:40.40ID:fwbEJCvA
>>322
> 時代はリモートでコラボれーしょんやら？
> WebVRで3Dチャット元年ではなかったのかと・・・

だからブラウザ使わなくて出来てるでしょｗ
2020/07/18(土) 13:02:21.10ID:fwbEJCvA
>>329
ブラウザの中に仮想マシンが実装されたと考えれえばいい
表示はブラウザの中の一部分が仮想マシンのウインドウになったようなもの
その中で何でも出来る。その中でしか動かない。
2020/07/18(土) 13:06:46.63ID:u6Nb4/2q
ブラウザのDeveloperToolでデバッグできる？
2020/07/18(土) 13:08:43.45ID:fwbEJCvA
JavaScriptもJITとか使うから計算とかならネイティブとほぼ同じ速度で動くんだよ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ

DOMの複雑なレンダリングアルゴリズムが原因だから
それは避けようがない。

しかしもともとは画面表示なんて縦横のビットマップでしかなかったわけで
DOMのレンダリングを避けて、直接描画しましょうっていうのがWebAssembly
DirectXの思想と似てるね。WebAssemblyの目的はレガシー技術の移植だから
DOMは必要ない。なのでWebAssemblyからDOMを直接さわれるようなことはないよ
間接的に触れればOK。

画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ
2020/07/18(土) 13:39:15.04ID:5tCG/Slu
wasmの画面描画について答えてくれてありがとう
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね

wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ
2020/07/18(土) 13:42:32.30ID:fwbEJCvA
外部との通信やファイルアクセスやI/OはブラウザのAPIエミュレートされる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる
2020/07/18(土) 13:44:42.37ID:fwbEJCvA
そういうI/O系はJavaScript APIを使ってエミュレートされるので
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ
2020/07/18(土) 13:48:10.88ID:zDePOjuW
wasmの画面表示って結局jsと同じDOMかWebGLじゃね？
2020/07/18(土) 13:58:51.62ID:fwbEJCvA
>>343
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）

だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される
2020/07/18(土) 14:54:17.15ID:5tCG/Slu
wasmおもしろそうだな
いっちょさわってみるか
346デフォルトの名無しさん
垢版 |
2020/07/18(土) 14:59:20.43ID:OjEg02/9
>>334
そんなものオタクしか興味ねーよ
手軽さとか互換性問題が起きない方がよっぽど大事
2020/07/18(土) 15:00:47.66ID:lkZeEJlA
>>302
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。
2020/07/18(土) 15:01:01.32ID:zDePOjuW
ああ、言いたかったのは描画に関しては結局jsと変わらんだろうということ。
Canvas APIやWebGL APIを呼ぶだけだしね。
2020/07/18(土) 15:03:36.80ID:lkZeEJlA
>>306-307
すぐBlazorやりたければ自分で作った会社で開発してマネタイズすればいい。

今までにC#でASP.netの開発やってる企業なら近いうちにBlazorの案件始めるよ
JSに比べて開発生産性高いのだからBlazorやらない理由がない

>>310
C#になれてるとdynamic languageへの拒否反応はたしかに強い
開発の生産性が低すぎるんだもの
2020/07/18(土) 15:08:26.33ID:lkZeEJlA
>>311
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ

なぜSPでネイティブアプリがあるかっておもに性能だろう

パフォーマンス重要な用途がわからない？？
開発者でそれが思い浮かばない人っているんだね

ハイパフォーマンスということはわざわざAndroidやiOSの
アプリつくって売上の30%ぼったくられなくても
Blazorでゲーム作って稼ぐようなこともできる。
それくらい思い浮かばないかふつう。

パフォーマンスめちゃくちゃ大事
2020/07/18(土) 15:28:43.67ID:fwbEJCvA
>>350
> なぜSPでネイティブアプリがあるかっておもに性能だろう
違うよ。ネイティブアプリの自由度の高さと
スマホ標準インターフェースとの統合
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もうんこ言語で
開発することになる
2020/07/18(土) 15:40:33.50ID:lkZeEJlA
>>313
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる

server sideまでうんこ言語（JS)やその改善版（TS)で
開発する時代がいつまでも続くと思うか？
俺は全く思わない

好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ
2020/07/18(土) 15:43:26.01ID:lkZeEJlA
>>318
JSってType safetyじゃないだろ
もともとcompileと合わないうんこ言語だからどうしようもない

C#とかに変えればいいだけだ
2020/07/18(土) 15:47:48.54ID:lkZeEJlA
>>320
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ

wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ
2020/07/18(土) 15:52:34.71ID:lkZeEJlA
>>328
そういうアホな質問はいたるところで論破されてる

SilverlightとちがってWebAssemblyはstandardなの
普及しない理由がないの
2020/07/18(土) 15:54:43.54ID:VwC7Y7IV
まあなんにせよいつまでもJS、TSにしがみついてるのはエンジニアとしてリスキーだよね
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た
2020/07/18(土) 15:54:46.28ID:lkZeEJlA
>>329
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1
2020/07/18(土) 16:41:05.47ID:5tCG/Slu
>>358
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね

ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い
2020/07/18(土) 16:44:31.11ID:fwbEJCvA
なんでクライアントとサーバーで同じ言語で作ったほうが
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？
2020/07/18(土) 16:44:51.36ID:fwbEJCvA
>>357
お前は何の言語にしがみついてるんだ？ｗ
2020/07/18(土) 16:51:43.65ID:5tCG/Slu
>>360
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？

おれはSQL併用するけどSQL使わない勢も実際にいるよ
ORMの自動生成クエリーだけでなんとかするっていう
逆にSQLでビジネスロジック全部やりたい勢もいるストアド大好きな人達

ソフトウェアって自由でいいな
2020/07/18(土) 16:53:18.15ID:fwbEJCvA
>>359
UIをコードで書くならDOMベースが一番適してるんだよ
HTMLかXMLかそれに近いマークアップ言語

その例外がゲームとかCADとか点や線ベースでの
インターフェースを持っているもの
具体的に言えば、点や線が目まぐるしく変わるもの
2020/07/18(土) 16:56:29.69ID:fwbEJCvA
>>362
> JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
RubyやPython使ってるだろ
目的に応じて適切な言語使ってるんだよ
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遅っそｗｗｗ重っもｗｗｗｗ
2020/07/18(土) 17:32:39.93ID:vLQD9afh
>>344
WebGLでもDOMのように階層持たせることはできるの？
俺は3Dゲーム作っていたんだが、あんな感じでポリゴンみたいにして作るのかな
今イチわからん
2020/07/18(土) 17:43:52.38ID:lkZeEJlA
>>359
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ

WPFはXAMLだっけ、あれはXMLの方言みたいなやつだよね

Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう
2020/07/18(土) 17:46:29.08ID:vfrpqE6H
>>366
WebGLはDOMの一要素canvasを仮想的なディスプレイと見立てて
その中にOpenGLの命令で自由に描画するもの
2020/07/18(土) 18:54:17.02ID:162OGkYI
>>359
WPFじゃないけどXamlでWeb開発可能らしいね
個人的にはよく知らんけどWinUIとかいうやつ
2020/07/18(土) 18:56:30.00ID:162OGkYI
間違えたWinUIじゃなかったUnoだ
2020/07/18(土) 19:26:35.55ID:5AaucbBP
>>336
あーもうそれこのスレ関係ないって事だよね
専用スレ立てればいいのにね
2020/07/18(土) 19:30:44.95ID:5AaucbBP
あんじゃん
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
https://mevius.5ch.net/test/read.cgi/tech/1308761577/
2020/07/18(土) 20:42:52.64ID:Rz8uT7Q+
wasmで処理速度が上がるのか知らんけどコンパイルされるわけだからネイティブコードよりも転送量増える理屈だよな。
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？
2020/07/18(土) 21:47:01.74ID:5tCG/Slu
そうですね
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる
2020/07/18(土) 22:58:32.39ID:lkZeEJlA
>>373
コンパイルされたものがBrowserに配られる
本番環境用にサイズを小さくするオプションもあるし
browser にcacheされるから2回目以降は速い。
demoみてもその辺は考慮されて設計されてるかんじ

最初は遅いのはPWAとかSPAでも同じでしょ

>>374
VMまるごと転送するなんてどこにも書かれてないし
そんなことやるとは思えない
Wasmで共通のバイナリはBrowser updateのときに入るでしょ
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なんてあるわけないだろうｗ
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
2020/07/19(日) 02:34:09.44ID:ktD9w8qF
とりあえずBlazorのsampleいっこだけ動かしてみた

>>377
「直接いじれない」と「いじれない」では全然違うでしょ

JavaScript Interopの存在は知ってるし
>>376はちゃんと「DOMいじれない」というのを否定してる。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況