Vue vs React vs Angular Part.4 YouTube動画>2本 ->画像>6枚

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.3
http://2chb.net/r/tech/1560333895/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください

建て乙

このスレ、HTMLパーサーの話題OK？

前スレでご質問の在ったクルクルとは、Googleで検索して見ようとすると、これ見よがしにお待ちくださいのような感じのクルクルが現れる現象のことです。

パーサーはNG
クルクルの説明して？

NGすんなよ。
NGならここは俺の次スレではないな。

だってパーサーの説明ろくにできないじゃん

聞く方にだってある程度の理解が求められるだろう。
今のメンツじゃ話しても無駄だと思ったから、じゃあ終わりって事にしたんだ。
Gumbo貼ってきたり、Chromeから抜くと言ってみたりじゃ、ちょっと無理だろ。

スレを盛り上げていく中で、それHTMLパーサーで出来るよ？とちょこちょこブッコむ。
この流れで理解を得ようという作戦だよ。

できれば、Gumbo程度は使ったことがあるって人が居ると望ましいのだが。
事前に問題を共有できてるから、出発点が少し先に行ける。

パーサーとjQueryはNGワードに入れとくわ

パーサースレ立てれ
そっちで存分にやってくれ

O2

テステス

各社のサイトのソースをみてReact, Angular, Vueのどれかを
使ってるかを判別する方法ってある？

URLが変わらずにページ内容が変更されることが多いならSPAの
フレームワーク使ってる可能性あるとはわかりそうだけど、そこから先がわからない

Wappalyzerプラグイン入れるか
個別に
React Developer Tools
Vue.js devtools
Augury
入れるかじゃない？
後者で検知されて前者で検知されない場合もあって
その場合どっちが正しいのかよく分からん

どっちもChrome,Firefox版はある

プラグインっていうかアドオンか

>>15-16
ありがとう、SPA初心者でどれも名前聞いたこと
ないけどいれていろいろ試してみる
お手本となるSAPの使い方というかを有名サイトで学びたい

part4まで来てたのか。angular使いはじめたきっかけだからこのスレには少し感謝してる。

>>14
サイトを分析する、BuiltWith

https://builtwith.com/ja/

angular使ってるけどstyleの管理が悩ましすぎる…
cssに書いたりhtmlに書いたり、はたまたtypescriptのクラスとして作ってngstyleでバインドしたりで散らかってしまう。
もういっそ全部ngstyleってのもありなんだろうか

コンポーネント毎にCSS書くってのはどう考えても無駄だよね

グローバルに設定するための「styles.css」が「index.html」と同じ階層に用意されてるじゃないですか

tailwindでいいよ

vue書くの苦行すぎる
結構細かくルール指定するくせにこんなこともやってくれねえのっての多すぎ

いきなりSPAに挑戦する前に既存のマルチページアプリにJSフレームワークを小規模に導入して勉強したいんですが
古き良きMVCフレームワークとJSフレームワークを組み合わせて使う場合はvue.jsが良いのでしょうか？

vueはやめとけ
途中でやっぱReactにしとけばよかったってなる

SPAって挑戦するもんじゃないだろ
挑戦だと思ってるならやめとけ

最初の導入なんて誰でも挑戦みたいなもんだろ
挑戦してみた結果結局jQueryでいいやって人が大多数居るわけで

フレームワークをちゃんと導入できるところなんてほんの一握りだと思うよ

>>25
最初からReactでいいとおもう
VueはTypeScript使えないので却下

Vueはマークアップ言語のように書けてわかりやすいのが強みだ

みんなSPAで何つくってんの？
ページ遷移型Webアプリじゃできないようなことやってるの？

元々デスクトップアプリ描いてた人の立場だとSPAの方が造りやすいかも知れない

SPAはウェブサイトには相性が悪いからね

Angular勢少ないな
一番スッキリ書けて使いやすいと思うんだけどな

まあ落ち着けって
2年後にはSvelte以外オワコンになってっから

>>35
あれが流行る理由が逆に分からんのだが
VueとReactの良いとこ取りとか言ってる輩がいるがReactの良いところってhtmlじゃなくjavascriptを主に開発出来るって所だと思ってるんだがその辺台無しになってる

>>34
Angular
SPAではトップ3に入ってるのは間違いないでしょ
Angular自分は学習コストが大きいと聞いてやめてReact学習中

>>25
vueもいいよ。今でも少し込み入ったフォーム(検索や問い合わせ)だけvueで置き換えるのは十分あり。メンテナンス性が格段に上がる。
あと、むしろvueでtypescriptは使わない方がいい。vueの良さである気軽さが損なわれる。jQueryと共存なんて気持ち悪い事もできる。

>>37
angular使ってるけど初期コスト高いとは思わなかったよ。先入観で除外するのは勿体無いと思うぞ。

そういえばなんで日本でVue人気あるの？
海外だとあんまり人気ない印象ある

日本人はアホだからReactとか難しすぎるんだよ
単にそれだけ

日本人は自分で使って判断するって考えがあまりない印象
他人の評判ばかり気にするし優先するあほばっか

例のキチはいなくなったか

Web siteではなくWeb applicationを作るとして
習得の難易度でいったらどの順番で簡単？
React, Angular, Vueの比較で

「フレームワークを習得」とか言ってることに違和感があるんだよなｗ
必要なら使うだけなんだし

Ruby on Rails では、Bootstrap か、React が多い。
Vue.js は、見ない

コンポーネントだから、組み合わせやすいのだろう。
ある部品だけ、Reactを使うみたいな感じ

それに米国の企業だし

rubyのことは聞いてないから

>>45
ReactはFrameworkではなくLibraryだから、
他と組み合わせしやすいんでしょう

最近はRails関連でもReact使ってるのか
Reactはecosystemが充実してるな

Ruby on Rails + React + Bootstrap + Material UI

Elemental UI は見ない

>>43
それならangular,next(react),nuxt(cur)との比較になる。
ただ習得難易度を比較するのはあまり意味がないと思う。迷うなら全部入れて弄ってみた方がいい。世間の評価と随分印象が違う事に気づくと思うよ。
俺はvueが好きだが選んだのはangular。

Rubyやってるヤツの頭の中がいかにごちゃごちゃなのか分かる書き込みだな

Ruby on Rails では書き方を強制した、規約だけのStimulus も使う

それをリアクティブプログラミングにした、StimulusReflex もある

Vue3.0からクラスベースのコンポーネントって無くなるの？

ほらな。まーた今までの技術がオワコンになった（笑）

Reactでは随分前にそうなってたもんな

reactってSFC標準にならないの
ファイル数多いから敬遠しちゃう

スーパーファミコン

今どきスーファミとかだっせーよなー

時代はメガドライブだよな

ReactのHooksが登場してからは、Reactが一番導入のハードル低い気がするなー
Hooks系のライブラリ充実してるし

useEffectでjQueryと共存なんてキモチ悪いことも簡単にｗ

Vue3.0
7月にRC
8月に正式版リリース

どう変わるんや

reactに近づく
つまりreactでよくね？ってなる

つうかElmでいいじゃん…

svelteならまだしもelmはもう終わってるでしょ

でも色んなツール出た方が活性化していいと思うなー
変化が無い方が廃れるの早いやろし

vueのTS対応遅いからreactに移ったわ
JSXが嫌いだったけど慣れたら便利だな

Vue3.0はvueの書き心地の良さだいぶ減る気がする
リアクティブなデータが一段ネストされるのもストレス

reactってクライアントサイドフレワなのに
サーバサイド技術のnpmとかnode.js
がインストールに必要なの意味わからなくね？
なんでjqueryと同様にCDNで配布してsrcで読み込む
シンプルな形式にしないの？
トランスパイルって鯖と蔵どっちで処理してんの？

なんでトランスパイラそのものをライブラリ内に
組み込んでHTMLのsrcで読み込んでブラウザに仕事させれば
いいものをユーザにnpmとかyarnとかwebpackとか
reqireさせるわけ？
そしてなんで色々なやり方が錯綜する訳？

なんでPHPがapacheやMySQLとズブズブに
蜜結合してるのと同じ轍を踏むわけ？

実行時のリソース消費を減らすためだよ

ちなみにCDNとscriptタグの組み合わせも使えるよ

有名なフレームワーク・モジュールには、CDN もある

Ruby on Rails など、ウェブ系の開発者は、
VSCode, Node.js, Webpack などが必須

jQuery, Bootstrap, React なども

>>69
おめーがアホだから理解不能なだけだろが

>>69
>サーバサイド技術のnpmとかnode.js

この認識が可笑しい

>>67
確かにvueのtypescript対応は不親切。
てかいい加減公式サイトぐらいtypescript対応しろと。

>>72
だからお前いつもグルーピングがおかしいってば

rubyｶﾞｲｼﾞに触るな

>>69
トランスパイルは、サーバー側でする。
その開発環境が、Node.js

もし、JSX で書いて、それをブラウザでトランスパイルすると、
時間が掛かるので、推奨されない

だから事前に、Node.js, Webpack, Babel, Browserify, Uglify, CssShrink, AutoPrefixer などで、
ES2015, JSX などを、ES5 に変換しておく

なんでガイジ鯖でトランスパイルなんてとんちきなこと言ってんのかと思ったけどもしかしてc9みたいな環境でやってんのかなこいつ？

トランスパイルの手順も、タスクランナーのGulp か、
プロジェクトのpackage.json 内の、npm scripts に書いて実行するだけ

watch 機能を書いて、ファイルを保存するたびに、自動的にトランスパイルすることもできる

Ruby on Rails では開発用サーバーに、webpack-dev-server を使う

そもそも、ブラウザでトランスパイルするのは、全ユーザーが同じ変換をするから無駄

サーバーなら、1回の変換で、全ユーザーに対応できる。
変換後のHTML を送るだけ

めんどくせーならNuxtでも使えや。

Docker か何かの開発サーバーじゃないの？

漏れは、自分のPC 内のWindows 10, WSL, Ubuntu 18.04 で、
VSCode の拡張機能、Remote WSL を使って、
Linux側に、プロジェクトを作っている

Windows側からのブラウザアクセスは、
VSCodeの拡張機能・open in browser ではローカルファイルアクセスとなるので制限されるが、
VSCodeの拡張機能・Live Server では、サーバーを立ててのアクセスとなるので制限されない

Linux側には、日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv を使って、
ruby 2.6.6, node 12.16.2 を入れた

yarn は、Windows側に入れて、WSL から、拡張子なしのyarn コマンドを呼べる。
これは、#!/bin/sh で始まるシェルスクリプト

anyenv は多言語向きで、rbenv, nodenv, pyenv, phpenv などを同じ使い方で、統一的に扱える。
同様のツールに、asdf もある

devcontainerのほうがいいでしょ
環境切り替えが楽チン

anyenvとかすぐに重くなるから嫌い
なんとかenvは全部作り直せと言いたくなる

phpenv が重いのは、すべてのファイルをコピーしているからとか、

何かのサイトに書いてあった

Stoyan Stefanov の本には、Babel, Browserify は、

グローバルにインストールした方がメリットが多い、とか書いてあるけど

>>81
そうじゃなくて、reactっていうかJSXのトランスパイルはrubyｷﾁｶﾞｲであるお前以外の99%はブラウザでもサーバでもなくフロントエンドの開発マシン、要は手元のPCでビルド時に行うの。

いや俺はデプロイ先のコンテナでビルドするように設定してるけど

それはないな
起動が遅いのはコンテナでは許されない

>>90
リリースのたびにローカルの開発環境でnpm run buildみたいなコマンド打って、トランスパイルされたjsファイルを手作業でアップロードみたいな作業するの？
零細サイト(アプリ)ならありかもしれないが…

なんで手動って決めつけてんの？
ビルドプロセスにデプロイも含めるでしょフツー

>>91
Laravelならプロジェクト一式の中にwebpack関連の一式も入ってるけどね

>>91
手動でアップロード？
意味わからんこと言うなよ

>>91
tsファイルの変更を自動検知して.jsに自動でトランスパイルする設定で
開発するのが普通なんじゃないの

>>92
deployっていう用語は開発が終わって本番サーバーに移すときに使う感じでしょ

開発中のこまめな修正はbuildだから
buildとdeployはセットにしてしまうと不便
頻度が違いすぎる

インフラ屋には「開発」って概念がないからｗ
あいつらは出来上がったものを配布するだけ
配布するときにビルドが必要かどうかってことしか知らない
ビルドだけが必要という発想がない

CIでビルドからデプロイまでやるわなフツウ
毎回デプロイまでプロセス進めるわけでもないが
なんらかのトリガで自動デプロイまで整ってないとしんどいよ

蔵「ここに要素追加で！中のここのテキストは決まり次第連絡します」
ワイ「よっしゃ手空いたし実装すすめたろ！ここのテキストは適当にうめとこ！できた！フロントビルドして表示確認したろ！」
CIとやら「ビルド＆デプロイ！」
本番サイト「おちんちんびろーん」
蔵「…」

手動デプロイする人、ビルド構成1つしか使えない人、いろいろいるんだなあー

手動デプロイって人数1人の超小規模開発だけだろ

なんかこのスレ、
・開発中のローカルサーバーでのビルド
・本番等へのデプロイ時に行うビルド
をごっちゃにしてる奴が居て話が噛み合わないわ

どっちも同じだろ
パラメータ少し変えるだけだし

ほらね

まさかローカル用とデプロイ用で分けてメンテしてんのか？
DRYはどこに行ったんだ

ハァ？なんでローカルの開発マシンで既にビルドしてるフロントをまたサーバーでビルドするんだ？
腐った思考がグルグル回ってんのはお前の頭ん中だけ。DRYじゃないのはお前。

>>105
はぁ？
開発中はローカルでビルドするし、CIサーバーでもビルドする
当たり前のことだろーが
お前、はっきり言って意味わからんよ

言うほどローカルでビルドする？

>>104
そもそもローカルではwebpack-dev-serverとか使って効率化するだろ。
お前…まさかファイル更新する度に毎回ビルドコマンド打ってるのか？

>>105
そもそも本番とかってリリース用のブランチと同期しながらリリースするんだから開発マシンとか関係ないだろ。
お前…まさか自分の開発マシンでビルド　したファイルを直接本番とかの環境にデプロイしてるのか？

てかそもそもローカルで開発やってんの？

本番機械にデプロイしてから
デバッグしてるよ

両方成敗されててワロタｗｗｗｗｗ

デプロイとか書くのやめたほうがいいよ
バカっぽいから

deployの発音と全然違う

デッポｫイ

>>108
今はコマンドを打つかウォッチで自動化するかどうかは関係ない
どっちにしろ構成は同じだ

ディプ・ローイ

gulpとかbabelとかwebpackとかyarnとか本末転倒なんだって
そんなものこれっぽっちも使いたくないんだよ。

楽したいと思うからフレームワークに頼るわけであって
使えるようになるまでコマンドいくつも叩くくらいなら
ネイティブJavaScriptで全部やりゃいいだろってなるわ

じゃなんでこのスレ開いたんだ

>>116
はっきりと勉強したくない（努力したくない・技術力をつけたくな）って言ったらどうか？
技術者の道具っていうのは自動車でも飛行機でも
技術力をつけて初めてさらに高度なことが出来るようになるもの
勉強しないで使えるものじゃないんだよ

npm install && npm run watch
たったこれだけやん
あとはソースの更新を自動検知して再ビルドしてくれる

