Vue vs React vs Angular Part.4

**デフォルトの名無しさん** · 2020/06/11(木) 19:01:45.26

実際どうなん？
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房が書き込んでも無視してください

**デフォルトの名無しさん** · 2020/07/18(土) 12:50:44.89

まだ直接DOMいじれない。
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ

**デフォルトの名無しさん** · 2020/07/18(土) 12:53:18.24

え、DOMいじれずC#(WPF)で描画もだきないのか
結局、JavaScript使わないといけないんじゃ微妙ね

ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ

**デフォルトの名無しさん** · 2020/07/18(土) 12:55:00.61

>>328
この返しは恥ずかしすぎる

**デフォルトの名無しさん** · 2020/07/18(土) 12:55:34.30

>>329
Razorマークアップ

**デフォルトの名無しさん** · 2020/07/18(土) 12:56:00.12

>>331
JSは要らんよ

**デフォルトの名無しさん** · 2020/07/18(土) 12:56:27.32

でもそのwasmの外にあるjsへの指示・管理はフレームワーク側の仕事だからあなたが直接dom api叩く必要はない

**デフォルトの名無しさん** · 2020/07/18(土) 13:00:40.40

>>322
> 時代はリモートでコラボれーしょんやら？
> WebVRで3Dチャット元年ではなかったのかと・・・

だからブラウザ使わなくて出来てるでしょｗ

**デフォルトの名無しさん** · 2020/07/18(土) 13:02:21.10

>>329
ブラウザの中に仮想マシンが実装されたと考えれえばいい
表示はブラウザの中の一部分が仮想マシンのウインドウになったようなもの
その中で何でも出来る。その中でしか動かない。

**デフォルトの名無しさん** · 2020/07/18(土) 13:06:46.63

ブラウザのDeveloperToolでデバッグできる？

**デフォルトの名無しさん** · 2020/07/18(土) 13:08:43.45

JavaScriptもJITとか使うから計算とかならネイティブとほぼ同じ速度で動くんだよ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ

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

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

画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ

**デフォルトの名無しさん** · 2020/07/18(土) 13:39:15.04

wasmの画面描画について答えてくれてありがとう
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね

wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ

**デフォルトの名無しさん** · 2020/07/18(土) 13:42:32.30

外部との通信やファイルアクセスやI/OはブラウザのAPIエミュレートされる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる

**デフォルトの名無しさん** · 2020/07/18(土) 13:44:42.37

そういうI/O系はJavaScript APIを使ってエミュレートされるので
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ

**デフォルトの名無しさん** · 2020/07/18(土) 13:48:10.88

wasmの画面表示って結局jsと同じDOMかWebGLじゃね？

**デフォルトの名無しさん** · 2020/07/18(土) 13:58:51.62

>>343
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）

だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される

**デフォルトの名無しさん** · 2020/07/18(土) 14:54:17.15

wasmおもしろそうだな
いっちょさわってみるか

**デフォルトの名無しさん** · 2020/07/18(土) 14:59:20.43

>>334
そんなものオタクしか興味ねーよ
手軽さとか互換性問題が起きない方がよっぽど大事

**デフォルトの名無しさん** · 2020/07/18(土) 15:00:47.66

>>302
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。

**デフォルトの名無しさん** · 2020/07/18(土) 15:01:01.32

ああ、言いたかったのは描画に関しては結局jsと変わらんだろうということ。
Canvas APIやWebGL APIを呼ぶだけだしね。

**デフォルトの名無しさん** · 2020/07/18(土) 15:03:36.80

>>306-307
すぐBlazorやりたければ自分で作った会社で開発してマネタイズすればいい。

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

>>310
C#になれてるとdynamic languageへの拒否反応はたしかに強い
開発の生産性が低すぎるんだもの

**デフォルトの名無しさん** · 2020/07/18(土) 15:08:26.33

>>311
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ

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

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

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

パフォーマンスめちゃくちゃ大事

**デフォルトの名無しさん** · 2020/07/18(土) 15:28:43.67

>>350
> なぜSPでネイティブアプリがあるかっておもに性能だろう
違うよ。ネイティブアプリの自由度の高さと
スマホ標準インターフェースとの統合

**デフォルトの名無しさん** · 2020/07/18(土) 15:35:33.35

>>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.50

>>313
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる

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

好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ

**デフォルトの名無しさん** · 2020/07/18(土) 15:43:26.01

>>318
JSってType safetyじゃないだろ
もともとcompileと合わないうんこ言語だからどうしようもない

C#とかに変えればいいだけだ

**デフォルトの名無しさん** · 2020/07/18(土) 15:47:48.54

>>320
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ

wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ

**デフォルトの名無しさん** · 2020/07/18(土) 15:52:34.71

>>328
そういうアホな質問はいたるところで論破されてる

SilverlightとちがってWebAssemblyはstandardなの
普及しない理由がないの

**デフォルトの名無しさん** · 2020/07/18(土) 15:54:43.54

まあなんにせよいつまでもJS、TSにしがみついてるのはエンジニアとしてリスキーだよね
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た

**デフォルトの名無しさん** · 2020/07/18(土) 15:54:46.28

>>329
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1

**デフォルトの名無しさん** · 2020/07/18(土) 16:41:05.47

>>358
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね

ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い

**デフォルトの名無しさん** · 2020/07/18(土) 16:44:31.11

なんでクライアントとサーバーで同じ言語で作ったほうが
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？

**デフォルトの名無しさん** · 2020/07/18(土) 16:44:51.36

>>357
お前は何の言語にしがみついてるんだ？ｗ

**デフォルトの名無しさん** · 2020/07/18(土) 16:51:43.65

>>360
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？

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

ソフトウェアって自由でいいな

**デフォルトの名無しさん** · 2020/07/18(土) 16:53:18.15

>>359
UIをコードで書くならDOMベースが一番適してるんだよ
HTMLかXMLかそれに近いマークアップ言語

その例外がゲームとかCADとか点や線ベースでの
インターフェースを持っているもの
具体的に言えば、点や線が目まぐるしく変わるもの

**デフォルトの名無しさん** · 2020/07/18(土) 16:56:29.69

>>362
> JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
RubyやPython使ってるだろ
目的に応じて適切な言語使ってるんだよ

**デフォルトの名無しさん** · 2020/07/18(土) 17:11:56.84

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.93

>>344
WebGLでもDOMのように階層持たせることはできるの？
俺は3Dゲーム作っていたんだが、あんな感じでポリゴンみたいにして作るのかな
今イチわからん

**デフォルトの名無しさん** · 2020/07/18(土) 17:43:52.38

>>359
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ

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

Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう

**デフォルトの名無しさん** · 2020/07/18(土) 17:46:29.08

>>366
WebGLはDOMの一要素canvasを仮想的なディスプレイと見立てて
その中にOpenGLの命令で自由に描画するもの

**デフォルトの名無しさん** · 2020/07/18(土) 18:54:17.02

>>359
WPFじゃないけどXamlでWeb開発可能らしいね
個人的にはよく知らんけどWinUIとかいうやつ

**デフォルトの名無しさん** · 2020/07/18(土) 18:56:30.00

間違えたWinUIじゃなかったUnoだ

**デフォルトの名無しさん** · 2020/07/18(土) 19:26:35.55

>>336
あーもうそれこのスレ関係ないって事だよね
専用スレ立てればいいのにね

**デフォルトの名無しさん** · 2020/07/18(土) 19:30:44.95

あんじゃん
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
https://mevius.5ch.net/test/read.cgi/tech/1308761577/

**デフォルトの名無しさん** · 2020/07/18(土) 20:42:52.64

wasmで処理速度が上がるのか知らんけどコンパイルされるわけだからネイティブコードよりも転送量増える理屈だよな。
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？

**デフォルトの名無しさん** · 2020/07/18(土) 21:47:01.74

そうですね
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる

**デフォルトの名無しさん** · 2020/07/18(土) 22:58:32.39

>>373
コンパイルされたものがBrowserに配られる
本番環境用にサイズを小さくするオプションもあるし
browser にcacheされるから2回目以降は速い。
demoみてもその辺は考慮されて設計されてるかんじ

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

>>374
VMまるごと転送するなんてどこにも書かれてないし
そんなことやるとは思えない
Wasmで共通のバイナリはBrowser updateのときに入るでしょ

**デフォルトの名無しさん** · 2020/07/18(土) 23:16:25.72

>>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.05

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.44

とりあえずBlazorのsampleいっこだけ動かしてみた

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

JavaScript Interopの存在は知ってるし
>>376はちゃんと「DOMいじれない」というのを否定してる。

