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房が書き込んでも無視してください
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いじれない」というのを否定してる。
2020/07/19(日) 03:24:25.64ID:Xo5fmFzm
完全にスレチじゃん？
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あたりと勝負してきてどうぞｗ
2020/07/19(日) 05:20:39.95ID:VEGN/NtA
WebAssembly自体が期待されるほど速くないから、今のままだと廃棄物になることがわかりきってるもんなあ。
ある日突然爆速になったら状況は全然変わってくるだろうけど
2020/07/19(日) 05:28:36.09ID:W3hSYpRn
WebAssemblyの目的は既存アプリ（特にゲーム）の移植なんだって
他の言語で開発できるって言うけど、
サーバーサイドは昔から他の言語で開発できたのに
遅いはずのスクリプト言語を使っていただろ
速度ははやければ良いねぐらいの扱いで、誰も期待してないんだよ

それに脆弱性につながるからブラウザのセキュリティ能力を超えることはできない
JavaScriptでもできることを他の言語でできるだけ
2020/07/19(日) 05:33:59.05ID:x6eBp0n6
Webはやはり描画がクソ重いよなあ
ゲームの超複雑な計算でも60fps出るだろ
DOM構築ごときに処理かかりすぎなんだよ
2020/07/19(日) 07:47:59.56ID:tFAvgvCU
>>375
wasmはVM転送しないの？
仕組みを見るとwasmは仮想アセンブラのバイトコードを実行するみたいに見える

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

同様にC#はVM部分をwasmにしてブラウザに転送する必要があるように見える
違うの？
libcやVMなどはブラウザ側の更新で増えていくものなの？
2020/07/19(日) 07:53:19.22ID:tFAvgvCU
やっぱり数MBのVM(mono.wasm)を転送するじゃないか！
2020/07/19(日) 08:02:41.88ID:PEwdaGfT
libcもmono.wasmもどっちもVMじゃないから。そういうライブラリのことを聞きたかったのだとしたら
使う言葉を間違えてる。
2020/07/19(日) 08:10:57.60ID:tFAvgvCU
.NETが現実的な選択肢になりえないことは分かったのでもういいですよ
2020/07/19(日) 08:26:55.45ID:W3hSYpRn
>>385
wasmは転送量増えるよね。
小規模なコードならJavaScriptの方が小さくなる

だからwasmが対象としてるのは過去の比較的大規模なアプリを
そのままブラウザで動かすためのもの
それは大体ゲームｗ
2020/07/19(日) 08:45:06.05ID:nXJK1voh
ブラウザでゲームやるならクラウドでええやんってなるに決まってるだろ
2020/07/19(日) 08:45:29.98ID:PIkW4oBq
>>380
LOHじゃん
よっぽど馬鹿なプログラム書かなきゃ問題にならんよ
2020/07/19(日) 08:47:06.11ID:W3hSYpRn
>>389
クラウドが何を言ってるのかわからんけど、
ここで言ってるゲームっていうのは過去PC用でリリースしたものの話だよ
移植を楽にしてくれるのがwasm
2020/07/19(日) 08:48:50.35ID:PIkW4oBq
>>388
業務系
2020/07/19(日) 08:50:00.32ID:j+IrtB5e
>>385
キャッシュされるからそれは無視していいよ
2020/07/19(日) 08:53:37.36ID:tFAvgvCU
>>393
気になるかならないか決めるのは開発者ではなく利用者だから
2020/07/19(日) 08:57:28.54ID:W3hSYpRn
>>393
jQueryなどは複数のサイトで同じライブラリを使うから
あるサイトでキャッシュされたら他のサイトでも早くなることがある。
CDNが使われることも多い
でもwasmはそうならんやろ？使われてる例自体も少ないし。
2020/07/19(日) 08:59:03.14ID:PIkW4oBq
>>394
ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
Gmailとか起動遅いけどみんな普通に使ってるだろ
まあ遅いといってもデスクトップアプリよりは速いし
開発者が過剰に神経質になってるだけだ
2020/07/19(日) 08:59:45.80ID:W3hSYpRn
>>392
業務系にwasmは使い物にならんよね。HTMLで簡単にUIをつかえるのに
wasmだとそこから作らなければいけない
ゲームならそこから作るのは当たり前だけど
業務系はすでにある使いやすいコンポーネントを再利用するのが普通
速度も業務系だと結局サーバーサイドでやることが多いし
2020/07/19(日) 09:01:44.02ID:W3hSYpRn
>>396
> ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
> Gmailとか起動遅いけどみんな普通に使ってるだろ

速度とかよりも手軽さ重視だからね
ブラウザでもアプリでも気にしないし
wasmの価値は移植を楽にしてくれる所というのはそういう話
2020/07/19(日) 09:02:52.10ID:tFAvgvCU
>>396
もういいって
遅くても我慢して使ってくれるから大丈夫！
とかなんなの？
あなたとは話す価値がないと判断した
2020/07/19(日) 09:02:58.39ID:PIkW4oBq
>>395
時間が解決する問題だな
つか別に複数サイトで共有しなくてもキャッシュされるし
つか.NETは単一バイナリのビルドとモジュールのトリミングを研究してるからデカイランタイム問題もすぐ解決するよ
2020/07/19(日) 09:04:20.16ID:W3hSYpRn
> 時間が解決する問題だな
「使う理由がない」は時間が解決してくれないよ
時間が解決するのは、今実際に起きている課題だけ
2020/07/19(日) 09:04:23.55ID:tFAvgvCU
時間が解決する問題ってことは
やはり現時点では.NETは現実的ではないってことね
成熟したらまた教えて
2020/07/19(日) 09:05:40.29ID:W3hSYpRn
>>399
> 遅くても我慢して使ってくれるから大丈夫！
> とかなんなの？

誰もそんな話はしていない。
遅いのだろうが許容範囲なのでみんな使ってくれているので大丈夫
使ってくれるはずという希望じゃないんだよ。
実際に使ってるんだよ。だからこの程度であれば大丈夫であることは証明済み。
2020/07/19(日) 09:06:25.23ID:PIkW4oBq
>>397
まるごと再利用しか頭にないのか？
業務系ではレガシーなシステムの移植とかいくらでもあるんだが
業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい
2020/07/19(日) 09:06:59.87ID:W3hSYpRn
> 業務系ではレガシーなシステムの移植とかいくらでもあるんだが
移植で作り変えるならブラウザ版を作りますって（笑）
2020/07/19(日) 09:08:44.46ID:W3hSYpRn
> 業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい

苦手なやつがC#使ったからって克服できるわけ無いやろｗ
苦手なら得意な人がやればいいだけだし
分業できる方が良いよ
2020/07/19(日) 09:09:00.50ID:PIkW4oBq
>>399
お前も話す価値ないよ
速度なんてこれからいくらでも最適化で改善していく部分だから現状で少しビハインドでも全く問題にならねえんだよね
逆にそこしか否定できないってことはもうBlazorを無意識化では認めちゃってるってことだよ
2020/07/19(日) 09:09:48.38ID:PIkW4oBq
>>401
時間が経てば使う理由も増えるわけだが
2020/07/19(日) 09:10:04.29ID:W3hSYpRn
JavaScriptの速度も随分と改善しましたしね。
十分実用レベルに達している。
さらにCPUの性能は上がり続けてる。
2020/07/19(日) 09:10:20.89ID:PIkW4oBq
>>402
十分実用的、で、時間が経てば更によくなる
2020/07/19(日) 09:10:39.96ID:W3hSYpRn
>>408
増えないよ。お前がネット始めてから20年ぐらい立つだろうが
普段やってることは大して変わってねーだろ？ｗ
2020/07/19(日) 09:11:54.71ID:tFAvgvCU
Blazor勢 必死すぎるだろw
もういいんだって
2020/07/19(日) 09:12:03.15ID:W3hSYpRn
そもそもな。デスクトップアプリとして以前からできることを
ブラウザでわざわざやる理由がないんだよ
アプリ版を作ればいいだけなんだから
2020/07/19(日) 09:12:19.58ID:PIkW4oBq
>>405
移植でブラウザ版を作るから業務系開発者が得意なC#で開発できること価値が大きいんだろ
2020/07/19(日) 09:14:29.32ID:W3hSYpRn
>>414
だからサーバーサイドは以前からC#で開発できてますってｗ
2020/07/19(日) 09:15:20.05ID:m5eV0pvm
追うのめんどいから誰か論点整理して貼って
2020/07/19(日) 09:18:02.57ID:PIkW4oBq
>>406
克服できてしまうんだなぁこれが
つか.NETとVisualStudioが優秀だからなんとなくで作れるようになる

得意なやつがやればいい、なんてのはコスト意識のない下っ端の考え方なのではっきり言って論外
業務系はWeb系みたいなホビーじゃねえんだよ
2020/07/19(日) 09:19:09.28ID:W3hSYpRn
コスト意識があったら、適材適所って言葉を知ってるはずだがなｗ
なぜ苦手な人がフロントを作るのか
2020/07/19(日) 09:20:43.25ID:W3hSYpRn
C#で業務系と言うとASP.NETを使います。
UI込ですでに実現できてるんですよ。
wasmで一体なんのUIを作るんですか？
2020/07/19(日) 09:22:19.43ID:PIkW4oBq
>>411
ユーザー目線では特に変わってない
ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ

マイクロソフトの提供する開発体験はいつも素晴らしいものだ
Blazorがもたらす開発体験にも当然、期待していいだろう
今では誰もが使ってるVSCodeもTypeScriptもそういやマイクロソフトだよなぁ
次のビッグウェーブが来てるんだろうな
2020/07/19(日) 09:24:05.39ID:PIkW4oBq
>>415
フロントエンドでもC#を使えるようになるのが大きいんだって話だろ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況