あ、Laravelの場合はね

確かにwebpackはクソ。
俺はビルド設定職人じゃねえっての。
何にでも設定あるのは仕方ないがややこしいすぎめんどすぎ設定方法すぐ変わりすぎ。
投げ捨ててsnowpackを使うことにした。
webpackはとっとと滅べ！

Ruby on Rails は普通、Heroku を使う

Rails 6 からは標準で、Webpack。
プロジェクト内に、node_modules もあるし、
最初から、Yarn に、便利なコマンドも登録されている

webpack-dev-server も入っているから、
最初から、ソースコードの変更をwatch している。
VSCode の拡張機能・Live Server のwatch と同じ

有名なYouTuber、雑食系エンジニア・KENTA も、
CircleCI も必要だって言ってるだろ

>>116
ほんとだね

Node.js, Webpack, Babel, Browserify, Uglify, CssShrink, AutoPrefixer などが無ければ、

ES2015, JSX などを、ES5 に変換できない

どんだけ必要なんだよww
馬鹿かよビルドばっかでReactの本題がほとんど頭に入らんわ
ちゃんと整理しろよwwww

あの程度のツールの組み合わせもまともに理解できないような輩は
プログラムを仕事でやるのは辞めてほしいわ。
railsなんか使っても何がどこに作用してるかわからなくて糞コードになるのが目に見えてる。

>>125
必要じゃなくてLaravelやRailsならもうプロジェクトに一式入ってる環境が整ってるからビギナーが気にする必要ないわけよ

>>125
てかReactとか普通に入門書やらチュートリアルサイト見ればNode入れてcreate-react-app入れたら
create-react-appで新規プロジェクトを作成してnpm startやるだけって書いてあるだろ
それすらできんって言うんならプログラミングの才能ないからやめた方がいいぞ

魚捌けなくても寿司は食えるみたいな

CPUが古いからかcreate-react-app、実行したら2分くらいかかるんだけど
新しめのRyzenとかだとどれくらいでcreate-react-appの処理終わるの？

>>128
チュートリアルの最初にcreate-react-appでてくるし
プログラミングの才能とかそんなレベルの話じゃない気がする

しかしReactの公式ドキュメントはそのあと一気にハードルあがる
いきなりゲームを作りましょうとかの解説になって挫折したわ
ゲーム作りはチュートリアルのレベルじゃないだろ！とツッコミたい

YouTubeの解説とかのがよっぽどわかりやすい

Bootstrap があれば、CSS 知らないでも、レスポンシブ対応できる

create-react-app は良いけど、
その後、どこから無料の、awesome なコンポーネントをパクッてくるのか、それが重要

Material-UI か？

Rails なんて、React からのコンポーネントのパクリしか考えていないw

青色のボタンを使うと、Bootstrap 臭がするとかw

Rails は今や、Node.js, Webpack, React からのパクリしか考えない、段階に入ったw

別にプロジェクトのイニシャルやるのに2分くらい掛かってもいいだろ
変更検知ビルドで2分掛かってたら大問題だけど

>>131
アイコンなら普通にReactDOMにリンクするdivタグがあるhtmlでcdn読み込みすればいいんじゃね？

>>130
CPUじゃなくて回線速度じゃねえの

IDEで新規プロジェクト作成に２分も掛かってたら待ってらんない
SQLのクリエイトデータベースでもそんなにかからない

遅いのは主に回線速度なのかなぁ？
みなさんは、create-react-app、何秒間で終わる？

>>136
Visual StudioでC#とかやってたから2分は相当長く感じる

create-react-appでプロジェクト作るところを言ってるのか、そのあとのbuildのことを言ってるのかどっち

だいたいwebpackのせい
滅びろ

>>138
もちろん、時間のかかる前者。project作成みたいな作業
ほかのひとは何秒くらいかかってるのかな、と
自分は120秒超えてたはず

そのあとのbuildというのはbuildしてる感覚はないのでよくわからない。
VSCodeがtsの変更を監視して.jsに変換するのがbuildなんだろうけど、
JSがcompile不要言語だからbuildといわれてもしっくりこない
後者は1秒未満

だいたいトランスパイルが面倒さの原因だしtsのまま動くようにしてほしい

よくもまあHTMLに埋め込むだけで動作する
シンプルなJavaScriptをここまで複雑にしたもんだ

開発環境複雑なのはマジでゴミだと思うわ
ツール名並べてビルド環境自慢してる奴はおもちゃ
組み立ててはしゃいでるガキと同じ。
そもそもそんな糞みてーなビルドなんかなくても動く
言語だったこと忘れてるみたいですね。

>>142
シンプルで済むのはお前が一人で作るカップラーメンのタイマーくらいなんだが

てかjQueryでいいわ
俺はフロントマウント界隈から降りるぜ

どうせビルドするならトランスパイルじゃなくてアセンブリでいいんだよな
Webasmがウェブの正当進化
これから先の時代ではビルドプロセスを間に挟むならWebasm
そうでないならJSと分化していくだろう
数年後にはJSでSPAやってる人は居なくなる

reactのテストってどういう風に書くのが正解？

>>141
全部のブラウザがTypeScript動くようにすればいいだけなんだよな
それでJSは開発終了でいい

そうだね
ブラウザでTypeScriptが動くようになるかJavaScriptがTypeScriptの機能を取り込んでいくのか分からんけど
トランスパイルは過渡期的な技術だと思う
5〜10年後には無くなっているだろう

マイナなんたらはIE11でしか申し込めないんだっけ？

wasmが直接実行できてDOMも生で触れたらJSなんていらないけどね
てかこのRFCとかないの？

・・が直接・できて・も生で触れたらJSなんていらないけどね
てか・・とかないの？

WebAssemblyでweb app作った場合に
ブラウザからソースとかはみえないんだよね？

開発する側にとってはソース見えないのは大きなメリットだけど
ユーザー側はセキュリティ的に実行していいコードなのかどうやって
判断するんだろ

>>149
smartphoneでも申し込めるんだからIE11限定はあり得ないでしょ

>>149
あんなの逆に既存ブラウザに拘らずにWin/Macでそれぞれ専用ブラウザアプリ作りゃ済んだ話なのにな

まあjqueryに適切なネームスペース設定があればって話もわからんではないけど。
でも結局静的チェックは必要だろうなとは思う。
jsはあまりにぐにょぐにょすぎる。

適切なネームスペース設定ってなんだ？jQueryに限った話なのか？

自分がぐにょぐにょだったというオチ

普通に考えたらvuexとかのフレームワークが提供するnamespace機能じゃねえの？

レガシー技術しか触らせてもれないエンジニアがいっぱい居るんだなぁ

VBAスレが勢い2位の板ですし

「触らせてもらえない」って変な表現だな。
もし触りたきゃ個人的に触るだろ。
単に必要がないだけじゃないか。

実際、サーバーサイドのAPIと通信したり、VuexやReduxでやるような状態管理が求められないようなアプリにフロントフレームワークがオーバースペックだっていう意見は同意する。

VueとかReact使うとフロントが楽なのは当然として、サーバーサイドも楽になる。
サーバーサイドはAPI化してJSON返せばいいだけになるし、ネイティブアプリ対応もサーバーサイドはワンソースで済む。

wordpressのような、htmlにサーバーサイドの変数を埋め込んでからレンダリングするようなレガシーアプリだと、言語がphpかrubyあたりに制限さられるし、何より密結合でクソ汚いコードが生成される。
逆にAPIへのリクエストが頻繁するようやサイトでjQueryだの生JSだの言ってたらメンテナンス性や開発効率は最悪だろうね。

あとはテストの書きやすさも違うと思う。
MVCに則ったサーバーサイドの場合、Controllerのいわゆる機能テストはViewの代わりにJSONになるからすごくシンプルになる。（Modelのメソッド単位のユニットテストになると関係無いけど）

