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。 ここで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 要求仕様にあるからやってんだよ 俺だってやりたかねぇよ 業務ならUbuntuにしとけよ。 おまえのはホビーだ。 ど素人が。 テキストのhtmlつなげてDIV.innerHTMLにぶち込んでいたけど JQueryが速いって聞いて書き直したら、クッソ遅くなった ま、昔の話だが まあ3年前ならそうかもしれんけど、いまはフレームワークの時代だからね。 やはりUbuntuだと思うんだわ。 >>283 そのクソくだらないおもちゃを みんな作りたがってるから 余計な仕事が無くならねんだよ さっきからそういう話をしてんだよ。、 金のために魂を売ったなら、結局地獄行きじゃねーか。 SvelteのTutorialやろうとして19のうち5で一時挫折 VueもSvelteも覚えることが多すぎる ほとんど覚えることがないReactは良かった Reduxは読みやすいReactをものすごく読みにくくして学ぶ気が起きない Webアプリしか作れないやつとWebサイトしか作れないやつじゃ話しは合わんわな Reactはなんで何度も実行して無駄なことしてんのって思ったことがSvelteは解消してんね コンパイルするから最小限のことしか実行しないようですばらしい vueとsvelteはほぼ同じようなものなんだけど、互いにいい所があって、両方のいいとこ取りしたものを欲しくなるんだよなあ >>290 そうじゃねーんだ。 ユーザーの立場から、ホームページは動かすなと言ってるんだ。 >>280 そういやって静的に作れるファイルを 動的に作るからフレームワークは遅いわけ >>296 あそこ何気にIPv6に対応してるからな >>296 それな。シンプルイズベスト ただのHTMLとCSSでいいのに なぜかわざわざ複雑にする >> 293 ホームページみたいなWebサイトしか作れないお前の立場じゃ、Webアプリを作るのに適してるスレタイのフレームワークの良さはわからんよ とりあえずお前はスレタイのフレームワークを使ってWebアプリを作るといい あとユーザーの立場で言えば今の多くのユーザーはネイティブアプリに慣れてるから、動きのあるページの方が良いって言うと思う > 動きのあるページ CSSアニメーションでできることを JavaScriptつかって再発明してそう(笑) 動くホームページなんて昭和の主婦かよ。 子供だましもいいとこ。 >>300 お前みたいなゴミはせいぜいwebサイトのcss止まりなのはわかった >>289 ReactやるぐらいならElmでよくねえ? >>277 なるほどなあ。これが所謂JQueryおじさんってやつか。構うんじゃなかったわ。。 分かった。お前はお前のやり方を通してくれ。 でもスレチだから出てってくれんかなぁ。一応フレームワークのスレなんでね。 お客様のなかに 想定い通り にお住まいの方はいらっしゃいますか〜 Vueって昔はcdnから読み込んでHTML属性にv-なんちゃら書けば簡単に使える nodeやビルドシステム要らずの良いフレームワークだと思ってたんだけど今のVueなにこれ。 Reactの後追いばかりして自分の良さを消しちゃってるよね。 もともとv-なんちゃら属性でHTMLで出来ることを拡張する コンセプトのフレームワークで全部JSファイルの上でwebコンテンツ作りますのReactとは違うのに無理してTypeScript使い出してて草 そういうのが受け入れられない人こそがVueの本来のターゲットユーザーであったはずなのに >>301 一応日本初のホームページは1992年(平成4年)だから 昭和の主婦には不可能です。 https://ja.m.wikipedia.org/wiki/ 日本最初のホームページ Vueはreact追いかけて変な方向に行ってしまったな。 従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる