Vue vs React vs Angular
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん?
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 中国人がどんどんcomponent作ってくれるから楽できる Aurelia試してみたけどcliでプロジェクト作ってもhttp-serverインストールした上必要なファイル手動で追加せんとデモ画面もろくに表示されんとかこりゃ流行らんの当たり前やん >>490
AngularはAngularJSでやらかしたのがデカイんじゃない?
一生懸命AngularJS勉強して「さあこれから本格的に開発していこう!」って矢先に互換性のないAngular 2発表、
AngularJSはオワコン化じゃ、次何が出ようと「誰がお前らのフレームワークの習得に投資するんだよ」ってなるわ。 >>496
わからない時は英語じゃなくて
中国語で検索しないといけなくなるのかな? >>500
ほんまそれだわ、3年前Angular2で別物になったと思えば、もう6とかいってるし…
数年でもう5まで行ったLaravelも大概じゃないがそれよりひどい あと、フルスタックじゃないAngularJSのような気軽さがないとね…。
ReactとRedux、Vueとnuxtみたいな関係が必要だ。門戸は広く、奥行きは深くすべき
ReactはVueに影響されたか、だいぶ記述はわかりやすくなったから、前よりは
とっつきやすくなったと思う おいreactに来たhooks apiめっちゃいいやんけ。クラスなんていらんかったんや! >>503
> ReactとRedux、Vueとnuxtみたいな関係
言いたい事は分かるが一応訂正。reactとnext.jsに対応するのはvueとnuxt.js。ステート保持はreactがredux、 vueがvuex。 Reduxが要らなくなるのがHooksなんじゃないの? context apiと組み合わせれば。
デカイアプリはまだまだreduxじゃないかな?
しかし確実にstate管理の枠組みにも変革を促すであろう。
post reduxにどんなのが出てくるのか楽しみ。 ということで、またオワコンが一つ増えますね。Reduxはオワコン。
ほれ、また次だぞ。チキンレースは終わってないぞ! まあreduxはめんどくさすぎるからな。
小規模アプリでも必須みたいな風潮が異常だった。 >>507
現状nuxtは大きくなりすぎたからnextと比較するのは不毛 reactでブラウザの戻るに一つしか履歴が登録されない
意味不明 ヒストリー使ってるんだけど
・createBrowserHistoryライブラリ(IE対応のため)
・redux
・react-redux
・connected-react-router
これら使ってなんとか構築してるんだが一つしか履歴残らん
てか解説サイトがほとんどない… とりあえずhistory直す
なんかわからんがLink使うとhistoryの履歴が3つ登録される
SPAはここがめっちゃめんどくせぇ
なんでブラウザの操作までjsで組まなきゃいけないんだか てかオッペケってReactマスターやなかったんかい 別にSPAにせず普通にページ遷移してもいいんだがな。誰もやらないだけで。したがってサンプルも転がってないw >>522
すまん、App.jsのコンストラクタ内でthis.props.history.listen使ってしまっておった
これやめたら直りました
dispatchで初期化するのにつかってたのが間違い Reactはホント人によって使うフレームワークやライブラリが全然違うな。
ちょっと興味あったけど、これじゃどっから始めたらいいか全然分からん。
てか、ReduxだのNextだの、第三者が作ってるであろうフレームワークの開発なりサポートなりが終わってしまったら、代わりはどうすんだ? 極力公式か大きめの企業がメンテしてるものだけで作る
コミッタが少ないものは使わない
ライブラリへの依存が散らばらないよう自コードで軽くラップして使う まぁ本当にSSR必要かってのもあるけどね
最近自分の関わってる案件だと会員サイトの認証済み領域の情報は一切検索エンジンにヒットさせる必要ないからSSRとは無縁なんだよな >>526
大丈夫。その前にReactが終わる。VueもAngularも
あと数年後は今存在してないフレームワークが使われてるよw 数年後も残ってるのはjQueryだけ
MVC+jQが正解なんだよ いやreact vue angularについては長生きすると思う。ここ数年は本当酷かったフレームワーク戦争も落ち着いたしあと5年は使えるんじゃないか?ようやく腰を据えて安心して学べる状態になった。 お前ら、RADツールって知ってるか?
ウェブの世界じゃあまり知られてないかもしれないが
デスクトプアプリの世界じゃ20年以上前から存在してるものだよ
VBとか有名だな
で、reactなどは近い将来RADツールに置き換わる。
RADはツールであってフレームワークではないから
正確に言うとRADツールを作りやすいフレームワークになるということ
コンポーネントは作ってパーツとして使える。
使いやすいコンポーネントが最初から揃っている。
GUIでマウスで操作するだけで簡単にコンポーネントが配置できる
まあここまではUIエディタ(HTMLエディタ、JSXエディタ)と
変わらんわけだがここからがJavaScript
コンポーネントを選ぶんで書きたいイベントを選ぶとイベントハンドラが生成される
自分で紐づけとかしなくて良いんだよ。JSXとか書かなくていい。
イベントハンドラ名もデフォルトで自動生成、プログラマはイベントの中身を書くだけ
データのバインドとかもRADツールで紐付けるべきものの名前を書くだけ
20年前のVBはすでにこういった世界だったんだよ? マウス1つでレスポンシブデザインまで対応出来るなんて
夢みたいなツールじゃん レスポンシブはブレークポイントを複数定義して
デフォルトからの差分みたいな感じでデザインするんだろうね 選択肢の一つをあたかも統合されるかのような詭弁はNG。
ポトペタASP.NETが密結合過ぎてわざわざOSS界隈に歩み寄った歴史を思い出せ。 技術がなく判断できない企業はノンプログラミングという言葉に騙されやすいのだろうね >>539
WIXはそんなに悪くないが一般的には酷いの多いよね >>539
ノンプログラミングはだめだろうね。
今のRADはGUIのエディタで作ってもいいし、
コードで書いたとしてもGUIに反映されるようになってる WebFormは一瞬でページ作れるから
ものによっては便利だが スキャフォールディングはページを作るものではなくて
ベージの一番最初のコードを生成するだけです。
その後に生成したコードを修正して作っていかなければいけません。 修正すればええやんけ
ポトペタより簡単でソースも綺麗やで
ポトペタなんてマウス操作とアイコン探しの悪魔的苦行の繰り返しやないか
あれが楽とかマゾでもよう言わんで いやちゃんとしたい時はMVCなんだが
WebFormの存在理由もそれなりにある さすがにVueとかにはくっつけられないから
スレ違いだったな
RazorPagesはくっつくかな >>538
MVCやSignalRも知らないおバカさん >>549
RADの話が出たからWebFormsみたいなクソが消えた歴史を考えろっつってんのに、何がSingnalRだよ。文脈読め。 >>550
ASP.NET=Web formsっていう発想自体が頭おかしいんだよ Reactというかredux?見てて思うのは、
お前らネットワークプロトコルでも作ってるのかよって話
普通にメソッド実行すればいいのに、
パケットデータ作って、そのパケット解析して処理実行する
メソッド一つ実行すりゃ終わりなのに
関数型にしたいのかどうか知らんが、目的を履き違えてる。
バグを減らすために関数型にする。そのために複雑にしてバグを作りやすくしてどうする
関数型じゃなくていい、バグを減らすためにシンプルにしろよ >>553
しかしflux概念は世界的に認められてるから広く使われるわけで、キミの主張vs世界中の開発者の同意でキミが勝てるわけないよね
そのへんどうすんの? 反論しないで、世界に広める方法を聞く
変なレスだなぁw ところでさ、
function foo() {
return { hoge: 1, hage: 2 };
}
expect(foo()).toEqual({ hoge: 1, hage: 2 });
みたいな意味のないテスト書いてないよな?
固定の連想配列返す関数のテスト書いても意味ないぞ
二度手間なだけで、それを避けるためにどうせコピペするんだろうし >>553
メソッド実行するって具体的にはどういう形?
dispatchの前処理と後処理を自分で追加したメソッドを
ストア(↓)に生やすようなのをイメージしたけど合ってる?
https://github.com/reduxjs/redux/blob/master/src/createStore.js >>557
ようするに、
Actionみたいな「処理の内容をパラメータ化したオブジェクト」を
いちいち作らせるのをやめてくれ、
Reducerみたいな、switchでActionのパラメータみて分岐して処理する
ようなおのをいちいち作らせるのやめてくれ
ってことだよ。
onclickにincrementメソッド書いたら、+1するincrementメソッドが呼ばれます。
でいいじゃねーか。直感的だろ?それで別にテストできないわけじゃないんだし IOモナド不要論に近いものを感じる
単にReactを選択しなければいいだけなのにね
選択肢の中に一つでも気に入らないものが混じってると全否定を始めるんだからもう IOモナド不要論というか、IOモナド至上主義じゃないってだけ
副作用排除は素晴らしいよ?でも複雑にしてまでやることじゃない。
バグは副作用でも増えるだろうが、複雑にしても増えるんだよ
書くものが増えれば増えるほど、書き間違いも増えテストも増えるんだから >>558
その形なら単にReduxを使わなければ良いだけでは?
使用を強制されてるのなら何とも言えないけど
ちなみにうちは本開発でReduxを使ってない
別に嫌ってるわけでもなく、とりあえずバニラなReactでやってるうちに
Contextが来たのもあって特に入れたい状況にもならずって感じ >>561
たぶんReduxは捨てろって流れになるだろうね。
それが可能になるContext
行き過ぎた関数型ブームなんだろうな。
だいたい行き過ぎて戻ってやっと最適な状態になる。
あと別に使用を強制されてない。
React自体使ってないものw >>553
ていうかまず状態って言うほどサイト全体で持つ必要あるのか?って思うね
大体の場合はコンポーネントの中で閉じててもいい場合が多いし
本当にサイト全体で持ちたいデータはリロードとかて吹っ飛ばないようにlocalstrageにでも書いた方がいいんじゃないかとか 遷移して戻ってまだ編集内容が残ってると逆に気持ち悪い どのコンポーネントが状態持ってるのか探す方がめんどくさいじゃん。 reactは好きだけどreduxめんどくさい論は大賛成!
hooks + contextに大期待!! >>565
その部品の情報がその部品で閉じてるなら探す必要ないじゃん? Redux使わずcontextAPIのみでアプリ作ったけど、なかなか良い感じ
シンプルisベストだね >>567
その部品で閉じるような状態ならな。
二つ以上の部品にまたがる状態だってあるだろ。 だから2つ以上の部品にまたがる所だけで良くなるだろ reduxなんて面倒くさいレベルに入らないだろ
しょぼいシステムしか作ったことがないんだろうが >>571
その分け方がわかりやすいと俺は思わん。アドホックな部分が増える。 >>572
つまりあなたも面倒くさいって思ってるわけですよね?
このぐらいのレベルなら耐えられるって言ってるだけだし Reactそのものが面倒だと思う
サーバーサイド一本の人が移動してきて、Reactのコンポーネント一つ任せたら、onclickで画面をエフェクトさせるのが出来ないとブーたれてた
cssと組み合わせてやるんですよと教えたけど、デザインとロジックが分離されてない糞フレームワークだと文句ダラダラ
結局Reduxのところだけ担当してもらった
サーバーサイドだけの人はこの世界では使い道がない それはサーバーサイドしか知らないのに画面のエフェクトだデザインとロジックの分離だ言う
その人個人の問題なんじゃないかね。 >>574
こんなのより何千倍も面倒くさいプログラミングしてきてるから面倒くさくねえ部類って言ってんの
頭イカれてんのか? 何千倍も難しいって、口調が前にどこかのスレで見たような気がする
確か自称ゲームプログラマーじゃなかったけ
私大文系はクズだのヴァカだの幾何学的計算が出来れば高卒でも理系とか意味不明な発言の人だった バカじゃなくてヴァカという変な単語を連呼してたので覚えてる てかテキストボックスのチェンジイベントでイチイチReducerだかDispatcherだかを経由してストアに書きに行くもんなの?
確定ボタン押した時でよくない? >>577
デザインとロジックが分離してない上にVueみたいにコンポーネントとして独立するわけでもないっていう中途半端さがね 落ち着け、議論を飛び出してケンカになってるぞ。そこまでくると他の人に迷惑だから頼むから我慢して2、3日スレから離れて観て欲しい。 >>583
ビビんなよ。5chではよくあることだろ ビジネスロジック→Service(バックエンド)
プレゼンテーションロジック→ViewModel(js)
デザイン→View(html/css)
サーバーサイドおじさんはプレゼンテーションロジックがお気に召さないらしい
ビジネスロジックとデザインだけで完結するMVCフレームワークが人気 >>585
そこに、ActionとAction CreatorとReducerとStoreは
どこに含まれるの?って話だよ
アーキテクチャ上、必要ないものが多すぎる >>586
分類するなら全部プレゼンテーションロジックだろう
SPAとかいう誰得要件のせいでプレゼンテーションロジックが過剰に肥大化複雑化してしまった結果それらが産まれた
従来のマルチページに戻すだけでスッキリ解消される 誰得っていうけどブラウザアプリ作るならSPAの方がUXが劇的に向上するケースが殆どじゃないか? UXが向上したということにしたいだけでは?
案外ユーザーはシンプルなMVCのほうが簡単で良いと思ってるものさ シンプルなMVCかどうかの判別ってユーザーからできるの?ユーザーってもしかして顧客のこと? 年明けてから二ヶ月経過したけどなんだかんだ書籍出てるな
売れてるんかねぇ
動かして学ぶ!Vue.js開発入門 (NEXT ONE)/翔泳社/森巧尚/2019/1/15発売/ISBN-13: 978-4798158921
Vue.js & Nuxt.js超入門/秀和システム/掌田津耶乃/2019/2/5発売/ISBN-13: 978-4798056593
AngularによるモダンWeb開発 基礎編 第2版/日経BP社/末次章/2019/2/23発売/ISBN-13: 978-4822254537
React.js&Next.js超入門/秀和システム/掌田津耶乃/2019/3/8発売/ISBN-13: 978-4798056920 ウチの会社でReactのアプリを独自UIの新規開発からロジック周りまで全部できるPGは一人しかいないわ
オフショア入れて百人以上PGいるけど、みんなFlexbox使って自分でUI書けませんとか、エフェクトのアニメーションを自作できませんとか、htmlとcssで躓いてる
デザイン系が得意なPGだと今度はDBやAPIが良く分かりませんという風になる
デザインとロジックの分離が不完全なので不器用な奴には使えない
結局Reactのアプリ制作はその一人が設計構造を考えて何人かで分担して作ってる
その一人がいなくなったら改修も容易ではない ■ このスレッドは過去ログ倉庫に格納されています