俺はサーバーサイドのテストはよく書くけど、フロントのテストはあまり書かないんだよね。（e2eテストって難しいし）
それでもフレームワークの有無の違いでテストの書きやすやが全く違うのは誰でも想像できることだと思う。

それって DOM to JSON みたいなシリアライザがあれば
DOMのテストは簡単にならんか？

Ruby on Rails のシステムテストは、Capybara, Selenium とか

Page Object みたいなデザインパターン

今日のNG確定

>>164
ワードでNG掛ければよくね？

「今日の」ね。
ワード単位なら分かるけど、こんな過疎スレでわざわざID単位でNGしたくなるって、どんだけ効いたんだろ。

そんなたいした作業か？
ロングタップしてNGIDに追加押すだけじゃんｗ

このスレにだけ出没するってんなら
そんな大した話でも無いんだがな

NGとか解除の手間考えたらやらない
この程度スルーできないでよく5chできるね
いちおうプログラミングの話だしNGするほどのことじゃない

>>163
Railsおじさん
いつもJSと関係ない脱線した話ばかり
Railsなのに脱線しかしてない

なぜ解除する必要が？一生NGだぞ。
過去ログ読む際出てきたら困るわ。
てか解除する人なんて聞いたことない。

Ruby on Rails のBDD, RSpec を知らない香具師は、

Jest, Jasmine も知らないと思う

>>170
5ch、特に技術系の話題なんて過去の情報に価値がないし
過去ログなんてまず読まない。
あとで必要になりそうな重要なレスはtext fileに保存しておく
そうしておかないと探す時間の無駄になる

プログラミングするやつがNG解除の理由わからないとはやばい。
NGチェックのために無駄な処理が増えて動作が遅くなっていく

NG追加しつづけるなんてことやってるひとは
非効率なコードを書いてる人だわ

NGIDなんてボコボコ追加しても全然読み込み速度落ちないから解除の必要ないけどね
楽をしても全く問題が生じない箇所でも無駄の無い凝ったコードを書くタイプと見た

>>173
仮に速度が落ちないとしても
すでに読んだログを残す行為自体が時間の無駄でしょ
必要な部分だけ残して削除しないと無駄になる

すでに読んで不要になったメールを残しておくのと同じで
すごく時間の無駄になる

コードは最初からスケールアウトを意識してコード書いてる

解除するのが時間の無駄だわバカらしい

>>172
俺も>>170もNGを解除する必要がないと考えてるからワードNGしてるだけだし
お前がそう思うんならそれでいいんじゃね？

削除しなければすぐ4桁超えるし
4桁とかのフィルターかけたら処理速度はがた落ちする
処理速度の低下に気が付いてないだけ

>>175
いったん読んだログを破棄しないほうが時間の無駄だろ
おまえはいったん読んだメールも全部とっておくようなアホなのか？

元々フロントにテストなんてなかっただろ、いい加減にしろ！
Reactのせいでフロントまでテストしなきゃならなくなったんか？

てかIDフィルターって時限で自動削除されなかったっけ？

逆にNGワードがすぐ四桁越えるって言ってるんなら異常だよ

だよね

いつまでもNGについて議論してるお前たちが一番スレチだって分からんのか

単にスルー力を鍛えればいいだけのような気が…
NGワードなんて必要？私には不要です、スルーすればいいだけだし…

スルー力とマト量子カってなんか似てるよな

改行をNGにするとだいぶ捗るよ

NGしまくるってことは5CHと相性悪いんだよ
別のSNSに移行したほうがいい

のとおり

QZの文字が観えたら読み飛ばすカは付いたと思う

「NG」をNGワードに追加したほうがいいなこりゃ

荒らしは、どんな時刻でも必ず、前のレスに賛同するアンカーを付けて、2回書き込む。
必ず、大勢の人がいるように見せかける

多くのスレで、死ねと書き込んでいるのも荒らし。
無視した方がよい

Python のスレのテンプレも、勝手に書き換えてる
>当スレに★Python以外のプログラミング言語での回答類を書くべからず★
>「Ruby では」「Rubyでは」「某言語では」をNGワード登録推奨

3大コテハンなど、目立つ香具師には攻撃していくから、無視すべき！
荒らしは、無視されるのが大嫌い

そう思うなら無視しろよ

>>191
ID:LmgOQRQZこそがム版で一番嫌われている荒らしなんだわ

reactが老害化してきたね。
うちの会社（そこそこ有名）はvueが主力になった。

世界の潮流に合わせられないゴミのような会社
社員もゴミだからReactが難しくて使えないらしいな

難しいとかいう視点でしか判定できない奴ｗｗｗ

まんま老害で草

Elmでいいじゃん

どっちもSvelteに対応できない老害

>>152
JSのソース見えても、使う側にはセキュアかどうかなんて分からんから同じ。
それにそもそも、ブラウザ内アプリはサンドボックス化されているので、
マシン本体にはウイルスを感染させることはほぼ不可能。
あるとすればフィッシング詐欺的なものだけで、それもソースが見えるかどうかより、
URLを本物かどうか確認することと、実際にメッセージが出てきた時に本人が気をつければ済む話。

それにソースがあろうがなかろうが、セキュリティーソフトに取ってみれば、同じ。
むしろ、Wasmのバイナリ形式の方がセキュリティーソフトには解析は楽。
というか、そもそもブラウザがサンドボックスなのでマシンには感染できないし。

もう開発するの疲れたよ。

Reactが老害化してきてるのは間違いない
無駄にバージョン上げるくせに全然進化しないしな

パクリ先が進化してくれないとパクれなくて困るもんなｗｗｗ

>>202
ころころと変わりすぎるJS界隈のなかでは
変化しすぎないのはむしろいいことだろう

>>199
WebAssemblyはC#とかでかけるから興味あるんだけど
WebAssemblyメインで作ってる大手サイトってあるのかな？

Vueにチャイナリスクがあるとか懸念されて承認が下りない

中華製の部品を使えないとなるとパソコンも許可が下りなくなる

外人は既に、Facebook 製のReact を使っているから、
中国製のVue.js へは移行しない

Reactの日本語訳が、2回表示されるから、ちゃんと直してほしい

それと、Webpack も日本語化してくれ

>>203
なるほど判り易い

snowpackが出たからwebpackはオワコン。
チャンク分けが後付けされたとは言え、基本的にひとつのバンドルにまとめるという思想がhttp1.1時代の時代遅れの化石。
加えて設定APIがクソかつすぐ変わるゴミ。

そして3年後・・・snowpackはオワコン！

その間webpackとかいうゴミに煩わされることがないからプライスレス

create-react-app使ってるからwebpackがどうのとかあんまり意識したことないわ

React使ってて
create-react-app使ってない人なんているのか

>>208
中国人も外国人。
外人は差別用語なので外国人と呼ぶのが知識人

>>214
Laravel-Mix使えばなくてもいける

vueがreact化して悲しい
もうreact移行するかな

>>215
LaravelってPHPだっけ
PHPで開発しないひとがLaravel-Mix使ってなにかメリットはでてくる？

単に↓への回答
>React使ってて
>create-react-app使ってない人なんているのか

>>214
あれって試作とか練習くらいにしか使わないもんだと思ってた。

Reactってなんとなくかっこいいから初めて見たけど
具体的なメリットって何なの？
ただ単に構築面倒にしてるだけじゃん

SPAが爆速でつくれる

>>220
何と比較して面倒なのか分からん

>>220
色々部品化進めて行くと段々開発効率が上がってくる

>>223
今までにどんな部品を作りました？
部品はいくつありますか？

だから小中規模はvueって言われてるんだろ

Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。

公式リポジトリに日本語ドキュメントあったｗｗｗ
https://github.com/alpinejs/alpine/blob/master/README.ja.md

