Vue vs React vs Angular Part.4
レス数が1000を超えています。これ以上書き込みはできません。
前スレでご質問の在ったクルクルとは、Googleで検索して見ようとすると、これ見よがしにお待ちくださいのような感じのクルクルが現れる現象のことです。 NGすんなよ。
NGならここは俺の次スレではないな。 聞く方にだってある程度の理解が求められるだろう。
今のメンツじゃ話しても無駄だと思ったから、じゃあ終わりって事にしたんだ。
Gumbo貼ってきたり、Chromeから抜くと言ってみたりじゃ、ちょっと無理だろ。
スレを盛り上げていく中で、それHTMLパーサーで出来るよ？とちょこちょこブッコむ。
この流れで理解を得ようという作戦だよ。 できれば、Gumbo程度は使ったことがあるって人が居ると望ましいのだが。
事前に問題を共有できてるから、出発点が少し先に行ける。 各社のサイトのソースをみてReact, Angular, Vueのどれかを
使ってるかを判別する方法ってある？
URLが変わらずにページ内容が変更されることが多いならSPAの
フレームワーク使ってる可能性あるとはわかりそうだけど、そこから先がわからない Wappalyzerプラグイン入れるか
個別に
React Developer Tools
Vue.js devtools
Augury
入れるかじゃない？
後者で検知されて前者で検知されない場合もあって
その場合どっちが正しいのかよく分からん
どっちもChrome,Firefox版はある >>15-16
ありがとう、SPA初心者でどれも名前聞いたこと
ないけどいれていろいろ試してみる
お手本となるSAPの使い方というかを有名サイトで学びたい part4まで来てたのか。angular使いはじめたきっかけだからこのスレには少し感謝してる。 angular使ってるけどstyleの管理が悩ましすぎる…
cssに書いたりhtmlに書いたり、はたまたtypescriptのクラスとして作ってngstyleでバインドしたりで散らかってしまう。
もういっそ全部ngstyleってのもありなんだろうか コンポーネント毎にCSS書くってのはどう考えても無駄だよね グローバルに設定するための「styles.css」が「index.html」と同じ階層に用意されてるじゃないですか vue書くの苦行すぎる
結構細かくルール指定するくせにこんなこともやってくれねえのっての多すぎ いきなりSPAに挑戦する前に既存のマルチページアプリにJSフレームワークを小規模に導入して勉強したいんですが
古き良きMVCフレームワークとJSフレームワークを組み合わせて使う場合はvue.jsが良いのでしょうか？ vueはやめとけ
途中でやっぱReactにしとけばよかったってなる SPAって挑戦するもんじゃないだろ
挑戦だと思ってるならやめとけ 最初の導入なんて誰でも挑戦みたいなもんだろ
挑戦してみた結果結局jQueryでいいやって人が大多数居るわけで
フレームワークをちゃんと導入できるところなんてほんの一握りだと思うよ >>25
最初からReactでいいとおもう
VueはTypeScript使えないので却下 Vueはマークアップ言語のように書けてわかりやすいのが強みだ みんなSPAで何つくってんの？
ページ遷移型Webアプリじゃできないようなことやってるの？ 元々デスクトップアプリ描いてた人の立場だと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を使うみたいな感じ
それに米国の企業だし >>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ってSFC標準にならないの
ファイル数多いから敬遠しちゃう ReactのHooksが登場してからは、Reactが一番導入のハードル低い気がするなー
Hooks系のライブラリ充実してるし useEffectでjQueryと共存なんてキモチ悪いことも簡単にｗ reactに近づく
つまりreactでよくね？ってなる 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
>サーバサイド技術のnpmとかnode.js
この認識が可笑しい >>67
確かにvueのtypescript対応は不親切。
てかいい加減公式サイトぐらいtypescript対応しろと。 >>72
だからお前いつもグルーピングがおかしいってば >>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 を送るだけ 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つしか使えない人、いろいろいるんだなあー なんかこのスレ、
・開発中のローカルサーバーでのビルド
・本番等へのデプロイ時に行うビルド
をごっちゃにしてる奴が居て話が噛み合わないわ まさかローカル用とデプロイ用で分けてメンテしてんのか？
DRYはどこに行ったんだ ハァ？なんでローカルの開発マシンで既にビルドしてるフロントをまたサーバーでビルドするんだ？
腐った思考がグルグル回ってんのはお前の頭ん中だけ。DRYじゃないのはお前。 >>105
はぁ？
開発中はローカルでビルドするし、CIサーバーでもビルドする
当たり前のことだろーが
お前、はっきり言って意味わからんよ >>104
そもそもローカルではwebpack-dev-serverとか使って効率化するだろ。
お前…まさかファイル更新する度に毎回ビルドコマンド打ってるのか？
>>105
そもそも本番とかってリリース用のブランチと同期しながらリリースするんだから開発マシンとか関係ないだろ。
お前…まさか自分の開発マシンでビルド したファイルを直接本番とかの環境にデプロイしてるのか？ デプロイとか書くのやめたほうがいいよ
バカっぽいから
deployの発音と全然違う >>108
今はコマンドを打つかウォッチで自動化するかどうかは関係ない
どっちにしろ構成は同じだ gulpとかbabelとかwebpackとかyarnとか本末転倒なんだって
そんなものこれっぽっちも使いたくないんだよ。
楽したいと思うからフレームワークに頼るわけであって
使えるようになるまでコマンドいくつも叩くくらいなら
ネイティブJavaScriptで全部やりゃいいだろってなるわ >>116
はっきりと勉強したくない（努力したくない・技術力をつけたくな）って言ったらどうか？
技術者の道具っていうのは自動車でも飛行機でも
技術力をつけて初めてさらに高度なことが出来るようになるもの
勉強しないで使えるものじゃないんだよ npm install && npm run watch
たったこれだけやん
あとはソースの更新を自動検知して再ビルドしてくれる 確かにwebpackはクソ。
俺はビルド設定職人じゃねえっての。
何にでも設定あるのは仕方ないがややこしいすぎめんどすぎ設定方法すぐ変わりすぎ。
投げ捨ててsnowpackを使うことにした。
webpackはとっとと滅べ！ Ruby on Rails は普通、Heroku を使う
Rails 6 からは標準で、Webpack。
プロジェクト内に、node_modules もあるし、
最初から、Yarn に、便利なコマンドも登録されている
webpack-dev-server も入っているから、
最初から、ソースコードの変更をwatch している。
VSCode の拡張機能・Live Server のwatch と同じ
有名なYouTuber、雑食系エンジニア・KENTA も、
CircleCI も必要だって言ってるだろ 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読み込みすればいいんじゃね？ IDEで新規プロジェクト作成に２分も掛かってたら待ってらんない
SQLのクリエイトデータベースでもそんなにかからない 遅いのは主に回線速度なのかなぁ？
みなさんは、create-react-app、何秒間で終わる？
>>136
Visual StudioでC#とかやってたから2分は相当長く感じる create-react-appでプロジェクト作るところを言ってるのか、そのあとのbuildのことを言ってるのかどっち >>138
もちろん、時間のかかる前者。project作成みたいな作業
ほかのひとは何秒くらいかかってるのかな、と
自分は120秒超えてたはず
そのあとのbuildというのはbuildしてる感覚はないのでよくわからない。
VSCodeがtsの変更を監視して.jsに変換するのがbuildなんだろうけど、
JSがcompile不要言語だからbuildといわれてもしっくりこない
後者は1秒未満 だいたいトランスパイルが面倒さの原因だしtsのまま動くようにしてほしい よくもまあHTMLに埋め込むだけで動作する
シンプルなJavaScriptをここまで複雑にしたもんだ
開発環境複雑なのはマジでゴミだと思うわ
ツール名並べてビルド環境自慢してる奴はおもちゃ
組み立ててはしゃいでるガキと同じ。
そもそもそんな糞みてーなビルドなんかなくても動く
言語だったこと忘れてるみたいですね。 >>142
シンプルで済むのはお前が一人で作るカップラーメンのタイマーくらいなんだが てかjQueryでいいわ
俺はフロントマウント界隈から降りるぜ どうせビルドするならトランスパイルじゃなくてアセンブリでいいんだよな
Webasmがウェブの正当進化
これから先の時代ではビルドプロセスを間に挟むならWebasm
そうでないならJSと分化していくだろう
数年後にはJSでSPAやってる人は居なくなる >>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 みたいなデザインパターン 「今日の」ね。
ワード単位なら分かるけど、こんな過疎スレでわざわざ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しまくるってことは5CHと相性悪いんだよ
別のSNSに移行したほうがいい 荒らしは、どんな時刻でも必ず、前のレスに賛同するアンカーを付けて、2回書き込む。
必ず、大勢の人がいるように見せかける
多くのスレで、死ねと書き込んでいるのも荒らし。
無視した方がよい
Python のスレのテンプレも、勝手に書き換えてる
>当スレに★Python以外のプログラミング言語での回答類を書くべからず★
>「Ruby では」「Rubyでは」「某言語では」をNGワード登録推奨
3大コテハンなど、目立つ香具師には攻撃していくから、無視すべき！
荒らしは、無視されるのが大嫌い >>191
ID:LmgOQRQZこそがム版で一番嫌われている荒らしなんだわ reactが老害化してきたね。
うちの会社（そこそこ有名）はvueが主力になった。 世界の潮流に合わせられないゴミのような会社
社員もゴミだからReactが難しくて使えないらしいな >>152
JSのソース見えても、使う側にはセキュアかどうかなんて分からんから同じ。
それにそもそも、ブラウザ内アプリはサンドボックス化されているので、
マシン本体にはウイルスを感染させることはほぼ不可能。
あるとすればフィッシング詐欺的なものだけで、それもソースが見えるかどうかより、
URLを本物かどうか確認することと、実際にメッセージが出てきた時に本人が気をつければ済む話。 それにソースがあろうがなかろうが、セキュリティーソフトに取ってみれば、同じ。
むしろ、Wasmのバイナリ形式の方がセキュリティーソフトには解析は楽。
というか、そもそもブラウザがサンドボックスなのでマシンには感染できないし。 Reactが老害化してきてるのは間違いない
無駄にバージョン上げるくせに全然進化しないしな パクリ先が進化してくれないとパクれなくて困るもんなｗｗｗ >>202
ころころと変わりすぎるJS界隈のなかでは
変化しすぎないのはむしろいいことだろう >>199
WebAssemblyはC#とかでかけるから興味あるんだけど
WebAssemblyメインで作ってる大手サイトってあるのかな？ Vueにチャイナリスクがあるとか懸念されて承認が下りない 中華製の部品を使えないとなるとパソコンも許可が下りなくなる 外人は既に、Facebook 製のReact を使っているから、
中国製のVue.js へは移行しない
Reactの日本語訳が、2回表示されるから、ちゃんと直してほしい
それと、Webpack も日本語化してくれ snowpackが出たからwebpackはオワコン。
チャンク分けが後付けされたとは言え、基本的にひとつのバンドルにまとめるという思想がhttp1.1時代の時代遅れの化石。
加えて設定APIがクソかつすぐ変わるゴミ。 その間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ってなんとなくかっこいいから初めて見たけど
具体的なメリットって何なの？
ただ単に構築面倒にしてるだけじゃん >>220
色々部品化進めて行くと段々開発効率が上がってくる >>223
今までにどんな部品を作りました？
部品はいくつありますか？ Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 >>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のライブラリ作ればいいんやで！ Blazor面白いね
あとは読み込み速くなればJS要らなくなる adobe airのときもsilverlightのときも同じこと言ってたよそいつ。
懲りない奴だｗ >>258
昔の知識のままの人か？
Blazorも.net Core対応と書いてあるし
.net CoreならLinuxやMacでも動くはずだ
Blazorのhelpにもapacheとかがかいてある いうてもApacheでASP.NETとか使ってるヤツ居るの？ >>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が動くとは言えないな >>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だの吐き気するわ。 バックエンドなんてフレームワークで構成して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で即座にバグ発見しやすい。
こんなの開発生産性が次元が違うだろ？ 自社プロジェクトで採用すればいいよ
なんで求人探すなんて面倒くさいことするんだ >>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で描画させて欲しいわ でもその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の命令で描画される >>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を習得して立場を守ったように
こんどはフロントエンドエンジニアが別の言語を学ばざるを得ない時代が来た >>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使ってるだろ
目的に応じて適切な言語使ってるんだよ >>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とかいうやつ >>336
あーもうそれこのスレ関係ないって事だよね
専用スレ立てればいいのにね 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 >>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を無意識化では認めちゃってるってことだよ 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
君、プログラム下手でしょ
インターフェイスと実装の分離ができないタイプと見た >>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
誰もそんな話はしてねー
そんな理解になるってお前の頭どういう構造してんだ > フロントエンド特化人材を雇わないと開発なんてできねえぞ
普通にフロントエンド開発者を使えばいいだけでは？ｗ
いないんですか？ 実際フロントエンドまともにできないゴミエンジニアばかりだからな
以前某エンジニアリクルート系の検索システムでフロントエンドエンジニアを検索したら全エンジニアの0.5％しかいなかった
その0.5％も自称だからガチで少ない >>440
Blazorはゲームチェンジャーになりうる
なんたって雑魚カスC#erでも超お手軽にSPAを開発できてしまうんだから
JS系のエンジニアの市場価値は相対的に下がるだろうね Blazor-wasmまとめ
重い>>385
遅い>>380
有名クラウドサービス採用実績ゼロ
（React/Angular採用多数は言わずもがな）
C#以外覚えられなくなった年寄りを再利用するための介護フレームワーク。 よっぽど高度なことするわけじゃない限り、C#書けるならReactとか2週間もあれば書けると思う >>441
バックエンドゴミエンジニアが何を使ったってゴミのようなフロントしか作れないぞ
絶望的に才能がない
目ん玉はただの飾り
こいつら（＝おまえら）に良い筆を持たせても無意味 数年後にwasmだらけになって涙目になるJSキッズが目に浮かぶ >>442
重さは、遅さは現状でも十分実用に堪えうる
というか既存のSPAも体感はほとんど変わらんレベル
ゴリッゴリに最適化された既存フレームワークと比較してだから、最適化の余地があるwasmのほうが将来的には優位
採用実績はまだ正式発表されたばかりだから、比較しても意味がないことは小学生でもわかるはずだが君はどうだ？ そこで振り落とされるような奴は今のJSフロントエンドすら無理。 blazor厨もそれに付き合うやつも
よそでやれよ
そんなんだからいつまでたっても
そんなんなんだぞ なんでこんな迷惑なBlazor厨に合わせてスレタイ変える必要があるのか
Blazor厨も相手してる連中もどっか行ってよ、ウザイ >>442
ついこないだRTMになったばかりのものを実績で批判しちゃうおばかさん それだけBlazorを恐れてるんだろうな
まあ自分の市場価値が下がるわけだから恐れて当然なんだけど 単純にスレチな話題を延々と展開するヤツが煩わしいだけ
どの道Microsoft系とは層は被らんよ >>382
大規模サイトのserver sideはJavaやC#が多かった。
社員しか使わないしょぼい業務系web appのことだけ考えていてはいけない。
あと大規模になるとtype safetyが必須になる
type safeでなければ開発生産性ががた落ちだ
速度も大事だがビジネスとしてみると開発生産性、コストもとても大事なわけ GAFAでは使ってないし大手SNSでも使ってないけどな >>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
ああ、知ってるが導入するコストと比べて型があるって事にメリットがそれほど感じられなかったから導入を見合わせたよ 仕事で扱ってるドメインがショボいと型安全性のありがたみはわからねえだろうな Blazorの話は過疎ってるxamarinスレでやってくれないか >>457
大規模サイトのback endはJavaとC#だらけなの知らないのか
Twitterは過去にRuby遅すぎて捨ててるし 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なんだからクライアントから測るの当たり前じゃんｗｗ
本番でユーザーに遅い言われたときサーバで測ったら速いです言うの？ｗｗｗ
バカ過ぎワロタｗｗｗｗおとなしくサーバサイドだけやっとけや老害ｗｗｗｗｗ 世界最速は、このサイト。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 >>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#使える人は～」とかこの二つを同列に見てるヤツは全然信用に値しない
この二つの言語は外見が似てるだけで設計ポリシーが全然違う Javaしか知らない新卒に、JSとSPA FWで作れって命令したら、泣きそうになって、開発環境構築で詰まってしまった
けどBlazorでやれって命令したら、あ、これならなんとか、Javaに似てるんでC#なんとなくわかります、VSってすごい簡単ですね、Razorマークアップシンプルで直感的でわかりやすいです♪って目に光が戻ってきた
Blazorが道に迷った若者を救ったのだ ＞Javaしか知らない新卒に、JSとSPA FWで作れって命令したら、泣きそうになって、開発環境構築で詰まってしまった
指示側が無能な典型やろそれ >>487
MSILになるからどっちみち書き方関係なく遅いってよ
現実から目を背けるなw Java AppletとSilverlightはなんで死んでしまったんだろうな
最近のSPAの流行を見るに需要はあったようにも思う
やはり事前のプラグインインストールが受け入れられなかったかね 今までJava、Flashとセキュリティホールの温床として排除されてきたけど何れwasmもそうならんとも限らんのよな >>498
JavaScriptと他の言語との決定的な違いは
JavaScriptはブラウザの外にアクセスできない言語としてできたということ
他の言語がファイルの読み書きやネットワーク通信が
出来るのに比べてJavaScriptはそれらが全くできない
常識ではファイルアクセスやネットワーク通信などの機能は
言語としてできて当たり前のことが、JavaScriptはできない
その貧弱さがセキュリティのもとでは逆にメリットに変わった
そこからセキュリティを考慮しつつ、それらの制限に
限定的に対応できるようにしてきた。
wasmも最終的にはJavaScriptでできることしか
外部リソースへのアクセスができないからセキュリティ的には問題ない
ただ外部リソースヘアクセスする場合、wasmの速度が速いなどの副次的な
メリットはなくなる。当初の目的通り既存のアプリの移植を容易になるだけ Silverlightはまあまあいい出来だったんだがな
Java applet、ActiveXのせいでPluginの印象が下落してSLも風評被害を受けた >>492
これ作り話くさいな
混沌としたFront endなのだから何を使ってどういう構成
にするのか具体的に指示しないと伝わるわけがない。
雑な指示したおまえが無能
本当に泣きそうになったとしたら言語うんぬんよりも
会社や上司に絶望してたのだろう
>>491
C#は生産性優先でJavaほど頑固なオブジェクト指向でないことは理解してる >>502
混沌としてるのはフロントエンドじゃなくJS ecosystemな
Blazorにすれば混沌とはおさらば >>496
Silverlight
pluginなことと
web standardじゃなかったこと かつて猛威を奮ったFormsほどではないが
Blazorならバカでもチョンでも簡単にSPAを作れてしまう
ジャバスク職人はもういらないのだよ 知識ゼロからASP.NET+Blazorの開発環境を立ち上げるのとNode.js+Reactの環境を立ち上げるの
どっちが簡単なんだろうね。 そりゃBlazorだろ
マイクロソフトはそのあたりは抜け目がない $ sudo apt install -y nodejs
$ npm install -g create-react-app
blazorもこのレベルで行けるん？ >>507
勝負にならない。
Blazorならコマンド2個打つくらいで動く
トータル3分くらいで終わる
ここのをやってみな
https://dotnet.microsoft.com/learn/aspnet/blazor-tutorial/intro
SDKインストールして、Power shellひらく
dotnet new blazorserver -o BlazorApp --no-https
cd BlazorApp
これだけでprojectが作成される。1秒で終わる。
dotnet run
でweb serverが立ち上がる >>510
create-react-appは
出来が悪くすごい待たされるが
Blazorならproject は1秒で完成する
Blazor使ったことない人は>>511やってみるべき それVirtualstudioのインストールを完全に無視してんじゃん VisualStudioはあったほうが快適だけど必須じゃ無いよ
VSCodeでもVimでもなんでも使えばいい >>511
それは単に自動生成してるだけやろ？
全てのリンクをスムーススクロールにするコード書いてみ >>513
webの開発者ならVS Codeくらいいれてるだろふつう
notepadだとさすがにまずいが通常のtext editorでも問題ない
C#やるならVisual Studioいれたほうがいいけどな >>516
プロジェクト作成なんて自動生成でつくられるべきだろ
create-react-appは時間かかりすぎでダサい >>518
自動生成で作れるのは
価値がないコートだけだよ
誰でも同じものが手に入るんだから 自演じゃないならBlazorの話してるヤツ３人以上居そうだし専用スレ立てても十分やっていけるだろ
いい加減専用スレ立てろよ 括りとしてはモダンSPAフレームワークなんでここでいいだろ >>511
なるほど面白い。ただ、このチュートリアルはSPAじゃないんだな。
create-react-appというよりexpress-generatorっぽい。 コマンド数回打つだけでこんなに簡単にプロ品質のものが
作れるのはBlazorしかないよ
素晴らしいアイデアだと思う 他の言語でもwasmベースのフレームワークが増えるといいね
JavaScriptを駆逐してやりたい まあ無理だね。
好むと好まざるとに関わらず残り続けるよ。
最低シナリオでもグルー言語として残り続ける。
そのころにはC#は滅んでるだろうがねｗ
TypeScriptと比べても設計古すぎなんだよこのクソ言語ｗ
WASMもプライマリ言語はRustになっちゃってるし。
クソ言語はその他有象無象の一つとしてしか立場はない。
ま、C#バカはJSすら覚えられずに恨み節なんだからRustなんて覚えられるわけないわなｗ
老害産業廃棄物としてゴミ箱行きｗｗｗ ははｗそれは無理やろ
ただでさえjQueryのシェアは年間1%以上（今年はすでに1.8%）増えてるなか
一番頑張ってるVue.jsででさえ年間0.1％しかシェアが増えてないんだから
https://w3techs.com/technologies/history_overview/javascript_library/all/y
僅かなパイを奪い合ってる状態だぞ 俺の予想ではwasmは最終的に
JavaScriptを駆逐するのではなく
JavaScriptを強化するために使われるだろうな
ウェブサーバーにキャッシュ機能の一つとして組み込まれ
開発者は普通にJavaScriptを置くだけで
自動的にコンパイルされて配信される
サーバーの設定をちょいといじるだけで
今までのJavaScriptの開発を変えずに
wasmの恩恵が受けられる >>527
酷ぇ調査だなこれ。カテゴリ分けずにJSライブラリでいっしょくたか。
一緒に使うライブラリでシェア割っちゃってるし。
例えばjQueryとBootstrapが競合だなんて業界にいたら誰も思わんだろ。
w3techはこれ作ったやつ即刻クビにしたほうがいい。 C#は設計古いところはどんどん改善して変化し続けてるけどな
次バージョンじゃMainいらなくなるしValueObjectを言語レベルでサポートする >>529
なんか問題があるの？
合計してみればわかるように100%を超えている
競合の有無は関係なく、それぞれのJavaScriptライブラリが
どれだけ使われてるかって数値だよ UI関連フレームワーク連敗記録は何処まで伸びるかね MSなら<canvas>にWPFをレンダリングするくらいできそうなもんだがなぁ。
やったらやったで反発がすごそうだが。 おれJavaScript書いて10年だけど、型のメリットなんて全く理解できないし、わざわざC#みたいなダメ言語触ってるやつの気がしれん オモチャ作って遊ぶだけならそれでもいいんだろうけどねえ
ビジネスでは型なしはちと厳しい >>522
いや、>>511のMSのsampleはちゃんとSPAになってる
Blazor WebAssemblyだからぜんぶBrowser上で動いてる
左側のメニューでクリックするとカウンターが増えていくけど
それがSPAになってる
page全体がreloadされずにcounterだけ増えるでしょ
https://dotnet.microsoft.com/learn/aspnet/blazor-tutorial/try >>528
jQueryおじさんまだいたか
速度と生産性を追求したらtype safeな言語にいきつく。
wasm時代はJS縛りがなくなるわけだから
大手は生産性の高い言語で開発を始めるようになる。 >>532
そんなに分裂させても過疎るとおもうけどな
フロントエンドJavaScriptフレームワーク総合
も過疎ってる。
Blazorの話題でるまではこのスレも超過疎だったし
次からスレタイにvs Blazorも追加しちゃえばいいよ >>536
Visual StudioでWindows appをつくってみろ
C#でな
それやるとtype safeのありがたみがわかる
開発スピードが別次元になる
そしてスクリプトの無力さに気付くだろう
型のメリットがわからないようなレベルのやつが
C#ダメ言語とかいったら笑われるぞｗ
スクリプトだとPerl, PHP, JSが世界3大クソ言語 >>540
それはJSがbrowserで動く唯一の言語だったからだ。
仕方なく使っていただけで人気なわけではない。
wasmの時代は好きな言語つかえるから
もうJSは終わりに向かってる 漏れは、UIPathで、RPAのプログラムを書いたけど、
操作するアプリから、取ってくる値も、
書き込む値も、両方、文字列なのに、いちいち変換させられるのが、大変で、困った！
数字を取ってきたときも、計算するために、文字列から、数値に変換させられるのは、分かるんだけど、操作してるアプリに、書き込むときは、文字列以外、あり得ないのだから、いちいち変換させられるのは、意味が分からなかった！ UIPathでは、C#しか、使えない！
Rubyでも、書けるようにして欲しい！ GithubはMicrosoftのサイトだからC#が人気なのでは。
GNUならPHPかもしれない。 ビビッドアーミーって広告よく出てない？
このゲームは中華だからやっぱりVueですか？ >>543
flutter来てるなー。Dartとか覚えるのめんどくさそうなのに。
なんでこんなに伸びてるんだろ。 >>544
マジでこれだよな
ほんとこれに尽きる
VS＋c#でやるとVSC＋javascriptがいかにクソでデバッグが苦しいかわかる >>478
で、Ruby on Rails でさえ、webpack に乗り換えた！
Linux のエコシステムがあるから、開発者は、C#・Windows へは行かない。
Windows は、OSS じゃなく情報が取得できない・エコシステムが利用できないから、
システム環境構築運用ができない
Linux では、日本人が作った、多言語のバージョンマネージャーのanyenv などが定番。
これで、rbenv, nodenv, pyenv, phpenv などを同じ使い方で、統一的に扱える。
同様のツールに、asdf もある
この辺の勉強を避けてきた、フロント側が仕事を取れなくなっただけ。
Ruby には、Linux・サーバー側が含まれている >>550
確認したけどフレームワーク的なものはなんも使ってなかった
気になるんならChromeかFirefoxでVue.js devtoolsでも入れて見てみたらいいと思う >>553
Rubyはecosystemが小さい
言語のバージョンアップですぐに互換性がなくなることで有名
性能も低い
Rubyは実質Rails専用言語と化している
PHPもwebでしかほぼ使われない
C#のように広い範囲で使われてる優秀な言語とは大違い
C#はwindows app, server-side, Gameなど範囲が広い 自分より下を見付けて安心するとか完全に劣等感思考だな
なんだ？C++勢にポインタが使いこなせないC#erってバカにされて八つ当たりにでもきたのか？ 今更やけどここ最近スレチ過ぎるわ
C系使ってるやつが書き込むのは全然いいけどスレタイに関係ないこと喋りたいんやったらそれぞれのスレ行け Javascriptはウェブ板というのが、ム板のルールだから。 スレ伸びてんなーと思ったらスレチで盛り上がってたのか。。
テキストエディタで書いてFireBugでデバッグしてた10年以上前と比べたら今のフロントの開発なんて天国だぜ。
これは言語というより、JSフレームワークとIDEの進化のおかげ。
回顧ジジイの戯言かもしれんが。。 >>564
まあそうなんだけど
そのぶんやることの範囲も求められることも多くなってユーザーも肥えてるから
昔とは違った辛さがあると思うよ C#って確かにいい言語だけど
業務上でブランチプログラムが沢山できて開発終了から５年くらい経った上に当時の担当者が辞めた場合とかどのブランチなのか確認するのに一苦労するから
最近スクリプト言語以外は避けたいなとか思ってる 「ブランチプログラム」でググっても出てこないんだけど？ >>566
それ逆だろう
C#こそ仕様変更あったときに修正しやすい。
IDEがエラー拾ってくれるから楽できる。
スクリプトだとそもそも5年後にメンテナンスされてなくて
セキュリティホール放置になってる
仕様変更にも弱い
論外
担当引継ぎはバージョン管理とかドキュメント保管の問題だが
メンテナンスコスト低いのは型のある言語 >>570
たぶんgitとかのbranchのことじゃないかね >>572
こんなオレオレ用語が通じると思ってる時点でアレだよね いやいやGitより遥かに昔からOSS界隈では枝分かれの事をForkとかBranchとか言ってたよ >>571
今そこで動いてるプログラムのソースの特定ってリリース直後なら全然問題ないけど時間が経つとPCが飛んだりファイルサーバーが飛んだりして色々分からんくなるんよ
管理が悪いと言われればそれまでだけど
たったちょっとの下らない修正をする場合に今サーバーで現在動いてるソースを正にできるならこんなに楽な事はない >>574
「ブランチプログラム」の話やで？ブランチやフォークじゃない >>575
具体的にC#でソースの特定になぜ困るの？ アセンブリのバージョン見りゃすぐにわかるし、簡単にデコンパイルもできるけど？
その程度の管理体制であれば、むしろスクリプトの方が安易にサーバー上での書き換えを助長してカオスになるやろ そんな杜撰な管理をする企業はウェブサイト公開したらだめだよ 自社ならどうしようもないが他社案件の引き継がない引き継ぎとかならまぁなくはない WEB系ってホビーの延長みたいな企業が多いからこういう杜撰なとこも少なくないのかね
業務系じゃ考えられないよ そんなもの引き受けなきいいに越した事はないが上が決めた事だから従わざるを得ない技術者が飛んだ会社の保守の引き継ぎとかさ >>583
それならなおさらスクリプトはやっかいだね >>581
お前が時代遅れのクソジジイだと認識しろよゴミwww なんでここシーシー言ってるおじいちゃん湧いてるんや
シーの読み書きのし過ぎで目バグってスレタイ読めんくなったんか >>586
えー？
うちは比較的モダンな現場なんでこんな杜撰な管理はしてませんよ
コードもリリースも全てテキストファイルでバージョン管理されてます Excel のマクロで、再帰的なファイル操作とかしてると、難しくて仕方ない。
おまけに仕様書もない。
こういう仕事が、1人月100万円
これが、Ruby のファイル操作なら、ものすごい簡単。
glob で済む JqueryおじとBlazorおじとRuby君で戦わせたらどうなんの？ Rubyガイジも爺さんだよ
年取ると周りの意見が耳に入らなくなるんだ 馬鹿は若くても人の話を聞かんから年齢は関係ないがな 年取って周りの意見が耳に入らなくなった老害JSおじさん
vs
若いBlazor勢力 Blazorの記事見てるけどなんかBlazorのソースってフレームワーク使ってないPHPやJSPみたいなコーディングするんだね >>594
ウェブシステムのフレームワークってどれもそういうもんだぞ
それが一番ウェブのシステム開発に適してると判断したってことだよ タグの中に分岐やループの制御文書くのってなんかレガシーな感じだよね >>597
ほぼすべてのフレームワークが、それを採用してる。
っていうか、それを採用してないフレームワークを
お前は一つでも言えるの？何も知らんでしょ？ まだ5年くらいしか経ってないJSTL（JSP Standard Tag Library）に
ようやく追いついてレガシー呼ばわりされるとは開発しがいがないね >>597
KISSの原則だな
人類は奇抜なアイデアに翻弄されて様々なアーキテクチャ浮気したけど
原点回帰かつそれを高度に洗練させたものが結局はイチバンだったというわけだ 昔ながらの誰しもが知ってる馴染み深い単純明快でインジェクション安全で型安全でインテリセンスもバリバリ働くRazor構文
それを使って最新のSPAフレームワークと同等以上の成果物を得られる
それってつまりどう考えても最高ってことじゃないか
もうSPAをするのに出来損ないのJS言語やぶくぶく太った醜いフレームワークに疲弊しなければならない暗黒時代は終わった おそらく>>597はゲームプログラミングしかしたことないんだろ
ゲームはユーザーインターフェースは全部自分で作るという特殊なアプリ
システムアプリではUIはHTML・XML系で作ったほう簡単
動的にUIを変更するならHTML・XML系に分岐やループを書くほうが適している >>601
制御文の中にタグがあるのはいいと思うんだよ
それを置きたいタグ枠の外で分岐やループしたものをコンポーネント化してそれを
置きたいタグ枠の中に配置すればタグの中に制御文はないという構造にできる >>594
frameworkなしと一緒にするなよ、ぜんぜんちがう
Razor syntaxはasp.net MVCとかでも使われていたし
ちゃんとMVCできれいに分離されてる
実際に使ってみればきれいにフォルダ分類されてるのにきづく >>597
タグの中に書かれてるんじゃない
Razor syntax
https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor?view=aspnetcore-3.1
HTML, CSSがロジックを扱えないわけだから
C#とhtmlの親和性の高いsyntaxが作られている。
ReactのJSXも同様だ。
ぜんぶごっちゃになってるJSPとは違う。
記事だけじゃなくインストールして試してみるべし これからは○○の時代！
結局生き残ってるのはjQuery（笑） >>597 594
Blazor WebAssemblyは再利用可能なコンポーネントなわけ。
ネストしたりもできる。
これが原始時代のJSPとかと一緒に見えるなら
WebAssemblyがなんのかという基本のところが
まったく理解できていないことになる。
>>607-608
スクリプトしかできないいつもの低能か
型すらないレガシー言語つかってる人って頭悪いよな > Blazor WebAssemblyは再利用可能なコンポーネントなわけ。
JavaScriptライブラリなんかも再利用可能なコンポーネントですが？ C#とTypeScriptは設計者が同じ
TypeScriptがその人の最新作かつ最高傑作
C#は見捨てられたロートル
C#の型表現の古臭いことｗ
C#おじさんの耳の後ろとおんなじ臭いがするよｗ もうDelphiとか知らんヤツばっかなんだろうな現代では TypeScriptはトランスパイラから脱却してからがスタートラインかな その前にjapascriptがtypescriptを吸収する ブラウザなんかじゃ実行時に型チェックしてエラーにしてもたいしてメリットないんじゃね？
せいぜい、型チェックをスルーしてトランスパイルなしで実行できるようにするくらいかな。 >>615
ES2023～ES2025くらいの間にそういうのもありそうだよね >>616
解析のせいで遅くなるだけでメリットは少ないだろうな
TypeScript処理系をブラウザに載せるのは悪手としかいえない
そんなことせんでもwasmにビルドできればいいんだよ wasm用には亜種のAssemblyScriptがあるっちゃある >>612
おまえと違って中級以上は型が必要なのわかっている
TSのおかげで型のない欠陥言語JSをましになってるが
うんこの制限をうけずいちから設計したC#にはとてもかなわない
見捨てられたとかいってる時点でこのバカなにもわかってない
C#は新しい機能をいれてきた言語だ
歴史はあるが常にアップデートされてきてる
互換性に固執しすぎて終わってるPerl , JS, Javaとは全然違う >>615
その前にWebAssemblyが普及して
JSで開発する必要がなくなるよ >>620
> おまえと違って中級以上は型が必要なのわかっている
Googleのこと？ >>621
お前の予測では、WebAssemblyが普及するのは何十年後？ >>623
理解力と先見性がある人はもう移ってるが。
C#とかを理解できない無能はPHPとかJSで開発を続けるだろう
今でもCOBOLやエクセルVBAでシステム開発してるアホな企業があるが
JSで開発というのはそういうやつらと同じ扱いになる C#は古いため、初期設計した天才不在の中、バカにどんどんゴミを付け足されたキメラで、醜い。
初期設計した天才はとっくに見捨ててしまったｗｗｗ
その天才は今、TypeScriptに熱心に取り組んでいるｗ C#は、おじさん
使ってる人も、おじさん
どっちも基本的な考えが古くて、臭う >>626
そいつは頭悪くてC#が理解できなくてコンプレックス持ってる
高機能で高速な言語C#への嫉妬
C#がゲーム開発でめちゃくちゃ使われてるのも知らないみたい 低能の相手しても時間もったいないからレスは控えるわ >>630
Pythonの作者が開発コミュニティから抜けた話は聞いた事あるけどC#もなわけね リアルな話、c#はWinFormsとUnityにしか使われていない >>628
っていうかコード補完なしで生きていけない人種ってだけっしょ？ >>632
MSに勤めてて、どっちもMSの製品だから抜けたというと語弊があるけど、
こっちがC#のリポジトリ
https://github.com/dotnet/csharplang
こっちがTypeScriptのリポジトリ
https://github.com/microsoft/TypeScript
そしてこれがヘルスバーグ先生のコントリビューション履歴ｗｗ
https://github.com/ahejlsberg
完全にC#は手放しててワロタｗｗｗｗ
ザコグラマにウンコ機能付け足されるだけのC#笑 C#は完成されてるから先生が面倒見なくても軌道に乗る
TypeScriptはまだまだ未熟でC#ほど洗練されてないので先生の助けが必要 つまりC#にザコグラマがどんどん足し続けてる機能は全くの蛇足と言うわけ。
昔は新鮮だった開封数十年のオレンジジュースに、泥水を延々注ぎ続けてるのがC#笑 >>639
URL2.0 もそうだったし、
C89 より後ろの C もそう
何かの文書で「言語法律家」と揶揄されていたのを見た記憶があります >>640
C++とかブラウザと一緒でコンパイラメーカーやコミュニティが先行して入れた機能を後から標準化団体が標準仕様として策定してるような感じじゃないの？ >>642
C++ は、今は規格が先行しコンパイラメーカーが必死になってついていく感じです 三大サーベイの中で最もJSに厳しいIEEEの今年のランキングが出たぞーｗｗｗ
Top Programming Languages 2020
https://spectrum.ieee.org/at-work/tech-careers/top-programming-language-2020
あっれれ～？おっかしぃぞ～？ｗｗｗｗ サーバーサイドレンダリングできる＝ググったときに検索結果に出やすいって認識でおけ？
カップ麺図鑑みたいなもん作ろうとしてて、カップ麺の商品名でググったらそのページが出やすくなるようにしたいのよね C#嫌いな人はStackOverflowも使用禁止な GitHubは、Ruby製。
Rubyアンチは、使用禁止！ 俺からすればC#, Perl, PHP, JSなんてクソの背比べ どうせ不毛ならｊおじとBlaおじの不毛な争いが見たかったな Blazorお姉さんだけど
jQueryおじさんとかはframeworkつかえないし
スクリプトおじさんはC#理解できないし
相手にならない
ところでJSのSPAの最初の読み込みは
何MBくらいになるのが普通？
何MBまで許される？
有名どころのSPA使ってるサイトあったら計測したいから教えてほしい >>656
一方SPAを使わなければ、必要なデータだけ読み込むので
数KBですむから、本末転倒になってるんだよなぁ
SPAかどうかはユーザーにとっては関係ない話
ページ表示の目安はGoogleがレポートしている
https://developers.google.com/speed/pagespeed/insights/
https://marketingnative.jp/how-to-measure-page-speed/
遅延する時間 ユーザーの反応
0~100ミリ秒 すぐに結果が得られたと感じる。これ以上時間がかかると、操作と反応にずれが生じる。
100~300ミリ秒 少しの遅れを感じる。
1000ミリ秒（1秒）以上 実行したタスクについて関心を失う。
つまり1秒以内だよ。100Mbpsだったら1秒で12.5Mバイトだけど
そんなスピードは出ないだろう。通常だと20Mbpsかねぇ。つまり1.5Mバイト
でも速度制限や回線が遅い場合を考えると500Kバイト程度に抑えたほうがいいだろうね お、Googleの推奨があった。
Googleの推奨は1.6MB。7,866のウェブサイトの平均は 2.43MB。あなたのトップページは？
https://webtan.impress.co.jp/u/2018/08/20/30244
通常だと～の計算と近いね wasmなら最適化も簡単だろう
今後どんどん速くなっていくとおもわれ WebAssemblyはファイルサイズがでかくなる WebAssemblyはバイナリだから小さくなると考えているやつがいるが、
JavaScriptでも配布する時はgzip圧縮をかけるので
バイナリになって小さくなるんだよな AngularもReactもVueも使ったことあるよーって人に聞きたいんだけど、どれが一番好き？ >>657
GmailのwebはSPAなのか
FirefoxでGmailを計測してみたら170 requestsくらいしてて11MBくらいだった。
しかもこれcache削除しないで測ってるから画像は除外された数字
backgroundで読み込むから読み込み完了まで25秒超えてる。
今はトップページ読みだけで10MB以上でも許される世界になってるのかな？
Gmailでかすぎ？完全にcacheけしたらどの程度いくんだろう, たぶん試さないけど。 >>657
ちなみにBlazor WebAssemblyのサンプルは初回読み込みで17MB程度だが
2回目以降は400kbとすごく小さい
初回通信でバイナリがほとんどcacheされてる
Blazor WebAssemblyのがはるかに優秀
やっぱりJSのSPAの時代は終わりだわ
JSは言語もゴミだし
これからはC#でBlazorの時代と確信した >>659
non-SPAと比べるのはフェアじゃない
SPAはUXが上というメリットがあるわけだからな
その目安はSPA関係ないし制限1秒はきつすぎる
あとMVNOだとランチタイムで速いところでも10Mbps
10秒待ってくれても12.5MBか
とりあえずBlazorの2回目以降400kbで
改めて優秀さは確認できた
MVNOのうんこ回線のランチタイムでも快適にloadできるはずだ
初回10MB超えるのも5Gきたら気にならない世界かもしれない Blazorの初回転送量は1.7MBくらいじゃなかったっけ？開発者ツールの見方間違ってない？ Blazorのテンプレートなら、Brotliで1.8MBだね ここまでスレタイに全く関係無い話を続けられるの逆にすごいな
ボケがはじまってんのか >>664
JavaScriptを主として掛けるからReact
他はhtmlタグが主でJavaScript従な感じ 世界最速のサイトは、Ruby on Rails 製！
https://dev.to/
元乃木坂46 の川後陽菜のWebサイト、SKIYAKI も速い。
https://kawagopro.com/
Rails に勝てる、フレームワークは無い！ >>668-669
どのテンプレートプロジェクト作成した？
Blazor WebAssemblyじゃなくてBlazor Serverになってない？
Storageにダウンロードされたdllとか確認した？
dotnet new blazorserver
で作成するとファイルサイズ小さくなるがそれだとWebAssemblyになってない。
Blazor Serverだとserver sideで動く
wasmで使うtemplateは
dotnet new blazorwasmを使う
本番向けのbuildするとかなり小さくなると書かれているがやり方まだ知らない。
それやったら初回17MBではなくもっと小さくなるかも
やり方知ってる人いたら教えて >>668-669
template動かしたときにrelease buildした記憶がないから
自分の書いた17MBはBrotliになってなかったかも
あとで試してみる
sizeはfirefox開発者ツールのnetwork tabでみた
初回1.8MBならぜんぜんOKだね
Blazor WebAssembly、ファイルサイズすごい小さい フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
https://krausest.github.io/js-framework-benchmark/current.html
二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。 最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
（BlazorはJSよりも10倍遅く、スピード競争に勝つことはない）
と述べた。 AOTサポートにより（JSに勝つことはないにせよ）性能向上が期待され、また宣伝し、信者も大いに期待していたが…
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
https://twitter.com/christianweyer/status/1270602821688328192?s=20
延期されたｗｗｗｗ
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよｗ
https://twitter.com/5chan_nel (5ch newer account) まあそれも時間の問題だろう
wasmのほうが最適化しやすいのだからそう遠くないうちに逆転する
これはほぼ既定路線と考えていい これか
Next for Blazor: AOT for 'Massive Speed Gains'
https://visualstudiomagazine.com/articles/2020/05/22/blazor-future.aspx
WASMで動く.NetランタイムがJIT無しのインタープリターだからILの実行が遅いってことね
これじゃあWASMがJSより速いと言っても、延期されたAOT(ILからWASMだよね？)が実装されないと、その速さが Blazor に反映されることは無い
.NET 5に間に合わないならAOTは来年以降
それまで Blazor スレで頑張ってください C#erって昔はこんなにスレチなところで延々と講釈を垂れ続けるようなバカじゃなかったはずなんだがなぁ
大体本当に優れてるものならそんな意味の分からん喧嘩なんて売りに来なくても広まるものは広まるだろ 長いJSの歴史の終焉を目の当たりにして感慨深いなぁって思っただけであって喧嘩を売ってるつもりは微塵もない >>682
jQueryはWeb"サイト"分野では永劫に使われ続けると思うよ
ブラックボックスってわけじゃないからブラウザベンダーに排除されることもないだろうし >>684
その終わるという根拠とやらはなんなの？ jQueryはすばらしいからこそJavaScriptに吸収される形でなくなって欲しいわ
実際、jQueryでしか書けなかったセレクタがJavaScriptに取り込まれたりしてるよね >>689
全然自明じゃないから聞いてるだが
具体的にどんなプロセスでどう終わるのか説明してみたまえ >>683
C#でもunityユーザーとかはマシだからC#erがガイジというよりはBlazorがガイジなんだろう JavaもVMで動かすなんて遅すぎるしクソとか批判されたが
C#含め普及していった。
Blazor、いやwasmもこれからpeformance改善されて
使う人が増えるのは間違いない
>>693
こうやってマシとか言ってる人はC#使えない人 煽りに乗りたいヤツはその思いの丈は全部こっちにぶちまけてやってくれ
【本命】Blazor スレ1【真打】
https://mevius.5ch.net/test/read.cgi/tech/1595255796/ GmailはSPAらしいけどAngularか？
いくらJSがブラウザ内でBlazorより早いといっても
Gmailだと11MBもサイト開くたびにデータ通信してるように
とてつもなく無駄なことやってる
ダウンロードサイズ、時間を考慮すると
Wasmとあんまり差がないってことにもなる
Blazor WebAssemblyは2回目以降のデータ非常に小さい。
データ消費量が課金にもかかわってくるモバイル回線では
Gmailのように大量にデータ通信するサイトよりwasmのがいいんじゃないか >>697
Googleでその手のフレームワーク使ってるサービスって意外とないんだよね BlazorプロジェクトマネージャーDaniel Roth「BlazorはJSよりも10倍遅く、スピード競争に勝つことはない」
今でも遅いのにブレキチのオナニーのためにBlazorでさらに10倍遅くさせられるGmail哀れｗｗｗｗｗ >>699
10倍遅いとか捏造しつこいな
chatでソースないのをいいことに捏造しまくり >>700
JITの無いインタプリタでJSと同等の速度が出るはずないだろ
JITの有無で速度の桁がひとつ変わるとか普通だ AoTコンパイラはバスに乗り遅れちゃって早くて一年後♪
嗚呼、それでも「JSにスピード競争で勝つことはない」
ミジメｗｗｗ
Blazorすごい！→宣伝してる俺すごい！
しようと思ってたのにまさかBlazorがC#おじさんのミジメな境遇まで堕ちてくるとはねｗｗｗｗｗ つかこんなに
フロントエンド界隈のライブラリが乱立して
ビルド構築手順ががわちゃわちゃしてる状況は異常
もうHTML自体をバージョンアップした方がいい
HTMLに直でReactやVueやTS SASSとかを記述して
ブラウザネイティブで解釈できるようにするべき
Bootstrapもどうせみんな使うんだか初めから
HTMLの仕様内に組み込んどけ >>701
ソースなしでは信ぴょう性がないし
どうせそういうのは発言の切り取り
Blazor wasmはAOT compile実装の予定あるのだから
速度は大幅に向上する
Browser外ではC#のがJSより速いのだから
speedは十分にはやくなる >>704
こんな発言しちゃうのがスクリプトおじさん
セットで仕様化したらどれか失敗したら全部が失敗するだろ
あと必要なcodeだけloadするから無駄な通信が減るのも常識
bootstrapは使ってないサイトたくさんある
View(html)とlogicをセットで仕様化など狂気の沙汰
あとbuildが煩雑なのはうんこframework使ってるからだ。
ASP.net MVCとかならクオリティ高いのがセットになってる
SPAなんてやらずにASP.net Coreみたいなまともなweb framework使えでおしまい
95%のサイトはSPAの必要がない いいかげんCの民は別スレ行けよ
ここのスレタイ
Vue vs React vs Angular
だから それにしてもAngular使ってるサイトだけは全然見つからないよね
Angular本家とお名前と去年の技術書展くらい(今年はReactに変わってた) WebAssembly使えばこういう問題も回避できるの？
Apple、プライバシー問題のため16ものWeb APIのSafariへの実装を拒否
https://css-tricks.com/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/
Appleが実装拒否したAPI一覧:
- Web Bluetooth
- Web MIDI API
- Magnetometer API
- Web NFC API
- Device Memory API
- Network Information API
- Battery Status API
- Web Bluetooth Scanning
- Ambient Light Sensor
- HDCP Policy Check extension for EME
- Proximity Sensor
- WebHID
- Serial API
- Web USB
- Geolocation Sensor (background geolocation)
- User Idle Detection >>709
Webはこんな方向に進もうとしてるのか
もはやプラットフォーム（OS）だな
そのうちベアメタル（直接ハードウェア）にインストールできるWebブラウザーとか出てきそう >>709
ブラウザベンダが実装拒否してるんじゃJSかwasmは関係なく無理だ
もしできるならセキュリティホールだし ブラウザがなんでもできるようになったらappletやactivexの時みたいにセキュリティ事故が相次いで
何処かの団体がセキュアなもののみを選択したAPIセットを発表して
そのAPIセットを実装したセキュアブラウザみたいなのが登場して
みんなそっちに乗り換えて
需要がなくなった多機能ブラウザは廃れて
すべてが最初に戻る まぁブラウザAPIは基本的なもの以外はサイト毎にそのAPIの実行権限をユーザーが許可するかどうかっていうのが大前提なんだけどね もうやってることがbrowse（拾い読み）の域を超えてるね >>704
同意
もっと言うとHTMLなんか無くした方がいいよね SPAの特徴まとめてみた
開発の時間とコストが大幅に増える
初期のローディングにかかる時間が増える
SEOの面で不利になる
開発者が少ない
外注する場合にコストが増える
セキュリティが低下する
メリットは高速なページ遷移が可能なことだが
逆に言えばそれが不要ならSPAは必要ないな
むしろコストアップや初回読み込み遅延などのデメリットが上回ってしまう > メリットは高速なページ遷移が可能なことだが
これ体感したことある？ 静的HTML+API+Vueの素朴なマルチページ構成がバランスいい >>718
画面全体をロードせず、必要な部分を
読み込むので高速になる、と一般的に言われてる。
アプリっぽく軽快に操作できないと困るサイトなら必要だけど
実際のところそこまで素早く操作が必要になるweb appはない気がする。
本当に快適にしたいならnatvie appしかないわけで
SPAは位置づけが微妙、手間とコストかかるわりに微妙すぎじゃないか？
FacebookがSPAで有名な事例だろうけど嫌いだから使わない SPAはWEBアプリケーションを作るための物であってWEBサイトを作るための物ではないからな
結局は使い分けだよ
世界に向けて情報発信するならWEBサイトが基本だからSPAの採用実績が少ないのは仕方ない
複雑になりがちな社内アプリケーションなどは今後はSPAが主流になっていくだろう >>717
SSRかSSG使えば初期ローディングとSEOの懸念事項は無くなるんでないかい
Googleだけに関して言えばJSも読んでくれるらしいからSPAでもSEOに関しては問題ない SPAは自分がユーザーの立場になってみると思ったより使い難いんだよね 全ページSSRにしたらJSが無くても使えるしね。
SPAは便利だね。 業務系システムとSPAは相性がいい
業務系では複雑怪奇なUIを求められることが多い
そして業務系と言えばJavaかC#
Javaは廃れ行く運命だがC#にはBlazorがある
業務系はもう全部Blazorでいんじゃねえの やっぱ業務系か
SPA需要ってPCありきかなと感じていたんだ
Android/iOSならSPAにこだわらずネイティブAppにしちゃったほうがユーザビリティ高いよね
そう考えるとモバイルファーストが謳われてる現在、SPAは下火になっていくのだろうか 非SPAの採用実績と比較したらSPAの実績なんてカスみたいなものだろうね
そしてこれから先もそんなに伸びることはないと思う
そもそもSPAを導入したら何か大きな恩恵を得られるかっていうとほとんどのサイトがいやー別にそれほどでも…って感じでしょ？
糞言語のJSに縛られてSPAを導入するぐらいなら、使い慣れたPHP、Ruby、Pythonでサクッと非SPAで作っちゃったほうが安くて、品質もいい
ということでSPAの生存戦略として、業務系にフォーカスするってのは有効だと思う
今のところBlazorだけが唯一そっち方面で流行しうる下地を持ったSPAフレームワークと言っていい
業務系ではJSもTSも蛇蝎のごとく嫌われてて人材が足りないから、業務系で既存SPAフャ戟[ムワーク三試墲ﾌ生き残りは血ｵしい
Blazorがうまく行ったら、Javaが後追いでパクリを出してくるだろうね
そしたらまた、勢力図が変わるかもしれん >>721
Web siteを作るのにSPA framework使ってる人は
ほぼいないしいたらアホでしょう
Web app限定の中でも95%以上はSPA必要ないだろうってこと
>>717のデメリットがメリットを上回る Googleが期待したほどSPAは盛り上がらなかったね
それで結局ChromeOSも方針転換してAndroidアプリ・Linuxアプリがインストールできるという流れになってしまった
でもVSCodeのようなWeb技術をベースにしたネイティブアプリも人気があるんだよね
Web技術はマルチプラットフォーム対応アプリを作るのには向いているのかも >>721
最終行
業務用のweb appはASP.net系シェアが圧倒的だし今後も変わらない。
ASP.net系は開発生産性が高い
長期でMSがセキュリティとかのパッチ出してくれる
だからASP.netは法人に選ばれる
Windows PC限定にしてWPFとかのnative appだけで作るのもあり
開発スピードが最速になるしUXも最高レベルになる
社内限定ならcross platformなんていらないし ActiveDirectoryに縛られて惰性で使ってるだけ >>722
SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ
SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損 >>731
ふーんJavaよりシェア大きいんだ
俺もネイティブは楽で高品質だから、良いと思うけど、
従業員への配信がめんどくさくないかい？ >>726-727
SPA調べてまさにそのSPAの中途半端さに気付いた
UXも開発スピードもNative appが最強だから
業務系ならnative appだけもあり
SPAは開発のコストと時間かかるわりにUX改善はたいしたことない
しかもサポート期間が短くメンテナンスも金がかかる blazor wasmで殴りこんで来て今度はネイティブアプリって
マジで何しに来たんだ >>735
ネイティブと比べた時のBlazorの利点はセキュリティと配信しやすさ
サポート期間と開発生産性はマイクロソフトだから心配してない >>734
WindowsならGroup policyとかのシステム管理機能で
Applicationの自動インストールとかできるしdeployは楽だよ
JavaはORACLE所有になってライセンス実質有料になったし
ますます下火になるでしょう SPAフレームワークが使えないんじゃなくてオメーらゴミエンジニアが使えるレベルに達していないだけな どっちにしても、今のSPAフレームワーク使っている奴ならこれからwasmやblazorとかが台頭してきても
それらが使い物になってから手を出しても全然遅くないだろう。
今phpやrailsとかで食えている人ならそもそもwasmに手を出す必要性すらないかもしれない。 使うなら使うで問題ないが、使う価値があるか、は全く別の問題だからなぁ
バカだったら、なんか知らんけど新しいもの、ぐらいの軽い気持ちで採用しちゃんだろうけど >>740
WordPressで済むようなWebサイトにJSフレームワークを入れるのが非効率なのと同様
一般的なWebにwasmなんて不要なはずなんだよ
canvasにゴリゴリレンダリングする様な演算回数が多い様な場合とかそういう場合だよね必要になるとすれば >>733
> SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ
失われないよ
SSRの仕組みは下記記事分かりやすいからおすすめ
https://qiita.com/amakawa_/items/e7d0720e1ab8632769bf
> SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損
同じこと書くけどGoogleに限ればSPAでもSEO的に問題ない
それにSSR・SSGなら他検索エンジンでもSEO的に問題ない
GoogleはJSを読んでくれるっていうのも結構前の話だから、今は他検索エンジンでもOKなやつあるかも YahooもGoogleのエンジン使ってるみたいだから多分YahooもSPAでSEO的におけやね SPAでもSEO的に問題ないんじゃなくて
SEO的に問題ないSPAを使うべきだよ
SPAが高速っていうのは2ページ目以降の話で
1ページ目は結局全体を読み込むんだから
静的ページとほぼ同じものをサーバー側から返すようにするべき
そうしないとJavaScriptの処理でレンダリングが遅くなる
2ページ目以降は速いなると言うがGoogleのクローラーなんかはページ読み込みの
タイミングはバラバラなので2ページ目以降も1ページと同じように読み込む。
そうするとSPAの速いっていうこうかがなくなる
ページ読み込みの速さもSEOで重要なので、どのページを最初に読み込んでも
JavaScriptなしで表示されるようにするのが正しいやり方 ようするに2ページ目以降JavaScriptあり（SPA）で表示する
1ページ目JavaScriptなしで表示する
これを実現するためにSPAでサーバーサイドレンダリングは必須なの SEOを考えるような内容のサイトでSPAが効果的な物って例えばどんな物がある？
pgadmin4のような高度なappならSPAが効果的って主張は理解できる
だけどqiitaのようなsiteにSPAを使うメリットは無いと感じた
伝統的なsiteの振る舞いと異なるから直感的な操作感で言うとマイナスまでありえる 寧ろSEOが必要ない様な利用者が限られる部分に使うべきなんだよ
EC的なものなら確かにシステム的な側面とSEO的な側面の両方が必要だけど
それ以外のシステムならそもそもトップページ以外検索エンジンにヒットする必要ないものって結構多いはず SSRはバックエンドのリソース消費量が増えるから嫌だな
クラウドだとコストにも響いてくる >>747
ないと思うよ。だからReactとかvueとかの
ウェブアプリ用フレームワークはjQueryの代替にはならないし
ウェブサイトがウェブアプリに作り変えられることもない
俺がもう5年ぐらい前に出した結論
そしてこの5年のjQueryのシェアの増え方と
フレームワークのシェアの増え方を見ればそれが
正しかったと証明されてる。 しかしそう考えると、学ぶべきフレームワーク、人気のフレームワークといった文句でSPAフレームワークが紹介されるのはなぜなんだろう？
そんなに人気があるなら、採用するサイトも増えるはずだけど、ほとんど見かけない
SPAフレームワークを覚えた人は何処で働いていて、どんな成果物を残したのか？
このスレの人の手がけた公開サイトがあるなら、ぜひ知りたい 業務用Webアプリの開発に使うからだろ
Webアプリ作れないゴミエンジニアは格安だから使えなくていいんだよ >>752
SaaSで使われまくってるよ
てか求人サイトでフレームワークの名前で検索するといっぱい出てくる
静的なWebサイトだとツールのドキュメントとかコーポレートサイトでちょくちょく見かけるかな
SasSでもWebサイトでも無い感じのやつだとTwitterとかYahooとかPixivとか >>752
見かける見かけないってそもそもブラウザにインジケーターアドオン入れてから言ってくれよ
どうせ入れてないんだろ？ ふーん
で、何割ぐらいのサイトでSPA使われてんの？ ゴミサイト含めたら圧倒的にほんの少しだろ
そんなにゴミサイトが気になるなら一生気にしていればいい 自分が分からない・作れない技術が普及したら恥ずかしくて困るから。
それに対するアクションがこんな辺鄙な場所でジタバタ足掻くこととはねｗ
こりゃ仕事できませんわｗ 寧ろ
・Wappalyzer
・React Developer Tools
・Vue.js devtools
・Augury
これらの拡張機能(アドオン)を入れずにどうやってないって判断してんだよ 敵視はしてないが純粋に疑問なんだ
これがどれほど役に立つのか
噂に聞くほどの実績が本当にあるのか
今のところそれほど有用ではなさそうだなといった感想
それを覆すほどポジティブな意見が見られない そのプログラミングモデルを自分で気に入るか気に入らないかでいいと思うがねぇ。
自分に合わないと思うなら別に使わなくていい。 現に俺様がSPAフレームワーク使って業務アプリ作りまくってるんだからこれが正しいんだよ
SPAフレームワーク使わなかったらもっと開発に時間かかる
さらに実際の業務にも時間がかかるようになる
オメーが知らねえだけで世界を知った気になるな フレームワーク自慢程反吐が出るものは無い
フレームワークは何でもそうだけど
フロントサイドだったら
必ずしも全員がHTMLや
CSSの仕様を完璧に理解している訳では無い
View層は特にやり方に絶対の正解がない
DBMSみたいなカッチリとしたデザパタはない。
フレワなしの純粋なHTML CSS
JavaScriptだけなら最初から全てを知っている必要なくて
必要なところだけ即興でググって記述することで
細かな調整ができるけど
フレワでそれを隠蔽したら
頭の中にCSSやHTMLの仕様を完璧に知っている必要がある
まずググるのが難しくなる
必要な箇所だけ自力で修正する事が難しくなる
フレワが自動生成するコードが増えるほど
DevToolsでの解析が難しくなる
自動生成されたclass属性のどれがどんな効果を持っていて
DOM要素にどのような影響を及ぼしているのかの
推測が立てにくくなる
そしてそれを頭の中に完璧に理解してる人間なら
HTMLやCSSや普通のJavaScriptを書いた方が早い
新たにフレワの文法を覚えるのが馬鹿馬鹿しい。
フレワが何種類も乱立してたらなおさらだ。 >>768
オメーがゴミなだけだろ
htmlとcssができないってどんだけ低レベルなんだよ？
デブツールみてわからんとかゴミクズじゃん
とにかくできない奴が声高々に吠えるな
ここにきちんとできている俺様がいるのにゴミが勝手に決めつけんじゃねえよ >>769
スマンな俺もUI/UXのフレームワークに頼りっきりでCSSは微調整以外は碌に書けん このスレはいつみても
どうでも良いことで
盛り上がってんな 外部向けサイト⇒SPAより非SPAのが向いてる
社内向けサイト⇒人材と既存資産が豊富なC#が有利⇒Blazor >>765
？
Webアプリ作るなら今のところ最適解がSPAだろ？
なんで化石も含めて大量にあるWebサイトの中でどれくらいの割合使われてるか知りたいの？ > Webアプリ作るなら今のところ最適解がSPAだろ？
たまたまSPAになってるだけだと思うけどな
通常はAjaxで十分だと思うよ >>773
スマホを視野に入れたPWAならSPA構成でいいと思う 流れをぶった切って悪いけど、SPAでレスポンシブに
対応したフレームワークって何がある？ >>773
最適じゃないからPHP、Ruby、Pythonなどの伝統的なフレームワークが選ばれる
SPAは僅かな領域だけでしか通用しない >>778
Bootstrapでも入れたらいいんじゃないか？
BootstrapVueでもReact BootstrapでもNative JavaScript for Bootstrap本家Bootstrap5αでも選択肢は選り取り見取り でもBootstrapはDOM操作をするだろ？
そうするとフレームワークと一緒に使えない >>781
上に挙げてるが
BootstrapVueやReact Bootstrapのようにフレームワークに特化したパッケージもちゃんとある >>778
スレタイのうちどれ使ってるの？
ReactならChakraUI超オススメ。 Rails + React + Bootstrap
Bootstrap は、CSS/SASS を知らなくても、簡単に見た目を整えられるから、
GUI に弱い、サーバー側開発者にとって必要
Rails 6.0 からは、Webpack が標準になったから、Node.js も必須
API モードもある。
描画せず、JSON だけで、やり取りする >>765
お前のその疑問に>>755が答えと探し方、>>764が確認の仕方を書いてくれてるやん
その感想が探してない、確認していない、認めたくない、ってことの証明になってるよ >>786
>>755
使われまくってる⇒子供か
いっぱい出てくる⇒子供か
ちょくちょく見かける⇒子供か
求人サイトで～⇒求人に乗ってる情報なんて極々僅かな割合でしかない
Twitterとか～⇒事例たったの3つしか挙げられないのか
>>764
アドオン～⇒ウェブ全体を走査する方法がわからねえだろ少しは考えてレスしてくれ そもそも>>752が見かけないっていうから
どうやってない事を確認したんだ？って話じゃん SPAの短所いろいろ書いてSPAって必要なの？って書いたら
批判、炎上するかと思ってたけど予想外にそうならなかった。
SPAに興味ありつつもSPAで開発経験ある人少ないってことだな
SPAは短所もあるからSPAのframework決める前に
SPAでやるかどうかをしっかり考えて決めるべきだと思う。
明らかに向かない用途ってある
SEO以外にもセキュリティ低下とか、開発工期、コスト上昇
JS-SPAなら短いサポート期間とか SPAは目的じゃないからね
ページの一部を動的に変更するならただのJavaScriptでいいし
全体に近いぐらい変更するならページ移動しても大差ない。
それに下手するとSPAにすることでユーザビリティが低下することがある
例えばURLをブックマークに入れてもそのページにたどり着けなかったり
ブラウザの進む、戻るがまともに機能しなかったりする
ユーザビリティの設計は難しくなるのにその設計をしないで
フレームワークを使ったからSPAになりました。
なにも工夫してないけどSPAなら速くなってるんでしょ？なんて
適当にやってる人が大半
ゲームやフォトショップみたいにアプリ（ウェブアプリ）を起動して
そこからデータファイルを読み込んで編集するツールならいいけど
ページ移動が行われるようなSPAはページ設計が重要になってくるのに
それを理解していない >>743
SSRだと更新は差分のみだから速いっていう主張だと思うけど
serverもUAも負荷が高くなければページ全体の更新でも
高速にレンダリングできるでしょう
UA側はPCはもちろん2万円の中華SPでもサクサクページ全体を開ける性能ある。
server側の性能さえ十分確保すれば差分更新かページ更新かは
あんまり問題にならないと思う >>764
Wappalyzer
Firefoxにいれてみたけどおもしろいな
大手でもSPA web frameworkの採用の少なさに気付いた
React人気と言ってる人多いがReact系のweb frameworkはあまり使われてない
ただのUIのライブラリとしてReactを使ってるだけってところばかり
Twitterもそう
>>708
Googleが作ったというにAngular自社で使ってないのが笑えるな
YouTubeはPolymerしか検出されない
Google MapもSPA framework使ってない
Vanilla JSでゴリゴリ書いてるんだろうな WebサイトみてReactとか使われていないとかいうゴミがいたらオメーの認識が未だに改まってねえからさっさと治せとしか言えない >>794
誰もReact使ってるサイトがゼロとは言っていない。
React使ってるサイトは0.4%程度だと言ってる。 >>781
メジャーなframeworkで
bootstrap使えないやつないんじゃないか だから言ったじゃん
コンサルの養分なんだよキミタチ >>792
SSRはサーバー負荷めちゃ高まるから嫌だ
このサーバーレスの御時世では最悪の選択肢1つと言って過言ではない
だいたいサーバーサイドに状態を持たせるとか大昔に逆行してるし >>799
サーバーサイドに状態を持たせないで作れるものを言ってみ
例としてオンラインゲームは無理な >>801
なんでもいいよ
セッション持たないRESTな設計なんて今どき珍しくもない
メモリキャッシュとか言い出しそうだから予め言っとくが
これは高速化のためであってSSRのようにしかたなくリソース食いつぶすゴミとは真反対だからな > セッション持たないRESTな設計なんて今どき珍しくもない
HTTPはセッション持たないじゃなくて持てないんですが？
あれあれ？すべてのウェブサイトはサーバーサイドに
状態を持たないって話でいいですか？ｗ セッション持たないRESTってなんですかね？
どのユーザーでも同じデータ返すって言ってるんですかね？ｗ >>804
バカかな
状態持たなくてもリクエスト（パラメータ）に応じて結果変えられるじゃん
RESTではこれが基本
セッションオブジェクトはあまり使わない >>805
セッションオブジェクトはリクエスト（パラメータ）に応じて結果変えてるので
サーバーに状態は持っていません
はぁ、仕組みを知らないんだな
フレームワークばっかり使ってるから
そういうアホなこと言うんやで（笑） >>805
あとはURLにセッションIDを入れる方式は
セキュリティ的に脆弱なもの扱いだからな
そんなもの提案したら素人だってバレるでｗ 言ってますねｗ 気付いて無いんですねｗ
HTTPの仕組みを知ってるのであれば
状態をもたせるやり方を言ってみ サーバーにセッションオブジェクト（メモリ）を確保する
セッションオブジェクトに対してセッションIDを発行する
セッションIDリクエストパラメーターやクッキーで維持される
クライアントは複数のリクエストに渡って同じセッションIDをサーバーに渡すので
サーバーはクライアントのリクエストの連続性（セッション）を認識できる
またセッションIDからセッションオブジェクトを引くことでセッションの状態（情報）を継続利用できる
間違っとる？ ああもしかして、セッションID＝リクエスト（パラメータ）だって知らないのかなｗ いやRESTはセッション使わない構成多いよ
REST＝関数のイメージ
引数に対して戻り値が返る
引数はリクエストパラメーター、戻り値はレスポンスね
RESTは一問一答で完了するパターンが多い
以前のREST呼び出しの内容な作用されない
だからセッションオブジェクトを使わないと言っている セッションIDはリクエストパラメーターになることはあるけど
リクエストパラメーターがセッションIDということなはならんよ /add?param1=123¶m2=456
この足し算RESTにセッション要るか？
このパラメーターがセッションIDなのか？ OWASPの"REST Security Cheat Sheet"ではただ一言。「セッションベースのユーザ認証を使え」と書いてある。
https://www.glamenv-septzen.net/view/1350#id55be56
ユーザ認証にはセッション管理を使え、とあり、さらに、セッションIDやAPIキー、ログインIDとパスワード、
トークンなどはURLに含めるな、ともある。
他にもこのページにはRESTスタイルで開発するときのセキュリティ上の注意点が解説されている。英語になるが、
内容的には普通のWebサイトと同じように入力チェック＋出力時のJSON/XMLに合わせたエンコーディング、
CSRF対策などをしてください、という流れ。
また以下のページは、逆にRESTなWeb APIを診断する、pentester向けのガイドとなっている。
クロールできたURLだけでは、全部のREST APIの機能を見れたことにはならない可能性があるので、
ソースコード診断（ホワイトボックステスト）も可能なら実施したい、などとあり、参考になる。 >>817
だからオンラインゲーム無理ってことですねｗ >>800
最近Next触り始めたけどドキュメントにやたらSSG推してたから、あながちGatsby最高マンダムなんかもなと思うわ
GatsbyはでもGraphqlと結びついとるから気軽にカスタマイズしようとしたらエラー吐きまくる >>817
クライアントだけで実装できるものしか
作れないと言ってます。
お前のやり方ではログインが必要なものは作れません。
オークションサイトは作れないし
ブログの管理をすることもできません。 >>803
ド素人がセッションも知らないのか？
CookieにセッションIdメモってサーバーサイドオブジェクトと紐付けるんだよ >>822
お前の理屈は、クッキーの代わりにパラメーターでセッションIDを渡せすという
セキュリティ的に脆弱なセッション管理を実装すれば
サーバーに状態は持ってないことになるんやろ？ｗ
アホやなぁと言ってる >>821
だからSPAのバックエンドにRESTが適してるんだよ
SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
サーバーがセッション管理から解放される
これもSPAのメリットと言えるかもしれないね もしかしてパラメーターのキーの名前がsession_idじゃなかったら
サーバーサイドに状態を持たせてないことになるとでも思ってるのか？ｗ > SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
え？ URLにパラメータとかユーザー名とかパスワードを入れればいいんだから
SPA関係ないじゃんｗ クッキーを使えばクライアントに状態を持ってる！
例えばセッションIDをクッキーに入れておけば、
ウェブサイトにアクセスしたときにログインしたことになる！
JavaScriptも不要！古くから使われてるログインの仕組みだ！
みたいな話をされてこ困るんだよなぁ（笑） クライアントにしかデータを持ってないと
別のパソコンでログインしてもデータが見れなくなる（笑）
まあそれでいいなら普通のウェブサイトのほうがいいだろうねｗ
HTML+CSS+jQueryで アホのために説明してやるか
Cookieとサーバーサイドのオブジェクトの紐付けで擬似的にリクエスト間の状態維持を実現する手法がセッションな
従来のシステムではよく使われていたが思ったよりメモリ消費がバカになんねえなぁってことで今はもう廃れた
今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
そうすれば極僅かなCPUの負荷増でメモリ消費をぐっと抑えることができるようになる
リクエストに乗せたくない重大な機密や大きすぎるデータは永続化層で管理する
これがメモリに乗るのはデータ利用するその時とキャッシュされた時だけ
これでサーバーサイドのリソース効率がだいぶ良くなった
ついでにいうと水平スケールもしやすくなって一石二鳥
SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRの特性上どうしてもﾋビューに関するほとんどの状態をサーバーのメモリ上に確保してクライアントが去りゆくまでずっと維持し続けなければならない
これがどれだけリソース効率が悪い邪悪なアーキテクチャかは猫でもわかるだろう
クラウドファーストなこの御時世ではサーバーサイドのリソース増加はコストに直結する
こんな金食い虫のアーキテクチャではやってられんのだ >>793
ちなみにWappalyzerでは検知出来ないけどReact Developer Toolsなら検知されるパターンもある
多分Webpackの難読化の影響かとは思うが
Amazonの欲しいものリストのページやプライムビデオのページとかそんな感じ >>797
AngularはMaterial系が主流だからBootstrapの対応はあんま良くないな >>829
> 今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
その方式はデータが大量になったときに破綻するので
セッションIDぐらいしか入れない >>829
> SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRとは無関係 https://ssr.vuejs.org/ja/
従来の SPA (シングルページアプリケーション) と比べて、SSR の利点は主に次の点にあります:
・検索エンジンのクローラが完全に描画されたページを直接解析するため、SEO が向上します。
現在のところ、Google と Bing は同期的 JavaScript アプリケーションのインデックスを作成できます。
同期がキーワードです。あなたのアプリケーションが読み込み中にスピナが表示され、
Ajax 経由でコンテンツを取得する場合、クローラーはあなたが完了するまで待たないでしょう。
つまり、SEO が重要なページで非同期にコンテンツを取得する場合は、SSR が必要な場合があります。
・特にインターネットの遅さや遅いデバイスでは、コンテンツの再生時間が短縮されます。
サーバで描画されたマークアップは、すべての JavaScript がダウンロードされて表示されるまで待つ必要がないので、
ユーザは完全に描画されたページをすぐに見ることができます。これにより、一般的にユーザーエクスペリエンスが向上し、
コンテンツの所要時間が直接コンバージョン率に関連付けられているアプリケーションにとっては重要になります。 >>820
たしかにたいていのことにプラグイン用意されてるからなんとかなってるけどじゃあ自分でgraphQL拡張するプラグイン作れと言われたらウッってなる。 >>835
Next使ってる？
Gatsbyと比較してそれぞれになんか思うことあったら教えてほしい
Next・Firebase・Stipe他でアプリ作ろうと思ってたけど、仰せの通りGatsbyはプラグインが充実しとるからGatsbyでええやん感が増してるわ
完成形に近いスターターに出会えればGatsbyの方が完成まで早そうやし ごめんNextは使ってない。
あれ基本サーバー側も含めた構成で全部静的配信したかった自分のSSGニーズと合わなかったしあまり検討しなかった。
Gatsbyとは違って個人ユースではなく企業サービスのビルディングブロックといった印象。いろいろいじる前提のプロ向けっぽい。
SSGモードも後付けされたけどだったらGatsbyでいいかなって。
ちなみに >>836 の strapiもfirebaseもプラグインあるね。
strapiのは試したこともある。特に困ることなかったｗｗ 全ページSSRにすればJSオフでも見れて快適ですね。 SSRした結果をファイルにキャッシュしておけば
静的ページとほぼ同じでサーバーの負荷も殆どないしね SSRを使うよりトップページを静的なS3とかにしたら良くない？
SSLの関係とかで出来ないのかな >>829
馬鹿はお前
パフォのためにコーディングの面倒さを犠牲にして
cookieみたいなヘッダいじったり
暗号化みたいな余計なことするくらいなら
メモリ倍くらいに増強してセッション使うわ
楽だからな。
ローバラがあるならセッションも諦めて全部
DBかローカルストレージのどっちか
とりあえずクッキーはない >>842
お前はもうちょっと世の中を見たほうがいぞ
REST APIはクッキーに暗号化してデータを埋め込む方式だ
どのREST APIもそういう設計になってるはずだ >>840
SEO気にするサイトはトップページだけ
indexされればいいわけじゃないと思うよ >>844
お前いつの時代のエセSEO業者だよｗ
SEOといったらページごとにテーマを決め
そのテーマに絞って内容を書くことでより多くのページを
検索に引っかかるようにするのが常識だろ >>845
なんなの？
2行つながってるわけだがトップページだけやればいいと誤解したのか？
そもそもweb appやSSRの文脈で「テーマに絞って内容を書く」ってアホじゃないの？
web appが動的に生成したpageをどうsearch engineにindexさせるかって話だろ。
staticなcontentsのSEOの話など誰もしていない Ruby on Rails では、未経験者が、1か月で作ったポートフォリオにも、ログイン機能はある
かよちんの動画
【ポイントは一つ】プログラミング未経験でも受かるポートフォリオの作り方
https://www.youtube.com/watch?v=la0rkh6wlxA
ログイン、投稿、コメント、いいね、検索、マイページ機能
Rails + Bootstrap
Github, Heroku 例えばユーザ認証するならFirebaseとか外部サービスに任せればいいだけだろ。。
ってか相変わらずスレチで伸びてるな。SPAって言葉が独り歩きしすぎだよ。
個人的にWEB開発者として重要な変化は、
・リアクティブ
・IDE(VSCode含む)による環境の統一やコード補完
・ホットリロード
この３点だろ。SPAだろうとSSR主体だろうと共通して劇的に楽になった。
あとは作りたいものに合わせてフレームワークなり言語選ぶだけだろ。
大手のサイトにフレームワークが導入されてないとか見たが、jQueryだけなんてサイトは案件的にありえない。
少なくともリアクティブでデータドリブン。どのライブラリを選定するかは大きな違いじゃない。
個々の要素は確実に進歩してるよ。 でもほとんどのサイトがSPAだとオーバースペック、UX低下(非SSRの場合)、リソース消費量激増(SSRの場合)、人材不足だから非SPAを選んでるんだよな
複雑なUIをどうしても避けられない高度なSaaS、社内システムなど、ならSPAを採用するメリットはあるかもしれんが、そうでないならデメリットのほうが大きい >>849
SSRゴミカス野郎にリアクティブやらせたらデータと表示が一致させられなくて死ぬ
>>850
ゴミカス自称フロントエンジニアのゴミのようなUI/UXスキルはどうしようもないほど低レベル
コイツらにまともなUIを作れるわけがない
一生かかってもゴミセンスから抜け出せない VueとかNext.js使ってる人は
結局SPAとしては使わずに、SSRで使ってるということか？ >>852
SPA最大の利点はサーバの負担が軽い事だと思う。
フロントのためのロジック丸ごと省略できるから。
主に製作者側の都合なんだけどね。
例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
バックエンドは完全に共通になるしメンテ楽だわ。
ただ現状、WEBを作る場合ほとんどのケースでNextでSSRが最適解になるなあ。 >>854
デベロッパーだけの都合でもないよ
クラウドのランニングコストを支払う運営の都合でもある >>854
SPA vs サーバーでその処理を行うだったらそのとおりだけど
実際にはサーバーで処理を行うとは限らないんだよ
例えばAjaxを使ってJSONだけ読み取ってローカルの
テンプレートエンジンで処理をする。
マルチページで作るんだからこれはSPAではないよ。
JSONだけ読み取るのは現在のページ（URL）での処理だけ
それでもサーバーの負荷はわずかに減ると思うかもしれないけど
ボトルネックは通常データベースアクセスになるので
単にサーバーのCPUの休み時間が増えるだけ
> 例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
> バックエンドは完全に共通になるしメンテ楽だわ。
それもSPAである必要はないね。JavaScript（Ajax）で作ればいいだけ それにしてもURLが異なれば、通常はJavaScriptの処理も
まるっきり変わってしまうのになんでSPAにしようとしてるんだろうね
単にマルチページ+JavaScript（Ajax=テンプレート+JSON）でいいじゃない？ ここでいうSPAフレームワークはリアクティブなんだよ
ajaxで取得したデータは自分で処理書かないといかんだろが
それとコンポーネント化
これらを理解できねーゴミクズたちが必死に浅い知識でSSR自慢しに来ている
わからねえならあっち行けよ まああれだな。新しい技術ができたら、それは銀の弾丸だとばかりに
それが正しい、それでやるべきだ！といういつもの流れ
そこから一方戻って、というブームがあったんだが実際はどうだろうか？
やりすぎだった。それが全てではない。適材適所だな。と気付いて
ようやく一人前の技術になると思うよ。今はまだブームの段階 >>859
リアクティブとSPAは関係ないだろう
マルチページじゃリアクティブできないとでも？ >>859
コンポーネントもSPAに限った話じゃないし
いにしえのJSFやASPNETですらサポートしてる
他のフレームワークもほとんどすべてがサポートしてるだろう >>860
ゴミクズの一味はおめえだよ
中身スカスカのレスいらないから
二度と来るな フレームワークでテストがしやすくなったというのも疑問点が残るよね。
例えばクリックしたら色が変わるってのをどうやってテストをしているのか
書いてみてほしいものだが web e2e test sweet とか
web e2e testing framework とかで検索してみたら？ テストがやりやすいと言う割に
ググらないといけないと言うねｗ >>857
その場合でも各ページの元になるhtmlはサーバが返すだろう？
ルーティングもサーバで処理する。それだとあまり美味しくない。
SPAの利点はWEBサーバのコード不要で静的ファイルを返すだけになり身軽になる事。
クライアントの帯域とコンピューティング予算を利用するスタイルだから、こっちは楽になるのは当然。
APIとDBサーバだけなら開発の負担はぐっと軽くなる。
逆にSPAの限界は、どうやっても肥大するJS。大規模には不向き。
いわゆるマルチページ（初めて聞いたが意味は分かる）が良いならNextでSSRすればいいよ。
どっちが良いという話じゃないし。 >>860
Wappalyzerで国内サイトを
40社程度調べたところだが、React-frameworkで
有名らしいNext.jsもGatsbyほとんど使われてない。
Gatsbyに関してはWappalyzerで集計すらされてない。完全ランク外
ブームといえる状態にも来てないと思う。
名前は有名になってるのに導入があまりされてないのは調べてはみたけども
導入する価値がないと考えたサイトが多い証拠なんじゃないかな >>870
新聞社のサイトで既に動いてるのがあって置き換えると思うか？
大手じゃなく新しいサイトを調べて >>872
劇的にユーザビリティが向上するなら置き換えるのでは？
ようするに大したメリットないってことか ほとんどすべてのサイトでは不要かむしろUXを悪化させるんだからSPAなんてものが流行るわけがない
コンサルさんは飯の種になるから必死に広めようとしてるようだけどな 数学わからないおじさん「数学なんて必要ない！」
英語わからないおじさん「英語なんて必要ない！」
こういう人はいくら必死に必要ない必要ない喚き続けても誰からも尊重されずバカにされてるよｗｗｗ >>876
不安でしょうがないんでしょｗ
精神的安定を得るため叩くしかないｗ
実際に必要ないとしても知れば恐れることなどないものを。
無知とは恐ろしいねｗｗｗ >>872
基幹業務と違ってWebのフロントは短期間でリニューアルする。
大手ほど資金力あるから制限なくStackを選べる。
日経、朝日、読売新聞を見てみたが
web frameworkすら使われてないじゃないかｗ
読売はWordPressだな、CMS
さすがIT後進国
IT先進国はどうか？NY Times見てみたがSvelte が使われてるな
どうやらSvelte採用のトップクラスサイトだったようだ。
Svelte の公式サイトではReactやVueを
traditional frameworksと表現して暗に時代遅れだと言ってるのが気になる
https://svelte.dev/
SpotifyとかYandexも使ってるな
https://www.wappalyzer.com/technologies/javascript-frameworks/svelte >>856
零細サイトを除いたらランニングコストはオンプレミスのが安いし
クラウド要らない派
クラウドはバックエンドの構築、運用ができない企業が使うものだと思ってる お前らが提案するフレームワーク名
毎回変わってて草 >>882
上場企業でもほとんどがバックエンドの構築、運用ができない企業に該当する
開発を外部に丸投げしてるから運用のノウハウもない 本当に良いものは長く使われる
SPAはすぐに次のトレンドに置き換えられるだろう
Svelteなどなどすでにその兆候がある 過去の遺産があれば大規模なリニューアルは難しいだろうよ。
それは否定しない。いろんな事情あるからね。
ただ内部で開発ガッツリしてる系のサービスはおおよそNextなりVue使ってる感じ。
以前みたDMMの記事は面白かったよ。興味があればDMM Insideとか見るといい。 どこそこの大手アプリはうまく行った！
こういうロジックでフレームワークを推奨してくる人には警戒したほうがいい
アプリのスケール感を全く考えてないから
日曜大工ツールセットで作るべき物を巨大重機で作ろうとするようにおかしなことになる フロントフレームワークって基本はSEO切り捨てていい部分のページ向けにまず作ってみるっていうのが大前提だと思う >>886
サイトの規模がトラフィックの事を言ってるならそれは間違いだよ。
単純に作りやすさ保守メンテを考えれば考慮に値する技術が沢山あるという事。 トップページをワッパライザしてSPA使われてねーとかほざいてるゴミ >>888
保守、メンテナンスを考えるとSPA人材の少なさが大きな問題だな
WEB系フレームワーク使う人って、やっぱ、新しいもの好きが多いんだよね
んで、要領良くチャラチャラ生きてきたせいか知らんけど、責任感もない人が多くて、すぐに新しいものに目移りしたり、転職しちゃう
こういう連中に、数年後に、ちょっと前に流行ったあのフレームワークなんだけど、君が作ったやつ、あれメンテナンスしほしいなー、って言うとすげー嫌がるんだわ
ただでさえ少ない人材が、年月を重ねるとまじで皆無になる
で、連中はコピペ人間かよって思うぐらい同じようにこういうんだ、「新しい素晴らしいフレームワークに載せ替えましょう。お見積りはこれぐらいで」
信用ならねぇわ、古くから愛用されて、これから先もずっと生き残ると思われる技術、それを使う技術者こそが信用にたりうる >>889
ゴミはおまえのこと
web エンジニアなら>>859のようにAjaxという言葉を使わない
Ajaxの定義と経緯を調べてこい
おまえが良く使うreactiveについてもはっきりした定義がない https://svelte.dev/blog/write-less-code
SvelteによるReact, Vue批判
コードが冗長すぎてうんこだと批判されてる。
Reactすこし触ったときにアホみたいにevent handler出てきて
なんでこんなめんどくさいことやってんだろうと思ったけど直観は正しかったようだ。
SvelteはcompilerだからJSの特殊さに縛られないらしい
たしかにコードがすごい短い
JS嫌いな人にはあってるかもしれないな テレ朝 react
日テレ vue
フジ nuxt
TBS 使ってない
TBS以外はSPA
TBSもがんばれ まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。 >>891
お前がゴミクソじゃねえか
俺はReactHooksが出る前のバージョンでWebアプリは数プロジェクト作ってる
全く問題ないどころかコンポーネント化が完璧にできているからメンテも楽
何が最新好きだよ？最新じゃなくてもSSRじゃ考えられないくらい開発しやすいわ
お前がゴミクソすぎてまったく使えないのはわかった
Ajaxがどうとか今さらそんなもので勝ち誇るなゴミクズ
レベルが低すぎるんだよ
クソみたいなUIしか作れないゴミクズの分際でうるせえわ
さっさとここから消えろ 多分こないだのBlazorくんと同一人物なんだろｗ
聞き齧った話しを言いふらしてちやほやされたいだけ。
おそらく自分では何も作ったことないｗ >>871
マルチページがいやなら、SRP（単一責任の原則）設計といえばいいんじゃね？ｗ
SPAって1ページになにもかも突っ込んでしまってよくない
大きなものを作る時は小さなものの組み合わせにしたほうが良いよね
SPAの方が速くなることがあるのは事実だけど作るのが大変になる ずっとvueやってたけど最近react覚え始めたら難しすぎるわ
vueのcreatedとかmountedとかわかりやすいの名前だったなあって >>878
> 基幹業務と違ってWebのフロントは短期間でリニューアルする。
なるほど（笑）
だからこそさ、フロントの役目はなるべく少なくして
サーバー側でやったほうが良いんじゃないかｗ
フロントとサーバーが同じ言語で出来るのがメリットのように
言ってるけど、分離したほうが良い。そして変化の少ないサーバーサイドと
変化の大きいフロントインドに分けて、フロントエンドのコードはなるべく少なくする
SPAの速いよりも、メンテナンス性の方が大事だろ？
フロントとサーバーが一体化されてるフレームワークだと
フロントを変えようと思った時サーバーまで引きづられてしまう
結局、動的なサーバー処理 と 静的（＋JavaScriptで動き付け）なフロントエンドという
設計のほうが長い製品寿命が得られる ゴミクズ連呼してる基地外は何に切れてるんだろうな
こんな感情的な奴はまわりでも低品質なコードしか書いてない >>894
> コードが冗長すぎてうんこだと批判されてる。
マジそれ。コードが短ければバグも少なくなる。
テストできるようにするのは良いけど、そのために冗長になってテストが大変になってる。
完璧なテストなんかやめて、テストできない部分を意図的に残すが
その部分は最小限のバグのないコードで書けるようにしたほうが良いと思うよ >>899
ﾜｯﾁｮｲ付きならもうちょい分かるのにな >>897
> まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。
そこでいう間違いっていうのは、すぐに陳腐化して負債になるコードな
わずか数年後にレガシーコードになってしまうものを覚えてどうする？
そういうコードを書くならちゃんとお前がメンテナンスしなきゃいかんぞ？ >>901
もうライフサイクルメソッドはHooksで置き換えられるからそんなに難しくないぞ Hooks使ってない人は過去に作ったプロジェクトを修正してるの？
それとも工数もらえないから放置？
プロジェクトを再開する時、これはもうレガシーですねとかいって
改修作業するの？ まあもってあと3年だろうな
その後はもう別のオモチャに乗り換えてる フロントは変化しやすいってことを考えると
フロントの処理が多くなりすぎてるんだろうな 大体黎明期に大きく変わって段々落ち着いてくるもんだけどね SvelteもいいけどElmもいいな
とにかくレトロJSと別言語ってのが筋がいい
レトロJSの都合から解放されるだけでなくWASMへの移行にも期待できる
TSも別言語っちゃそうだけどこいつはレトロJSの面影が強く残ってるのが減点 ○○は嫌いなんだ！だからレトロと言おう、レガシーと言おう！
という印象操作。脱jQueryも同じ仲間
レトロとかレガシーとか脱とか言ってるのに
それが現実にならないのは悔しいだろうなぁｗ >>899
おめーはアホだからブレザー野郎と区別すらつかねえんだなゴミクズ なんかQiitaとかでReact始めましたって人が皆classでコンポーネント書いてるのはチュートリアルがHooks対応してないって事なん？ >>913
んーでも実際レトロじゃないか？
ブラウザで動くのがそれしかない&資産（負債）が溜まりすぎて移行できないっていう、言語自体の良さ以外の理由で生き残ってるあたりレトロ臭がキッツい
WASMでそのあたりが変わって行くと素晴らしいことだが、残念ながらまだもう少し時間がかかりそうだ >>908
んなもんどんなフレームワーク使っていても同じだろゴミクズ
バックエンドのフレームワークも数年で変わってるだろゴミクズ
フロントが変化しやすいってなんだゴミクズ
テメーが使えてねえだけだろ >>916
なぜブラウザでしか動かなかったらレトロなんだ？
そのブラウザはどこでも動くんだがｗ > WASMでそのあたりが変わって行くと素晴らしいことだが
そのWASMはどこでも動かない（笑） >>918
ブラウザでしかうごかないからレトロとは言ってない
ブラウザで動くのがそれしかないという理由で生き残ってきたのがレトロ臭キツいって言ってる >>917
重要なのはフロントとサーバーが分離できてるって所
一つでどでかいシステム作るよりも
小さなコンポーネントを組み合わせたほうが良い >>928
今まで他の言語が採用できない理由を考えたほうが良いよ
採用する機会はいままで幾度となくあった
もともとHTMLのscriptタグはJavaScript以外にも
対応できる設計で、実際VBScriptだって使えた。
一時期はRubyとかPythonとかも動かそうという動きがあった
だがそれが実現しなかったのは、JavaScriptほどのメリットがなかったからだよ
JavaScriptは生き残ってきただけじゃない
他の言語が参入できなかったという事実を無視してはいけない >>915
確認したらclassになってるわ
これは公式ドキュメントから読む真面目な層がかわいそう＆公式がんばれ フレームワークを使う時は、あとからフレームワークを
捨てられるように設計することが重要なんだよな よく考えたらもう一年近くクラスコンポーネント書いてないわｗ
全部ファンクションコンポーネント＋フックAPI
createClassはそうでもなかったけどクラスコンポーネントはホンマ嫌いやったわ。
全部単なる関数で書けて最高に幸せ。
そもそもJSにclass構文持ってきた池沼は地獄に落ちろと思う。 wasmに期待してる人は一度使ってみなよ。期待してるようなものと全然違うことがわかるから Ruby on Rails では、ビジネスロジックをサーバー側へ寄せていく。
GUI には、React を使っても、コンポーネントとして使う。
フレームワークとしては使わない
Bootstrap なら、素人でもレスポンシブ対応できる。
規約だけのフレームワーク・Stimulus も使う
Reactive なら、Stimulus Reflex とか
pjax(ajax + historyAPI のpushState)も使える。
HTML のbody だけの入れ替え。
head 部分は送らないから、エコ
他にも、メール送受信、S3 へ保存、画像変換とか
デフォルトで、一式揃っているから、新規起業は、Rails で作るのが多い つまりReact、Vue、Svelte、Blazorの完成形がPHPということでよろしいか？ >>922
メリットがなかったんじゃなく単にセキュリティ担保が難しかっただけだな >>900
デスクトップアプリは全部そういう構造なんだが
設計ちゃんとしてれば詰め込みすぎでヤバいなんてことにならない メニューの階層が深すぎて設定項目がどこか見当たらないのはその為か >>926
マジでそれ。実際に書いて使ってみれば一発でわかるような事がわかってないレスが多い。 Blazor(wasm)を実際に使ってるが期待以上だった
バイナリサイズ、速度は今でも十分悪くないが今後急速に改善されるだろう 速度は今でも十分悪くない>>675-677
今後急速に改善される>>703 >>934
体感的には全く問題ない
そう言ってるだけ >>918 >>920
JSはbrowserで動く唯一の言語という特権が
あるから今の地位がある。
優遇されてるのにweb frameworkではJSは人気がない。
WappalyzerでみてもJS系web framework利用者は少なく
最大シェアでもExpressの7%
1%以上のシェアのものはExpressとNext.jsしかない
ちなみにASP.NETはシェア52% >>922
WebAssemblyならJSの縛りはなくなるし
JSを完全に捨て去ることができる。 しかし現実は圧倒的にjQueryが
シェアナンバーワンなのである JavaScriptって1回死んだよな
それをGoogleがAJAXで復活の呪文させてしまった
あのときJavaScriptでは無理だからちゃんとしたプログラミング言語とUIツールキットを載せようってなってたら違った未来があったのかな >>934-935
Wasmはbrowserで実行されるわけだからユーザーが
体感的に気にならないスピードになればいいだけだ。
C#使える人にとっては開発のスピードはすでに最速になってる。
SoCのスピードは毎年30%近くあがってるから、
ソフトウェア変えなくても今1秒かかってる処理が
まったく気にならないレベルになってしまう。 >>938
jQueryおじさんそれweb frameworkじゃないから
936の統計に入ってない
機能不足 >>941
そりゃjQueryはフレームワークに圧倒的な差で勝ってしまうからなぁ
DOM APIの薄いラッパーなので速度は早い
ライブラリのサイズも小さい
HTML/CSSとの連携で最小限のJavaScriptコードで実現するから jsが駄目ならtsで良いじゃん。c# も使えるけどtsが言語的にc#に劣る部分なんてほとんど無いよ >>936の統計に含まれてないのは
jQueryが圧倒的に勝ってしまうから？ jQueryって云わばフレームワークを使わない場合のPHPみたいなもんだしな >>942 >>944
jQueryおじさんって複数いたのか
すでに書いたように機能が不足しててweb frameworkに分類されない
最低でもrouting機能くらいないとweb frameworkとは呼べない
jQueryはJS Libraryの項目で集計されてる
https://www.wappalyzer.com/technologies/javascript-libraries
>>943
TSはJSに変換する以上、どうしてもJSの機能や速度に制限受ける >>947
JavaScriptでルーティングをすること自体がおかしい
JavaScriptが無効だと動かないサイトになるだろ >>947
機能はc#並みにはあるよ。
jsとwasmの速度の違いはリソースのコンパイルとロードにかかる時間だけだよ >>948
機能も目的も違うしjQueryはweb frameworkと
比べても意味ないんだけどそれわかんないの？
DBとかbackendの開発したことないでしょう？ とりあえずjQueryはスレチだからやめとこうぜ。 >>943
しょせんトランスパイラ
JSの束縛からは逃げられない
TSがwasmを吐き出すようになったらスタートライン blazorの遅さは体感的に問題ないと言ったり
JSの速度はやたら気にしたりよく分からん
asm.js→wasmで解決したJSの束縛って一体なんなのさ wasm触ったことないんだが、ブレイクポイント設定できるのかね？
これが出来ないなら採用は無いな。 JSの文法とライブラリに縛られるってこと
それを回避するためにスマートでないコード生成が必要になることもあるだろうな >>953
C#の出来がいいからだよ
gameとかもたくさんC#で開発されてるし言語として速い部類。
そして開発生産性が高い
Blazorの速度問題は改善の余地が相当あってMSが取り組んでるし
最も将来性がある >>952
TSがwasm吐くよりTSがブラウザーでネイティブサポートされるほうが嬉しいな Blazorはc#ランタイムをwasm上で動かしてんの？ >>956
まじか。一体どんな理屈で動作してるんだ。。
ブラウザ側にフックが既に組み込まれてるのかな。 >>958
最悪のパターンだよそれ
それやっちゃうとTSなのに環境差異出まくってTSにトランスパイルする別の言語が作られかねない TSがブラウザ実装されるとかまじで最悪のパターンじゃん
よく考えてから書けよ
IFとしてもWASM一択 Wasmにすれば、たちどころにGUIとかOpenGLとかが簡単に使えたり、高速になったり、ｍゲームが作りやすきうなったりすると思っている人がいるかも知れないが、それは誤解。
そういうものは、ツールキット次第。
Blazorの場合、実行速度も遅いし、ダウンロードサイズも大きいのでJSよりむしろ
悪化するだけ。
つまり、Blazorは悪いツールキット。 Wasmではなくnative的なものでも、
Unityはゲームが作りやすい、WinFormsやQtはGUIが作りやすい、
C++はC#より速い。C++やC#はIDEが充実している、MFCとWin32ならMFCの方
が便利、など、言語やツールキットによってそれぞれ特色があり、千差万別。
Wasmは、アセンブリ言語相当のものだから、それと同様にその上に載る言語や
ツールキットによって、それぞれ待った区別の特徴を持つ状態になる。
サイズの大きさも、GUIのプログラムしやすさも、実行速度も、これから
選べる時代になったと言うこと。
Wasmだから、速度が絶対に速かったり、絶対に便利になったりするわけではない。
便利でも遅いもの、サイズが大きいためにWebでの即時実行には不向きなものもある。
C#をWasm化すると、2重に仮想マシンが載ることになるために基本的に遅くなる。 >>964
まだ黎明期
これから期待通りになるので安心しろ >>966
MSはあらゆるもののサイズがどんどん大きくなっているので、
サイズが小さくなることは望めない。 >>969
TSをES2019とかのJSにトランスパイルしたら型情報以外ほぼそのままJSにならない？ >>965
MSの人がC# wasmでAOT compileも選べるようにするとか書いてたから
Speedはかなり速くなる可能性秘めてる。 wasm自体が未完成(MVP)で策定中の部分が多いのに将来の覇権なんて分かる訳無いじゃん
C#イイ！ってだけでゴリ押しされても反応出来んわ 速度、開発生産性、人材確保、長期サポート
全てにおいて期待が高まり、そしてそれは実現するだろう
なんたって信頼と実績のマイクロソフトだもの
マイクロソフトの提供するDXは、いつだって時代の数歩先を行ってた >>975
Web frameworkの現在の覇権がASP.NET。ぶっちぎりだ。
wasmが仮に流行らないとしたら今のままASP.net MVC Coreとかが
使われるだけだろう
文句つけてるひとはBlazor試したこともないだろう これを持ち上げるのは不本意だけどぶっちゃけASPよりRoRの方がシェア高いやろ >>979
WordPress以上のもん出さんと無理やろね
いや普通にWixの方がいいのは確かなんだけど >>978
Railsは検討してる。9%程度
ASP.NET除いたらけっこういいframeworkだな
ASP.NETは52%
ぶっちぎり >>982
なんどもソース書いてるだろ
Wappalyzerでの検出結果だ
英語わからないアホな人っぽいな wasmってただの中間コードだろ？
JSの構文解析が終わるのと
wasmのライブラリがダウンロードされるのとのスピード勝負か？ 1年後の世界へ行こう！
／'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーｰ' γ⌒ヽ／ﾌﾞﾚｷﾁ＼ ／'⌒⌒ヽ、
,-ｰｰ-､ .||~￣~|/-O-O-ヽ|. （ ┃ ⌒ヽ
/ ┃ ） || 6| . : )'e'( : . |9 ＼ ━┛ ）
.（. ┃ ） || ｀‐-＝-‐ ' ＼＿＿_,ノ
ヽ､＿＿,ノ || ＿(つ¶¶と)＿_
／||'''''| 三 | |'（⌒）
／ '―――――` ￣ ＼
`＝＝＝＝＝＝＝＝＝＝＝＝' ￣￣￣| | ｌｌヽ _| ヽ
| | |l￣| | l Blazorって未来ではどうなってんの？
| | / ´＼ /
| | ヽ､＿ ｀＾イ
二二二 」 ＿ ＿＿ ｌﾆ二二ｌ､ ＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ ┌ヽ ヽ┐ ／´ ｀＼
二二二二二二ｌ / | | | |. / ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| |_| / ヽ
| ／｀ヽ__, ─ ､ノ |─l ｌ l
|───/ ／lﾆ/ /二ﾆluul. | ! え？そんなゴミないよ
| ___|￣ | | |_|. l /
└─（ ）(ﾆ| ￣|./二ﾆ) ヽ /
￣￣ / ） >━━━━━━ く
｀ー ´ / ヽ WordPressが全ウェブサイトの35%(CMS市場では6割超)のシェアなのにaspが過半数なんておかしいと思ったｗ
https://www.similartech.com/compare/asp-net-vs-php
やっぱphp以下じゃんｗｗｗ c#や.NETの何が嫌かって
MS環境やvisual studio前提ってこと
Linuxサーバでyumやapt経由じゃないこと
つまりnodeやRailsと違って
コンテナや仮想環境にデプロイしにくい
IDEって普通のエディタと違って
重いし、勝手なことするし
そんなのlinuxとスクリプト言語で成り立ってきた
web業界で流行るわけが無い >>988
何年前の世界からタイムスリップしてきたんだ？ MSのエヴァンジェリストって困る。
名は体を表さず、悪魔。
自分で神の名を名乗るような者にろくなのはいない。 >>988
PHPやJSは無料なのに、.NET、C#、ASPは金取られるしね。
MSにこれ以上金を流したら、日本は終わり。 日本人は、みんなが力を合わせて、アメリカのIT企業の足を引っ張るべき。
アメリカ企業に就職した人は、国賊認定して徹底的に苛めるべき。
そうでなければ、この国は持たない。 技術がなくても、学は無くとも、知恵は無くとも、それぞれが少しずつでいいから、
アメリカ企業にダメージを与えて欲しい。
逆元気玉。
日本人は力を合わせてアメリカ企業を壊そう。 1年後の世界へ行こう！
／'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーｰ' γ⌒ヽ／ﾌﾞﾚｷﾁ＼ ／'⌒⌒ヽ、
,-ｰｰ-､ .||~￣~|/-O-O-ヽ|. （ ┃ ⌒ヽ
/ ┃ ） || 6| . : )'e'( : . |9 ＼ ━┛ ）
.（. ┃ ） || ｀‐-＝-‐ ' ＼＿＿_,ノ
ヽ､＿＿,ノ || ＿(つ¶¶と)＿_
／||'''''| 三 | |'（⌒）
／ '―――――` ￣ ＼
`＝＝＝＝＝＝＝＝＝＝＝＝' このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 48日 7時間 22分 47秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
