Vue vs React vs Angular Part.5
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん?
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.4
https://mevius.5ch.net/test/read.cgi/tech/1591869705/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください
Svelte, Next, Nuxt, Gatsby, VuePress, RedWoodなどはおk。 >>178
C#はネイティブメモリを安全に活用する機能があるのでメモリ効率がすごくいいよ
この機能が追加されたおかげで.NET Coreの全体的なパフォーマンスが急激に上がったのは記憶に新しい
スタックで済むところはスタックで処理できるから従来のC#、Java、JavaScriptのように必要のないところでオブジェクトのためにメモリを確保しなくても済むようになった
これがパフォーマンスにとって大きな影響がある
JSがこれを模倣しようとしても型安全性と構造体がないからそう簡単にはできない
TSがトランスレーターに甘んじてるうちはTSでも同じこと
TSが完全にコンパイラなったとしてもref、Span、構造体に相当する言語機能を導入しなければならないから簡単には行かない >>183
jsの場合jitがその辺はやってるんだよ。型が変わらない変数ぐらいjitは見つけて最適な型で最適なところに割り当ててる、スタックやレジスタレベルでね。refどころか関数のインライン化もやるよ。
c#のjitも凄いけど、それをwasm上でやるのは大変じゃないかな? ホントは、Wasmの本質は速度向上ではなくて、言語を変えられることだよ。 >>184
その程度じゃ全然最適化が足りないんだよ
機械的な判断じゃどうしたって最適化していいか確定しない部分が沢山でてくる
C#だってデスクトップやサーバーサイドで最適化のノウハウをしこたま溜め込んでる
その蓄積があるのにあえてプログラマの手で高速化するための手段を用意した
マイクロソフトはJITを極めてもそれだけじゃ満足できないとわかってたからね
結果として.NET Coreは凄まじいパフォーマンスを獲得したわけ
Blazorはまだ黎明期だからしかたないけどサーバーサイドのベンチマークはまじで凄いからね >>185
それ。他言語のライブラリとか持ってこれるのが助かる
>>186
そうだね。早く速くなるといいね >>186
お前いつまでここに寄生してその話続けんの? >>187
他からライブラリを持ってこれる、というようなことだけじゃなく、
JSには、ちゃんとしたclassの概念もなければ、ちゃんとしたstructの概念も無い。
明示的な型指定も出来ない。
また、常にGCがONなので速度的に不安定。
変数は原則的に全てHeapからの確保になってしまうので使い始めが遅い。
動的に型が決まるので、JITでもある程度以上最適化できない。
そういうところがC++では改善できる。 >>191
wat書くとそのへんは痛感するね。流石にcppとかrustには叶いませんわ。 C++はJITが効かないので、最悪Javaの20倍ほど遅い。 >>194
それは、狭い範囲における非常に稀なケースだが、
WasmはJITが効くので、C++も出力をWasmにしてしまえば、原理的には
同じ事が出来るわけだけど。 > C++はJITが効かないので
JITって何かわかってる?
ただのCPUに最適化したコンパイルに過ぎないぞ
C++でもコンパイル時にCPUに最適化すれば同じことだ >>195
JITの方が速くなる可能性があるとすれば
1. たまたま実行した環境では、要素数の多いSIMDが使えるCPUの場合、そのCPUに
合わせて最適化できる。
2. 予め最適化する場合には、実行段階で、CPUの場合分けのためのオーバーヘッド
が少し生じる。
3. 実際に実行してからのプロファイリングを用いて、繰り返し回数の多いループ
を重点的に最適化できる。
これもテスト時にあらかじめ行っておくことも出来るが、何らかの要因で
条件が大幅に変わった場合には、JITでやる場合と差が出てくる可能性がある。 そもそもwebというかブラウザがdomとcssに結局は縛られるから、そっちのが問題だと思うけどなあ。。
そしてdomはとても壊れやすい。それが起因の問題は今でもちょくちょく体験する。ブラウザ互換も未だに完全じゃない。
wasmだc#だと言っても、UIまで包括的に別の仕組みで動作しないと同じだと思うよ。 Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 wasmとかc#とかMSの話してる奴
これもう荒らしだろ。
単語NG安定 >>200
そういうマイナーなframeworkは
バグとかの情報少ないし一番めんどくさいだよ
お手軽っていうのはユーザーが多い
ASP.NETとかRuby on Railsのことなんだ
Rubyはweb以外ではろくに使われてないし
結局、ASP.NETが最強ということになる >>199
QTが動いたって話だしそのうちDOMに依存しないUIフレームワークもでてくるだろうな
それが良いかどうかは未知数だが 【ワッチョイ有】Vue vs React vs Angular Part.5.5
https://mevius.5ch.net/test/read.cgi/tech/1596110361/
スレチガイジが居ないスレはこっち >>191
スタックメモリを有効活用しようとしたらstruct必須だからJSの言語機能を大幅に改修しないといけないね >>206
c#しか知らないのにそういうネタ出すの止めたら? >>207
他の言語も知ってるけど?
俺はJSしか知らないフロントエンジニアじゃないよ C#しか知らない業務ソフトおじさん
略してソフトおじさん >>205
C#理解できないレベルの低い人たちだけのスレ立てたのか
わざわざ分裂させて時間を無駄にしたがる人たちは理解できない Ruby は、Vagrant, Chef, ServerSpec, Github とか、サーバー構築テストに強い
Chef では、以下の抽象化構文で、Cent 系のrpm/yum, Debian 系のdeb/apt の、両方に対応できる
package "dstat" do
action :install
end ここでCの話してるやつって外国に忍び込んで蝕んでいく中国人みたいだな JavaScriptに話を戻そう
ReactってそもそもHTML要素が既にある時点で
イベントハンドラとかprops stateとか作りこんんで行く訳だが
そもそもHTML自体をしこたま動的に生成しなきゃならん事
多い。
そういう時ネイティブ JavaScriptの
createElementとappendChild使うのがいちばん便利
なんだわ。
動的に生成したDOM要素にイベントリスナ設定して
ピタゴラスイッチ見たいにUI構築していくのは楽しい。 手動でやりたいならどうぞご自由にとしか。
JSスレ行ってね。
あ、ついでにC#ガイジとRubyガイジも一緒につれてって。頼んだよ。 Document.createDocumentFragment( ) だろ >>204
QTってWEBはWebGLが前提だろうから、どうなんだろうね。
でもWEB版とネイティブアプリ版両方作るなら、一番合理的とも言える。
欠点は読み込みがクソ重くなる事か。。 >>214
まあ仮想DOMってdocument配下にないメモリ上の状態でガチャガチャやるわけだし
実DOM直接操作するよりはオーバーヘッドないんじゃない? >>218
仮想的なDOMを操作しても
最終的に実DOMに反映しなければいけないのだから
仮想DOMの処理はは100%オーバーヘッドだよ 一番速いのは、仮想DOM操作も実DOM操作もしないこと
当たり前だよね?
つまりHTML/CSSだけで実装するのが一番速いわけ
できないと思うなら「CSSだけで作った」で検索してみりゃ
いくつもCSSだけで動きがあるものを作っているサンプルが見つかる
次に速いのは必要最小限の実DOM操作を行うこと
これも当たり前。これはCSSだけでできないことをJavaScriptで
行うが、必要最小限のクラスなどの属性の変更で行うこと
DOM要素の追加削除は行わなず、CSSを使って表示非表示で対応するのでのでこれも速い
ただしHTMLとCSSを正しく理解していなければいけないので
JavaScriptからウェブに入ったなんちゃってウェブプログラマには荷が重い(笑)
ちなみにjQueryを使ったプログラミングでは、この必要最小限のDOM操作を行うのに適している
仮想DOMっていうのは、このHTML/CSS/JavaScritpのベストプラクティスを無視して
全部JavaScriptでやったら重くなった→どうにかしてマシにしたい
というバッドノウハウとして生まれたものだよ
HTML/CSSまたは、jQueryを使って正しくプログラミングしたものに比べれば
仮想DOMは遅い jQueryがネイティブより速い? 何言ってんの? >>221
ネイティブより速いなんてどこにも書いてないよ
速度で言えば速い順に
JavaScriptなし > ネイティブ > jQuery >>>> フレームワーク
なのは当たり前でしょう? 要はその「必要最小限のDOM操作」が自明じゃないような大規模な画面の変化をさせたい場合には
仮想DOMの効果が出せるということ。 いや実DOMに対するappendを
一回でドンとappendするか
複数回こまごまとappendするか
どっちがオーバーヘッドが大きいかって話じゃない? vDOMはオートマ
jQueryはマニュアル
jQueryおじさんは軽トラ運ちゃん >>228
C#おじさんID変えまくってるから望み薄だなぁ jQueryが嫌いな訳じゃないんだよな。昔は散々世話になった訳だし。
ただスレチ。話も長くなるし。 >>226
> いや実DOMに対するappendを
> 一回でドンとappendするか
一回でappendする場合DOM操作ではなく、innerHTMLの代入とかに
なるわけだがフレームワークはそんなコトしていない
そもそもinnerHTMLだから速いというわけではなく
JavaScriptで追加するか、ブラウザ内部の処理で追加するかの違いでしか無い
ブラウザ内部で処理したら速いように思えるが、innerHTMLでは
HTMLのパース処理が必要になるので無駄な処理をしている
それに昔はJavaScriptが遅かったが、今は速くなっているため
JavaScriptのDOM操作とinnerHTMLによる一回でドンは大差なくなってる。
仮想DOMは純粋なオーバーヘッド。実DOMに反映する処理+仮想DOMのオーバーヘッド >>227
> vDOMはオートマ
> jQueryはマニュアル
> jQueryおじさんは軽トラ運ちゃん
そして一番重要なのは、どの方法が一番早く目的地につけるか?
って話なんだよねw 仮想DOMが遅い理由
Why Virtual DOM is slower
If you think it’s fast, this article might be what you were missing
https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b964b4c9e なんちゃってアマチュアレーサーがマニュアルのほうが速いとかでマウント取ってくるのと一緒だな。
ひっきりなしにガチャガチャガチャガチャ動かしたくないんだわ。 >>236
だから動かさなければいいのでは?
HTMLとCSSでできることはJavaScriptを使わない
コードがないのでバグも減るし、速度も早い
JavaScriptからウェブに入ってきた人って
HTMLとCSSの技術力が低すぎる人が多いんだわ
知らないくせに、知らない俺すごい。みたいな考え方してるw
どうどうと嫌いです(だから勉強していません)みたいなこと言うからな 例えばCSSだけで作られたアコーディオン
https://webdesignday.jp/inspiration/technique/css/5316/
JavaScriptなしでブラウザ内部だけで実行するから最速
こういうのを作れるとお前ら何JavaScriptフレームワークで
無駄な努力してんの?ってなる え? innerHTMLでドンと入れるもんなの?
ドンと入れるってのは一個Element作ってその下にたくさんElementぶら下げて最後にappendChildするものだとばかり。さもなくばtemplateタグかと…… >>239
じゃあ、DOM APIで一個Element作ってその下にたくさんElementぶら下げた方が速いですねw >>238
アコーディオン
クリックしてから開くまで遅すぎ
JS使ってないのにこの遅さはひどい そもそもアコーディオンなんて使うほうがアホ
アコーディオンあるとスクリーンショットとれない
ユーザビリティ考えてないゴミといっていい >>240
それだと一個足す毎に描画発生するじゃん? >>241
開閉スピードはCSSのパラメータで変更できる。最小0だよ。
そういう当たり前に想像できることにレスするから
お前の間抜けさが際立つわけ >>243
発生しないが?
まさかお前、DOM APIではできない方法を使って
JavaScriptフレームワークが実装されてるとでも思ってるのか?w
不思議やなぁ。ただのJavaScriptフレームワークなのに
JavaScriptでは使えない方法を使ってると思うんやぁw >>241
アコーディオンのデモだからアニメーションを強調して長目にしてるだけじゃん 速度もとめるならwebglだな
3Dはもちろん2Dも速い そういやValkanってブラウザ対応とかするんかな? >>245
最初からDOMの話してるんだけど。
bodyからのツリーにぶら下げなきゃ描画しないのは知ってるよ?
だからこう書いたのに
> 一個Element作ってその下にたくさんElementぶら下げて最後にappendChildする >>237
アプリ作る目的がこのスレなのにhtmlとcssのみとか頭イカれてんだろゴミ野郎
何ヶ月も同じこと言ってんじゃねえよ バニラでアプリ作れない雑魚のための介護マシン≒React等低速フレームワーク
ということでFA? UIだけの話しかできないやつなんなの
ここframeworkの話するところ
>>253
開発生産性を考えられないアホは
バニラでやってればいい 自分ではうまくcssだけで実現できたつもりでも
クロスブラウザ対応できてないケースが多い。
ライブラリ使わないとクロスブラウザ対応は事実上不可能
web frameworkも同様
不要だといってるアホは開発生産性を考慮できていない >>247
意外と素のOpenGL ESよりだいぶ遅いのが気になるが。 >>255
クロスブラウザだけならjQueryで充分
生産の効率化がフレームワークの肝じゃないかなぁ いやーもう俺はjQueryだけとか無理だわ。保守が苦行すぎだろ。
ScopedじゃないCSSとか思い出すだけで辛い。
型も無しにApi呼ぶの怖すぎ。リファクタリングに手間かかりすぎ。
スレタイのフレームワークなりライブラリ使うだけで劇的に快適になるよ。
中規模以上ならフレームワーク必須。
今更仮想DOMが遅いとか。。文句の付け所が見当違い甚だしい。 emotionのcss prop便利すぎワロタwww
styled component形式も併用できる。けどネスト深くなるから好きじゃなかったんだよね。 >>254
とか言ってるやつが1番開発生産性をわかってない
SPAフレームワークなんて人材調達がめんどくさくて高いからコスパが悪い
MVC+jQueryなら人集めるのが簡単だ
後者は長年の経験の蓄積があるから作業を開始してからもSPAキッズより速い >>260
いや、わかってる。
俺は個人でも仕事でもSPA使ってない。
ASP.NET MVC系 + C#だ
前スレでも結論でたとおもうが大手法人サイトでも
web frameworkとしてはReact , Vueをほとんど使ってない。
ただのUIまわりだけの利用にとどまっていて
SPAとして動かしてない 長年の経験があって安くて簡単に手に入る人材? 地雷では? >>252
アプリを作るとは?
実際にはUI作ってるだけやろ >>258
> いやーもう俺はjQueryだけとか無理だわ。保守が苦行すぎだろ。
> ScopedじゃないCSSとか思い出すだけで辛い。
SPAにするんじゃなくてサイト全体をモジュール化しましょう。
それぞれ独立したページだから、ページごとのscopedになっている
sassを使いましょう。CSSファイル一つでも
ページごとのCSSが作れます。
お前HTML/CSSの技術知らんだろ?
無知だから苦行なんだよ >>261
わかってる人だったか
すまんなここは喧嘩売ってくる人が多いから攻撃的になってしまっていた SPAを作るのが楽なのはわかるが、それはSPAじゃなきゃだめなのか?
UIを作るのが楽なのはわかるが、それはそんなに複雑なものなのか?
って話なんだよな
ほんの少し必要なもののために、全体を複雑化してしまってる。
UIなんて要素の表示非表示で殆どのものは作れるんだよ
DOMによる要素の操作(属性変更以外)が必要なのはフォーム項目数が
増減する場合ぐらいしか無いんだが、一体何のために
フレームワークを使わないといけないんだって話なんだよな な?俺が言ってることが正論だから
まともな反論一つできないわけだ >>265
独立したページだからページごとのscoped?ってどんな小規模なサイトなのよ。普通のサイトでも1ページに複数のcss組み合わせてpackするだろ。。それにaltCssは関係ない。単に名前空間の話なんだけど分からない?
気をつければ問題ない、じゃないのよ。保証されてないとダメなの。その保証をフレームワークがしてくれるワケ。
って言っても分からんか。。よく手作業でやるよな。まあ精々頑張ってくれ。 >>269
最後の3行が無知を晒してんだろがボケ
お前みたいなゴミがゴミサイトしか作れないからそれしかわからねえんだろゴミ >>270
名前空間ならクラスを使えばいいだろ
単にネストするだけ
書き方がわからんのなら教えてやるぞ?
.my-namespace {
.module {
.component {
.name {
color: red;
}
}
}
} フレームワークを使うのはホームページビルダーを使うような事だ >>271
理由はないけど最後の3行は無知なんだ!
と言っても誰も賛同しないって(笑) >>272
やっぱり分かってない。そんな事みんな知ってて随分昔に通り過ぎてるんだよ。
それを手作業でやる必要ないだろ。必ず間違えるのが人間なんだから。
君もそんな所にとどまってないで登ってきなよ。歓迎するよ? >>272
通り過ぎる?
じゃあこれの何が問題か言えるよね?
先に言っておくわ。はい言えなーいw >>275
HTMLの基本である文書構造とスタイルの分離を
理解できてないやつがいるからね。
昔はCSSを変更するだけで見た目をガラリと変更できた
早くフレームワークでそういう本来あるべき時代が来るといいねw >>237
ごめん、技術力がないんじゃなくて
タグ書くのとか別ファイルにCSS書くのが純粋に
めんどくさいからあえてJavaScriptで書いてるんだわ。
HTMLもCSSも全部JavaScriptで生成してるんだわ
JavaScriptならconsole.logで
途中経過確認できるし
forやif 配列 連想配列
イベントリスナ
location ajax全部自在だから
JavaScript使うんだわ
単なるwebサイト制作屋じゃなくて
プログラマなら誰だってそーする。 ウェブサイトをプログラミングすんなよ。
画面がグニョんとうごく動的でダイナミックでエクセレントなホームページ作ってるやつ。
おまえ地獄に落ちるぞ。
おまえのせいでページを見てるみんなが困ってんだ。
謝れ。
ページがぐにょぐにょ動く必要ない。
おまえの自己満足だ。 >>281
要求仕様にあるからやってんだよ
俺だってやりたかねぇよ ■ このスレッドは過去ログ倉庫に格納されています