>>220
比較対象を書かないと伝わらない。

Reactはframeworkじゃないから面倒なんじゃないか
Reactは単体だとUIまわりだけのLibraryなわけ。

効率あげるにはFrameworkと併用したほうがいい。
ReactベースのNext.jsというframeworkのtutorialみたら印象変わった。

React使ったweb appはたいていNext.jsも使ってるんじゃないかな
統計データは持っていないが

Reactはframeworkだよ。
フレームワークは他のフレームワークと共存できない
Reactも共存できないのでフレームワーク

React – ユーザインターフェース構築のための JavaScript ライブラリ
https://ja.reactjs.org/

React
https://ja.wikipedia.org/wiki/React
React (リアクト) は、Facebookとコミュニティによって開発されているユーザインタフェース構築のためのJavaScriptライブラリである[3]。

React単体はView部分専業のライブラリ。
フレームワーク　で　は　な　い。
ReactをView構築担当パーツとして採用した　フ　レ　ー　ム　ワ　ー　ク　には以下のようなものがある。
Next.js by Vercel - The React Framework
https://nextjs.org

GatsbyJS
https://www.gatsbyjs.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
https://redwoodjs.com
Bringing full-stack to the Jstack. An opinionated framework that combines React, GraphQL, Prisma2, SQL, and lots more out of the box.
https://github.com/redwoodjs/redwood
Redwood is an opinionated, full-stack, serverless web application framework that will allow you to build and deploy JAMstack applications with ease.

これらが　フ　レ　ー　ム　ワ
ー　ク。

>>229
お前の脳みそが現実と共存できてないだけだったなｗｗｗ

React単体だと新規アプリの書きはじめは少し面倒だね
デザイナーがいる場合は特に
すでにあるものをいじるのはめちゃくちゃ楽だけど

>>229
違う
ReactはframeworkではなくLibraryだ
公式にもそうかいてあるし
実際にUIまわりの機能しか持ってない
web frameworkと呼べるほどの機能はない

だからReact単体で開発しようとしたら
めんどくさいのは当たり前なの
Frameworkに相当する機能が揃ってない

>>234
reduxとかrouterとか定番のセットを組み合わせれば十分だし別に面倒と言うような事はない

routerくらいだろ、必須なのって
小・中規模のアプリなら状態管理はhooksの機能で十分

jQueryで十分！
→だからjQueryはフレームワーク！！

lodashで十分！
→だからlodashはフレームワーク！！

フレームワークは、Next.js とか

React は単なる、UI ライブラリ・部品だから、
Ruby on Rails, Bootstrap と組み合わせる

一方、Rails + Vue.js は、ほとんど見ない

何かを作るのに十分云々じゃなくてフレームワークの構成要件として十分かどうかの話

>>237は状態管理やルーティング以前にライフサイクルもないだろ

Next → フルスタックフレームワーク
React・Vue → マイクロフレームワーク
Angular → ？

ザコはすぐ造語作りたがるなｗｗｗ
強制連行ｗｗｗｗマイクロｗフレームワークｗｗｗｗｗ

いや俺が作った単語じゃねーぞ
wikipediaにも載ってるし

本当に愚か者だな、お前は。
https://en.m.wikipedia.org/wiki/Microframework
マイクロフレームは、ミニマリスティック ウェブ アプリケーション フレームワークを指すために使用される用語である。フルスタックフレームワークとは対照的です。

次のような本格的な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ライブラリはマイクロフレームワークか？
バリデーションライブラリはマイクロフレームワークか？ええ？
英語読めなかったのか？あん？
読めないにしても翻訳機能使う知恵もなかったか？

>>242
wikipediaなんて誰でも編集できるし
分類なんて人それぞれ

ReactはFacebookがLibraryといってるんだからそれで確定だ。

公式見解を尊重する限り、
Vue → framework
React → library
Angular → framework
ってことになるな

ちなみに僕の公式見解は
僕 → Zetsurin
だよ。

reactはライブラリなのかフレームワークなのかquoraで聞いてみようぜ
って思ったら英語版にはすでに質問あったわ

>>228
比較対象はネイティブJavaScript
ただ単にDOM操作するだけだぜ？
ビルドいる？

ネイティブJavaScriptがそんなにもっさり重いの？
なんもコマンド叩かずにコーディングできるんだよ？
HTMLに直接書けるんだよ？

人によってはframeworkに分類しちゃうけど
公式がLibraryと言っている以上、Libraryなのだ。

routingすらないReactをweb frameworkと呼ぶには無理がある

>>248
え、frameworkもLibraryもTSも使わず
生のJSでちっぽけなアプリ書いてる人だったのか

そんなやり方でまともな中規模以上のアプリ作れない
生産性が低すぎる
いまどきHTMLに直接コード書くなんて論外だろう

>>250
単なるGUI制御がHTMLに組み込んで何が悪いか
じゃあお前がどんだけグレートな規模のプロジェクト
手がけてるか紹介してみろやカスが

>>248
そりゃカップラのタイマーにReactはオーバースペックだろ…

もしgmailのフロントを生JSで書けって言われたら逃げるわ

自分でJavaScriptのライブラリ作ればいいんやで！

名前はoreoreactにしよう

Blazor面白いね
あとは読み込み速くなればJS要らなくなる

ブラジャー？

流石にIIS依存のものはなぁ…

adobe airのときもsilverlightのときも同じこと言ってたよそいつ。
懲りない奴だｗ

>>258
何言ってんのこいつw

>>258
昔の知識のままの人か？
Blazorも.net Core対応と書いてあるし
.net CoreならLinuxやMacでも動くはずだ
Blazorのhelpにもapacheとかがかいてある

いうてもApacheでASP.NETとか使ってるヤツ居るの？

今から使い始めるならIISよりはapacheだろ

>>262
言い訳する前に知識が古かったのを認めろよ

Linuxでasp.net使いたいニーズがあったからこそ対応したんだろ
ApacheだけでなくNginxもかいてある

https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-3.1

あとweb frameworkで一番シェア高いのはASP.NETだぞ
WordPressとか間接的にframework使ってるの除いたらシェアトップ

>>262
うちはnginx, asp.net core api, asp.net core MVC+Vue

>>263
この文脈でIISとApacheを比較するのかよ・・・
この文脈でのIISはWebサーバーとしての側面ではなくアプリケーションサーバー（.NETコンテナ）としての話だろ
比較するならApacheやnginxではなくTomcatやGlassFishだと思うが

>>266
おまえもApacheやnginxでASP.net Coreが
動かないと思ってるのか？

Blazor ServerってSSRだよな
このスレに関係ないじゃん

>>265
OSとDatabaseは何使ってるの？
遅いのは最初の読み込みだけ？
Microsoftのデモ動画みたら動作も遅いように見えた場面が
あってパフォーマンスどうなのかなと。

WebAssemblyでいい性能出るならC#で書きたい
JSもTSもめんどくさい

>>267
Apacheやnginxでは.NETは動かないだろ？
まさかなーと思って今調べてみたけどやっぱり動かないみたいだぞ

検索してみると出てくるのはdotnet runでポート5000をリッスンさせてApacheやnginxをリバースプロキシとして表に立たせる構成ばかりだ
これはdotnet runプロセス自体がアプリケーションサーバーの役割を担ってるだろ？
Apacheやnginxで.NETが動くのとは程遠い話だ

俺がまだ勘違いしてるのか？
もしApacheで.NETが動くというのならmod名とか教えてくれ

>>267
すまんがASPに対しては負の遺産という印象しかない

>>270
それ言ったらnginxでphp使う方法と変わらんからASP厨がドヤ顔でえばるだけやぞ

PHPとかnginxのことは知らんのだけど
Apache + PHP だとCGI（別プロセス）で動かすのではなく、Apacheプロセス内で動かす専用modとかあるんでしょ？
そのくらい特化してたらApacheで動くと言ってもいいと思うが
リバースプロキシ立てただけで「Apacheで動く」は恥ずかしいよ

