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房が書き込んでも無視してください
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#を使えるようになるのが大きいんだって話だろ
2020/07/19(日) 09:24:15.27ID:W3hSYpRn
> ユーザー目線では特に変わってない
> ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ

どういう理屈？言ってみただけの中身がない言葉は要らないよ
2020/07/19(日) 09:26:11.82ID:W3hSYpRn
>>421
> フロントエンドでもC#を使えるようになるのが大きいんだって話だろ

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

繰り返すが、C#で一体なにを実装するの？
すでにユーザーインターフェースは揃っている。
2020/07/19(日) 09:26:37.05ID:PIkW4oBq
>>418
やっぱホビーだなあんた
安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
大規模なチームで仕事をするなら絶対に必要なスキルだ
それをシラナイということは個人開発か、少数精鋭で作れるおもちゃみたいなスタートアップしかやったことないんだろ
2020/07/19(日) 09:27:14.26ID:W3hSYpRn
> 安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
だからフロントはHTMLが得意な安い人材を使います。
2020/07/19(日) 09:31:34.04ID:PIkW4oBq
>>419
SPAを作るんだよ
既存のASP.NET(Core)でも開発はできるがデスクトップアプリと比べると操作性が悪いことは否めない
複雑怪奇な業務に適応するためにSPAの導入は今後不可避になるだろう
しかしSPAをやるには今まではクソッタレJSやらポンポン入れ替わるWebフレームワークを学ぶ必要があって学習コストが高すぎた
業務系の主力である安い人材では習得が難しいのでSPAはずっと見送られてきた
しかしBlazorならその問題を一挙にカイケツすることができる
2020/07/19(日) 09:32:22.28ID:PIkW4oBq
>>422
君、プログラム下手でしょ
インターフェイスと実装の分離ができないタイプと見た
2020/07/19(日) 09:32:58.15ID:PIkW4oBq
>>423
>>426
2020/07/19(日) 09:37:55.76ID:PIkW4oBq
>>425
フロントエンド特化人材は高えんだよ

私、フロントエンドなんてぜんぜんできませんよ～
って具合の人材を
ふ～ん、なら少し安めのお値段で雇ってもいいよね？
大丈夫、大丈夫、こっちでうまいことレール敷くんで、安心して手だけ動かしてください
ってな具合で格安で調達すんの
できない奴でも、できるようにすんの
2020/07/19(日) 09:38:44.30ID:W3hSYpRn
>>426
お前フレームワークもなしに独自でSPA作るの？ｗ

https://codezine.jp/article/detail/10599

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を連携したアプリケーションを素早く開始することができます。
2020/07/19(日) 09:39:23.07ID:W3hSYpRn
>>429
> フロントエンド特化人材は高えんだよ
ならフロントエンドに特化してない人を使えば？
バカなのかなこいつ
2020/07/19(日) 09:42:08.97ID:W3hSYpRn
なんかC#を使ってWindows Formsとかでデスクトップアプリを作れば
それがそのままSPAになるって思ってそうなんだよなｗ
URLどうするんのよって感じだ
2020/07/19(日) 09:45:34.17ID:W3hSYpRn
URLじゃ話通じないですかね？ｗ
SPAはデスクトップアプリとは違ってURLがあって
ブラウザの進むや戻るがつかえるんですよ
2020/07/19(日) 09:47:19.12ID:PIkW4oBq
>>430
意味不明な切り返しすんな
SPAでやると決まったらフレームワーク使うに決まってんだろ

お前が得意げに挙げた.NETの従来のSPAテンプレートは各種JSフレームワークのテンプレートを生成するだけだ
おまけ程度にC#のAPI開発テンプレートも生成してくれるがJSフレームワークを隠蔽するようなものじゃない
だからそれらを使ってもフロントエンド特化人材を雇わないと開発なんてできねえぞ
2020/07/19(日) 09:49:53.45ID:PIkW4oBq
>>431
オメーがバカ
特化した人材は高い
特化してない人材ではJSフレームワーク使った開発は生産性が低い
安いには安いなりの理由があるんだよ
だがBlazorならそんな安い連中でもC#とVSを使って簡単に開発できるようになる
2020/07/19(日) 09:50:41.48ID:PIkW4oBq
>>432
誰もそんな話はしてねー
そんな理解になるってお前の頭どういう構造してんだ
2020/07/19(日) 09:51:14.00ID:W3hSYpRn
> フロントエンド特化人材を雇わないと開発なんてできねえぞ

普通にフロントエンド開発者を使えばいいだけでは？ｗ
いないんですか？
2020/07/19(日) 09:52:08.96ID:PIkW4oBq
>>437
高えつってんだろ
鳥頭か
2020/07/19(日) 10:52:37.38ID:5Si5cYu0
そろそろwasmの話は別スレでやってくれないか？
2020/07/19(日) 10:58:54.20ID:x6eBp0n6
実際フロントエンドまともにできないゴミエンジニアばかりだからな
以前某エンジニアリクルート系の検索システムでフロントエンドエンジニアを検索したら全エンジニアの0.5％しかいなかった
その0.5％も自称だからガチで少ない
2020/07/19(日) 11:04:27.08ID:jXwWFSFG
>>440
Blazorはゲームチェンジャーになりうる
なんたって雑魚カスC#erでも超お手軽にSPAを開発できてしまうんだから
JS系のエンジニアの市場価値は相対的に下がるだろうね
2020/07/19(日) 11:18:11.07ID:AjlQmunT
Blazor-wasmまとめ
重い>>385
遅い>>380
有名クラウドサービス採用実績ゼロ
（React/Angular採用多数は言わずもがな）
C#以外覚えられなくなった年寄りを再利用するための介護フレームワーク。
2020/07/19(日) 11:20:10.35ID:m5eV0pvm
よっぽど高度なことするわけじゃない限り、C#書けるならReactとか2週間もあれば書けると思う
2020/07/19(日) 11:34:57.86ID:x6eBp0n6
>>441
バックエンドゴミエンジニアが何を使ったってゴミのようなフロントしか作れないぞ
絶望的に才能がない
目ん玉はただの飾り
こいつら（＝おまえら）に良い筆を持たせても無意味
2020/07/19(日) 12:02:35.96ID:Xo5fmFzm
いい加減専用スレ立ててそっちでやれよ
2020/07/19(日) 12:11:33.06ID:kmbJyWa5
数年後にwasmだらけになって涙目になるJSキッズが目に浮かぶ
2020/07/19(日) 12:14:17.72ID:kmbJyWa5
>>443
2週間�人数の教育工数が無駄
2020/07/19(日) 12:16:36.81ID:kmbJyWa5
>>442
重さは、遅さは現状でも十分実用に堪えうる
というか既存のSPAも体感はほとんど変わらんレベル
ゴリッゴリに最適化された既存フレームワークと比較してだから、最適化の余地があるwasmのほうが将来的には優位
採用実績はまだ正式発表されたばかりだから、比較しても意味がないことは小学生でもわかるはずだが君はどうだ？
2020/07/19(日) 12:17:49.08ID:PEwdaGfT
そこで振り落とされるような奴は今のJSフロントエンドすら無理。
2020/07/19(日) 12:20:18.80ID:BU8dfNcw
blazor厨もそれに付き合うやつも
よそでやれよ
そんなんだからいつまでたっても
そんなんなんだぞ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況