20/07/08 16:12:22.96 MVSOOhWY.net
>>90
リリースのたびにローカルの開発環境でnpm run buildみたいなコマンド打って、トランスパイルされたjsファイルを手作業でアップロードみたいな作業するの？
零細サイト(アプリ)ならありかもしれないが…
92:デフォルトの名無しさん
20/07/08 16:19:50.85 I47WXMxT.net
なんで手動って決めつけてんの？
ビルドプロセスにデプロイも含めるでしょフツー
93:デフォルトの名無しさん
20/07/08 16:28:48.25 0bRtE3JM.net
>>91
Laravelならプロジェクト一式の中にwebpack関連の一式も入ってるけどね
94:デフォルトの名無しさん
20/07/08 16:47:50.70 Kr2gnfN5.net
>>91
手動でアップロード？
意味わからんこと言うなよ
95:デフォルトの名無しさん
20/07/09 10:02:09.72 mOpBi7N3.net
>>91
tsファイルの変更を自動検知して.jsに自動でトランスパイルする設定で
開発するのが普通なんじゃないの
>>92
deployっていう用語は開発が終わって本番サーバーに移すときに使う感じでしょ
開発中のこまめな修正はbuildだから
buildとdeployはセットにしてしまうと不便
頻度が違いすぎる
96:デフォルトの名無しさん
20/07/09 10:04:52.31 G/OlOUwD.net
インフラ屋には「開発」って概念がないからｗ
あいつらは出来上がったものを配布するだけ
配布するときにビルドが必要かどうかってことしか知らない
ビルド�
97:ｾけが必要という発想がない
98:デフォルトの名無しさん
20/07/09 10:35:48 w7BJW0S5.net
CIでビルドからデプロイまでやるわなフツウ
毎回デプロイまでプロセス進めるわけでもないが
なんらかのトリガで自動デプロイまで整ってないとしんどいよ
99:デフォルトの名無しさん
20/07/09 12:28:57 KHuqFwsC.net
蔵「ここに要素追加で！中のここのテキストは決まり次第連絡します」
ワイ「よっしゃ手空いたし実装すすめたろ！ここのテキストは適当にうめとこ！できた！フロントビルドして表示確認したろ！」
CIとやら「ビルド＆デプロイ！」
本番サイト「おちんちんびろーん」
蔵「…」
100:デフォルトの名無しさん
20/07/09 12:52:10.72 CLykJNt5.net
手動デプロイする人、ビルド構成1つしか使えない人、いろいろいるんだなあー
101:デフォルトの名無しさん
20/07/09 14:13:27.36 fGQp3/0X.net
手動デプロイって人数1人の超小規模開発だけだろ
102:デフォルトの名無しさん
20/07/09 14:22:33.72 fGQp3/0X.net
なんかこのスレ、
・開発中のローカルサーバーでのビルド
・本番等へのデプロイ時に行うビルド
をごっちゃにしてる奴が居て話が噛み合わないわ
103:デフォルトの名無しさん
20/07/09 14:25:16.59 w7BJW0S5.net
どっちも同じだろ
パラメータ少し変えるだけだし
104:デフォルトの名無しさん
20/07/09 14:39:00.18 vrNDocOm.net
ほらね
105:デフォルトの名無しさん
20/07/09 14:42:43.21 w7BJW0S5.net
まさかローカル用とデプロイ用で分けてメンテしてんのか？
DRYはどこに行ったんだ
106:デフォルトの名無しさん
20/07/09 14:46:26.77 KHuqFwsC.net
ハァ？なんでローカルの開発マシンで既にビルドしてるフロントをまたサーバーでビルドするんだ？
腐った思考がグルグル回ってんのはお前の頭ん中だけ。DRYじゃないのはお前。
107:デフォルトの名無しさん
20/07/09 14:51:31.22 w7BJW0S5.net
>>105
はぁ？
開発中はローカルでビルドするし、CIサーバーでもビルドする
当たり前のことだろーが
お前、はっきり言って意味わからんよ
108:デフォルトの名無しさん
20/07/09 15:02:50 pDJXId50.net
言うほどローカルでビルドする？
109:デフォルトの名無しさん
20/07/09 15:15:30 fGQp3/0X.net
>>104
そもそもローカルではwebpack-dev-serverとか使って効率化するだろ。
お前…まさかファイル更新する度に毎回ビルドコマンド打ってるのか？
>>105
そもそも本番とかってリリース用のブランチと同期しながらリリースするんだから開発マシンとか関係ないだろ。
お前…まさか自分の開発マシンでビルド したファイルを直接本番とかの環境にデプロイしてるのか？
110:デフォルトの名無しさん
20/07/09 15:18:52 dGRiARSQ.net
てかそもそもローカルで開発やってんの？
111:デフォルトの名無しさん
20/07/09 15:19:43 7NNwjcns.net
本番機械にデプロイしてから
デバッグしてるよ
112:デフォルトの名無しさん
20/07/09 15:50:54 U0+2kDKX.net
両方成敗されててワロタｗｗｗｗｗ
113:デフォルトの名無しさん
20/07/09 16:06:12.14 mOpBi7N3.net
デプロイとか書くのやめたほうがいいよ
バカっぽいから
deployの発音と全然違う
114:デフォルトの名無しさん
20/07/09 16:09:12.55 DLLEuHaF.net
デッポｫイ
115:デフォルトの名無しさん
20/07/09 16:12:04.53 p1w6aC/e.net
>>108
今はコマンドを打つかウォッチで自動化するかどうかは関係ない
どっちにしろ構成は同じだ
116:デフォルトの名無しさん
20/07/09 16:57:49.39 Oqcc9RL+.net
ディプ・ローイ
117:デフォルトの名無しさん
20/07/10 00:30:34.49 wxXFpnos.net
gulpとかbabelとかwebpackとかyarnとか本末転倒なんだって
そんなものこれっぽっちも使いたくないんだよ。
楽したいと思うからフレームワークに頼るわけであって
使えるようになるまでコマンドいくつも叩くくらいなら
ネイティブJavaScriptで全部やりゃいいだろってなるわ
118:デフォルトの名無しさん
20/07/10 00:51:02.42 2N+fP911.net
じゃなんでこのスレ開いたんだ
119:デフォルトの名無しさん
20/07/10 01:17:45.44 jhbOVfsR.net
>>116
はっきりと勉強したくない（努力したくない・技術力をつけたくな）って言ったらどうか？
技術者の道具っていうのは自動車でも飛行機でも
技術力をつけて初めてさらに高度なことが出来るようになるもの
勉強しないで使えるものじゃないんだよ
120:デフォルトの名無しさん
20/07/10 01:26:15.32 ykDeil39.net
npm install && npm run watch
たったこれだけやん
あとはソースの更新を自動検知して再ビルドしてくれる
121:デフォルトの名無しさん
20/07/10 01:26:33.04 ykDeil39.net
あ、Laravelの場合はね
122:デフォルトの名無しさん
20/07/10 02:14:28.34 73Gt5ed7.net
確かにwebpackはクソ。
俺はビルド設定職人じゃねえっての。
何にでも設定あるのは仕方ないがややこしいすぎめんどすぎ設定方法すぐ変わりすぎ。
投げ捨ててsnowpackを使うことにした。
webpackはとっとと滅べ！
123:デフォルトの名無しさん
20/07/10 05:57:04.39 QHte8x2K.net
Ruby on Rails は普通、Heroku を使う
Rails 6 からは標準で、Webpack。
プロジェクト内に、node_modules もあるし、
最初から、Yarn に、便利なコマンドも登録されている
webpack-dev-server も入っているから、
最初から、ソースコードの変更をwatch している。
VSCode の拡張機能・Live Server のwatch と同じ
有名なYouTuber、雑食系エンジニア・KENTA も、
CircleCI も必要だって言ってるだろ
124:デフォルトの名無しさん
20/07/10 06:13:16.31 tMSRuIv2.net
>>116
ほんとだね
125:72
20/07/10 07:49:21.18 QHte8x2K.net
Node.js, Webpack, Babel, Browserify, Uglify, CssShrink, AutoPrefixer などが無ければ、
ES2015, JSX などを、ES5 に変換できない
126:デフォルトの名無しさん
20/07/10 08:17:54 gdbFqfW8.net
どんだけ必要なんだよww
馬鹿かよビルドばっかでReactの本題がほとんど頭に入らんわ
ちゃんと整理しろよwwww
127:デフォルトの名無しさん
20/07/10 08:47:02 LiH0PaR7.net
あの程度のツールの組み合わせもまともに理解できないような輩は
プログラムを仕事でやるのは辞めてほしいわ。
railsなんか使っても何がどこに作用してるかわからなくて糞コードになるのが目に見えてる。
128:デフォルトの名無しさん
20/07/10 09:00:52.47 ykDeil39.net
>>125
必要じゃなくてLaravelやRailsならもうプロジェクトに一式入ってる環境が整ってるからビギナーが気にする必要ないわけよ
129:デフォルトの名無しさん
20/07/10 09:09:17.82 ykDeil39.net
>>125
てかReactとか普通に入門書やらチュートリアルサイト見ればNode入れてcreate-react-app入れたら
create-react-appで新規プロジェクトを作成してnpm startやるだけって書いてあるだろ
それすらできんって言うんならプログラミングの才能ないからやめた方がいいぞ
130:デフォルトの名無しさん
20/07/10 09:46:57.35 GKub8uAj.net
魚捌けなくても寿司は食えるみたいな
131:デフォルトの名無しさん
20/07/10 10:16:52.30 tLJkl0Xj.net
CPUが古いからかcreate-react-app、実行したら2分くらいかかるんだけど
新しめのRyzenとかだとどれくらいでcreate-react-appの処理終わるの？
>>128
チュートリアルの最初にcreate-react-appでてくるし
プログラミングの才能とかそんなレベルの話じゃない気がする
しかしReactの公式ドキュメントはそのあと一気にハードルあがる
いきなりゲームを作りましょうとかの解説になって挫折したわ
ゲーム作りはチュートリアルのレベルじゃないだろ！とツッコミたい
YouTubeの解説とかのがよっぽどわかりやすい
132:デフォルトの名無しさん
20/07/10 10:38:58 QHte8x2K.net
Bootstrap があれば、CSS 知らないでも、レスポンシブ対応できる
create-react-app は良いけど、
その後、どこから無料の、awesome なコンポーネントをパクッてくるのか、それが重要
Material-UI か？
Rails なんて、React からのコンポーネントのパクリしか考えていないw
133:131
20/07/10 10:42:42 QHte8x2K.net
青色のボタンを使うと、Bootstrap 臭がするとかw
Rails は今や、Node.js, Webpack, React からのパクリしか考えない、段階に入ったw
134:デフォルトの名無しさん
20/07/10 10:46:13 4aXnhBqR.net
別にプロジェクトのイニシャルやるのに2分くらい掛かってもいいだろ
変更検知ビルドで2分掛かってたら大問題だけど
135:デフォルトの名無しさん
20/07/10 11:25:16.45 n1XvZUez.net
>>131
アイコンなら普通にReactDOMにリンクするdivタグがあるhtmlでcdn読み込みすればいいんじゃね？
136:デフォルトの名無しさん
20/07/10 13:26:16.21 2N+fP911.net
>>130
CPUじゃなくて回線速度じゃねえの
137:デフォルトの名無しさん
20/07/10 13:41:18 /uHfdbTh.net
IDEで新規プロジェクト作成に２分も掛かってたら待ってらんない
SQLのクリエイトデータベースでもそんなにかからない
138:デフォルトの名無しさん
20/07/10 15:23:36.78 tLJkl0Xj.net
遅いのは主に回線速度なのかなぁ？
みなさんは、create-react-app、何秒間で終わる？
>>136
Visual StudioでC#とかやってたから2分は相当長く感じる
139:デフォルトの名無しさん
20/07/10 18:51:55.72 QmDdrWog.net
create-react-appでプロジェクト作るところを言ってるのか、そのあとのbuildのことを言ってるのかどっち
140:デフォルトの名無しさん
20/07/10 18:59:02.17 nECgv1tu.net
だいたいwebpackのせい
滅びろ
141:デフォルトの名無しさん
20/07/10 19:09:24.73 tLJkl0Xj.net
>>138
もちろん、時間のかかる前者。project作成みたいな作業
ほかのひとは何秒くらいかかってるのかな、と
自分は120秒超えてたはず
そのあとのbuildというのはbuildしてる感覚はないのでよくわからない。
VSCodeがtsの変更を監視して.jsに変換するのがbuildなんだろうけど、
JSがcompile不要言語だからbuildといわれてもしっくりこない
後者は1秒未満
142:デフォルトの名無しさん
20/07/10 19:20:51.32 K5rpfeoQ.net
だいたいトランスパイルが面倒さの原因だしtsのまま動くようにしてほしい
143:デフォルトの名無しさん
20/07/10 19:44:24.02 sls7voqY.net
よくもまあHTMLに埋め込むだけで動作する
シンプルなJavaScriptをここまで複雑にしたもんだ
開発環境複雑なのはマジでゴミだと思うわ
ツール名並べてビルド環境自慢してる奴はおもちゃ
組み立ててはしゃいでるガキと同じ。
そもそもそんな糞みてーなビルドなんかなくても動く
言語だったこと忘れてるみたいですね。
144:デフォルトの名無しさん
20/07/10 20:01:19.85 2N+fP911.net
>>142
シンプルで済むのはお前が一人で作るカップラーメンのタイマーくらいなんだが
145:デフォルトの名無しさん
20/07/10 20:46:41.69 d3LQjj1F.net
てかjQueryでいいわ
俺はフロントマウント界隈から降りるぜ
146:デフォルトの名無しさん
20/07/10 21:29:33.92 tmsI80qx.net
どうせビルドするならトランスパイルじゃなくてアセンブリでいいんだよな
Webasmがウェブの正当進化
これから先の時代ではビルドプロセスを間に挟むならWebasm
そうでないならJSと分化していくだろう
数年後にはJSでSPAやってる人は居なくなる
147:デフォルトの名無しさん
20/07/11 00:07:21 OpVuA9Ov.net
reactのテストってどういう風に書くのが正解？
148:デフォルトの名無しさん
20/07/11 01:19:29 UYSRZN1t.net
>>141
全部のブラウザがTypeScript動くようにすればいいだけなんだよな
それでJSは開発終了でいい
149:デフォルトの名無しさん
20/07/11 01:41:33 TUFHIPon.net
そうだね
ブラウザでTypeScriptが動くようになるかJavaScriptがTypeScriptの機能を取り込んでいくのか分からんけど
トランスパイルは過渡期的な技術だと思う
5～10年後には無くなっているだろう
150:デフォルトの名無しさん
20/07/11 02:13:09 cZoTn3pS.net
マイナなんたらはIE11でしか申し込めないんだっけ？
151:デフォルトの名無しさん
20/07/11 03:30:23.47 T1/tMyE9.net
wasmが直接実行できてDOMも生で触れたらJSなんていらないけどね
てかこのRFCとかないの？
152:デフォルトの名無しさん
20/07/11 03:56:17.01 n/VQ0E7w.net
・・が直接・できて・も生で触れたらJSなんていらないけどね
てか・・とかないの？
153:デフォルトの名無しさん
20/07/11 07:13:13.43 UYSRZN1t.net
WebAssemblyでweb app作った場合に
ブラウザからソースとかはみえないんだよね？
開発する側にとってはソース見えないのは大きなメリットだけど
ユーザー側はセキュリティ的に実行していいコードなのかどうやって
判断するんだろ
>>149
smartphoneでも申し込めるんだからIE11限定はあり得ないでしょ
154:デフォルトの名無しさん
20/07/11 07:56:00.22 M8nptmnx.net
>>149
あんなの逆に既存ブラウザに拘らずにWin/Macでそれぞれ専用ブラウザアプリ作りゃ済んだ話なのにな
155:デフォルトの名無しさん
20/07/11 09:57:32.58 0/l6dmQ+.net
まあjqueryに適切なネームスペース設定があればって話もわからんではないけど。
でも結局静的チェックは必要だろうなとは思う。
jsはあまりにぐにょぐにょすぎる。
156:デフォルトの名無しさん
20/07/11 10:04:21 fJlL8BSP.net
適切なネームスペース設定ってなんだ？jQueryに限った話なのか？
157:デフォルトの名無しさん
20/07/11 14:58:25.28 uAzO8/bZ.net
自分がぐにょぐにょだったというオチ
158:デフォルトの名無しさん
20/07/11 20:14:49.67 tYF4Dhe8.net
普通に考えたらvuexとかのフレームワークが提供するnamespace機能じゃねえの？
159:デフォルトの名無しさん
20/07/11 23:15:12 CRVUgJTS.net
レガシー技術しか触らせてもれないエンジニアがいっぱい居るんだなぁ
160:デフォルトの名無しさん
20/07/12 01:12:29.71 FwLv8JRl.net BE:981588645-2BP(1000)
URLﾘﾝｸ(img.5ch.net)
VBAスレが勢い2位の板ですし
161:デフォルトの名無しさん
20/07/12 01:20:57.95 Ttk2hZRW.net
「触らせてもらえない」って変な表現だな。
もし触りたきゃ個人的に触るだろ。
単に必要がないだけじゃないか。
実際、サーバーサイドのAPIと通信したり、VuexやReduxでやるような状態管理が求められないようなアプリにフロントフレームワークがオーバースペックだっていう意見は同意する。
VueとかReact使うとフロントが楽なのは当然として、サーバーサイドも楽になる。
サーバーサイドはAPI化してJSON返せばいいだけになるし、ネイティブアプリ対応もサーバーサイドはワンソースで済む。
wordpressのような、htmlにサーバーサイドの変数を埋め込んでからレンダリングするようなレガシーアプリだと、言語がphpかrubyあたりに制限さられるし、何より密結合でクソ汚いコードが生成される。
逆にAPIへのリクエストが頻繁するようやサイトでjQueryだの生JSだの言ってたらメンテナンス性や開発効率は最悪だろうね。
162:デフォルトの名無しさん
20/07/12 01:39:59.65 Ttk2hZRW.net
あとはテストの書きやすさも違うと思う。
MVCに則ったサーバーサイドの場合、Controllerのいわゆる機能テストはViewの代わりにJSONになるからすごくシンプルになる。（Modelのメソッド単位のユニットテストになると関係無いけど）
俺はサーバーサイドのテストはよく書くけど、フロントのテストはあまり書かないんだよね。（e2eテストって難しいし）
それでもフレームワークの有無の違いでテストの書きやすやが全く違うのは誰でも想像できることだと思う。
163:デフォルトの名無しさん
20/07/12 02:16:40.18 6LAoyHzZ.net
それって DOM to JSON みたいなシリアライザがあれば
DOMのテストは簡単にならんか？
164:デフォルトの名無しさん
20/07/12 09:32:00.73 sEYtnhuz.net
Ruby on Rails のシステムテストは、Capybara, Se
165:lenium とか Page Object みたいなデザインパターン
166:デフォルトの名無しさん
20/07/12 11:16:28 NK7E+AG5.net
今日のNG確定
167:デフォルトの名無しさん
20/07/12 11:26:50 vwiHN0KN.net
>>164
ワードでNG掛ければよくね？
168:デフォルトの名無しさん
20/07/12 12:13:06 vC5oJzvU.net
「今日の」ね。
ワード単位なら分かるけど、こんな過疎スレでわざわざID単位でNGしたくなるって、どんだけ効いたんだろ。
169:デフォルトの名無しさん
20/07/12 12:25:19.68 86r/iRcT.net
そんなたいした作業か？
ロングタップしてNGIDに追加押すだけじゃんｗ
170:デフォルトの名無しさん
20/07/12 12:33:46.69 VRndaT/s.net
このスレにだけ出没するってんなら
そんな大した話でも無いんだがな
171:デフォルトの名無しさん
20/07/12 13:21:54 oDnBGDI7.net
NGとか解除の手間考えたらやらない
この程度スルーできないでよく5chできるね
いちおうプログラミングの話だしNGするほどのことじゃない
>>163
Railsおじさん
いつもJSと関係ない脱線した話ばかり
Railsなのに脱線しかしてない
172:デフォルトの名無しさん
20/07/12 13:32:09.95 86r/iRcT.net
なぜ解除する必要が？一生NGだぞ。
過去ログ読む際出てきたら困るわ。
てか解除する人なんて聞いたことない。
173:163
20/07/12 13:35:40.32 sEYtnhuz.net
Ruby on Rails のBDD, RSpec を知らない香具師は、
Jest, Jasmine も知らないと思う
174:デフォルトの名無しさん
20/07/12 18:02:19.97 oDnBGDI7.net
>>170
5ch、特に技術系の話題なんて過去の情報に価値がないし
過去ログなんてまず読まない。
あとで必要になりそうな重要なレスはtext fileに保存しておく
そうしておかないと探す時間の無駄になる
プログラミングするやつがNG解除の理由わからないとはやばい。
NGチェックのために無駄な処理が増えて動作が遅くなっていく
NG追加しつづけるなんてことやってるひとは
非効率なコードを書いてる人だわ
175:デフォルトの名無しさん
20/07/12 18:10:27.29 hVdx08FL.net
NGIDなんてボコボコ追加しても全然読み込み速度落ちないから解除の必要ないけどね
楽をしても全く問題が生じない箇所でも無駄の無い凝ったコードを書くタイプと見た
176:デフォルトの名無しさん
20/07/12 19:37:58.22 oDnBGDI7.net
>>173
仮に速度が落ちないとしても
すでに読んだログを残す行為自体が時間の無駄でしょ
必要な部分だけ残して削除しないと無駄になる
すでに読んで不要になったメールを残しておくのと同じで
すごく時間の無駄になる
コードは最初からスケールアウトを意識してコード書いてる
177:デフォルトの名無しさん
20/07/12 20:06:12 86r/iRcT.net
解除するのが時間の無駄だわバカらしい
178:デフォルトの名無しさん
20/07/12 21:29:39.15 vwiHN0KN.net
>>172
俺も>>170もNGを解除する必要がないと考えてるからワードNGしてるだけだし
お前がそう思うんならそれでいいんじゃね？
179:デフォルトの名無しさん
20/07/12 23:43:13.36 oDnBGDI7.net
削除しなければすぐ4桁超えるし
4桁とかのフィルターかけたら処理速度はがた落ちする
処理速度の低下に気が付いてないだけ
>>175
いったん読んだログを破棄しないほうが時間の無駄だろ
おまえはいったん読んだメールも全部とっておくようなアホなのか？
180:デフォルトの名無しさん
20/07/12 23:43:29.17 cQ5/TUwm.net
元々フロントにテストなんてなかっただろ、いい加減にしろ！
Reactのせいでフロントまでテストしなきゃならなくなったんか？
181:デフォルトの名無しさん
20/07/12 23:51:53 vwiHN0KN.net
てかIDフィルターって時限で自動削除されなかったっけ？
182:デフォルトの名無しさん
20/07/12 23:52:53 vwiHN0KN.net
逆にNGワードがすぐ四桁越えるって言ってるんなら異常だよ
183:デフォルトの名無しさん
20/07/13 00:07:28.01 7n0GYdR/.net
だよね
184:デフォルトの名無しさん
20/07/13 00:11:44.77 ShQksDA
185:z.net
186:
20/07/13 00:20:48.80 0HNl98GR.net
単にスルー力を鍛えればいいだけのような気が…
NGワードなんて必要？私には不要です、スルーすればいいだけだし…
187:デフォルトの名無しさん
20/07/13 01:00:56.11 b4eaK6qk.net
スルー力とマト量子カってなんか似てるよな
188:デフォルトの名無しさん
20/07/13 02:48:03 vA9Bua7i.net
改行をNGにするとだいぶ捗るよ
189:デフォルトの名無しさん
20/07/13 07:17:50.44 r62CIauI.net
NGしまくるってことは5CHと相性悪いんだよ
別のSNSに移行したほうがいい
190:デフォルトの名無しさん
20/07/13 07:52:13.21 V+zIL/Eb.net
のとおり
191:デフォルトの名無しさん
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#で開発できてますってｗ