>>273
nginxの場合php-fpmっていう別サービスを立てて
nginxのリバースプロキシでポートもしくはソケット経由でphpのリクエストをphp-fpmに渡す様な形式

>>269
RDBはポスグレ
起動も思ったより早いよ
リクエストはまじで爆速

>>274
ありがとう
nginx + PHPにもphp-fpmという専用のFastCGI機構があるのね
ここまで特化してたらnginxでPHPが動くと言ってもいい

だがdotnet runは構成がまったく違う
Apacheやnginxはdotnet runを特別に扱ってないし関知もしてない
やはりApacheやnginxで.NETが動くとは言えないな

スレタイ読めないのかな？
npm trends

>>277
angularと@angular/coreの違いについて頼む

>>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単体で動かしてもいい
おそらくそれが最速になる

kestrel(dotnet run)を否定しているわけじゃないよ
それは単体でHTTPを話す能力を持ってるじゃん
つまりTomcatやGlassFishと同じ位置付け
Apache、nginx等のWebサーバーを手前に追加するもしないも自由

でもそれは「Apacheで.NETが動く」という話にはならない

>>273 >>280
従来型のASP.netはModとかFastCGI対応していた。
Linuxでうごくこういうやつがあった
https://www.mono-project.com/docs/web/aspnet/
Monoは互換性がいまいちなので個人的にお勧めしない

ASP.net CoreをKestrel単体またはKestrel+(Nginx or Apache or IIS)
で動かすのが今のMicrosoft推奨のやりかた。

高速に動くなら内部の仕組みはどうでもいい話だろう？
あとは重要なところでLinuxで動いてライセンス無料になってるんだし
Modがあるかなんてどうでもいいよ。

そもそもApacheは高速なWeb serverじゃないの知ってるの？
あえてApache選ぶ理由がないよ。
大規模サイトはNginxが多い

>>280
古い知識のままでIISやWindowsのライセンス料を払わないと
動かないと勘違いしてる人が多いし
そういうひとにはApacheで動くといった方がわかりやすいだろ

.net知らない人にKestrelがどうこういっても伝わらない。
あなたもdotnet runとかしつこくかいてるし。それはただのコマンド。
多くの人が知りたいのはLinuxでライセンスフリーで使えるかどうかだから

Apacheに乗せるなんて無駄なことしたくない
Nginx RP + Inproc Httpがスマートで最高

静的コンテンツのレスポンス高速化のためだけにリバースプロキシ（Apache, nginx）置くわけじゃないから
俺は認証の柔軟性の高さでApacheを使い続けてる
LDAP認証の設定とか慣れちゃってるからね
nginxでも同じことはできるんだろうけど俺にとっては乗り換えるほどの動機になってない
静的コンテンツ主体の大規模サイトじゃないからね
だいだいのリクエストが後方のアプリケーションサーバーに流れるので俺にとってApacheは認証用なの
同接数の劣るApacheを使い続けてることを恥ずかしいと思ったことはない

最近はApacheを知らない若者も居るようだ
知ってても学校でさわりだけやりましたみたいな
先にNGINXでやってみてできないことがApacheでできるならApacheを検討する
若者の間ではそういうことになってるらしい

Nginx は、リバースプロキシ

世界最速は、Ruby on Rails 製の
https://dev.to/

これよりも速いものは、作れない

最近JIT対応したPHP8のalpha版が結構いいスコア出してるそうだがな

>>278
angularは1系で@angular/coreは2以降じゃないかな
しっかしReact圧倒的だね

1系ってAngularJS表記なんだと思ってたがそうじゃないのか

Reactってjadeと互換性あるの？
HTMLや動的テンプレファイル上に
直で書くとサーバ変数そのままJavaScriptに
埋め込んでコーディングできるから
.jsファイルの外部化は個人的にかなり抵抗感がある

フロントエンドのライブラリだというのに
って言いたいところだけど最近はバックエンドでも（たいていBFF止まりだが）使っちゃったりするから説明がめんどくさい…
端的に言うと、バックエンドのテンプレートはそのままPug使ってりゃいいよ。
JAMスタック構成にしてくと、あくまでバックエンドにPugのようなテンプレートエンジンを使わなくなっていくのであって、バックエンドのテンプレートの代わりにReactを使っていくようになるわけではないからだ。ほんとにこれはもう全くない。
全然端的に言えてないなうん

>>287
PHPは言語がうんこすぎて
ベンチマークいくらよくても使う気にならない

phpはhtmlに直接サーバーサイド変数を埋め込めるという点で負の遺産を残しすぎた。
wordpressだのsmartyだの吐き気するわ。

>>293
それの何が悪いの？

バックエンドなんてフレームワークで構成してJSONやり取りするもんだからそんなの別に気にする事じゃないだろ

>>275
PostgreSQLか

爆速いいね
TypeSafeだしVisualStudio使えるしC#でWebAssembly最強になるかも

C#使えるしReact+Next.js勉強やめてWebAssemblyやろうかな
WebAssembly、既に本番環境で使えるレベルのクオリティだと感じる？

> React+Next.js勉強やめて

勉強し始めて、終わらなかったってこと？ｗ
たかだかReact+Next.jsが？ｗ
そんな頭じゃ何やったって時間足らんだろｗ

>>297
俺が何時間やったかも書いてないのにそんなレスつけてしまうおまえが頭悪い

あと頭いい人はそうやって文末にwつけないしアンカーをつける

なるほどつまり数時間やって分かんなくて嫌になってwasmならできるモン！ってことか。説明ご苦労。

そんな根性じゃ何やったってモノにならんだろｗｗｗｗｗ

WebAssemblyに夢見過ぎなヤツ多いな
そんなに速度が必要な事をやってるのかと

>>300
速度は大事だろ
動けばいいレベルで満足しちゃうの？
例えばECでも遅いとすぐユーザー離脱して売り上げおちる

夢見すぎ？
WebAssemblyはほとんどデメリットが見当たらない
最初の読み込みが少し遅そうということくらい。

実行スピードだけでなく開発の生産性も高いのだから
JSのSPA開発はすぐ駆逐されると思う

Blazorはサンプル動かすまで超簡単
あれこれ聞く前に自分で試したほうが早いよ

dotnet sdkの最新版を落としてインストールしたら

dotnet new blazorwasm
dotnet run
これだけでBlazorが動く
頭の悪い大量の設定を書く必要はない
小学生やお猿さんでも簡単にできる

ちな↑は完全に静的なサイトを作りたいとき
サーバーサイドAPIも作りたいなら
dotnet new blazorwasm --hosted
dotnet run
これでおｋ

サーバーサイドレンダリングしたいなら
dotnet new blazorserver
dotnet run
これでおｋ

>>301
ECでボトルネックになるのは大体の場合サーバーサイドだろ

>>299
根性とかアホじゃないか
C#やJavaで開発してきた人がTSの開発を理解できないわけがない

>>303
server sideが負担かかるのはあたりまえ。
RDBがボトルネックになりやすいし
Shardingとかを使うめんどくさい世界になる。NoSQLでもいいけど

速度の重要性が理解できない人でも開発の生産性は理解できるだろう。
DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
まとめてデバックできていた。
しかもTypeSafeで即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？

wasmの求人需要ってある？

1ミリもない

自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ

>>304
根性じゃなきゃやっぱり頭のほうかｗ
数時間かけても理解できずに止めたんだろ？なんかゴメンなｗｗｗ

理解できないことはないんだろうけど
拒否反応を起こす人は結構いるね

JavaやC#やってるとやはりJavaScriptやTypeScriptはまだまだ不自由なところがあるから
言語仕様もそうだしIDEが未成熟というのもあるし

