20/07/13 10:53:05.37 WBkWHxcT.net
QZの文字が観えたら読み飛ばすカは付いたと思う
192:デフォルトの名無しさん
20/07/13 12:15:10.45 b+UXm16S.net
「NG」をNGワードに追加したほうがいいなこりゃ
193:デフォルトの名無しさん
20/07/13 12:29:39.46 LmgOQRQZ.net
荒らしは、どんな時刻でも必ず、前のレスに賛同するアンカーを付けて、2回書き込む。
必ず、大勢の人がいるように見せかける
多くのスレで、死ねと書き込んでいるのも荒らし。
無視した方がよい
Python のスレのテンプレも、勝手に書き換えてる
>当スレに★Python以外のプログラミング言語での回答類を書くべからず★
>「Ruby では」「Rubyでは」「某言語では」をNGワード登録推奨
3大コテハンなど、目立つ香具師には攻撃していくから、無視すべき！
荒らしは、無視されるのが大嫌い
194:デフォルトの名無しさん
20/07/13 12:35:02.51 b4eaK6qk.net
そう思うなら無視しろよ
195:デフォルトの名無しさん
20/07/13 12:47:48.14 ny9O75E1.net
>>191
ID:LmgOQRQZこそがム版で一番嫌われている荒らしなんだわ
196:デフォルトの名無しさん
20/07/13 15:23:06 IlKawd1o.net
reactが老害化してきたね。
うちの会社（そこそこ有名）はvueが主力になった。
197:デフォルトの名無しさん
20/07/13 15:24:46.77 0CEBwLzL.net
世界の潮流に合わせられないゴミのような会社
社員もゴミだからReactが難しくて使えないらしいな
198:デフォルトの名無しさん
20/07/13 16:26:38.51 IlKawd1o.net
難しいとかいう視点でしか判定できない奴ｗｗｗ
199:デフォルトの名無しさん
20/07/13 16:30:52.86 ShQksDAz.net
まんま老害で草
200:デフォルトの名無しさん
20/07/13 16:39:59.00 O/fP36p+.net
Elmでいいじゃん
201:デフォルトの名無しさん
20/07/13 16:42:27.69 wgMdCM9I.net
どっちもSvelteに対応できない老害
202:デフォルトの名無しさん
20/07/13 16:56:21.10 V204cNMI.net
>>152
JSのソース見えても、使う側にはセキュアかどうかなんて分からんから同じ。
それにそもそも、ブラウザ内アプリはサンドボックス化されているので、
マシン本体にはウイルスを感染させることはほぼ不可能。
あるとすればフィッシング詐欺的なものだけで、それもソースが見えるかどうかより、
URLを本物かどうか確認することと、実際にメッセージが出てきた時に本人が気をつければ済む話。
203:デフォルトの名無しさん
20/07/13 16:58:37.13 V204cNMI.net
それにソースがあろうがなかろうが、セキュリティーソフトに取ってみれば、同じ。
むしろ、Wasmのバイナリ形式の方がセキュリティーソフトには解析は楽。
というか、そもそもブラウザがサンドボックスなのでマシンには感染できないし。
204:デフォルトの名無しさん
20/07/13 19:21:02.94 FYVnLaI5.net
もう開発するの疲れたよ。
205:デフォルトの名無しさん
20/07/14 06:59:46.26 GDMj7Uve.net
Reactが老害化してきてるのは間違いない
無駄にバージョン上げるくせに全然進化しないしな
206:デフォルトの名無しさん
20/07/14 09:35:50 bivsLz8c.net
パクリ先が進化してくれないとパクれなくて困るもんなｗｗｗ
207:デフォルトの名無しさん
20/07/14 10:04:52.53 9XrJ6bL4.net
>>202
ころころと変わりすぎるJS界隈のなかでは
変化しすぎないのはむしろいいことだろう
208:デフォルトの名無しさん
20/07/14 10:15:51.07 9XrJ6bL4.net
>>199
WebAssemblyはC#とかでかけるから興味あるんだけど
WebAssemblyメインで作ってる大手サイトってあるのかな？
209:デフォルトの名無しさん
20/07/14 12:31:13 B+3PexkI.net
Vueにチャイナリスクがあるとか懸念されて承認が下りない
210:デフォルトの名無しさん
20/07/14 12:39:39 sTPCx6YN.net
中華製の部品を使えないとなるとパソコンも許可が下りなくなる
211:デフォルトの名無しさん
20/07/14 13:04:29 wxNuZUMy.net
外人は既に、Facebook 製のReact を使っているから、
中国製のVue.js へは移行しない
Reactの日本語訳が、2回表示されるから、ちゃんと直してほしい
それと、Webpack も日本語化してくれ
212:デフォルトの名無しさん
20/07/14 13:32:34.76 Mma3I+br.net
>>203
なるほど判り易い
213:デフォルトの名無しさん
20/07/14 14:48:05.50 UqAnAnhr.net
snowpackが出たからwebpackはオワコン。
チャンク分けが後付けされたとは言え、基本的にひとつのバンドルにまとめるという思想がhttp1.1時代の時代遅れの化石。
加えて設定APIがクソかつすぐ変わるゴミ。
214:デフォルトの名無しさん
20/07/14 14:55:31.21 2Tt/Vrq1.net
そして3年後・・・snowpackはオワコン！
215:デフォルトの名無しさん
20/07/14 16:29:00.65 UqAnAnhr.net
その間webpackとかいうゴミに煩わされることがないからプライスレス
216:デフォルトの名無しさん
20/07/14 16:56:48 jn6Quu/M.net
create-react-app使ってるからwebpackがどうのとかあんまり意識したことないわ
217:デフォルトの名無しさん
20/07/15 00:00:35.08 xU1YmUix.net
React使ってて
create-react-app使ってない人なんているのか
>>208
中国人も外国人。
外人は差別用語なので外国人と呼ぶのが知識人
218:デフォルトの名無しさん
20/07/15 00:05:02.16 Z2+aTjG5.net
>>214
Laravel-Mix使えばなくてもいける
219:デフォルトの名無しさん
20/07/15 00:24:33.30 MbNh6cxA.net
vueがreact化して悲しい
もうreact移行するかな
220:デフォルトの名無しさん
20/07/15 00:32:34.69 xU1YmUix.net
>>215
LaravelってPHPだっけ
PHPで開発しないひとがLaravel-Mix使ってなにかメリットはでてくる？
221:デフォルトの名無しさん
20/07/15 00:40:54 Z2+aTjG5.net
単に↓への回答
>React使ってて
>create-react-app使ってない人なんているのか
222:デフォルトの名無しさん
20/07/15 06:43:28.43 Iul+D8/c.net
>>214
あれって試作とか練習くらいにしか使わないもんだと思ってた。
223:デフォルトの名無しさん
20/07/15 20:24:41.28 anBecQlm.net
Reactってなんとなくかっこいいから初めて見たけど
具体的なメリットって何なの？
ただ単に構築面倒にしてるだけじゃん
224:デフォルトの名無しさん
20/07/15 20:32:39.60 ubc4KaZa.net
SPAが爆速でつくれる
225:デフォルトの名無しさん
20/07/15 20:33:03.40 naaKKVhJ.net
>>220
何と比較して面倒なのか分からん
226:デフォルトの名無しさん
20/07/15 21:14:44.27 Z2+aTjG5.net
>>220
色々部品化進めて行くと段々開発効率が上がってくる
227:デフォルトの名無しさん
20/07/16 00:49:43.48 fGKOjjQM.net
>>223
今までにどんな部品を作りました？
部品はいくつありますか？
228:デフォルトの名無しさん
20/07/16 02:59:26.58 fifr3+U/.net
だから小中規模はvueって言われてるんだろ
229:デフォルトの名無しさん
20/07/16 03:28:32.84 QwF0ci9g.net
Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。
230:デフォルトの名無しさん
20/07/16 03:31:40.20 QwF0ci9g.net
公式リポジトリに日本語ドキュメントあったｗｗｗ
URLﾘﾝｸ(github.com)
231:ja.md
232:デフォルトの名無しさん
20/07/16 04:44:57.61 q8NPRuZD.net
>>220
比較対象を書かないと伝わらない。
Reactはframeworkじゃないから面倒なんじゃないか
Reactは単体だとUIまわりだけのLibraryなわけ。
効率あげるにはFrameworkと併用したほうがいい。
ReactベースのNext.jsというframeworkのtutorialみたら印象変わった。
React使ったweb appはたいていNext.jsも使ってるんじゃないかな
統計データは持っていないが
233:デフォルトの名無しさん
20/07/16 04:59:36.62 fGKOjjQM.net
Reactはframeworkだよ。
フレームワークは他のフレームワークと共存できない
Reactも共存できないのでフレームワーク
234:デフォルトの名無しさん
20/07/16 06:00:59.82 QwF0ci9g.net
React – ユーザインターフェース構築のための JavaScript ライブラリ
URLﾘﾝｸ(ja.reactjs.org)
React
URLﾘﾝｸ(ja.wikipedia.org)
React (リアクト) は、Facebookとコミュニティによって開発されているユーザインタフェース構築のためのJavaScriptライブラリである[3]。
235:デフォルトの名無しさん
20/07/16 06:20:20.62 QwF0ci9g.net
React単体はView部分専業のライブラリ。
フレームワーク で は な い。
ReactをView構築担当パーツとして採用した フ レ ー ム ワ ー ク には以下のようなものがある。
Next.js by Vercel - The React Framework
URLﾘﾝｸ(nextjs.org)<)
Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps
RedwoodJS - Bringing Full-stack to the Jamstack
URLﾘﾝｸ(redwoodjs.com)<)
Redwood is an opinionated, full-stack, serverless web application framework that will allow you to build and deploy JAMstack applications with ease.
これらが フ レ ー ム ワ
ー ク。
236:デフォルトの名無しさん
20/07/16 06:22:09.96 rhL5J6vC.net
>>229
お前の脳みそが現実と共存できてないだけだったなｗｗｗ
237:デフォルトの名無しさん
20/07/16 06:50:19.00 Tpmfh3cP.net
React単体だと新規アプリの書きはじめは少し面倒だね
デザイナーがいる場合は特に
すでにあるものをいじるのはめちゃくちゃ楽だけど
238:デフォルトの名無しさん
20/07/16 07:16:19.31 q8NPRuZD.net
>>229
違う
ReactはframeworkではなくLibraryだ
公式にもそうかいてあるし
実際にUIまわりの機能しか持ってない
web frameworkと呼べるほどの機能はない
だからReact単体で開発しようとしたら
めんどくさいのは当たり前なの
Frameworkに相当する機能が揃ってない
239:デフォルトの名無しさん
20/07/16 07:27:36.37 ZNt3NFO3.net
>>234
reduxとかrouterとか定番のセットを組み合わせれば十分だし別に面倒と言うような事はない
240:デフォルトの名無しさん
20/07/16 07:31:43.65 3QdZwCAR.net
routerくらいだろ、必須なのって
小・中規模のアプリなら状態管理はhooksの機能で十分
241:デフォルトの名無しさん
20/07/16 10:06:56.10 smD3FpeB.net
jQueryで十分！
→だからjQueryはフレームワーク！！
lodashで十分！
→だからlodashはフレームワーク！！
242:デフォルトの名無しさん
20/07/16 12:07:04.89 J/CG/YnB.net
フレームワークは、Next.js とか
React は単なる、UI ライブラリ・部品だから、
Ruby on Rails, Bootstrap と組み合わせる
一方、Rails + Vue.js は、ほとんど見ない
243:デフォルトの名無しさん
20/07/16 12:07:14.26 ZNt3NFO3.net
何かを作るのに十分云々じゃなくてフレームワークの構成要件として十分かどうかの話
>>237は状態管理やルーティング以前にライフサイクルもないだろ
244:デフォルトの名無しさん
20/07/16 14:10:46.45 wMaulIJo.net
Next → フルスタックフレームワーク
React・Vue → マイクロフレームワーク
Angular → ？
245:デフォルトの名無しさん
20/07/16 15:24:46.50 8zSSWZDX.net
ザコはすぐ造語作りたがるなｗｗｗ
強制連行ｗｗｗｗマイクロｗフレームワークｗｗｗｗｗ
246:デフォルトの名無しさん
20/07/16 16:49:40.17 wMaulIJo.net
いや俺が作った単語じゃねーぞ
wikipediaにも載ってるし
247:デフォルトの名無しさん
20/07/16 17:29:18.20 QwF0ci9g.net
本当に愚か者だな、お前は。
URLﾘﾝｸ(en.m.wikipedia.org)
マイクロフレームは、ミニマリスティック ウェブ アプリケーション フレームワークを指すために使用される用語である。フルスタックフレームワークとは対照的です。
次のような本格的なWebアプリケーションフレームワークで期待される一般的な機能のほとんどが不足しています。
- アカウント、認証、承認、ロール
- オブジェクトリレーショナルマッピングによるデータベースの抽象化
- 入力のバリデーションとサニタイゼーション
- Webテンプレートエンジン
通常、マイクロフレームワークは、HTTPリクエストの受信、適切なコントローラーへのHTTPリクエストのルーティング、コントローラーのディスパッチ、HTTPレスポンスの返送を容易にします。Microframeworksは、多くの場合、別のサービスまたはアプリケーションのAPIを構築するために特別に設計されています。[1]たとえば、Lumenマイクロフレームワークは、マイクロサービス開発およびAPI開発用に設計されています。
マイクロフレームワークス
- PythonのBottle
- RubyのCamping
- Node.js用のExpress.js
- Python用Falcon
- Python用Flask
- ScalaのScalatra
- PHP用Lumen
- PHP用Slim
- PHP用のSilex
- RubyのSinatra
…
なんでこの説明読んでreactがマイクロフレームワークになるんだ？
テンプレートエンジンの代わりになるからか？
じゃあ認証ライブラリはマイクロフレームワークか？
ORMライブラリはマイクロフレームワークか？
バリデーションライブラリはマイクロフレームワークか？ええ？
英語読めなかったのか？あん？
読めないにしても翻訳機能使う知恵もなかったか？
248:デフォルトの名無しさん
20/07/16 18:14:37.53 q8NPRuZD.net
>>242
wikipediaなんて誰でも編集できるし
分類なんて人それぞれ
ReactはFacebookがLibraryといってるんだからそれで確定だ。
249:デフォルトの名無しさん
20/07/16 19:17:30.88 N/WMVO7e.net
公式見解を尊重する限り、
Vue → framework
React → library
Angular → framework
ってことになるな
250:デフォルトの名無しさん
20/07/16 20:36:35.64 GDWqXa2M.net
ちなみに僕の公式見解は
僕 → Zetsurin
だよ。
251:デフォルトの名無しさん
20/07/16 21:53:24.18 ThZ5aiRV.net
reactはライブラリなのかフレームワークなのかquoraで聞いてみようぜ
って思ったら英語版にはすでに質問あったわ
252:デフォルトの名無しさん
20/07/16 21:54:17.77 N8xKeP5m.net
>>228
比較対象はネイティブJavaScript
ただ単にDOM操作するだけだぜ？
ビルドいる？
ネイティブJavaScriptがそんなにもっさり重いの？
なんもコマンド叩かずにコーディングできるんだよ？
HTMLに直接書けるんだよ？
253:デフォルトの名無しさん
20/07/16 21:56:41.55 q8NPRuZD.net
人によってはframeworkに分類しちゃうけど
公式がLibraryと言っている以上、Libraryなのだ。
routingすらないReactをweb frameworkと呼ぶには無理がある
254:デフォルトの名無しさん
20/07/16 22:01:28.47 q8NPRuZD.net
>>248
え、frameworkもLibraryもTSも使わず
生のJSでちっぽけなアプリ書いてる人だったのか
そんなやり方でまともな中規模以上のアプリ作れない
生産性が低すぎる
いまどきHTMLに直接コード書くなんて論外だろう
255:デフォルトの名無しさん
20/07/16 22:07:09.50 N8xKeP5m.net
>>250
単なるGUI制御がHTMLに組み込んで何が悪いか
じゃあお前がどんだけグレートな規模のプロジェクト
手がけてるか紹介してみろやカスが
256:デフォルトの名無しさん
20/07/16 22:32:35.09 wMaulIJo.net
>>248
そりゃカップラのタイマーにReactはオーバースペックだろ…
257:デフォルトの名無しさん
20/07/16 22:35:03.43 ThZ5aiRV.net
もしgmailのフロントを生JSで書けって言われたら逃げるわ
258:デフォルトの名無しさん
20/07/16 23:21:28.07 5vmd5oHm.net
自分でJavaScriptのライブラリ作ればいいんやで！
259:デフォルトの名無しさん
20/07/16 23:23:56.85 3r6uNJIb.net
名前はoreoreactにしよう
260:デフォルトの名無しさん
20/07/17 00:12:04.02 HKFGOVIo.net
Blazor面白いね
あとは読み込み速くなればJS要らなくなる
261:デフォルトの名無しさん
20/07/17 00:41:47.48 rScYk2f8.net
ブラジャー？
262:デフォルトの名無しさん
20/07/17 00:57:10 5L8OAF1I.net
流石にIIS依存のものはなぁ…
263:デフォルトの名無しさん
20/07/17 01:02:45 d4gKLDNu.net
adobe airのときもsilverlightのときも同じこと言ってたよそいつ。
懲りない奴だｗ
264:デフォルトの名無しさん
20/07/17 01:46:03 OVoiSg0p.net
>>258
何言ってんのこいつw
265:デフォルトの名無しさん
20/07/17 08:38:22.72 Mcc/Kfhl.net
>>258
昔の知識のままの人か？
Blazorも.net Core対応と書いてあるし
.net CoreならLinuxやMacでも動くはずだ
Blazorのhelpにもapacheとかがかいてある
266:デフォルトの名無しさん
20/07/17 08:41:05.93 5L8OAF1I.net
いうてもApacheでASP.NETとか使ってるヤツ居るの？
267:デフォルトの名無しさん
20/07/17 08:50:27.95 wFTyM9Vl.net
今から使い始めるならIISよりはapacheだろ
268:デフォルトの名無しさん
20/07/17 08:58:36.98 Mcc/Kfhl.net
>>262
言い訳する前に知識が古かったのを認めろよ
Linuxでasp.net使いたいニーズがあったからこそ対応したんだろ
ApacheだけでなくNginxもかいてある
URLﾘﾝｸ(docs.microsoft.com)
あとweb frameworkで一番シェア高いのはASP.NETだぞ
WordPressとか間接的にframework使ってるの除いたらシェアトップ
269:デフォルトの名無しさん
20/07/17 09:12:02 HKFGOVIo.net
>>262
うちはnginx, asp.net core api, asp.net core MVC+Vue
270:デフォルトの名無しさん
20/07/17 10:23:29.59 rScYk2f8.net
>>263
この文脈でIISとApacheを比較するのかよ・・・
この文脈でのIISはWebサーバーとしての側面ではなくアプリケーションサーバー（.NETコンテナ）としての話だろ
比較するならApacheやnginxではなくTomcatやGlassFishだと思うが
271:デフォルトの名無しさん
20/07/17 10:32:08.75 Mcc/Kfhl.net
>>266
おまえもApacheやnginxでASP.net Coreが
動かないと思ってるのか？
272:デフォルトの名無しさん
20/07/17 10:36:10.93 4woZuOkK.net
Blazor ServerってSSRだよな
このスレに関係ないじゃん
273:デフォルトの名無しさん
20/07/17 10:37:15.19 Mcc/Kfhl.net
>>265
OSとDatabaseは何使ってるの？
遅いのは最初の読み込みだけ？
Microsoftのデモ動画みたら動作も遅いように見えた場面が
あってパフォーマンスどうなのかなと。
WebAssemblyでいい性能出るならC#で書きたい
JSもTSもめんどくさい
274:デフォルトの名無しさん
20/07/17 11:00:42.67 rScYk2f8.net
>>267
Apacheやnginxでは.NETは動かないだろ？
まさかなーと思って今調べてみたけどやっぱり動かないみたいだぞ
検索してみると出てくるのはdotnet runでポート5000をリッスンさせてApacheやnginxをリバースプロキシとして表に立たせる構成ばかりだ
これはdotnet runプロセス自体がアプリケーションサーバーの役割を担ってるだろ？
Apacheやnginxで.NETが動くのとは程遠い話だ
俺がまだ勘違いしてるのか？
もしApacheで.NETが動くというのならmod名とか教えてくれ
275:デフォルトの名無しさん
20/07/17 11:21:27.37 afn+PT1M.net
>>267
すまんがASPに対しては負の遺産という印象しかない
276:デフォルトの名無しさん
20/07/17 11:26:49.33 afn+PT1M.net
>>270
それ言ったらnginxでphp使う方法と変わらんからASP厨がドヤ顔でえばるだけやぞ
277:デフォルトの名無しさん
20/07/17 11:35:17 rScYk2f8.net
PHPとかnginxのことは知らんのだけど
Apache + PHP だとCGI（別プロセス）で動かすのではなく、Apacheプロセス内で動かす専用modとかあるんでしょ？
そのくらい特化してたらApacheで動くと言ってもいいと思うが
リバースプロキシ立てただけで「Apacheで動く」は恥ずかしいよ
278:デフォルトの名無しさん
20/07/17 12:08:02.38 hTUFpXFi.net
>>273
nginxの場合php-fpmっていう別サービスを立てて
nginxのリバースプロキシでポートもしくはソケット経由でphpのリクエストをphp-fpmに渡す様な形式
279:デフォルトの名無しさん
20/07/17 12:30:36.62 p1TzKNxq.net
>>269
RDBはポスグレ
起動も思ったより早いよ
リクエストはまじで爆速
280:デフォルトの名無しさん
20/07/17 12:36:31.61 rScYk2f8.net
>>274
ありがとう
nginx + PHPにもphp-fpmという専用のFastCGI機構があるのね
ここまで特化してたらnginxでPHPが動くと言ってもいい
だがdotnet runは構成がまったく違う
Apacheやnginxはdotnet runを特別に扱ってないし関知もしてない
やはりApacheやnginxで.NETが動くとは言えないな
281:デフォルトの名無しさん
20/07/17 13:17:03 HR6IsBOl.net
スレタイ読めないのかな？
npm trends
URLﾘﾝｸ(leerob.io)
282:デフォルトの名無しさん
20/07/17 13:23:21 PZ71VWVR.net
>>277
angularと@angular/coreの違いについて頼む
283:デフォルトの名無しさん
20/07/17 14:16:04.30 Mcc/Kfhl.net
>>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単体で動かしてもいい
おそらくそれが最速になる
284:デフォルトの名無しさん
20/07/17 14:35:49.91 rScYk2f8.net
kestrel(dotnet run)を否定しているわけじゃないよ
それは単体でHTTPを話す能力を持ってるじゃん
つまりTomcatやGlassFishと同じ位置付け
Apache、nginx等のWebサーバーを手前に追加するもしないも自由
でもそれは「Apacheで.NETが動く」という話にはならない
285:デフォルトの名無しさん
20/07/17 14:45:14.98 Mcc/Kfhl.net
>>273 >>280
従来型のASP.netはModとかFastCGI対応していた。
Linuxでうごくこういうやつがあった
URLﾘﾝｸ(www.mono-project.com)
Monoは互換性がいまいちなので個人的にお勧めしない
ASP.net CoreをKestrel単体またはKestrel+(Nginx or Apache or IIS)
で動かすのが今のMicrosoft推奨のやりかた。
高速に動くなら内部の仕組みはどうでもいい話だろう？
あとは重要なところでLinuxで動いてライセンス無料になってるんだし
Modがあるかなんてどうでもいいよ。
そもそもApacheは高速なWeb serverじゃないの知ってるの？
あえてApache選ぶ理由がないよ。
大規模サイトはNginxが多い
286:デフォルトの名無しさん
20/07/17 14:48:05.03 Mcc/Kfhl.net
>>280
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ
.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから
287:デフォルトの名無しさん
20/07/17 14:49:01.58 bZMoLlJz.net
Apacheに乗せるなんて無駄なことしたくない
Nginx RP + Inproc Httpがスマートで最高
288:デフォルトの名無しさん
20/07/17 14:55:32.14 rScYk2f8.net
静的コンテンツのレスポンス高速化のためだけにリバースプロキシ（Apache, nginx）置くわけじゃないから
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない
289:デフォルトの名無しさん
20/07/17 15:02:52.55 bZMoLlJz.net
最近はApacheを知らない若者も居るようだ
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい
290:デフォルトの名無しさん
20/07/17 15:46:01.13 Q8AVDrqq.net
Nginx は、リバースプロキシ
世界最速は、Ruby on Rails 製の
URLﾘﾝｸ(dev.to)
これよりも速いものは、作れない
291:デフォルトの名無しさん
20/07/17 19:01:29 gHhKsxDc.net
最近JIT対応したPHP8のalpha版が結構いいスコア出してるそうだがな
292:デフォルトの名無しさん
20/07/17 21:28:04.44 LPqky/1r.net
>>278
angularは1系で@angular/coreは2以降じゃないかな
しっかしReact圧倒的だね
293:デフォルトの名無しさん
20/07/17 21:55:04.26 XQc3SgYX.net
1系ってAngularJS表記なんだと思ってたがそうじゃないのか
294:デフォルトの名無しさん
20/07/17 22:04:00.19 5B+Amw9H.net
Reactってjadeと互換性あるの？
HTMLや動的テンプレファイル上に
直で書くとサーバ変数そのままJavaScriptに
埋め込んでコーディングできるから
.jsファイルの外部化は個人的にかなり抵抗感がある
295:デフォルトの名無しさん
20/07/17 23:32:34.52 pbRdpk23.net
フロントエンドのライブラリだというのに
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん
296:デフォルトの名無しさん
20/07/18 00:18:41.79 lkZeEJlA.net
>>287
PHPは言語がうんこすぎて
ベンチマークいくらよくても使う気にならない
297:デフォルトの名無しさん
20/07/18 00:25:43.24 Rz8uT7Q+.net
phpはhtmlに直接サーバーサイド変数を埋め込めるという点で負の遺産を残しすぎた。
wordpressだのsmartyだの吐き気するわ。
298:デフォルトの名無しさん
20/07/18 01:02:58.86 mlew4XCO.net
>>293
それの何が悪いの？
299:デフォルトの名無しさん
20/07/18 01:08:32.40 5AaucbBP.net
バックエンドなんてフレームワークで構成してJSONやり取りするもんだからそんなの別に気にする事じゃないだろ
300:デフォルトの名無しさん
20/07/18 02:09:48.73 lkZeEJlA.net
>>275
PostgreSQLか
爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも
C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？
301:デフォルトの名無しさん
20/07/18 02:21:16.88 N4WthBbf.net
> React+Next.js勉強やめて
勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ
302:デフォルトの名無しさん
20/07/18 02:39:54.52 lkZeEJlA.net
>>297
俺が何時間やったかも書いてないのにそんなレスつけてしまうおまえが頭悪い
あと頭いい人はそうやって文末にwつけないしアンカーをつける
303:デフォルトの名無しさん
20/07/18 04:07:12.10 N4WthBbf.net
なるほどつまり数時間やって分かんなくて嫌になってwasmならできるモン！ってことか。説明ご苦労。
そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ
304:デフォルトの名無しさん
20/07/18 08:45:31.60 5AaucbBP.net
WebAssemblyに夢見過ぎなヤツ多いな
そんなに速度が必要な事をやってるのかと
305:デフォルトの名無しさん
20/07/18 09:04:24.26 lkZeEJlA.net
>>300
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる
夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。
実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う
306:デフォルトの名無しさん
20/07/18 09:10:26.95 huqpRUrM.net
Blazorはサンプル動かすまで超簡単
あれこれ聞く前に自分で試したほうが早いよ
dotnet sdkの最新版を落としてインストールしたら
dotnet new blazorwasm
dotnet run
これだけでBlazorが動く
頭の悪い大量の設定を書く必要はない
小学生やお猿さんでも簡単にできる
ちな↑は完全に静的なサイトを作りたいとき
サーバーサイドAPIも作りたいなら
dotnet new blazorwasm --hosted
dotnet run
これでおｋ
サーバーサイドレンダリングしたいなら
dotnet new blazorserver
dotnet run
これでおｋ
307:デフォルトの名無しさん
20/07/18 09:10:56.66 5AaucbBP.net
>>301
ECでボトルネックになるのは大体の場合サーバーサイドだろ
308:デフォルトの名無しさん
20/07/18 09:13:11.20 lkZeEJlA.net
>>299
根性とかアホじゃないか
C#やJavaで開発してきた人がTSの開発を理解できないわけがない
309:デフォルトの名無しさん
20/07/18 09:28:04.98 lkZeEJlA.net
>>303
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど
速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？
310:デフォルトの名無しさん
20/07/18 09:33:43.74 Zsjd19dY.net
wasmの求人需要ってある？
311:デフォルトの名無しさん
20/07/18 09:41:11.98 a72QTQ2S.net
1ミリもない
312:デフォルトの名無しさん
20/07/18 09:48:13.03 37eL7IOf.net
自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ
313:デフォルトの名無しさん
20/07/18 10:09:29.41 N4WthBbf.net
>>304
根性じゃなきゃやっぱり頭のほうかｗ
数時間かけても理解できずに止めたんだろ？なんかゴメンなｗｗｗ
314:デフォルトの名無しさん
20/07/18 10:18:52.49 5tCG/Slu.net
理解できないことはないんだろうけど
拒否反応を起こす人は結構いるね
JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし
315:デフォルトの名無しさん
20/07/18 11:01:01 fwbEJCvA.net
>>301
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？
今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる
「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？
316:デフォルトの名無しさん
20/07/18 11:07:30 fwbEJCvA.net
>>305
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。
WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い
317:デフォルトの名無しさん
20/07/18 11:20:03 fwbEJCvA.net
WebAssemblyはどんな問題（課題）を解決するのかを答えられないようじゃ
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。
WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ
つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない
318:デフォルトの名無しさん
20/07/18 11:23:08 oiSxLKa2.net
wasmでVM動かしてる状況だとまだ劇的に速いとは言えないのでは
wasmのGC実装もこれからだし流石に時期尚早感がある
319:デフォルトの名無しさん
20/07/18 11:28:21 5tCG/Slu.net
JavaScriptだってネイティブ実行されてるわけじゃなくJITコンパイルしながら実行されてるでしょ
wasmのVMが大きなオーバーヘッドだとは思わないけどな
320:デフォルトの名無しさん
20/07/18 11:29:28 Z+cMIoZ7.net
>>313
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！
321:デフォルトの名無しさん
20/07/18 11:33:48 fwbEJCvA.net
>>316
そんな人もいるんだからって言いたいの？ｗ
322:デフォルトの名無しさん
20/07/18 11:49:48 zDePOjuW.net
jsをwasmにコンパイル出来たら爆発的に普及しそうなんだが、いまだにまともにできないんだよな。
323:デフォルトの名無しさん
20/07/18 11:54:20 Z+cMIoZ7.net
>>317
そうですワタシが変なおじさんです。
応答速度がどうのこうのと言う話の流れを見てますと
WebブラウザのSPAで3次元CADも出来る時代になったのだなあと感慨に老けっております。
324:デフォルトの名無しさん
20/07/18 11:59:32 fwbEJCvA.net
>>319
論点はそこじゃなくて、
「3次元CADやるなら別にブラウザじゃなくていいよね」
だから
なぜわざわざ遅いとわかってるブラウザで動かすのか？
ブラウザで動かさなきゃいけない使命でもあるの？
325:デフォルトの名無しさん
20/07/18 12:07:43.56 OjEg02/9.net
jquery bootstrap Vue React angular
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！
326:デフォルトの名無しさん
20/07/18 12:18:23.75 Z+cMIoZ7.net
>>320
時代はリモートでコラボれーしょんやら？
WebVRで3Dチャット元年ではなかったのかと・・・
327:デフォルトの名無しさん
20/07/18 12:25:07.68 huqpRUrM.net
VS+C#の快適さに比べたらJSやTSなんてゲロ以下でしょ
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー
328:デフォルトの名無しさん
20/07/18 12:27:17.68 a72QTQ2S.net
vscode + js のウルトラ開発体験知らんのか？
329:デフォルトの名無しさん
20/07/18 12:28:49.89 5AaucbBP.net
>>323
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない
330:デフォルトの名無しさん
20/07/18 12:29:31.05 huqpRUrM.net
>>324
VSCodeは不安定すぎて話にならんわ
331:デフォルトの名無しさん
20/07/18 12:31:33.52 huqpRUrM.net
>>325
宗教上の理由でIDEを避けたいならそうすればいい
Blazorも例に漏れずVScodeでもVimでもなんだって開発できる
ま、VSが最強なので他はオススメはせんがね
332:デフォルトの名無しさん
20/07/18 12:33:55.33 cNrPu/ON.net
VSおじさんｗ
Silverlightはどうなりましたかｗ
333:デフォルトの名無しさん
20/07/18 12:40:21.88 fQsuqJMx.net
wasm(たとえばC#)って画面描画どうやってやるの？
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？
wasm詳しい人教えてくれ！
334:デフォルトの名無しさん
20/07/18 12:50:44.89 cNrPu/ON.net
まだ直接DOMいじれない。
将来的にも解放されるか微妙。
なので描画はふつうにjs側でやってるｗ
335:デフォルトの名無しさん
20/07/18 12:53:18.24 5tCG/Slu.net
え、DOMいじれずC#(WPF)で描画もだきないのか
結局、JavaScript使わないといけないんじゃ微妙ね
ブラウザ画面全体をキャンバスとしてWPFで描画させて欲しいわ
336:デフォルトの名無しさん
20/07/18 12:55:00.61 hYOY3gDK.net
>>328
この返しは恥ずかしすぎる
337:デフォルトの名無しさん
20/07/18 12:55:34.30 hYOY3gDK.net
>>329
Razorマークアップ
338:デフォルトの名無しさん
20/07/18 12:56:00.12 hYOY3gDK.net
>>331
JSは要らんよ
339:デフォルトの名無しさん
20/07/18 12:56:27.32 cNrPu/ON.net
でもそのwasmの外にあるjsへの指示・管理はフレームワーク側の仕事だからあなたが直接dom api叩く必要はない
340:デフォルトの名無しさん
20/07/18 13:00:40.40 fwbEJCvA.net
>>322
> 時代はリモートでコラボれーしょんやら？
> WebVRで3Dチャット元年ではなかったのかと・・・
だからブラウザ使わなくて出来てるでしょｗ
341:デフォルトの名無しさん
20/07/18 13:02:21.10 fwbEJCvA.net
>>329
ブラウザの中に仮想マシンが実装されたと考えれえばいい
表示はブラウザの中の一部分が仮想マシンのウインドウになったようなもの
その中で何でも出来る。その中でしか動かない。
342:デフォルトの名無しさん
20/07/18 13:06:46.63 u6Nb4/2q.net
ブラウザのDeveloperToolでデバッグできる？
343:デフォルトの名無しさん
20/07/18 13:08:43.45 fwbEJCvA.net
JavaScriptもJITとか使うから計算とかならネイティブとほぼ同じ速度で動くんだよ
問題はDOMで複雑なレンダリング処理が入るからどうしても遅くなる
それはWebAssembly使っても同じななわけ
DOMの複雑なレンダリングアルゴリズムが原因だから
それは避けようがない。
しかしもともとは画面表示なんて縦横のビットマップでしかなかったわけで
DOMのレンダリングを避けて、直接描画しましょうっていうのがWebAssembly
DirectXの思想と似てるね。WebAssemblyの目的はレガシー技術の移植だから
DOMは必要ない。なのでWebAssemblyからDOMを直接さわれるようなことはないよ
間接的に触れればOK。
画面部分は遅いけどメンテナンスしやすい言語、速度が必要なのはDLLという
昔のVB+VCによる開発と同じようなことをウェブの世界で繰り返してるだけ
344:デフォルトの名無しさん
20/07/18 13:39:15.04 5tCG/Slu.net
wasmの画面描画について答えてくれてありがとう
DOMいじらなくてもいいのね興味出てきたわ
あとwasmでマルチスレッドは使える？
JavaScriptって長年マルチスレッド使えなかったじゃん
Web Workerという仕組みも出てきたけとJavaやC#で扱う普通のスレッドとはちょっと違うよね
wasmは普通にマルチスレッド使えるの？（C#のThread関連API使えるの？）
あとソケットAPIもC#で使えるのかな？
そこまでできるならwasm移行したいわ
345:デフォルトの名無しさん
20/07/18 13:42:32.30 fwbEJCvA.net
外部との通信やファイルアクセスやI/OはブラウザのAPIエミュレートされる
つまりブラウザで出来ることは出来るしブラウザでできないことはできない
スレッドもWeb Workerを使ってエミュレートされる
なのでそういったものはネイティブに比べて遅くなる
346:デフォルトの名無しさん
20/07/18 13:44:42.37 fwbEJCvA.net
そういうI/O系はJavaScript APIを使ってエミュレートされるので
JavaScriptから直接使ったほうが速いというね
WebAssemblyが速いのはCPUとメモリアクセスでできる処理のみ
347:デフォルトの名無しさん
20/07/18 13:48:10.88 zDePOjuW.net
wasmの画面表示って結局jsと同じDOMかWebGLじゃね？
348:デフォルトの名無しさん
20/07/18 13:58:51.62 fwbEJCvA.net
>>343
そうだよ。DOMは1ピクセル単位で描画できない
（CSSのposition: absoluteとか使えばできなくはないけど
ドットごとにDOM要素が必要になる）
だから実質WebGL一択でしょう
wasmから（仮想的な）ディスプレイのドットに点を打つと
それがWebGLの命令で描画される
349:デフォルトの名無しさん
20/07/18 14:54:17.15 5tCG/Slu.net
wasmおもしろそうだな
いっちょさわってみるか
350:デフォルトの名無しさん
20/07/18 14:59:20.43 OjEg02/9.net
>>334
そんなものオタクしか興味ねーよ
手軽さとか互換性問題が起きない方がよっぽど大事
351:デフォルトの名無しさん
20/07/18 15:00:47.66 lkZeEJlA.net
>>302
ありがとうメモした
Blazor WebAssemblyは.net core SDK 3.1で正式サポートされたようだから
productionに使えるレベルになってるはず、なので
たまってるアニメ見終わった後でやってみる。
352:デフォルトの名無しさん
20/07/18 15:01:01.32 zDePOjuW.net
ああ、言いたかったのは描画に関しては結局jsと変わらんだろうということ。
Canvas APIやWebGL APIを呼ぶだけだしね。
353:デフォルトの名無しさん
20/07/18 15:03:36.80 lkZeEJlA.net
>>306-307
すぐBlazorやりたければ自分で作った会社で開発してマネタイズすればいい。
今までにC#でASP.netの開発やってる企業なら近いうちにBlazorの案件始めるよ
JSに比べて開発生産性高いのだからBlazorやらない理由がない
>>310
C#になれてるとdynamic languageへの拒否反応はたしかに強い
開発の生産性が低すぎるんだもの
354:デフォルトの名無しさん
20/07/18 15:08:26.33 lkZeEJlA.net
>>311
普通に使えてるのはそのスマートフォンの性能に
合わせて開発してるからに決まってるだろうｗ
なぜSPでネイティブアプリがあるかっておもに性能だろう
パフォーマンス重要な用途がわからない？？
開発者でそれが思い浮かばない人っているんだね
ハイパフォーマンスということはわざわざAndroidやiOSの
アプリつくって売上の30%ぼったくられなくても
Blazorでゲーム作って稼ぐようなこともできる。
それくらい思い浮かばないかふつう。
パフォーマンスめちゃくちゃ大事
355:デフォルトの名無しさん
20/07/18 15:28:43.67 fwbEJCvA.net
>>350
> なぜSPでネイティブアプリがあるかっておもに性能だろう
違うよ。ネイティブアプリの自由度の高さと
スマホ標準インターフェースとの統合
356:デフォルトの名無しさん
20/07/18 15:35:33.35 lkZeEJlA.net
>>312
Blazorだとclient, severの両方をC#でかけるから
開発生産性が高い
という当たり前の話が前提としてある
Blazorでは既存のJS libraryは使えるがJS開発はおまけ
自分で開発するのは主にC#
node.jsはbrowserがJSだからserverも同じ言語だと効率がいいっていう
理屈で作られたものだろう
しかしJS自体がうんこなのでnode.jsはserver sideもうんこ言語で
開発することになる
357:デフォルトの名無しさん
20/07/18 15:40:33.50 lkZeEJlA.net
>>313
あほらしい
JS自体がレガシーそのものだろう。
あんなもの開発者は望んでいない
その証拠にType safetyなTypeScriptが人気になってる
server sideまでうんこ言語（JS)やその改善版（TS)で
開発する時代がいつまでも続くと思うか？
俺は全く思わない
好きな言語で開発できてパフォーマンスがいいWasmが当たり前になるさ
358:デフォルトの名無しさん
20/07/18 15:43:26.01 lkZeEJlA.net
>>318
JSってType safetyじゃないだろ
もともとcompileと合わないうんこ言語だからどうしようもない
C#とかに変えればいいだけだ
359:デフォルトの名無しさん
20/07/18 15:47:48.54 lkZeEJlA.net
>>320
だからそのBrowserが遅いのはcompileされてないJS
とかを実行してるからという要因が大きいわけだが
それすらわかってないようだ
wasmならnative codeが走るからかなり速くなる
用途が広がる
それでiOSやAndoriod app作らなくてよくなるとしたら
とんでもない開発生産性の向上だ
360:デフォルトの名無しさん
20/07/18 15:52:34.71 lkZeEJlA.net
>>328
そういうアホな質問はいたるところで論破されてる
SilverlightとちがってWebAssemblyはstandardなの
普及しない理由がないの
361:デフォルトの名無しさん
20/07/18 15:54:43.54 VwC7Y7IV.net
まあなんにせよいつまでもJS、TSにしがみついてるのはエンジニアとしてリスキーだよね
サーバーサイドエンジニアが嫌々ながらJS、TSを習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た
362:デフォルトの名無しさん
20/07/18 15:54:46.28 lkZeEJlA.net
>>329
URLﾘﾝｸ(docs.microsoft.com)
363:デフォルトの名無しさん
20/07/18 16:41:05.47 5tCG/Slu.net
>>358
ざっと読ませてもらったけどblazorマークアップでdivタグとか出てきてちょっと萎えた
抽象化されてはいるけどやっぱDOMツリーを意識させられちゃうのね
ピクセル描画なんて話が出ていたからWinFormsやWPFの作り方でブラウザに画面出せるのかと期待してしまった
これはC#経験者でもblazorでのUI構築を学ばないといけないね
blazorが生き残ってくれるのならいいけどWebフロントエンドは死屍累々だから怖い
364:デフォルトの名無しさん
20/07/18 16:44:31.11 fwbEJCvA.net
なんでクライアントとサーバーで同じ言語で作ったほうが
生産性が良いと思ってるんだろ？
SQL使わんのか？別の言語だぞ？
365:デフォルトの名無しさん
20/07/18 16:44:51.36 fwbEJCvA.net
>>357
お前は何の言語にしがみついてるんだ？ｗ
366:デフォルトの名無しさん
20/07/18 16:51:43.65 5tCG/Slu.net
>>360
クライアントとサーバーで同じ言語使えたほうが学習コストが低くなるじゃん
JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
おれはSQL併用するけどSQL使わない勢も実際にいるよ
ORMの自動生成クエリーだけでなんとかするっていう
逆にSQLでビジネスロジック全部やりたい勢もいるストアド大好きな人達
ソフトウェアって自由でいいな
367:デフォルトの名無しさん
20/07/18 16:53:18.15 fwbEJCvA.net
>>3
368:59 UIをコードで書くならDOMベースが一番適してるんだよ HTMLかXMLかそれに近いマークアップ言語 その例外がゲームとかCADとか点や線ベースでの インターフェースを持っているもの 具体的に言えば、点や線が目まぐるしく変わるもの
369:デフォルトの名無しさん
20/07/18 16:56:29.69 fwbEJCvA.net
>>362
> JavaScript勢もそう考えてるからサーバーでnode.js使ってるんじゃないの？
RubyやPython使ってるだろ
目的に応じて適切な言語使ってるんだよ
370:デフォルトの名無しさん
20/07/18 17:11:56.84 UMJ4s/bl.net
nodeは立ち上がりが軽くて速くてスケール時に使い捨てしやすいからだろう。
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
URLﾘﾝｸ(levelup.gitconnected.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
.NET遅っそｗｗｗ重っもｗｗｗｗ
371:デフォルトの名無しさん
20/07/18 17:32:39.93 vLQD9afh.net
>>344
WebGLでもDOMのように階層持たせることはできるの？
俺は3Dゲーム作っていたんだが、あんな感じでポリゴンみたいにして作るのかな
今イチわからん
372:デフォルトの名無しさん
20/07/18 17:43:52.38 lkZeEJlA.net
>>359
Blazorもweb appだからHTMLとCSSの世界は当然あるよ
でも、ReactのJSXよりは可読性高いと思うよ
WPFはXAMLだっけ、あれはXMLの方言みたいなやつだよね
Blazorで再利用可能なUI componentが公開されてるから
カレンダーみたいな複雑なcomponentはコピペで使えると思うよ
C#みたいなドラッグ＆ドロップまではいかないけど十分かんたんでしょう
373:デフォルトの名無しさん
20/07/18 17:46:29.08 vfrpqE6H.net
>>366
WebGLはDOMの一要素canvasを仮想的なディスプレイと見立てて
その中にOpenGLの命令で自由に描画するもの
374:デフォルトの名無しさん
20/07/18 18:54:17.02 162OGkYI.net
>>359
WPFじゃないけどXamlでWeb開発可能らしいね
個人的にはよく知らんけどWinUIとかいうやつ
375:デフォルトの名無しさん
20/07/18 18:56:30.00 162OGkYI.net
間違えたWinUIじゃなかったUnoだ
376:デフォルトの名無しさん
20/07/18 19:26:35.55 5AaucbBP.net
>>336
あーもうそれこのスレ関係ないって事だよね
専用スレ立てればいいのにね
377:デフォルトの名無しさん
20/07/18 19:30:44.95 5AaucbBP.net
あんじゃん
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
ｽﾚﾘﾝｸ(tech板)
378:デフォルトの名無しさん
20/07/18 20:42:52.64 Rz8uT7Q+.net
wasmで処理速度が上がるのか知らんけどコンパイルされるわけだからネイティブコードよりも転送量増える理屈だよな。
速度目的に使うんじゃなくて互換目的に使うのが本来の用途だろ？
379:デフォルトの名無しさん
20/07/18 21:47:01.74 5tCG/Slu.net
そうですね
ランタイム環境（VM）の転送というオーバーヘッドもあるので新規開発ではなく既存資産わ流用したい場合にwasmなのかなって気がする
だけどwasm使ってもUI周りは流用できずに作り直しになるようなのでモヤっとする
UI周り作り直しになるなら他の選択肢（JavaScript等）も視野に入ってくる
380:デフォルトの名無しさん
20/07/18 22:58:32.39 lkZeEJlA.net
>>373
コンパイルされたものがBrowserに配られる
本番環境用にサイズを小さくするオプションもあるし
browser にcacheされるから2回目以降は速い。
demoみてもその辺は考慮されて設計されてるかんじ
最初は遅いのはPWAとかSPAでも同じでしょ
>>374
VMまるごと転送するなんてどこにも書かれてないし
そんなことやるとは思えない
Wasmで共通のバイナリはBrowser updateのときに入るでしょ
381:デフォルトの名無しさん
20/07/18 23:16:25.72 lkZeEJlA.net
>>373
速度はあがるし目的としても書かれてる
URLﾘﾝｸ(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なんてあるわけないだろうｗ
382:デフォルトの名無しさん
20/07/19 00:48:48.05 xggXZiaY.net
URLﾘﾝｸ(qiita.com)
> WebAssembly側から直接Domを操作することは出来ない。そのため、WebAssemblyにコンパイル出来る各言語にJavaScriptのAPIを呼び出すWasm用のライブラリが開発されている。
URLﾘﾝｸ(github.com)
> 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
383:デフォルトの名無しさん
20/07/19 02:34:09.44 ktD9w8qF.net
とりあえずBlazorのsampleいっこだけ動かしてみた
>>377
「直接いじれない」と「いじれない」では全然違うでしょ
JavaScript Interopの存在は知ってるし
>>376はちゃんと「DOMいじれない」というのを否定してる。
384:デフォルトの名無しさん
20/07/19 03:24:25.64 Xo5fmFzm.net
完全にスレチじゃん？
385:デフォルトの名無しさん
20/07/19 04:14:25.27 VuyFWk7z.net
blazor-serverはともかくblazor-wasmは深刻なパフォーマンス問題があって、
[Blazor WebAssembly] Serious performance issues
URLﾘﾝｸ(github.com)
その対策は進行中↓
Blazor performance optimizations #22432
URLﾘﾝｸ(github.com)
つまりまだ全然安定しておらず、スレタイなんかと成熟度は比べるべくもない。
トラブルが起こったときアセンブリレベルでデバッグしたいならどうぞ。
blazor-serverのほうは実用レベルに到達してるけど、それこそスレチだしphpあたりと勝負してきてどうぞｗ
386:デフォルトの名無しさん
20/07/19 05:20:39.95 VEGN/NtA.net
WebAssembly自体が期待されるほど速くないから、今のままだと廃棄物になることがわかりきってるもんなあ。
ある日突然爆速になったら状況は全然変わってくるだろうけど
387:デフォルトの名無しさん
20/07/19 05:28:36.09 W3hSYpRn.net
WebAssemblyの目的は既存アプリ（特にゲーム）の移植なんだって
他の言語で開発できるって言うけど、
サーバーサイドは昔から他の言語で開発できたのに
遅いはずのスクリプト言語を使っていただろ
速度ははやければ良いねぐらいの扱いで、誰も期待してないんだよ
それに脆弱性につながるからブラウザのセキュリティ能力を超えることはできない
JavaScriptでもできることを他の言語でできるだけ
388:デフォルトの名無しさん
20/07/19 05:33:59.05 x6eBp0n6.net
Webはやはり描画がクソ重いよなあ
ゲームの超複雑な計算でも60fps出るだろ
DOM構築ごときに処理かかりすぎなんだよ
389:デフォルトの名無しさん
20/07/19 07:47:59 tFAvgvCU.net
>>375
wasmはVM転送しないの？
仕組みを見るとwasmは仮想アセンブラのバイトコードを実行するみたいに見える
たとえばC/C++をコンパイルする場合、完全スタティックリンクが必要になるのでは？
つまり依存libcもwasmにして転送されるのではないですか？（全体ではなく必要な関数だけとはいえ）
同様にC#はVM部分をwasmにしてブラウザに転送する必要があるように見える
違うの？
libcやVMなどはブラウザ側の更新で増えていくものなの？
390:デフォルトの名無しさん
20/07/19 07:53:19.22 tFAvgvCU.net
やっぱり数MBのVM(mono.wasm)を転送するじゃないか！
391:デフォルトの名無しさん
20/07/19 08:02:41.88 PEwdaGfT.net
libcもmono.wasmもどっちもVMじゃないから。そういうライブラリのことを聞きたかったのだとしたら
使う言葉を間違えてる。
392:デフォルトの名無しさん
20/07/19 08:10:57.60 tFAvgvCU.net
.NETが現実的な選択肢になりえないことは分かったのでもういいですよ
393:デフォルトの名無しさん
20/07/19 08:26:55.45 W3hSYpRn.net
>>385
wasmは転送量増えるよね。
小規模なコードならJavaScriptの方が小さくなる
だからwasmが対象としてるのは過去の比較的大規模なアプリを
そのままブラウザで動かすためのもの
それは大体ゲームｗ
394:デフォルトの名無しさん
20/07/19 08:45:06.05 nXJK1voh.net
ブラウザでゲームやるならクラウドでええやんってなるに決まってるだろ
395:デフォルトの名無しさん
20/07/19 08:45:29.98 PIkW4oBq.net
>>380
LOHじゃん
よっぽど馬鹿なプログラム書かなきゃ問題にならんよ
396:デフォルトの名無しさん
20/07/19 08:47:06.11 W3hSYpRn.net
>>389
クラウドが何を言ってるのかわからんけど、
ここで言ってるゲームっていうのは過去PC用でリリースしたものの話だよ
移植を楽にしてくれるのがwasm
397:デフォルトの名無しさん
20/07/19 08:48:50.35 PIkW4oBq.net
>>388
業務系
398:デフォルトの名無しさん
20/07/19 08:50:00.32 j+IrtB5e.net
>>385
キャッシュされるからそれは無視していいよ
399:デフォルトの名無しさん
20/07/19 08:53:37.36 tFAvgvCU.net
>>393
気になるかならないか決めるのは開発者ではなく利用者だから
400:デフォルトの名無しさん
20/07/19 08:57:28.54 W3hSYpRn.net
>>393
jQueryなどは複数のサイトで同じライブラリを使うから
あるサイトでキャッシュされたら他のサイトでも早くなることがある。
CDNが使われることも多い
でもwasmはそうならんやろ？使われてる例自体も少ないし。
401:デフォルトの名無しさん
20/07/19 08:59:03.14 PIkW4oBq.net
>>394
ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
Gmailとか起動遅いけどみんな普通に使ってるだろ
まあ遅いといってもデスクトップアプリよりは速いし
開発者が過剰に神経質になってるだけだ
402:デフォルトの名無しさん
20/07/19 08:59:45.80 W3hSYpRn.net
>>392
業務系にwasmは使い物にならんよね。HTMLで簡単にUIをつかえるのに
wasmだとそこから作らなければいけない
ゲームならそこから作るのは当たり前だけど
業務系はすでにある使いやすいコンポーネントを再利用するのが普通
速度も業務系だと結局サーバーサイドでやることが多いし
403:デフォルトの名無しさん
20/07/19 09:01:44.02 W3hSYpRn.net
>>396
> ユーザーは遅いなら遅いでしゃあねえかって使うもんだよ
> Gmailとか起動遅いけどみんな普通に使ってるだろ
速度とかよりも手軽さ重視だからね
ブラウザでもアプリでも気にしないし
wasmの価値は移植を楽にしてくれる所というのはそういう話
404:デフォルトの名無しさん
20/07/19 09:02:52.10 tFAvgvCU.net
>>396
もういいって
遅くても我慢して使ってくれるから大丈夫！
とかなんなの？
あなたとは話す価値がないと判断した
405:デフォルトの名無しさん
20/07/19 09:02:58.39 PIkW4oBq.net
>>395
時間が解決する問題だな
つか別に複数サイトで共有しなくてもキャッシュされるし
つか.NETは単一バイナリのビルドとモジュールのトリミングを研究してるからデカイランタイム問題もすぐ解決するよ
406:デフォルトの名無しさん
20/07/19 09:04:20.16 W3hSYpRn.net
> 時間が解決する問題だな
「使う理由がない」は時間が解決してくれないよ
時間が解決するのは、今実際に起きている課題だけ
407:デフォルトの名無しさん
20/07/19 09:04:23.55 tFAvgvCU.net
時間が解決する問題ってことは
やはり現時点では.NETは現実的ではないってことね
成熟したらまた教えて
408:デフォルトの名無しさん
20/07/19 09:05:40.29 W3hSYpRn.net
>>399
> 遅くても我慢して使ってくれるから大丈夫！
> とかなんなの？
誰もそんな話はしていない。
遅いのだろうが許容範囲なのでみんな使ってくれているので大丈夫
使ってくれるはずという希望じゃないんだよ。
実際に使ってるんだよ。だからこの程度であれば大丈夫であることは証明済み。
409:デフォルトの名無しさん
20/07/19 09:06:25.23 PIkW4oBq.net
>>397
まるごと再利用しか頭にないのか？
業務系ではレガシーなシステムの移植とかいくらでもあるんだが
業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい
410:デフォルトの名無しさん
20/07/19 09:06:59.87 W3hSYpRn.net
> 業務系ではレガシーなシステムの移植とかいくらでもあるんだが
移植で作り変えるならブラウザ版を作りますって（笑）
411:デフォルトの名無しさん
20/07/19 09:08:44.46 W3hSYpRn.net
> 業務系の開発者はフロントエンド苦手だからC#でフロントを新規開発できるというメリットはあまりにも大きい
苦手なやつがC#使ったからって克服できるわけ無いやろｗ
苦手なら得意な人がやればいいだけだし
分業できる方が良いよ
412:デフォルトの名無しさん
20/07/19 09:09:00.50 PIkW4oBq.net
>>399
お前も話す価値ないよ
速度なんてこれからいくらでも最適化で改善していく部分だから現状で少しビハインドでも全く問題にならねえんだよね
逆にそこしか否定できないってことはもうBlazorを無意識化では認めちゃってるってことだよ
413:デフォルトの名無しさん
20/07/19 09:09:48.38 PIkW4oBq.net
>>401
時間が経てば使う理由も増えるわけだが
414:デフォルトの名無しさん
20/07/19 09:10:04.29 W3hSYpRn.net
JavaScriptの速度も随分と改善しましたしね。
十分実用レベルに達している。
さらにCPUの性能は上がり続けてる。
415:デフォルトの名無しさん
20/07/19 09:10:20.89 PIkW4oBq.net
>>402
十分実用的、で、時間が経てば更によくなる
416:デフォルトの名無しさん
20/07/19 09:10:39.96 W3hSYpRn.net
>>408
増えないよ。お前がネット始めてから20年ぐらい立つだろうが
普段やってることは大して変わってねーだろ？ｗ
417:デフォルトの名無しさん
20/07/19 09:11:54.71 tFAvgvCU.net
Blazor勢 必死すぎるだろw
もういいんだって
418:デフォルトの名無しさん
20/07/19 09:12:03.15 W3hSYpRn.net
そもそもな。デスクトップアプリとして以前からできることを
ブラウザでわざわざやる理由がないんだよ
アプリ版を作ればいいだけなんだから
419:デフォルトの名無しさん
20/07/19 09:12:19.58 PIkW4oBq.net
>>405
移植でブラウザ版を作るから業務系開発者が得意なC#で開発できること価値が大きいんだろ
420:デフォルトの名無しさん
20/07/19 09:14:29.32 W3hSYpRn.net
>>414
だからサーバーサイドは以前からC#で開発できてますってｗ
421:デフォルトの名無しさん
20/07/19 09:15:20.05 m5eV0pvm.net
追うのめんどいから誰か論点整理して貼って
422:デフォルトの名無しさん
20/07/19 09:18:02.57 PIkW4oBq.net
>>406
克服できてしまうんだなぁこれが
つか.NETとVisualStudioが優秀だからなんとなくで作れるようになる
得意なやつがやればいい、なんてのはコスト意識のない下っ端の考え方なのではっきり言って論外
業務系はWeb系みたいなホビーじゃねえんだよ
423:デフォルトの名無しさん
20/07/19 09:19:09.28 W3hSYpRn.net
コスト意識があったら、適材適所って言葉を知ってるはずだがなｗ
なぜ苦手な人がフロントを作るのか
424:デフォルトの名無しさん
20/07/19 09:20:43.25 W3hSYpRn.net
C#で業務系と言うとASP.NETを使います。
UI込ですでに実現できてるんですよ。
wasmで一体なんのUIを作るんですか？
425:デフォルトの名無しさん
20/07/19 09:22:19.43 PIkW4oBq.net
>>411
ユーザー目線では特に変わってない
ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ
�
426:}イクロソフトの提供する開発体験はいつも素晴らしいものだ Blazorがもたらす開発体験にも当然、期待していいだろう 今では誰もが使ってるVSCodeもTypeScriptもそういやマイクロソフトだよなぁ 次のビッグウェーブが来てるんだろうな
427:デフォルトの名無しさん
20/07/19 09:24:05.39 PIkW4oBq.net
>>415
フロントエンドでもC#を使えるようになるのが大きいんだって話だろ
428:デフォルトの名無しさん
20/07/19 09:24:15.27 W3hSYpRn.net
> ユーザー目線では特に変わってない
> ということは開発者目線での進化がフレームワーク選定に大きな影響を与えるということだ
どういう理屈？言ってみただけの中身がない言葉は要らないよ
429:デフォルトの名無しさん
20/07/19 09:26:11.82 W3hSYpRn.net
>>421
> フロントエンドでもC#を使えるようになるのが大きいんだって話だろ
だからサーバーサイドの開発にフロントエンドも含まれてるんだってｗ
C#の面倒な実装じゃなくて、テンプレートエンジンを使った簡単な方法で
フロントエンドを作成できる
繰り返すが、C#で一体なにを実装するの？
すでにユーザーインターフェースは揃っている。
430:デフォルトの名無しさん
20/07/19 09:26:37.05 PIkW4oBq.net
>>418
やっぱホビーだなあんた
安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
大規模なチームで仕事をするなら絶対に必要なスキルだ
それをシラナイということは個人開発か、少数精鋭で作れるおもちゃみたいなスタートアップしかやったことないんだろ
431:デフォルトの名無しさん
20/07/19 09:27:14.26 W3hSYpRn.net
> 安い人材でもそれなりに開発できるように、うまいこと誘導するんだよ
だからフロントはHTMLが得意な安い人材を使います。
432:デフォルトの名無しさん
20/07/19 09:31:34.04 PIkW4oBq.net
>>419
SPAを作るんだよ
既存のASP.NET(Core)でも開発はできるがデスクトップアプリと比べると操作性が悪いことは否めない
複雑怪奇な業務に適応するためにSPAの導入は今後不可避になるだろう
しかしSPAをやるには今まではクソッタレJSやらポンポン入れ替わるWebフレームワークを学ぶ必要があって学習コストが高すぎた
業務系の主力である安い人材では習得が難しいのでSPAはずっと見送られてきた
しかしBlazorならその問題を一挙にカイケツすることができる
433:デフォルトの名無しさん
20/07/19 09:32:22.28 PIkW4oBq.net
>>422
君、プログラム下手でしょ
インターフェイスと実装の分離ができないタイプと見た
434:デフォルトの名無しさん
20/07/19 09:32:58.15 PIkW4oBq.net
>>423
>>426
435:デフォルトの名無しさん
20/07/19 09:37:55.76 PIkW4oBq.net
>>425
フロントエンド特化人材は高えんだよ
私、フロントエンドなんてぜんぜんできませんよ～
って具合の人材を
ふ～ん、なら少し安めのお値段で雇ってもいいよね？
大丈夫、大丈夫、こっちでうまいことレール敷くんで、安心して手だけ動かしてください
ってな具合で格安で調達すんの
できない奴でも、できるようにすんの
436:デフォルトの名無しさん
20/07/19 09:38:44.30 W3hSYpRn.net
>>426
お前フレームワークもなしに独自でSPA作るの？ｗ
URLﾘﾝｸ(codezine.jp)
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を連携したアプリケーションを素早く開始することができます。
437:デフォルトの名無しさん
20/07/19 09:39:23.07 W3hSYpRn.net
>>429
> フロントエンド特化人材は高えんだよ
ならフロントエンドに特化してない人を使えば？
バカなのかなこいつ
438:デフォルトの名無しさん
20/07/19 09:42:08.97 W3hSYpRn.net
なんかC#を使ってWindows Formsとかでデスクトップアプリを作れば
それがそのままSPAになるって思ってそうなんだよなｗ
URLどうするんのよって感じだ
439:デフォルトの名無しさん
20/07/19 09:45:34.17 W3hSYpRn.net
URLじゃ話通じないですかね？ｗ
SPAはデスクトップアプリとは違ってURLがあって
ブラウザの進むや戻るがつかえるんですよ
440:デフォルトの名無しさん
20/07/19 09:47:19.12 PIkW4oBq.net
>>430
意味不明な切り返しすんな
SPAでやると決まったらフレームワーク使うに決まってんだろ
お前が得意げに挙げた.NETの従来のSPAテンプレートは各種JSフレームワークのテンプレートを生成するだけだ
おまけ程度にC#のAPI開発テンプレートも生成してくれるがJSフレームワークを隠蔽するようなものじゃない
だからそれらを使ってもフロントエンド特化人材を雇わないと開発なんてできねえぞ
441:デフォルトの名無しさん
20/07/19 09:49:53.45 PIkW4oBq.net
>>431
オメーがバカ
特化した人材は高い
特化してない人材ではJSフレームワーク使った開発は生産性が低い
安いには安いなりの理由があるんだよ
だがBlazorならそんな安い連中でもC#とVSを使って簡単に開発できるようになる
442:デフォルトの名無しさん
20/07/19 09:50:41.48 PIkW4oBq.net
>>432
誰もそんな話はしてねー
そんな理解になるってお前の頭どういう構造してんだ
443:デフォルトの名無しさん
20/07/19 09:51:14.00 W3hSYpRn.net
> フロントエンド特化人材を雇わないと開発なんてできねえぞ
普通にフロントエンド開発者を使えばいいだけでは？ｗ
いないんですか？
444:デフォルトの名無しさん
20/07/19 09:52:08.96 PIkW4oBq.net
>>437
高えつってんだろ
鳥頭か
445:デフォルトの名無しさん
20/07/19 10:52:37.38 5Si5cYu0.net
そろそろwasmの話は別スレでやってくれないか？
446:デフォルトの名無しさん
20/07/19 10:58:54.20 x6eBp0n6.net
実際フロントエンドまともにできないゴミエンジニアばかりだからな
以前某エンジニアリクルート系の検索システムでフロントエンドエンジニアを検索したら全エンジニアの0.5％しかいなかった
その0.5％も自称だからガチで少ない
447:デフォルトの名無しさん
20/07/19 11:04:27 jXwWFSFG.net
>>440
Blazorはゲームチェンジャーになりうる
なんたって雑魚カスC#erでも超お手軽にSPAを開発できてしまうんだから
JS系のエンジニアの市場価値は相対的に下がるだろうね
448:デフォルトの名無しさん
20/07/19 11:18:11.07 AjlQmunT.net
Blazor-wasmまとめ
重い>>385
遅い>>380
有名クラウドサービス採用実績ゼロ
（React/Angular採用多数は言わずもがな）
C#以外覚えられなくなった年寄りを再利用するための介護フレームワーク。
449:デフォルトの名無しさん
20/07/19 11:20:10.35 m5eV0pvm.net
よっぽど高度なことするわけじゃない限り、C#書けるならReactとか2週間もあれば書けると思う
450:デフォルトの名無しさん
20/07/19 11:34:57.86 x6eBp0n6.net
>>441
バックエンドゴミエンジニアが何を使ったってゴミのようなフロントしか作れないぞ
絶望的に才能がない
目ん玉はただの飾り
こいつら（＝おまえら）に良い筆を持たせても無意味
451:デフォルトの名無しさん
20/07/19 12:02:35.96 Xo5fmFzm.net
いい加減専用スレ立ててそっちでやれよ
452:デフォルトの名無しさん
20/07/19 12:11:33.06 kmbJyWa5.net
数年後にwasmだらけになって涙目になるJSキッズが目に浮かぶ
453:デフォルトの名無しさん
20/07/19 12:14:17.72 kmbJyWa5.net
>>443
2週間�人数の教育工数が無駄
454:デフォルトの名無しさん
20/07/19 12:16:36.81 kmbJyWa5.net
>>442
重さは、遅さは現状でも十分実用に堪えうる
というか既存のSPAも体感はほとんど変わらんレベル
ゴリッゴリに最適化された既存フレームワークと比較してだから、最適化の余地があるwasmのほうが将来的には優位
採用実績はまだ正式発表されたばかりだから、比較しても意味がないことは小学生でもわかるはずだが君はどうだ？
455:デフォルトの名無しさん
20/07/19 12:17:49.08 PEwdaGfT.net
そこで振り落とされるような奴は今のJSフロントエンドすら無理。
456:デフォルトの名無しさん
20/07/19 12:20:18.80 BU8dfNcw.net
blazor厨もそれに付き合うやつも
よそでやれよ
そんなんだからいつまでたっても
そんなんなんだぞ
457:デフォルトの名無しさん
20/07/19 12:28:01.28 ZFRvNo6R.net
次スレはvs Blazorも入れたほうがいいな
458:デフォルトの名無しさん
20/07/19 12:46:08.93 YlpileWs.net
なんでこんな迷惑なBlazor厨に合わせてスレタイ変える必要があるのか
Blazor厨も相手してる連中もどっか行ってよ、ウザイ
459:デフォルトの名無しさん
20/07/19 12:46:49.46 n0f5aqSv.net
>>442
ついこないだRTMになったばかりのものを実績で批判しちゃうおばかさん
460:デフォルトの名無しさん
20/07/19 13:08:12.92 PQF4JxAh.net
それだけBlazorを恐れてるんだろうな
まあ自分の市場価値が下がるわけだから恐れて当然なんだけど
461:デフォルトの名無しさん
20/07/19 13:27:13.14 Xo5fmFzm.net
単純にスレチな話題を延々と展開するヤツが煩わしいだけ
どの道Microsoft系とは層は被らんよ
462:デフォルトの名無しさん
20/07/19 13:32:43.99 ktD9w8qF.net
>>382
大規模サイトのserver sideはJavaやC#が多かった。
社員しか使わないしょぼい業務系web appのことだけ考えていてはいけない。
あと大規模になるとtype safetyが必須になる
type safeでなければ開発生産性ががた落ちだ
速度も大事だがビジネスとしてみると開発生産性、コストもとても大事なわけ
463:デフォルトの名無しさん
20/07/19 13:54:52.10 Nf0PDjLy.net
GAFAでは使ってないし大手SNSでも使ってないけどな
464:デフォルトの名無しさん
20/07/19 14:00:36.02 DFSJX5gq.net
>>455
ほんそれ
465:デフォルトの名無しさん
20/07/19 14:20:55.19 ktD9w8qF.net
>>384
最小限のファイルだけbrowserに転送されるし
cacheされるから2回目以降は読み込みもはやい
ほとんどの人は5秒未満で初回読み込み終わるんでは
2回目以降速いのにそんなにガタガタ騒ぐ理由がわからない
いまどきトップページ読んだだけで数MB消費のサイトたくさんあるだろ
mobileでYouTube見てる人とかたくさんいる時代に
初回だけ数MBの読み込みって問題になるとは思えない
466:デフォルトの名無しさん
20/07/19 14:25:37.40 ktD9w8qF.net
>>385 >>387
初回はデータ読み込み多いのはAngularとかのSPAも同じだから
このスレに来ないほうがいいと思うぞ
いつまでも古い開発に固執していればいい
そもそもwebでC++とか普通使わないだろ、開発生産性が低い
client sideにロジックが増えるという事は
それだけユーザーは快適に使えるようになるってことだ。
メリットとデメリットのトレードオフ
467:デフォルトの名無しさん
20/07/19 14:29:43.28 ktD9w8qF.net
>>455
TypeScriptの開発がMicrosoftなのも知らない人か
MSアンチやアップル信者の人ってこういう知識ない人が多い感じ
468:デフォルトの名無しさん
20/07/19 15:10:43.98 x6eBp0n6.net
もうここはBlazorスレだな
Reactとか微塵にも話題に出ない
469:デフォルトの名無しさん
20/07/19 15:18:33.36 Xo5fmFzm.net
>>461
ああ、知ってるが導入するコストと比べて型があるって事にメリットがそれほど感じられなかったから導入を見合わせたよ
470:デフォルトの名無しさん
20/07/19 15:23:00.55 m5eV0pvm.net
絶対ts入れた方がいいぞ
471:デフォルトの名無しさん
20/07/19 15:27:00.79 n0f5aqSv.net
>>457
どこの世界の話だろうか
472:デフォルトの名無しさん
20/07/19 15:35:58.18 3+L828Di.net
仕事で扱ってるドメインがショボいと型安全性のありがたみはわからねえだろうな
473:デフォルトの名無しさん
20/07/19 15:41:47.27 RfQaIH9f.net
Blazorの話は過疎ってるxamarinスレでやってくれないか
474:デフォルトの名無しさん
20/07/19 16:10:02.58 n0f5aqSv.net
>>467
スレチ
475:デフォルトの名無しさん
20/07/19 16:59:27.91 ktD9w8qF.net
>>457
大規模サイトのback endはJavaとC#だらけなの知らないのか
Twitterは過去にRuby遅すぎて捨ててるし
476:デフォルトの名無しさん
20/07/19 17:05:03.82 xggXZiaY.net
nodeは立ち上がりが軽くて速くてスケール時に使い捨てしやすいからだろう。
AWS Lambda Cold Start Language Comparisons, 2019 edition ☃
URLﾘﾝｸ(levelup.gitconnected.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
URLﾘﾝｸ(miro.medium.com)
.NET遅っそｗｗｗ重っもｗｗｗｗ
Java遅っそｗｗｗ重っもｗｗｗｗ
477:デフォルトの名無しさん
20/07/19 17:36:47.16 lVLELK+9.net
.NET優秀やん
478:デフォルトの名無しさん
20/07/19 17:48:38.32 +/vqE4Sh.net
Javaや.NETは基本サーバーは決められた台数立てっぱなしが当たり前の時代に設計されたからな。
最近のコンテナ単位・ラムダ単位で負荷に合わせてスケールアウト・スケールインするアーキテクチャは想定外だったんだろう。
479:デフォルトの名無しさん
20/07/19 19:13:15.19 x6eBp0n6.net
もうjsでいいじゃん
使えないバックエンドゴミクズエンジニアがヒーヒー言ってるだけだろ
480:デフォルトの名無しさん
20/07/19 19:25:21.82 c7cY5EYc.net
Why I Converted from Vue to React
URLﾘﾝｸ(dev.to)
> The purpose of this post was not to say that Vue is bad
ワロタ
481:デフォルトの名無しさん
20/07/19 21:20:08.98 ktD9w8qF.net
>>377 >>470
これ記事かいたやつもそれ張り付けてるおまえもアホすぎ
.net2とかいう言語はない。
.netが言語だと思ってる時点で相当レベル低い
あとcold startだけのbenchなんてほとんど意味ない。
しかもcloud環境で計測してるというバカっぷり
そんなのその時のserver混雑状態で変わるってのｗｗ
482:デフォルトの名無しさん
20/07/19 21:51:47.75 xggXZiaY.net
hot startなんだから対象言語の実行に必要なVM・環境のロード時間含まれるの当たり前じゃんｗ
lambdaなんだからクライアントから測るの当たり前じゃんｗｗ
本番でユーザーに遅い言われたときサーバで測ったら速いです言うの？ｗｗｗ
バカ過ぎワロタｗｗｗｗおとなしくサーバサイドだけやっとけや老害ｗｗｗｗｗ
483:デフォルトの名無しさん
20/07/19 21:52:18.36 xggXZiaY.net
*cold
484:デフォルトの名無しさん
20/07/19 22:25:34.23 aWdyr5NP.net
世界最速は、このサイト。Ruby on Rails 製
URLﾘﾝｸ(dev.to)
Rails + React + Bootstrap + (Node.js + Webpack) の組み合わせには勝てない。
このエコシステムを超えるのは、無理
Rails: webpack(er)に乗り換える25の理由（翻訳）
URLﾘﾝｸ(techracho.bpsinc.jp)
485:デフォルトの名無しさん
20/07/19 22:34:28.77 KAosLxZz.net
ｶﾞｲｼﾞ大集合ｗｗｗｗｗ
486:デフォルトの名無しさん
20/07/19 23:23:56.46 PIkW4oBq.net
Rubyって遅い言語代表格じゃん
487:デフォルトの名無しさん
20/07/20 00:48:26.56 PYo76fqp.net
>>470
なんでgoがこんなに遅いかね
488:デフォルトの名無しさん
20/07/20 05:20:10.55 AOg6xuBm.net
>>476
ほんとバカだな
ベンチマークなんて負荷なしの状態でかけないと正確な値がわからない。
プログラミングやらないやつでもそんなこと知ってると思うわ
多くのユーザーが使ってるサーバーで言語ごとのベンチマークとるとか馬鹿すぎ
それを何度も張ってるおまえも同レベル
もし言語ごとにやるならオンプレミスでやらないといけない
その環境をつくれないバカだから混雑してるクラウドでやるとする
Front endのスクリプトしかできない奴はやっぱりレベル低い
489:デフォルトの名無しさん
20/07/20 06:01:17.63 uvZgkaZD.net
>>482
lambdaがどういう運用されるか知らないの？ｗ
やはり老害は立てっぱなしの旧来アーキテクチャしか理解できないようだなｗｗ
言語と同じで信者もスケール出来ない産廃ｗｗｗ
490:デフォルトの名無しさん
20/07/20 06:44:08.94 f45H4Kz0.net
Blazor信者の声でかいからBlazor調べてみたけどHTML構文のきもさとか実行の遅さとかファイルサイズのでかさがやばいな
これむしろBlazorアンチだろ
信者だとしたらずっとBlazor触ってて欲しいな。デメリットも享受出来ないで持ち上げる人は大海を知らないでほしい
491:デフォルトの名無しさん
20/07/20 06:58:19.08 AOg6xuBm.net
>>483
C#できない低能のおまえは何の言語使えるつもりになってるの？
で、おまえがベンチマークだとおもってるそれは
何を計測してると思ってるの？
まともなベンチマークですらないのに言語の速さと勘違いしてるし
>>481
それまともなベンチマークじゃないから無視でいい
492:デフォルトの名無しさん
20/07/20 07:00:16.28 eYf0BG4n.net
C#ってJavaScriptよりも簡単やろ？
JavaScript使えるなら誰でも使えるで
だからC#の給料は安い
493:デフォルトの名無しさん
20/07/20 07:06:07.22 AOg6xuBm.net
>>484
htmlじゃなくてRazor syntaxな
ReactのJSXより綺麗だろ
ASP.net系やってるひとはわかるsyntax
AssemblyファイルをダウンロードしないBlazor Serverっていうのもある
その辺は要件によって使い分けること
性能もC#だから速い。遅いと言ってる人はコードの書き方が悪い