**デフォルトの名無しさん** · 2020/07/19(日) 03:24:25.64

完全にスレチじゃん？

**デフォルトの名無しさん** · 2020/07/19(日) 04:14:25.27

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あたりと勝負してきてどうぞｗ

**デフォルトの名無しさん** · 2020/07/19(日) 05:20:39.95

WebAssembly自体が期待されるほど速くないから、今のままだと廃棄物になることがわかりきってるもんなあ。
ある日突然爆速になったら状況は全然変わってくるだろうけど

**デフォルトの名無しさん** · 2020/07/19(日) 05:28:36.09

WebAssemblyの目的は既存アプリ（特にゲーム）の移植なんだって
他の言語で開発できるって言うけど、
サーバーサイドは昔から他の言語で開発できたのに
遅いはずのスクリプト言語を使っていただろ
速度ははやければ良いねぐらいの扱いで、誰も期待してないんだよ

それに脆弱性につながるからブラウザのセキュリティ能力を超えることはできない
JavaScriptでもできることを他の言語でできるだけ

**デフォルトの名無しさん** · 2020/07/19(日) 05:33:59.05

Webはやはり描画がクソ重いよなあ
ゲームの超複雑な計算でも60fps出るだろ
DOM構築ごときに処理かかりすぎなんだよ

**デフォルトの名無しさん** · 2020/07/19(日) 07:47:59.56

>>375
wasmはVM転送しないの？
仕組みを見るとwasmは仮想アセンブラのバイトコードを実行するみたいに見える

たとえばC/C++をコンパイルする場合、完全スタティックリンクが必要になるのでは？
つまり依存libcもwasmにして転送されるのではないですか？（全体ではなく必要な関数だけとはいえ）

同様にC#はVM部分をwasmにしてブラウザに転送する必要があるように見える
違うの？
libcやVMなどはブラウザ側の更新で増えていくものなの？

**デフォルトの名無しさん** · 2020/07/19(日) 07:53:19.22

やっぱり数MBのVM(mono.wasm)を転送するじゃないか！

**デフォルトの名無しさん** · 2020/07/19(日) 08:02:41.88

libcもmono.wasmもどっちもVMじゃないから。そういうライブラリのことを聞きたかったのだとしたら
使う言葉を間違えてる。

**デフォルトの名無しさん** · 2020/07/19(日) 08:10:57.60

.NETが現実的な選択肢になりえないことは分かったのでもういいですよ

**デフォルトの名無しさん** · 2020/07/19(日) 08:26:55.45

>>385
wasmは転送量増えるよね。
小規模なコードならJavaScriptの方が小さくなる

だからwasmが対象としてるのは過去の比較的大規模なアプリを
そのままブラウザで動かすためのもの
それは大体ゲームｗ

**デフォルトの名無しさん** · 2020/07/19(日) 08:45:06.05

ブラウザでゲームやるならクラウドでええやんってなるに決まってるだろ

**デフォルトの名無しさん** · 2020/07/19(日) 08:45:29.98

>>380
LOHじゃん
よっぽど馬鹿なプログラム書かなきゃ問題にならんよ

**デフォルトの名無しさん** · 2020/07/19(日) 08:47:06.11

>>389
クラウドが何を言ってるのかわからんけど、
ここで言ってるゲームっていうのは過去PC用でリリースしたものの話だよ
移植を楽にしてくれるのがwasm

**デフォルトの名無しさん** · 2020/07/19(日) 08:48:50.35

>>388
業務系

**デフォルトの名無しさん** · 2020/07/19(日) 08:50:00.32

>>385
キャッシュされるからそれは無視していいよ

**デフォルトの名無しさん** · 2020/07/19(日) 08:53:37.36

>>393
気になるかならないか決めるのは開発者ではなく利用者だから

**デフォルトの名無しさん** · 2020/07/19(日) 08:57:28.54

>>393
jQueryなどは複数のサイトで同じライブラリを使うから
あるサイトでキャッシュされたら他のサイトでも早くなることがある。
CDNが使われることも多い
でもwasmはそうならんやろ？使われてる例自体も少ないし。

**デフォルトの名無しさん** · 2020/07/19(日) 08:59:03.14

>>394
ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
Gmailとか起動遅いけどみんな普通に使ってるだろ
まあ遅いといってもデスクトップアプリよりは速いし
開発者が過剰に神経質になってるだけだ