>>301
> 速度は大事だろ
> 動けばいいレベルで満足しちゃうの？

今の速度で不足しているなら大事と言えるが
スマホですらWebAssemblyがなくて普通に使えてる

「そんなに速度が必要な事をやってるのか」という言葉の意味は
どんな用途だと不足するのかを聞いてる。
お前には答えられるか？

>>305
> DemoみたかぎりVisual StudioでJSとWebAssemblyとserver sideを
> まとめてデバックできていた。

WebAssemblyと何の関係が？
WebAssemblyがなくてもデバッグできるよね
なら余計なコンポーネントがない方が開発の生産性は高くなる。
Visual StudioでJSとserver sideをまとめてデバッグできる方が生産性は高い

WebAssemblyはどんな問題（課題）を解決するのかを答えられないようじゃ
WebAssemblyを理解してるとは言えない。
課題というのは現在困ってることを言う「速い」は課題ではない。
そしてウェブ開発は「遅い」ことで困ってたりしない。

WebAssemblyが解決するものは速度ではなく
過去に作ったデスクトップアプリの移植を容易にすることや
JavaScriptでは達成できてる言語のポータビリティ性を
他の言語でも達成できるようにすることだ

つまりはレガシー技術を延命しようとしているだけであり
それらを必要としてない人にとっては意味がない

wasmでVM動かしてる状況だとまだ劇的に速いとは言えないのでは
wasmのGC実装もこれからだし流石に時期尚早感がある

JavaScriptだってネイティブ実行されてるわけじゃなくJITコンパイルしながら実行されてるでしょ
wasmのVMが大きなオーバーヘッドだとは思わないけどな

>>313
ええ、OfficeソフトなんてWindows3.1のWorksで必要十分で御座います。
オフラインに割り切って使う
ノートパソコンは最近Windows95にアップデートしたばかり。
3次元CADだって動くんですよ！

>>316
そんな人もいるんだからって言いたいの？ｗ

jsをwasmにコンパイル出来たら爆発的に普及しそうなんだが、いまだにまともにできないんだよな。

>>317
そうですワタシが変なおじさんです。
応答速度がどうのこうのと言う話の流れを見てますと
WebブラウザのSPAで3次元CADも出来る時代になったのだなあと感慨に老けっております。

>>319
論点はそこじゃなくて、
「3次元CADやるなら別にブラウザじゃなくていいよね」
だから

なぜわざわざ遅いとわかってるブラウザで動かすのか？
ブラウザで動かさなきゃいけない使命でもあるの？

jquery bootstrap Vue React angular
redux nuxt kockout sass gulp webpack
ああもうめちゃくちゃだよ！
お前ら全員webからい居なくなれ！
はっきり言って邪魔なんだよ！

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

VS+C#の快適さに比べたらJSやTSなんてゲロ以下でしょ
この時点で即座に乗り換える理由になる
流石はマイクロソフトというべきか、言語や開発環境だけじゃなく、Blazor自身もフレームワークとしてのセンスが良く、パクリ元のVueやReactより生産性が高い
速度面で若干の心配があるけど、やってみると現時点ですでに爆速とわかり安心
スクリプトより最適化が簡単だから、今後のさらなる改善も大いに期待できる
おまけにデスクトップ、モバイルネイティブ、PWA、ハイブリッドのサポートもロードマップに入ってる
むしろ乗り換えない理由が見つからねー

vscode + js のウルトラ開発体験知らんのか？

>>323
昔C#使ってたけど正直使わなくて済むならIDEは使いたくない

>>324
VSCodeは不安定すぎて話にならんわ

>>325
宗教上の理由でIDEを避けたいならそうすればいい
Blazorも例に漏れずVScodeでもVimでもなんだって開発できる
ま、VSが最強なので他はオススメはせんがね

VSおじさんｗ
Silverlightはどうなりましたかｗ

wasm(たとえばC#)って画面描画どうやってやるの？
C#で書けるだけで画面描画はやっぱりDOMツリーいじるの？
それともブラウザ全面がウィンドウ扱いでWPF使えるとか？

wasm詳しい人教えてくれ！

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

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

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

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

>>329
Razorマークアップ

>>331
JSは要らんよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>312
Blazorだとclient, severの両方をC#でかけるから
開発生産性が高い
という当たり前の話が前提としてある

Blazorでは既存のJS libraryは使えるがJS開発はおまけ
自分で開発するのは主にC#

node.jsはbrowserがJSだからserverも同じ言語だと効率がいいっていう
理屈で作られたものだろう
しかしJS自体がうんこなのでnode.jsはserver sideもうんこ言語で
開発することになる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





.NET遅っそｗｗｗ重っもｗｗｗｗ

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

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

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

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

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

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

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

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

あんじゃん
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
http://2chb.net/r/tech/1308761577/

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

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

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

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

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

>>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なんてあるわけないだろうｗ

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

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

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

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

完全にスレチじゃん？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>388
業務系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>423
>>426

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

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

>>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を連携したアプリケーションを素早く開始することができます。

>>429
> フロントエンド特化人材は高えんだよ
ならフロントエンドに特化してない人を使えば？
バカなのかなこいつ

なんかC#を使ってWindows Formsとかでデスクトップアプリを作れば
それがそのままSPAになるって思ってそうなんだよなｗ
URLどうするんのよって感じだ

URLじゃ話通じないですかね？ｗ
SPAはデスクトップアプリとは違ってURLがあって
ブラウザの進むや戻るがつかえるんですよ

>>430
意味不明な切り返しすんな
SPAでやると決まったらフレームワーク使うに決まってんだろ

お前が得意げに挙げた.NETの従来のSPAテンプレートは各種JSフレームワークのテンプレートを生成するだけだ
おまけ程度にC#のAPI開発テンプレートも生成してくれるがJSフレームワークを隠蔽するようなものじゃない
だからそれらを使ってもフロントエンド特化人材を雇わないと開発なんてできねえぞ

>>431
オメーがバカ
特化した人材は高い
特化してない人材ではJSフレームワーク使った開発は生産性が低い
安いには安いなりの理由があるんだよ
だがBlazorならそんな安い連中でもC#とVSを使って簡単に開発できるようになる

>>432
誰もそんな話はしてねー
そんな理解になるってお前の頭どういう構造してんだ

> フロントエンド特化人材を雇わないと開発なんてできねえぞ

普通にフロントエンド開発者を使えばいいだけでは？ｗ
いないんですか？

>>437
高えつってんだろ
鳥頭か

そろそろwasmの話は別スレでやってくれないか？

実際フロントエンドまともにできないゴミエンジニアばかりだからな
以前某エンジニアリクルート系の検索システムでフロントエンドエンジニアを検索したら全エンジニアの0.5％しかいなかった
その0.5％も自称だからガチで少ない

>>440
Blazorはゲームチェンジャーになりうる
なんたって雑魚カスC#erでも超お手軽にSPAを開発できてしまうんだから
JS系のエンジニアの市場価値は相対的に下がるだろうね

Blazor-wasmまとめ
重い>>385
遅い>>380
有名クラウドサービス採用実績ゼロ
（React/Angular採用多数は言わずもがな）
C#以外覚えられなくなった年寄りを再利用するための介護フレームワーク。

よっぽど高度なことするわけじゃない限り、C#書けるならReactとか2週間もあれば書けると思う

>>441
バックエンドゴミエンジニアが何を使ったってゴミのようなフロントしか作れないぞ
絶望的に才能がない
目ん玉はただの飾り
こいつら（＝おまえら）に良い筆を持たせても無意味

いい加減専用スレ立ててそっちでやれよ

数年後にwasmだらけになって涙目になるJSキッズが目に浮かぶ

>>443
2週間�l数の教育工数が無駄

>>442
重さは、遅さは現状でも十分実用に堪えうる
というか既存のSPAも体感はほとんど変わらんレベル
ゴリッゴリに最適化された既存フレームワークと比較してだから、最適化の余地があるwasmのほうが将来的には優位
採用実績はまだ正式発表されたばかりだから、比較しても意味がないことは小学生でもわかるはずだが君はどうだ？

そこで振り落とされるような奴は今のJSフロントエンドすら無理。

blazor厨もそれに付き合うやつも
よそでやれよ
そんなんだからいつまでたっても
そんなんなんだぞ

次スレはvs Blazorも入れたほうがいいな

なんでこんな迷惑なBlazor厨に合わせてスレタイ変える必要があるのか
Blazor厨も相手してる連中もどっか行ってよ、ウザイ

>>442
ついこないだRTMになったばかりのものを実績で批判しちゃうおばかさん

それだけBlazorを恐れてるんだろうな
まあ自分の市場価値が下がるわけだから恐れて当然なんだけど

単純にスレチな話題を延々と展開するヤツが煩わしいだけ
どの道Microsoft系とは層は被らんよ

>>382
大規模サイトのserver sideはJavaやC#が多かった。
社員しか使わないしょぼい業務系web appのことだけ考えていてはいけない。

あと大規模になるとtype safetyが必須になる
type safeでなければ開発生産性ががた落ちだ

速度も大事だがビジネスとしてみると開発生産性、コストもとても大事なわけ

GAFAでは使ってないし大手SNSでも使ってないけどな

>>455
ほんそれ

>>384
最小限のファイルだけbrowserに転送されるし
cacheされるから2回目以降は読み込みもはやい

ほとんどの人は5秒未満で初回読み込み終わるんでは
2回目以降速いのにそんなにガタガタ騒ぐ理由がわからない
いまどきトップページ読んだだけで数MB消費のサイトたくさんあるだろ

mobileでYouTube見てる人とかたくさんいる時代に
初回だけ数MBの読み込みって問題になるとは思えない

>>385 >>387
初回はデータ読み込み多いのはAngularとかのSPAも同じだから
このスレに来ないほうがいいと思うぞ
いつまでも古い開発に固執していればいい

そもそもwebでC++とか普通使わないだろ、開発生産性が低い

client sideにロジックが増えるという事は
それだけユーザーは快適に使えるようになるってことだ。
メリットとデメリットのトレードオフ

>>455
TypeScriptの開発がMicrosoftなのも知らない人か
MSアンチやアップル信者の人ってこういう知識ない人が多い感じ

もうここはBlazorスレだな
Reactとか微塵にも話題に出ない

>>461
ああ、知ってるが導入するコストと比べて型があるって事にメリットがそれほど感じられなかったから導入を見合わせたよ

絶対ts入れた方がいいぞ

>>457
どこの世界の話だろうか

仕事で扱ってるドメインがショボいと型安全性のありがたみはわからねえだろうな

Blazorの話は過疎ってるxamarinスレでやってくれないか

>>467
スレチ

>>457
大規模サイトのback endはJavaとC#だらけなの知らないのか

Twitterは過去にRuby遅すぎて捨ててるし

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





.NET遅っそｗｗｗ重っもｗｗｗｗ
Java遅っそｗｗｗ重っもｗｗｗｗ

.NET優秀やん

Javaや.NETは基本サーバーは決められた台数立てっぱなしが当たり前の時代に設計されたからな。
最近のコンテナ単位・ラムダ単位で負荷に合わせてスケールアウト・スケールインするアーキテクチャは想定外だったんだろう。

もうjsでいいじゃん
使えないバックエンドゴミクズエンジニアがヒーヒー言ってるだけだろ

Why I Converted from Vue to React
https://dev.to/brettfishy/why-i-converted-from-vue-to-react-1abn

> The purpose of this post was not to say that Vue is bad

ワロタ

>>377 >>470
これ記事かいたやつもそれ張り付けてるおまえもアホすぎ

.net2とかいう言語はない。
.netが言語だと思ってる時点で相当レベル低い

あとcold startだけのbenchなんてほとんど意味ない。
しかもcloud環境で計測してるというバカっぷり
そんなのその時のserver混雑状態で変わるってのｗｗ

hot startなんだから対象言語の実行に必要なVM・環境のロード時間含まれるの当たり前じゃんｗ
lambdaなんだからクライアントから測るの当たり前じゃんｗｗ
本番でユーザーに遅い言われたときサーバで測ったら速いです言うの？ｗｗｗ
バカ過ぎワロタｗｗｗｗおとなしくサーバサイドだけやっとけや老害ｗｗｗｗｗ

*cold

世界最速は、このサイト。Ruby on Rails 製
https://dev.to/

Rails + React + Bootstrap + (Node.js + Webpack) の組み合わせには勝てない。
このエコシステムを超えるのは、無理

Rails: webpack(er)に乗り換える25の理由（翻訳）
https://techracho.bpsinc.jp/hachi8833/2020_04_10/90859

ｶﾞｲｼﾞ大集合ｗｗｗｗｗ

Rubyって遅い言語代表格じゃん

>>470
なんでgoがこんなに遅いかね

>>476
ほんとバカだな
ベンチマークなんて負荷なしの状態でかけないと正確な値がわからない。
プログラミングやらないやつでもそんなこと知ってると思うわ

多くのユーザーが使ってるサーバーで言語ごとのベンチマークとるとか馬鹿すぎ
それを何度も張ってるおまえも同レベル
もし言語ごとにやるならオンプレミスでやらないといけない
その環境をつくれないバカだから混雑してるクラウドでやるとする
Front endのスクリプトしかできない奴はやっぱりレベル低い

>>482
lambdaがどういう運用されるか知らないの？ｗ
やはり老害は立てっぱなしの旧来アーキテクチャしか理解できないようだなｗｗ
言語と同じで信者もスケール出来ない産廃ｗｗｗ

Blazor信者の声でかいからBlazor調べてみたけどHTML構文のきもさとか実行の遅さとかファイルサイズのでかさがやばいな
これむしろBlazorアンチだろ
信者だとしたらずっとBlazor触ってて欲しいな。デメリットも享受出来ないで持ち上げる人は大海を知らないでほしい

>>483
C#できない低能のおまえは何の言語使えるつもりになってるの？

で、おまえがベンチマークだとおもってるそれは
何を計測してると思ってるの？
まともなベンチマークですらないのに言語の速さと勘違いしてるし

>>481
それまともなベンチマークじゃないから無視でいい

C#ってJavaScriptよりも簡単やろ？
JavaScript使えるなら誰でも使えるで
だからC#の給料は安い

>>484
htmlじゃなくてRazor syntaxな
ReactのJSXより綺麗だろ
ASP.net系やってるひとはわかるsyntax

AssemblyファイルをダウンロードしないBlazor Serverっていうのもある
その辺は要件によって使い分けること

性能もC#だから速い。遅いと言ってる人はコードの書き方が悪い

>>486
JSしか使えない人はオブジェクト指向理解できてなくて
大規模なプログラムや効率的なコード書けない人ばっかり
能力が違いすぎる

JavaやC#使える人はスクリプト言語はどれでも理解できる
逆は無理
スクリプト野郎はType(型)がなんなのかすらわかってない人が大半
このlogのすこしまえにもTSのtype safetyのメリットがわからなかったと
かいてる>>463がそういう人が典型的

とか言ってるヤツに限ってぐちゃぐちゃなクラス設計してそう

>>488
え？JavaScriptでクラスが普通に使われてることを知らないの？
そんな人がJavaScriptはーって言った所で説得力無いよ

Reactの場合昔はクラス使ってたけど最近はクラス使わない方向にシフトしてきてるけどね

「JavaやC#使える人は〜」とかこの二つを同列に見てるヤツは全然信用に値しない
この二つの言語は外見が似てるだけで設計ポリシーが全然違う