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房が書き込んでも無視してください >>443
でもAngular人気ないよね
日本ではなく世界の話
https://2018.stateofjs.com/front-end-frameworks/overview/
世界二万人超の開発者に対するアンケートの結果みたいなんだけど
Angularは「使ったことあるけどもう使わない」
ってのが飛び抜けて多い
なんでこんな嫌われているのか全然わからないけど 確かにせっかくの大規模アンケートなんだから理由も見たかったよな。 破壊的な変更が原因でしょう
また大幅な変更あるのではとリスクを嫌ってる WebComponentsの登場で
今のフレームワーク全滅するっていうのになw >>450
本来のjavascriptと解離が大きいのがな。
やっぱ通用するスキルが身につくことが重要よ。 >>453
それも結局はXHRと一緒なんじゃない?
原始的で汎用的なものを提供するけど結局ラッピングされたものの方が使いやすいってなると思う >>456
> それも結局はXHRと一緒なんじゃない?
なんでXHRの話なんか出てくるんだ?
UIコンポーネントの話なんだが
> 原始的で汎用的なものを提供するけど結局ラッピングされたものの方が使いやすいってなると思う
そりゃラッピングされたもののほうが使いやすいでしょw
だからjQueryの方が使いやすいんだし。
問題は、WebComponentsをラッピングしたものは、AngularやVueやReactとは別のものになるってこと。
AngularやVueやReactもWebComponentsを考慮しつつ開発してるんだろうが、
WebComponentsが最終的にどうなるのかわからないし、
WebComponentsがない時代の設計をWebComponentsに最適化するのは大変。
どうせWebComponentsに最適化された新しいフレームワークが出るに決まってる。
そしたら今のフレームワークは全部おさらばw >>455
ひとつだけステッカー貼ってアピールしてるのが哀愁を誘うなw >>457
html5だかECMAScriptだかの標準仕様を持ち上げるって意味では一緒じゃね?
WebComponentsもXMLHttpRequestも逆に何が違うって言うんだよ? なんも作ってない人ってなんでこんなにわかりやすいバカさを露呈しちゃうんだろうね。 web componentに過剰に期待しちゃダメだよ。仕様を大きく超えて肥大化した今のフレームワークのほんの一部を標準化しますってだけ。
少し触ってみれば分かるが期待とは別物。到底現状のコンポーネントが置き換わるレベルじゃない。 >>459
> WebComponentsもXMLHttpRequestも逆に何が違うって言うんだよ?
WebComponentsはコンポーネントを作るAPI
いろんな人や会社がコンポーネントを作って配布することになるだろう。
ここが大きな違い。
XMLHttpRequestはそれ単体で使うものだが、
WebComponentsは、そのAPIを使ってコンポーネントを作る人と
作られたコンポーネントを使う人に分かれる それって結局Reactとやってる事変わらなくないか? >>455
使ったことないアホどもの人気投票だろうな >>463
そうだよ?やってることがかぶってるから
WebComponents(ウェブ標準)に置き換わるって言ってんの >>464
使ってる人の数の非もこんなもんなんじゃない? とにかくJSフレームワークは
他人のコードみたくないし保守したくない
作り逃げの案件しかやりたくねー >>465
置き換わるわけないやんどうせ機能ショボいのに まぁwasmを独自タグ化できるとかならワンチャンなくもないかも知れんけど
ウェブ標準とReactなら大半の人はReact選ぶと思うけどね それにしてもAngularはホント使ってるとこ見ないよね技術書展のサイトくらいしかまともに使ってるとこ見たことない
Reactは動画配信サイトの類とかでわりと使ってるところよく見る
Vueはライブラリとして読み込んでるサイトはわりとあるけどフレームワークとして(Vuex,vue-routerとか使って)ガッツリ作り込んでるところ半分くらいで他はjQueryとの共存でだましだましに使ってるんじゃないかとね vue,reactならreactのが好きだけどreduxがデファクト取ったのほんとつらい >>472
react,vueくらいならちょこっと作るのもそこまで苦じゃないけど
angularはなんか闇を感じるぞ。。 >>441
HTMLエンコードも、しないといけない。
「& < > "」などを、「&」「<」「>」「"」に置換
Ruby のERB では、
結果を出力するなら、<% = 式 >
しないなら、<% 式 >
<% # コメント >
地の文(Rubyの式以外)で、<% を使う、
または、ERBタグ内で、%> を使う場合は、% を2重にする(エスケープ) 自己レス
>「& < > "」などを、「&」「<」「>」「"」に置換
あれ? どうして「&」と表示されたのか?
「&」(全角なら「&amp;」)と書いたのに。
5ch のバグ? 自己レス
>「&」(全角なら「&amp;」)と書いたのに。
「&」
ここには半角で「& a m p ;」(ただし、空白を除く)、
全角で書くと「&amp;」と書いているけど、「amp;」が表示されない!
なぜ? vueできますの人ってJQueryの延長で使えてるだけの人多いから危険だわ
Reactできますの人雇った方が安全
アプリとしての設計できるか否かと文法覚えたからコード書けますは違うから
Reactできるなら設計できると考えていい >>478
2chの頃からUnicodeの表示には10進文字参照使ってるから
&のエスケープだけ効くようになってる
&amp;と書けばいい ちゃんとしっかり向き合えば難しいって事はないよ
Reduxだって書いてれば慣れるし慣れればそれほど難解じゃない
一回ベタでJSX書いてそこから部品になりそうなものを切り出したら
次に似たような画面作る時劇的に手間が減ったりする Aureria使ってるけど全然難しくないぞ
Reactも難しくはないんだろう
むしろVueってそんなに簡単なの? どのフレームワークも書き方が違うだけで構成する要素(状態、ルーティング、コンポーネント)は似たり寄ったりだと思うよ
ただVueの場合
<div id="app">
…
</div>
をルートコンポーネントとしてVueに関連付けるのにdiv涛烽フDOMをそのまま使えるっていうのが新規にはとっつきやすい一因だと思う
もちろん別ファイルに書いたルートコンポーネントをマウントすることもできるけど
DOMがそのまま→既存のサイトに追加できるって事で入りやすいんだろうけど
できたものはカオスなんだろうなって思う 問題は非同期通信をどこに置くか、どう実行するかってとこでしょ。 そもそもそれSPAにする意味あるの?というところからだな そもそもただの静的なhtmlで十分てのはあるがそれはまた別の話だな。 >>487
静的なHTMLは、サーバーに置いたHTMLを表示するだけ
動的なHTMLは、データベースなどにアクセスしてHTMLを動的に生成するもの
どちらもJavaScript使用の有無は関係ないのですよ Reduxって他のフレームワークでも
汎用的に使えるの?
vueにはVuex があるし >>481
Reactは設計や構造を考えられる人じゃないと
まともに動くモノは組めないからね
学習コストはAngularより低いけども設計力が必要
Reactに関しては得手不得手が分かれると思う
合ってる人なら即日使えるようになる
苦手な人は勉強しても駄目かもしれない 設計や構造を考えないで動的に動くview作ろうってのがそもそも間違いじゃね?
と思うんだが。 (汎用の)コンポーネントを作るという考え方で作れば良いんですよ。
そうすれば、全体を考えなくていい。 んなこたない。
部品で分けても結局どう繋ぐかって問題は出てくる。
だからコールバックを引き回すのかreduxみたいな一周するパターンを使うのか考えるわけだ。 まだプログラミング自体初心者だった頃に、個人で何か作ろうとしてみたりしてたときは、確かに設計なんかせずに順番に動くように動くようにプログラミングしてたわ。 reactもvueも適材適所でいいんじゃない?設計は別のレベルの話だろう。所詮道具なんだしさ。いやそれを議論するスレだったなw 大抵の人はjqueryを使う規模で十分であるが
jqueryで何か新しく書こうとなると辛い
そこで規模にマッチするのがVueになるからVueが人気 周りvue使う奴ばかりで俺だけReactだから取り残された感がある >>499
react出来るならvueもすぐ覚えられるやろ create-react-app がデフォルトなだけって気はする。 互換性はないけど枠組みとしては確かに似たり寄ったり Reduxって親コンポーネントに偽装してReduxのステートをPropsとして受け取る感じなんだね
慣れてくればそれほどstateと変わらない感じ VueでTypeScriptってどうなの?
オーバースペック??? >>505
vdomとbindingはロジック部分を根本から変えた。後戻りできない部分だな。他はjQueryでも無理すれば代替できん事はないが。 ロジック部分ってなに?
普通ロジック部分っていうと、UIは除いた部分のことだから
jQuery使っても同じはずだが? >>508
ページ単位で小規模に適用する分にはvueにTSは必要ない。コスト上がるだけでvueのフットワークを殺す。
新規なら先日nuxtがv2.5で完全にTS対応したから最初からそっち使った方が良いよ。にしてもnuxt-tsはキモかった。 >>510
JQueryはdomが主役だがbindingはデータが主。だからデータ構造とそれを処理するロジックが根本から違う。これ以上はスレチになるから深くは説明しないが。 >>512
つまり、jQueryに足りない部分 = DOM以外ってことですよね?
それは同じでしょ? もしかしてVueとかって、UI部分とロジックが分離できない?
密結合しちゃってるの? 基本的なMVCアーキテクチャだけで良いのにね
意識高い馬鹿コーダーが変な技術を持ってくる
極論言ったらJavaScriptだけでも作れるのに >>513
何の話なんだそれ。
>>514
逆だよって今更すぎる。
テーブルがあって1行追加したいとしよう。jQueryだと
$().append(..render(..).html())
に似た処理をどこかで入れるだろ?元のデータは何なら”破棄しても良い”。domが主だから。ココが違う部分だからよく考えて。
bindingだとlistに1行追加するだけ。
list.push({})
あとは自分で調べて。スレチで長々とすまん皆の衆。 最初からSPA作る目的ならならわかるけど
そうでなければReactもVueもう導入した先は絶対カオスになるだろ >>517
> bindingだとlistに1行追加するだけ。
嘘ついたらいかんよ。
HTMLにごちゃごちゃ書かないとダメだろ。ループ処理とか
JSXかもしれんが jQueryでもvueでもデータそのものは、listに1行追加するだけなんだよ。
そとは、そのlistのデータを見て、JavaScript(jQuery)でHTMLを生成するか、
vueを使って、HTMLのテンプレートでlistみてループ処理やって、場合によってはif文相当のことをかいて
どの変数がどの部分に埋め込まれるか書いて、どのイベントがどのハンドラに対応するかをかいて
ようやく連携が取れるんだよ 最初からSPA作るのと、>>518はやってることが違うから、別にカオスにはならないだろ react宗の人間だがvueは大規模で逃亡するほどきついのかね? 例の件でVueがネタ言語扱いされるとか…
ひどい風評被害だな 不毛だよなぁ
react、vue、angular使えますとか
rails、laravel、spring boot使えますとか
どっちもどっちか一つでいいのに…
複数学ぶのは時間の無駄で、技術選択する時間も馬鹿にできんし Model(Data/Logoc) <==> View Model(jQuery/DOM) <==> UI(HTML)
Model(Data/Logoc) <====> UI(HTML+Vue Markup)
三段構成の中間層がフレームワークによって消滅するんじゃよ >>532
https://012-jp.vuejs.org/guide/
> Model と View を同期するオブジェクトです。 Vue.js において,
> 全ての Vue インスタンスは ViewModel です。
> それらは Vue コンストラクタかそのサブクラスでインスタンス化されます:
消滅してないけど? ふと思ったのはexcelみたいなUI考えた場合、modelとviewを無理やり引き剥がしても
ほとんど意味ないんじゃないかということ。 firebaseが台頭してきてるから
Web屋はフロントエンドで生きていくしかねーな firebaseなんてGCPの一プロダクトにすぎない そんな象は動物の一種に過ぎないみたいな当たり前のことドヤ顔で言われましても… 言いたいことは分かるよ
アスペには分からないだろうけど アスペに素人教えさせると
知ってて当たり前だと怒り出す >>519
元の話がロジックとUIの分離からそれでいいんだよ。dom appendなんぞロジック上は不要。単なる事実だが。 勘違い素人「こうですね!(どやぁ)」
上級者「こうしたほうが無駄がなくていいよ」
勘違い素人「ムキー、これでもいいだろ!」 >>542
うん。だからHTML(JSX)にループや条件分岐の
ロジックが移動してますよねって事実 >>544
論点ずらしは二重に恥だからやめとけ。あとスレチだからこの話はもうやめろ。 最近Angular触ってみてるんだけど
Reactって結構Atomic Design指向だから細かい部品に分けた方が効率よくなるけどAngularは小分けにすると逆にカオスになりそうだね 出たよバズワードに踊らされる奴
Atomic designが流行ったのはReactが普及したあと。
Atomic designをReactで実践したいならできるがReactがAtomic design指向なんてことはない。
コンポーネント指向とごっちゃになってるんじゃないか。 いや、実際にある程度使ってみて部品化した方が効率が上がるのにAtomic Designって言葉使うのが適切かなって思ったから言っただけで別に言葉が先にあるわけじゃないよ reactで開発されたアプリの解読でコンポーネントやらReducerやら100ファイル以上あって熱が出そう
細かい部品に分けるのもいい加減にしろや 部品に分けるからって別にファイル数無駄に増やすってよりも
最小の部品こそ属性の付け方で色々な使い方できるようにしたり
でもデフォルト値はあって最小の指定でもちゃんと動作するようにしたり
以前はC#でdll部品とか作ってたから使い勝手のいい部品作るのは楽しい ■ このスレッドは過去ログ倉庫に格納されています