**デフォルトの名無しさん** · 2020/07/19(日) 08:59:45.80

>>392
業務系にwasmは使い物にならんよね。HTMLで簡単にUIをつかえるのに
wasmだとそこから作らなければいけない
ゲームならそこから作るのは当たり前だけど
業務系はすでにある使いやすいコンポーネントを再利用するのが普通
速度も業務系だと結局サーバーサイドでやることが多いし

**デフォルトの名無しさん** · 2020/07/19(日) 09:01:44.02

>>396
> ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
> Gmailとか起動遅いけどみんな普通に使ってるだろ

速度とかよりも手軽さ重視だからね
ブラウザでもアプリでも気にしないし
wasmの価値は移植を楽にしてくれる所というのはそういう話

**デフォルトの名無しさん** · 2020/07/19(日) 09:02:52.10

>>396
もういいって
遅くても我慢して使ってくれるから大丈夫！
とかなんなの？
あなたとは話す価値がないと判断した

**デフォルトの名無しさん** · 2020/07/19(日) 09:02:58.39

>>395
時間が解決する問題だな
つか別に複数サイトで共有しなくてもキャッシュされるし
つか.NETは単一バイナリのビルドとモジュールのトリミングを研究してるからデカイランタイム問題もすぐ解決するよ

**デフォルトの名無しさん** · 2020/07/19(日) 09:04:20.16

> 時間が解決する問題だな
「使う理由がない」は時間が解決してくれないよ
時間が解決するのは、今実際に起きている課題だけ

**デフォルトの名無しさん** · 2020/07/19(日) 09:04:23.55

時間が解決する問題ってことは
やはり現時点では.NETは現実的ではないってことね
成熟したらまた教えて

**デフォルトの名無しさん** · 2020/07/19(日) 09:05:40.29

>>399
> 遅くても我慢して使ってくれるから大丈夫！
> とかなんなの？

誰もそんな話はしていない。
遅いのだろうが許容範囲なのでみんな使ってくれているので大丈夫
使ってくれるはずという希望じゃないんだよ。
実際に使ってるんだよ。だからこの程度であれば大丈夫であることは証明済み。

**デフォルトの名無しさん** · 2020/07/19(日) 09:06:25.23

>>397
まるごと再利用しか頭にないのか？
業務系ではレガシーなシステムの移植とかいくらでもあるんだが
業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい

**デフォルトの名無しさん** · 2020/07/19(日) 09:06:59.87

> 業務系ではレガシーなシステムの移植とかいくらでもあるんだが
移植で作り変えるならブラウザ版を作りますって（笑）

**デフォルトの名無しさん** · 2020/07/19(日) 09:08:44.46

> 業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい

苦手なやつがC#使ったからって克服できるわけ無いやろｗ
苦手なら得意な人がやればいいだけだし
分業できる方が良いよ

**デフォルトの名無しさん** · 2020/07/19(日) 09:09:00.50

>>399
お前も話す価値ないよ
速度なんてこれからいくらでも最適化で改善していく部分だから現状で少しビハインドでも全く問題にならねえんだよね
逆にそこしか否定できないってことはもうBlazorを無意識化では認めちゃってるってことだよ

**デフォルトの名無しさん** · 2020/07/19(日) 09:09:48.38

>>401
時間が経てば使う理由も増えるわけだが

**デフォルトの名無しさん** · 2020/07/19(日) 09:10:04.29

JavaScriptの速度も随分と改善しましたしね。
十分実用レベルに達している。
さらにCPUの性能は上がり続けてる。

**デフォルトの名無しさん** · 2020/07/19(日) 09:10:20.89

>>402
十分実用的、で、時間が経てば更によくなる

**デフォルトの名無しさん** · 2020/07/19(日) 09:10:39.96

>>408
増えないよ。お前がネット始めてから20年ぐらい立つだろうが
普段やってることは大して変わってねーだろ？ｗ

**デフォルトの名無しさん** · 2020/07/19(日) 09:11:54.71

Blazor勢必死すぎるだろw
もういいんだって

**デフォルトの名無しさん** · 2020/07/19(日) 09:12:03.15

そもそもな。デスクトップアプリとして以前からできることを
ブラウザでわざわざやる理由がないんだよ
アプリ版を作ればいいだけなんだから

**デフォルトの名無しさん** · 2020/07/19(日) 09:12:19.58

