Vue vs React vs Angular Part.2
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん? Vue https://jp.vuejs.org/ React https://reactjs.org/ Angular https://angular.io/ - VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured ※前スレ Vue vs React vs Angular http://mevius.5ch.net/test/read.cgi/tech/1545395856/ ★ここではjQueryの話題は禁止です ★jQuery房が書き込んでも無視してください >>345 このスレじゃなさそうだな。。今angularを勉強してるが、これじゃないとという理由が見つけられないでいる。学習曲線や人員的な問題は置いといて、明らかに有利な点や逆にangularで困る事があったら教えて欲しい。 日本にいるとVue人気だから勘違いしそうになるがやっぱ採用実績はReactが圧倒してるんだな。475kサイト vs 64kサイトか…… しかしなぜかGitHubのスター数だけタメ張ってるw Top JavaScript Frameworks For 2019 https://www.codementor.io/nikhil21tyagi/top-javascript-frameworks-for-2019-s8881i8ga パフォーマンスについてはReactよりVueのほうがいいな。 AppRunってやつ速くて気になる。 しかしAngularいくらなんでも酷すぎる…… A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update) https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075 >>349 AngularJSは確かにダントツで遅いけどAngularは別に悪くないじゃん SPAでログイン画面というかログイン機構作る場合はどうするのがベストプラクティス?認証用のアカウント情報はサーバー側のDBにあるとして >>352 使ってるフレームワークとやりたい事で変わるからなんとも。。 例えばログイン後は各ユーザ用の専用ページがあるって感じ?でなければセッションに保存して分岐するだけで済むはずだが。 Angularは脂肪確定でよろしいか? ReactかVue.jsの二つやっとけはいいのかな >>354 俺も悩んでる。普段reactとvue(nuxt)使ってて、今angular勉強中なんだが乗り換える必然性が見つからん。もちろんangularは力技使わなくても色々解決出来そうな感じで良さげなんだが。 ただもう少し勉強せんと冷静な判断できんわ。 >>352 Firebase Authentication使えばよくあるGoogleアカウントでログインだのFacebookアカウントでログインなんかが出来るよ。 面倒くさいDBでのアカウント管理も全部Firebase上で出来るから実装に無駄な時間を掛けなくて済むよ。 Google I/O 2019 (5月7日〜9日)で Angularと対立することになる Flutter for Web (Hummingbird) の新たな発表があるそうだから Angularを考えるのはその後にした方が良いと思うよ >>357 Flutter面白そうだね。たしかにクロスプラットフォーム開発はスタンダードが無いから学習するなら狙い目なのかも。現状swiftとkotlinでゴリゴリ書いてるけどどうしてもrealmが必要なんだよね。 Webアプリの弱点の一つオフラインDBをある程度解決できるなら真面目に検討したいんだが。 >>358 オフラインDBが弱点って具体的にどういうこと? >>359 ユーザデータを大量に保存してローカルで処理する系のアプリは現状webアプリだと厳しい。主に速度面で。 indexedDB+lovefieldみたいな組み合わせでsqlぽい事はできるけど、flutterがアプリ+webのクロスを狙うならソコどうするのかなって。DBの同期まではできなくても、一つのスキーマから全プラットフォームで動作するDB作れたら夢だよね。 もういい加減 "ウェブアプリ" なんてやめればいいのに ローカルでデータを大量に処理ってそれ、 ウェブである理由はアプリのインストールとアップデートのためだけじゃん モバイル端末のストア経由っていうのが煩わし過ぎるからなぁ >>360 ごめん、おれの経験不足なのかやっぱわからん。 >>ユーザデータを大量に保存してローカルで処理する ↑ クライアントは1台だけなのに、速度が気になるほどデータを処理する例が全く思い付かない… バックエンド主義の人が強引に考えたついた難癖にしか見えない フロント処理で充分 いやまあ、別に現状でも工夫すればできるからブラウザのローカルDBにそこまでこだわっては無いよ。課題も多いし。ユーザがいつでも削除できるとか。 ただネイティブアプリとwebアプリが同じコードとロジックを共有するなら避けられない課題だろうなと。 ユーザーが自由に削除できることが課題?? 世の中のソフトウェア殆どがそうだけど何か困るのか? >>367 indexeDBのことだよ。ブラウザのキャッシュクリアで簡単に消えちゃうだろ。間違えて消してクレームくるんだよ。 >>370 大丈夫。俺もわからん てか、あんなの小規模なWebアプリケーションにはいらん Reduxわかるの? じゃあ、Reduxを使うことで、 どんなメリットがあったか教えて > 処理の流れが一方向なのでわかりやすい。 文章がつながってない。 処理の流れが一方向なのはまだいいとして、 なんでそれで、わかりやすいということになるのか? そもそも "処理の流れ" が一方向であるならば、 何を使っても一方向にしかならないはず。 Reduxを使うことで、一方向になるわけではない。 また双方向とか一方向というのは、局所的に見るか 全体的に見るかの違いでしかないのではないか? 例えば電話での会話だって、双方向に見えても、実際には自分の通話口から 相手のスピーカー、相手の通話口から自分のスピーカーへの一方向通信だ。 一方向も双方向も大した違いはない。 まあ実際、説明の難しいところではある。 >また双方向とか一方向というのは、局所的に見るか >全体的に見るかの違いでしかないのではないか? これはその通りだがその違いが大きいとしか言いようがない。 treeをたどるロジックというのは一般に指定が複雑になりやすいとか、 ノード間のコミュニケーションがコールバックでつなぐと相当複雑になるとか 色々あるけれどその辺を単純化できてるようには思う。 電話の比喩を持ち込むならマイクとスピーカーが同じより違った方が良いとかになるのかな? もう少し具体的な例を出そう。 getterとsetterと言えば、俺が言いたいことが見えてくると思うが Reduxが言いたいことは、単にgetterは値を取得するだけ setterは値を入れるだけにしましょうってことだろう? まあgetter/setterは別の批判も有るから、getter/functionの方が良いか? もう一つの例としてRESTで例えるならば、GETは何度GETしても状態は変わらない。 単にデータを取得するだけ。POSTはデータを送信するだけ。 この考えかたと同じことだろう? これをオブジェクト指向に当てはめるならば、このメソッドはデータを更新し、 このプロパティはデータを参照するという話でしか無い。 これは普通のオブジェクト指向のベストプラクティスとなんらかわりはないんだが、 Reduxを使う必要はあるのか? このメソッドはGETかPOST(相当)であると ドキュメントに書けば済む話だろう? マイクとスピーカーで分けたほうが良いという考え方は 反対しないが、まともな設計能力が有るならば、最初からそうしているわけで、 Reduxを使う理由にはならない。 まともな設計能力がない人のための矯正器具=Reduxということか? だが矯正器具はいつまでも使っているわけじゃあるまい? まともな設計能力がついた人にとっては、邪魔な道具でしか無い。 >>378 そうだね。あなたはredux使う必要ないと思うよ。 あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。 もちろん、Reduxが何の負担もなしに、もしくは低い負担で ベストプラクティスを実現できるというのなら導入する価値はあるが、 一方向を得るために、Reduxのやり方で設計しろっていうのは負担が高すぎる。 Reduxのやり方はルールが多すぎて単純ではないからだ。 Reduxの設計方針を理解しないまま、Reduxを使うよりも まずは知識をつけるのが先だろう? このメソッドは書き込みを行うメソッド、このメソッドは読み込みを行うメソッド 明確に分けたほうが良いと。そしたらあとはメソッドのコメントに書けばすむだろう? (普通はコメントで書くまでもなく、メソッド名からどちらであるかはわかる) それだけのことなのに、それを矯正するためのフレームワークというのは 意味不明すぎる。便利にするためのものじゃない。矯正するためのもの まったくもってReduxはわからん。 スパゲッティになるならreduxは必須 でもそうならないなら本当に必要ない、とは思う コード量多くなるからね >>379 > あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。 だから聞いたんだよ 「どんなメリットが"あったか"教えて」 どんなメリットが "あるのか?" じゃない。"あったのか?" だ。 あんただってそれなりにまともな設計ぐらいできるだろう? あんたの能力がどれくらいで、Reduxを使うことで どういうメリットが、あったんだ? なにかを矯正されたんか? 俺は矯正が必要なほど設計が下手なつもりはないんだが。 とりあえずメリットは書いたし、びっくりするほど文章読んでないのも理解できる。 Reduxがやってるのって、 1. オブジェクト指向のクラスがあります。 2. クラスから読み込み専用メソッドを抜き出します。 3. クラスから書き込み専用メソッドを抜き出します。 4. クラスに残ったものはデータのみです。これを一つのオブジェクトとしてPublicにします。 オブジェクト指向のクラスが、 読み込み専用メソッド、書き込み専用メソッド、データ の3つに分離されました。 ってだけだからな。 >>383 いうだけなら誰でもできる。 コミュニケーション取ろうぜw 処理をAPI化するイメージかな必ずその経路を経由して状態を変更するからグローバル変数みたいなどこからでもアクセスできるけどちゃんとアクセス経路は限定できるみたいな その "グローバル変数" をクラスにして、APIをクラスのメソッドにすれば 普通のわかりやすいオブジェクト指向設計になるんですが? Reduxの存在意義って? そしてReduxは、クラスのメソッドを抜き出すだけじゃないからね メソッド(関数)は普通にメソッドに引数渡して普通に呼び出せるが、 Reduxは「引数つきでメソッドを呼び出すため」のデータを作って データを投げて、そのデータ解析して(←ここ自分で作る) そしてやっとメソッドを呼び出すという無駄なことをしてる。 結局の所 Redux はわかりやすいものではなくて (わかりやすい = ただのセールストーク) オブジェクト指向 VS 関数型(?) の戦いから 俺たちはアンチオブジェクト指向で行くぜ!という派閥から 生まれたものに過ぎない。 それ自体は考え方の違いでありだとしても、 Reduxの仕組みは、それを実現するためのルールが多すぎて 百歩譲ってわかりやすいとしても、そのルールに従って コーディングするためのコストが大きすぎて小さいプロジェクトではペイしない (大きいプロジェクトでもはたしてペイできるかどうか) "設計方針の違いを反映させるためだけ" でしかなくて、 それしか得られない割に、コストが大きすぎる 別にコールバックでdom treeたどるのが大変でないならredux使う必要ないわな。 それでいいと思うよ。 てか読んでないのにコミニュケーションを要求するとか まともに設計できる人間じゃないことはわかるよ。 一度Reduxで作ってみたら後は別のプロジェクトでも同じように作ればいいだけだから何も問題はない 最初だけ複雑に思うだけ 確かにreduxのproviderとconnectの対応は暗黙な繋がりでわかりにくいところはあると思うんです。 reduxというかfluxの実装として他に方法はあるかもとは思う。 vue公式からの引用で恐縮だが、、 もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。 あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。単純な ストアパターン が必要なだけかもしれません。 しかし、中規模から大規模のSPA を構築する場合は、Vue コンポーネントの外の状態をどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です: Flux ライブラリは眼鏡のようなものです: それらが必要になったときに知るのです。 まあ大きなもの作ったことない人にはわからん世界だと思うよ。俺も学生の頃はフレームワークの必要性とかさっぱり理解できなくて制作者の自己満足だと思ってたもん。 そして必要になったことがない人にはどんなに説明しても納得してもらえないもんだよ。 今軽くReduxググってみたけど何がしたいのかさっぱり分からんw jsにprivateが無いからsetter/getterのレイヤー作ってんの? いやfluxで調べたら少しわかった オブジェクト指向でいちいち相互参照とか面倒くさいから シングルトンにデータ全部詰め込んでおこうぜ見たいな話だな おまいら、vueの利点として、サイトの一部分のjQueryで 作っていた部分をちょこっと置き換えるのに良いって 言ってるくせに、それがいつか大規模なSPAに変わると思ってんの? >>393 こっちのほうがわかりやすくね?w Flux ライブラリはサスペンダーのようなものです: それらが必要になったときに知るのです。 (意味 デブになれば必要な理由がわかる。だがそもそもデブになんかならねーし、デブなのが一番の問題) 猫も杓子もreduxだけどほかのflux実装の感想聞きたいわ それなりの規模で使用した、もしくはしてるみたいな人おらんの? つかfacebookはfacebook/flux使ってるのかね メンテされてる感じせんけど >>397 そんなこと書くと議論がすり変わりそうだぞ。 ID:IXPbMXJWが書いてくれたことで十分でしょ。それで納得できる人もいればできない人もいる。 万人が使うものでないことは間違いないわけだし。それはスレタイの3つがそもそもそうなわけだけど。 よくまとまってる。 https://mizchi.hatenablog.com/entry/2018/10/04/101308 > Middleware に何を使うかで、 redux ユーザー同士の非同期のノウハウは共有できず、 > 分断されている(thunk, saga, steps, epic, no middleware) これが一番の問題点。 suspence見たけど状態管理をsimple-cache-providerに移動しただけな感じがする 明確なIDが無いリクエストみたいなのが渡ってくる場合だと コンポーネントと非同期キャッシュの対応付けが面倒になりそう コンポーネントインスタンス毎に一意ID生成してstateに保持だと本末転倒な感じだし 静的サイトジェネレーターでBlog作りたいのだが情報少ないね。 VuePressがよさげなのだが なんでvuepress?nuxtよりいいとこある? ガチガチのSPA作ろうと思ったらAngularじゃねーの? ionicでwebアプリ作ってみたけどストレスなく作れて良かったよ まずフロントエンド周りに関わる仕事はしないほうがいいと思う 全てが無駄になる可能性が高い reduxで一回のdispatchで2つのstateを一緒に更新したい場合ってreducerどう書くのが正解? とりあえずreducerのreturnをjsonオブジェクトみたいにすれば良さそうではあるんだけど ReactのReduxはそろそろ廃れて欲しい ホックで何とかなるでしょ Reduxは奇形的だと思う >>405 じゃあNUXT.jsでw こっちもそんなに情報ないよね Vue vs React vs Angular とあるがどれも学ばないというのが4の選択肢が正解じゃないか 他に時間を投資すべき どうしても必要ならVueを摘むの適切 それでもVueを深く学習してVueメインでガチャガチャ動くサイトなんて作っちゃいけない >>412 それな。どうせどれ使っても数年で消える。 jQueryだけが今もこれからも使われて続ける いいんだけどさ、forthスレやqbasicスレ、coqスレなんかにも「必要ないって言ってるでしょ!」ってムキになって書き込みに行ってるの?w 一部にvue入れるのもアリだよ。検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。俺もそこから始めた。 >>415 > 検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。 具体例で見せてほしい フォームはVueの練習には良いよね。 でも大きく要素が入れ替わらないTodoリストくらいだったらJQuery + HTMLのテンプレート要素で作ったほうが簡単に感じる。 テンプレート要素が適用しづらいなって思ったら使うべきか。 >>406 だよね。angular思ったより全然使いやすい。迷う事が少なくていい。 >>420 因みになんだけど、jQueryのテンプレートエンジンは何を使ってるの。俺はよくjsRender使ってた。 >>422 俺は、lodash (underscore) のtemplateだな https://lodash.com/docs/4.17.11#template https://underscorejs.org/#template このライブラリはテンプレート専用じゃなくて 通常のプログラミングでも非常に便利なライブラリなので テンプレートを使うかどうかに関係なく組み込んでる。 >>419 具体例いらんだろう。長くなるとスレチになりそうだし公式見てほしい。 >>415 残念ながらフォームを作る場合に、DOM APIよりもvueは便利だが jQueryよりも便利ってことはないんだよ 具体例、ないだろう?そういうこと 廃れるものを一通り勉強するってのも乙なもんだけどね。 それはないな。DOM APIを使うのと(jQueryの方が生産性が高い以外)何も変わらんのだし そらWeb"サイト"作ってるところjQueryは使い続けられるだろ 元々フレームワークを使うのはWebシステムを構築する人向けなんだから 平たく言えば例えばスタンドアローンアプリをWebに置き換える様な案件向け 別にそういうモノを作る予定なんてないって人はjQueryは使い続けてても全く支障はないと思うよ 基本jquery使う限りアングラーさんしかないのか >>429 Webシステムじゃよくわからん。 JavaScriptを一切使わないWebシステムだって有るんだし > 別にそういうモノを作る予定なんてないって人はjQueryは使い続けてても全く支障はないと思うよ ずっとそれを言ってる。ウェブであちこちのサイト見て、 そのサイト、アプリで作ればいいのに?って思うことある? そういうことだよ。ウェブで皆が見てるものの大半は、アプリ用のフレームワークなんか使っちゃダメ 流行の移り変わり前提ならAureliaになるんかね 実務の世界ではwebは運用を考えないといけないから ビルド必須なのは辛いんだよね JAM Stackにバリバリ行きたい気持ちはあるのだが 結局はjQueryを使った無難なサイトがメインになって しまう エンジニアは運用の視点を忘れたらいけない サイト制作にはjQueryが必須だと思う。 でもSPAで作る時は日本語のドキュメントがまだ出て 来てないような最前衛の実装方法で暴走するけどねw >>432 君には一生縁のない世界みたいだからおうちにおかえり ちょっとしたサイトなら、jQuery, Lo-dash のテンプレートエンジンで十分。 Underscore.js のテンプレートエンジンを使ったフレームワークが、Backborn.js フレームワークを使うのは、データベースを使うような、web アプリ Ruby のテンプレートエンジンの ERB でも、基本は、文字列を連結していくような原始的なもの 本当にちょっとしたものならそんな何万文字ものライブラリいらんだろ const template = ctx => ` <html> <head><title>${ctx.daimei}</title></head> <body>${ctx.naiyou}</body> </html> ` const data = { daimei: '題名', naiyou: '内容', } const html = template(data) Vue試してみてるけど Vuexってもしかして必須か コンポーネント間の簡単な操作でも複雑に感じたわ それならもうAngularみたいに全部入りでいいじゃんと思いました >>442 世界中でどれか一つに統一されるならAngularをおしたい。 慣れた時の開発効率やわかりやすさはAngularだと思う。 >>440 かいてることめちゃくちゃ > ちょっとしたサイトなら、jQuery, Lo-dash のテンプレートエンジンで十分。 「ちょっとした」の意味がわからん。 そもそもテンプレートに大きいも小さいもないだろ > フレームワークを使うのは、データベースを使うような、web アプリ データベースならウェブアプリだけやなくウェブサイトでも使うし それはフレームワークを使う理由にはならん。 > Ruby のテンプレートエンジンの ERB でも、基本は、文字列を連結していくような原始的なもの 文字列を連結ってなんのことを言ってるんだか。内部の実装の話なんか関係ないだろ lodashのテンプレは確かに便利 これは同意する >>441 > 本当にちょっとしたものならそんな何万文字ものライブラリいらんだろ 何万じゃサイズがわからん。 1万文字 = 10KB程度ってことでいいのか? 何万文字 = 数十KB、画像1枚分もなくて、 ADSLや光回線なら0.1秒以下、スマホの128kbps制限中でも 2〜3秒程度でダウンロードできるサイズ だよね? 今度から「僅かなサイズのライブラリ」って書いてくれない? 意図的に多く見せようとしてるようにしか見えないからさw >>441 あとそのコードは単なる文字列中の変数埋め込み テンプレートエンジンを名乗るなら、ループと条件分岐ぐらいは 対応してないとだめだろう ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる