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房が書き込んでも無視してください 自分が欧米人だと思うならreact
中国人だと思うならvue どっちも覚えるくらいの気概がないならフロントエンドに手を出すべきじゃない。 >>220
今から始めるならvueを勧める。基本だけなら一日で習得できるからやってみて判断するべし。 angular.jsのtwo way data bindingがバグの温床になるからって理由で、
React + fluxが世の中に普及したのに、
わざわざangular.jsを作りなおしたみたいなvue.jsを使うのは、
世界が電通や博報堂といった陰謀に踊らされている以外に他ならない >>220
大きいものならts環境がデフォで入ってるangular
小さいものならvue.js
を勧める。
reactは、どちらにも対応できそうでいて、flux, redux, typescript環境を整えようとすると、
とんでもない学習コストが必要になる。 >>226
それは払うべきコストだと俺は思うけどね。 この調子だとvueが生き残って他は今年中に死にそうだな 残念ながら5年後、生き残るっているのはjQueryのみです。 作り方はガラッと変わるけどjQueryの後継がvueだと感じてる。reactやangularとは使われ方が違うから、良い感じに共存するんじゃないかな。 >>225
Vuexは双方向バインディングじゃないじゃん >>237
いや知ってるんだけど使ったことはないから実感知りたいだけ >>239
他のフレームワークに比べると便利な機能とかはないけど、習熟したときのポテンシャルは一番高いと思う。廃れる可能性も一番低そう。 いや単なる素のjsやんけ
なんだこれエイプリルフールか? 生jsとか「this」とは。。とかなんでそんな哲学せにゃならんのかって気持ちになるわ。 Reactもカメラ映像からcanvasに転写して画像処理とかやった時は結構メソッドに.bind(this)とか沢山書いたけどな >>232
どうだろ。jQueryの優れている点は後方互換性の高さだからな。
jQueryの古臭い構文に則って書きさえすれば、最新の環境でも10年前の粗大ゴm…レガシーな環境でも動くけど、
モダンブラウザでの利用を前提としたvueはレガシー環境ではjQueryの代替にはなりえないかと。
あとはjQueryの馬鹿にでも覚えらる簡単さも、vueには真似できない点じゃないかな。
1日あればそれなりに読めて書けるようになるjQueryと、じっくり数週間は座学を要するvueだと、
即戦力(という名の使い捨て)を確実に揃える際にはjQueryの方がより適切なんじゃないかな。
vueは下手すりゃ時間と労力だけ消費して、結局習得できませんでしたーとか平気でありえるわ。 フレームワーク選びのポイントは
どんな規模を作るのか、最終的にどういった
開発環境を、使えるように成りたいかによるだろう。
Vueはmvvmのテンプレートエンジンが
他よりディープに作り込まれてて、コンポーネントが他より再利用しやすいのが特長。
だけどツールとして使えるように
なるには、かなり熟達してないといけない。。 >>249
かと言っていつまでもjQueryは辛すぎるだろう。保守に必要なのはしょうがないが、インタラクティブなページだけvueに置き換えてくだけでも随分楽になるんだがなあ。フォーム周りとか特に。 jQueryそこまで互換維持してる?結構非互換変更をやってるような気が
propとattrが分離した時なんて大混乱だったし > propとattrが分離した時なんて大混乱だったし
それは2011年の話。それが最初で最後の大きな変更 サーバー側フレームワークが足してくるやつとサードパーティースクリプトとクライアント側フレームワークが使ってるやつで3種のバージョンでグチャグチャになってエラってるのに当たった
もうあんなのは嫌だ サーバのフレームワークが吐くscriptだろう。ちょっと違うがカスタムしたwordpressは本当カオスだわ。もう二度とメンテしたくない。今でも元気に動いてるのが不思議。 >>259
function.phpでフックするかプラグインで実装するか、直書きするか、WordPressの標準機能でやるかの4択だから見る箇所多くてな… このくらいデザイナーでもできるのにフロントエンジニアができないってどういうことだよ? 研修二日、実務経験二年のペテンシ・エンジニアリング・サービス・ソリューション♪ >>228
いいや、データの双方向的な流れがバグの温床になるって話だった
で、 reactはflux, angularはデータバスにrxjs
angular.jsのアーキテクトだったかがvue.jsのメンテナーへ
小規模なアプリはvue.js,大規模ならangularへ流れても良いと思うんだがなー
angular2が出た初期の頃みたいにボイラープレートを動かすだけに何日も掛かるような糞ではなくなったんだし jqueryの作者はreactへ流れてただろ
jquery的な用途で使われるのはvue.jsの方だとは思うが
reactは設定のための学習コストが高すぎて、アホなweb屋たちが使いこなせない reactの学習コストが高いっていうけど、
安定したもの作ろうと思ったら他のフレームワークやるとしても結局同じくらい学習コストかかると思うぞ。 >>266
もう3年も前の話だな。それからのReactの状況はいぜんと何も変わらず
いつになったら普及するのかね?
>>267
すごいものを作ろうとしたらどれも大変
ではなくてだな、
ちょいちょいで終わるようなものを作ろうとしたら大変なんだよ
世間で必要とされるもののほとんどは、ちょいちょいで終わるようなものばかり >>265
実際そういう流れになってると思うよ。ただバインディングの仕組み自体がトリッキーだから、フレームワーク関係無く不安定さが付き纏うのはしょうがない。
要求に対してweb標準仕様が貧弱すぎるから、いつまで経ってもどこか不安定なのはwebの宿命だよ。 本質的にフロントエンド要らないと思うんだよね
デバックにコストが掛かり過ぎて、コストを掛けてまで誰が欲しいのかって話で
片手間のテンプレート的に扱えたangular.jsからvue.jsへ流れると思うけど
frontendの専門部署でreactでなくてvue.jsを使う勢は単に頭が沸いてるだけ Reactは難し過ぎた
みんなあんなの使えてるの凄いね >>268
ちょいちょいでいいならexcelにボタンでもつけとったらええやんけとか思う。
まあ実際はバカ経営者に見栄えいいのを見せる目的があるから
クソみたいなフレームアピールするんだろうけどな。
心底くだらねーと思うわ。 Reactごとき難しいってお前らエセプログラマーだろ
世の中のプログラミングの中では圧倒的に簡単なほうなんだが ライセンスの修正じゃないかな。
その前に急落したのもライセンスが問題にされ始めたころじゃないかと思う。 >>275
2017後半-2018前半頃のトレンドって言ったらPython/機械学習に注目が集まった時期かな >>275
Angularが今後、死ぬ運命ということだけはわかった 世界中の華橋・華人を動員した結果GitHubスター数はReactを抜いたVueとデッドヒートしてるじゃんw
誇っていいだろ >>276
それだ!
落ち込み、反転、両方説明がつく。
スッキリしたありがとう。 そのうちページ全体が<canvas>になる時代がくるんだろうか ははは。そんなことありえない。
ウェブアプリなんて一部でしか作られてないよ
殆どはウェブサイト。だからjQueryが使われ続けている。 >>273
React特有のpropが変わると再描画という形がキツかった
普通に部分的な動きをさせたいだけで全部その形にしなきゃいけないのが不自然
不要な部分の更新まで行われてしまったり何回も同じ更新が走ってまくってしまって原因調べるのがきつい shouldComponentUpdateでfalse返してもダメなパターン? 何らかのアンチパターンやってるケースでしょ
設計思想とか、中の仕組みを想像出来ないとやらかしてしまうのは分かる
うちのメンバーでそういうのあった 逆にreactのコンポーネントを使わずにreduxで更新をやるって感じで
入門するのはどうなんだろうか?こっちのがわかりやすいんじゃなかろうか。 react+reduxは考え方としてはいいんだが、素のreactではコンポーネントのstoreに
閉じていたようなデータまでstore内に混在するのがなんとなく気持ち悪い。
MとVMを分離できたらよかったんだがなぁ。 javascript歴浅めのものです。
この手のフレームワークのデータバインディンクの仕組みって、buildした後のjavascript的にはどう実現されてるの?
{{data}}とかでマークアップされた箇所にイベントハンドラ付きのjavascriptが挿入されてる感じなんかな? >>290
簡単な例ならtwo way binding javascriptでググると沢山出てくると思う。ただこれに仮想domやコンポーネントが絡むからずっと複雑。深追できないしするべきじゃない。 two way bindingねえ
例えばvar helloのバインディングならglobal(window)にsetter/getterのhello()を追加して、
helloのsetterが呼ばれて値が変わったら<input>.valueにもそれを代入し、
<input>要素にはイベントリスナーで値が変わったときにバインディング変数(hello)に同じ値をセットしてるのかな 一般のGUIでも常套手段だが、値が変わらなかったらそれ以上伝播しないってことでいいんじゃね。 >>292
>>295
なるほど、やっぱそれくらいのコード書かないとできないのですね。
となるとリッチなwebアプリケーション作るとなると、どれかしらのフレームワーク使いたくなりますな。 徐々にだとしても、今後webブラウザベースのアプリが増えるはずと思っていろいろ勉強中なんです。 >>283
そこ海外フォーラムとかで議論されてるから見ればいい
>>284
それ完全ではないから
あと配列は浅い更新しかみてないから注意
>>286
さすがに全部Reduxにする必要はない いじめはどこの町にもあるが島本町は特に酷い
「大阪府三島郡島本町のいじめはいじめられた本人が悪い 」なんて
公言する町は他に無い >>297
アプリというか、アプリの様に動作するwebサイトだね。storeに登録しない。個人的に最難関はDBのオフライン対応+同期だと思う。
firestoreもあるがフレームワーク側で対応して欲しい。魔境なので難しいとは思うが。。 >>300
個人的にはオフラインDBは諦めるのがスジがいいと思うけどな。ネットに繋がってて当たり前の時代じゃないですか。 >>300
> アプリというか、アプリの様に動作するwebサイトだね。
それは増えない。アプリの様に動作するwebサイトはjQuery Mobileが
失敗したことからも必要とされていないことがわかっている
※ jQuery Mobile は jQueryとは違うもので、
jQuery UI(こちらもjQueryではない)がデスクトップ用のUIなのに比べて
jQuery Mobile はスマホ用のUIを作るもの
webブラウザベースのアプリが増えるとしても、それはwebサイトからの
変更ではなく、PCアプリ・スマホアプリから、ウェブアプリへの変更となる。
ウェブサイトからウェブアプリに変更したいという要求は
本質的に違うものへの変更になるから生まれてこないんだよ。
PCアプリ・スマホアプリから、ウェブアプリの場合は、
本質的に同じもので動くプラットフォームが拡大されるからそういう要求はある。 >>302
そうか?office365とかgoogle documentとか成功してるじゃん。 >>302はいったい何を否定しようとしたんだ?webサイトという言葉の使い方がおかしいということなのか? >>303
> そうか?office365とかgoogle documentとか成功してるじゃん。
それらは、もともとデスクトップアプリだったもの
ウェブサイトだったわけじゃない。
>>305
> webサイトという言葉の使い方がおかしいということなのか?
アプリのように動作するウェブサイトという
変なインターフェースは誰も求めてないという話。
例えるならば、ジョイスティックで操作し、美麗な3Dゲームのような
新聞ビューワーみたいなもの。誰もそんなので新聞を読みたいなんて思わんだろ? >>306
ん?だったら例えばoffice365はアプリのように動作するwebサイトで成功してるじゃん。 >>302
jQueryMobileは単純にBootstrapとかにとって代わられただけじゃん >>301
そうなんだよね。オフライン対応って無理がありすぎるんだよね。
以前firebaseのrealtime database使ったが、オフラインからの同期処理に制限が多すぎて厳しい。更新が時系列を保証せず最終更新分だけ同期するとか、かなりクセがある。
WebworkerとindexedDBで効率よくキャッシュする方が当面は幸せになれそう。 >>307
office365はアプリのように動作するウェブアプリであって
ウェブサイトじゃないんだよ excelで作ったドキュメントをなるべくそのままの形でhtml化する方法は無いでしょうか?
excelでhtml形式で保存すると裏側が汚いです
Gatsbyのプラグインにそれらしきモノがあったので試してみたら、色もセル結合もフォントサイズも全部落ちてしまいました
まぁ自分で自作すればいいんでしょうが、気が遠くなるくらいたくさん作り込まねばならず、皆さんはexcelドキュメントをそのままWeb化したいとか要望された事はありませんか? >>311
いやだから>>305でwebサイトという言葉の使い方がおかしいということなの?って聞いたのによくわからん回答されたから混乱してるんだが…
で、結局webサイトという言葉の使い方がおかしいってことなのね。 要は、office365のようなものをwebサイトと呼ぼうがwebアプリと呼ぼうが話の本筋には何の影響もないのに、>>302の長文で謎の語りが入ったから話がグチャッとなっちゃったって事実に気づいて欲しい。 オフラインデータはクッキーをいじり回すことしか出来ないのね
せめて画像を確実にローカルに保存できればオフラインでも動かせる
アプリが作れるだろうに >>317
Webストレージで画像保存できるじゃん reactは覚える事は少ないけども設計力が必要
宣言型プログラミングと同じで高い論理性が要求されるから苦手な人は多いかもね 悲しいのはAngularの勢いが無くなり、横ばいのAngularJSの方が残りそうなところ
もうAngularはGoogle Graveyard入りだろ。どうすんだよAngularで作ってる新規プロジェクト ■ このスレッドは過去ログ倉庫に格納されています