>>405
移植でブラウザ版を作るから業務系開発者が得意なC#で開発できること価値が大きいんだろ

**デフォルトの名無しさん** · 2020/07/19(日) 09:14:29.32

>>414
だからサーバーサイドは以前からC#で開発できてますってｗ

**デフォルトの名無しさん** · 2020/07/19(日) 09:15:20.05

追うのめんどいから誰か論点整理して貼って

**デフォルトの名無しさん** · 2020/07/19(日) 09:18:02.57

>>406
克服できてしまうんだなぁこれが
つか.NETとVisualStudioが優秀だからなんとなくで作れるようになる

得意なやつがやればいい、なんてのはコスト意識のない下っ端の考え方なのではっきり言って論外
業務系はWeb系みたいなホビーじゃねえんだよ

**デフォルトの名無しさん** · 2020/07/19(日) 09:19:09.28

コスト意識があったら、適材適所って言葉を知ってるはずだがなｗ
なぜ苦手な人がフロントを作るのか

**デフォルトの名無しさん** · 2020/07/19(日) 09:20:43.25

C#で業務系と言うとASP.NETを使います。
UI込ですでに実現できてるんですよ。
wasmで一体なんのUIを作るんですか？

**デフォルトの名無しさん** · 2020/07/19(日) 09:22:19.43

>>411
ユーザー目線では特に変わってない
ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ

マイクロソフトの提供する開発体験はいつも素晴らしいものだ
Blazorがもたらす開発体験にも当然、期待していいだろう
今では誰もが使ってるVSCodeもTypeScriptもそういやマイクロソフトだよなぁ
次のビッグウェーブが来てるんだろうな

**デフォルトの名無しさん** · 2020/07/19(日) 09:24:05.39

>>415
フロントエンドでもC#を使えるようになるのが大きいんだって話だろ

**デフォルトの名無しさん** · 2020/07/19(日) 09:24:15.27

> ユーザー目線では特に変わってない
> ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ

どういう理屈？言ってみただけの中身がない言葉は要らないよ

**デフォルトの名無しさん** · 2020/07/19(日) 09:26:11.82

>>421
> フロントエンドでもC#を使えるようになるのが大きいんだって話だろ

だからサーバーサイドの開発にフロントエンドも含まれてるんだってｗ
C#の面倒な実装じゃなくて、テンプレートエンジンを使った簡単な方法で
フロントエンドを作成できる

繰り返すが、C#で一体なにを実装するの？
すでにユーザーインターフェースは揃っている。

**デフォルトの名無しさん** · 2020/07/19(日) 09:26:37.05

>>418
やっぱホビーだなあんた
安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
大規模なチームで仕事をするなら絶対に必要なスキルだ
それをシラナイということは個人開発か、少数精鋭で作れるおもちゃみたいなスタートアップしかやったことないんだろ

**デフォルトの名無しさん** · 2020/07/19(日) 09:27:14.26

> 安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
だからフロントはHTMLが得意な安い人材を使います。

**デフォルトの名無しさん** · 2020/07/19(日) 09:31:34.04

>>419
SPAを作るんだよ
既存のASP.NET(Core)でも開発はできるがデスクトップアプリと比べると操作性が悪いことは否めない
複雑怪奇な業務に適応するためにSPAの導入は今後不可避になるだろう
しかしSPAをやるには今まではクソッタレJSやらポンポン入れ替わるWebフレームワークを学ぶ必要があって学習コストが高すぎた
業務系の主力である安い人材では習得が難しいのでSPAはずっと見送られてきた
しかしBlazorならその問題を一挙にカイケツすることができる

**デフォルトの名無しさん** · 2020/07/19(日) 09:32:22.28

>>422
君、プログラム下手でしょ
インターフェイスと実装の分離ができないタイプと見た

**デフォルトの名無しさん** · 2020/07/19(日) 09:32:58.15

>>423
>>426

**デフォルトの名無しさん** · 2020/07/19(日) 09:37:55.76

>>425
フロントエンド特化人材は高えんだよ

私、フロントエンドなんてぜんぜんできませんよ～
って具合の人材を
ふ～ん、なら少し安めのお値段で雇ってもいいよね？
大丈夫、大丈夫、こっちでうまいことレール敷くんで、安心して手だけ動かしてください
ってな具合で格安で調達すんの
できない奴でも、できるようにすんの