【ﾜｯﾁｮｲ有】Vue vs React vs Angular Part.5.5
!extend:on:vvvvv:1000:512
実際どうなん？
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などはおｋ。
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured Blazorガイジのﾜｯﾁｮｲは相手にする者もまとめてNGネーム登録推奨 現実は希望通りにはいかない
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
2020年2月 74.4%
2020年6月 75.5%
2020年7月現在 75.9% まぁ何かを広報するようなオシャレ系なサイトは別にjQueryでいいだろ ちなみにﾜｯﾁｮｲは毎週木曜更新だからID寿命が一週間に伸びたってのと大まかな回線種別が分かるってだけで完全固定ってわけじゃないよ あとワッチョイがあったとしても書き込みまでは防げないんだよね。
5ちゃんブラウザとか使えば書き込まれたものを見えにくくすることは出来るけど
他人は見えるし、レスが見えなくなる＝反論レスもできないので
知らない間に話が進んでるとかねｗ 少なくとも飛行機ビュンビュンやってIDコロコロ変えてるヤツは同定できるとかその程度の話
これで都合の悪いヤツは… vue3.0でスライダー作ろうとするとプラグイン系が軒並み対応してなくて自作する羽目になるな。時間かけた割に劣化版が出来上がったわ。 Vueはreact追いかけて変な方向に行ってしまったな。
従来のVueの手軽さがいい人にはAlpineJSをお薦めするよ。 vue3取っ付きにくかったけどreact勉強始めたら結構すんなり理解できた そんだったら最初からreactでいいじゃんってなるよな
なんでわざわざ寄せてったのだろうか >>12
それだったらreactでいいじゃんｗ
react理解しないと分からないvueに何の価値があるんだ簡単なのが売りだったのにｗｗｗ >>14
とっつきやすさはあるかも知れないけど簡単かと言えばちゃんとしたものを作ろうとしたら結構難しくない？
今やHooks実装したReactが一番シンプルな気がするんだけど vueが変な方向行ったとはいえ、class based じゃなければ 2.x までの書き方でもほぼ問題ないからな。
composition api は必須ではないよ。 composition apiはHooksよりかはセンスが良い
そもそもVueはReactよりセンスが良い。Class based以外は jsスキーとしては理解すべき要素が全部単純なjsの知識に還元されるreactのほうがシンプルでいいわ。 ウェブの知識のうち、JavaScriptだけの知識でいいというのは
プログラム言語の知識の内、全部配列の知識に還元できるから
シンプル（＝少ない知識でいい）という考えですか？
少ない知識（シンプル？ｗ）で作ると
コードは複雑になりますよ
「知識が少ない」と「シンプル」は意味が違います。 vueは↑この書き込みみたいな感じ。
ごちゃごちゃしてて何言いたいのかさっぱり分からん。 >>20
あたま悪そうだねｗ
適切な道具を使うほうがシンプルに作れる
だがお前は、勉強しないことがシンプルだと勘違いしてる 最近QiitaでReactの記事書いてる人の殆どがHooksもアロー関数オブジェクトも使ってなくてなんだかなぁって感じ ReactでJSの知識しか要求されないってお前React触ったことあんのかってレベルだよね var component = function(){…}
こんな書式使ってる人いたんだがどうしてそうなったし… Hooks表記使ってない事以外に関してはconnected-react-routerのexampleってホントよくできた教材だと思う >>19
覚えなきゃいけないVueの固有仕様が多いって事
Reactの場合はその大多数をプログラミング全般に言えるような考え方で実現できる >>27
プログラミングの原則は、覚えることを増やすことで
コードをシンプルにすることです。 言わんとする事はわかると思う。
単純なifとforだけでロジックは組めるけど、それは簡単なだけでシンプルな読みやすいコードとは言えない。
コード内にパターンがあるならどんどん抽象化すればコードは短くなってゆく。
でもやり過ぎればマクロだらけの複雑怪奇なDSLになる。そのへんのバランスは難しいし用途によっても変わるので、完璧なライブラリなんて無い。
どうせ覚えるなら他所とも地続きな抽象化をしてるライブラリの方が応用効くとは思う。 VueでもAngularでもだけど拡張プロパティの右辺と左辺ぎゃくじゃね？ってのがなんか気になるんだよね
構文上そういう作りにせざるを得ないんだろうけど v-model.number="age"
みたいなの 8/4
トラハックのエンジニア学習ゼミ【とらゼミ】
Reactのスタイリング定番styled-componentsの活用パターン
https://www.youtube.com/watch?v=LJqr0Qvjupo なんかフロントエンドの人があまりいない環境で、フロント書くのに、VueあたりでSPAにしようとしたらSPAである必要がないみたいな感じで反発くらってるんだけどどう思う
パフォーマンスとかはあんま気にしてなくて、単純に今はフレームワーク充実してるから、フロントをSPAにしてjsだけに集中したほうが楽なんじゃないかなと思ってるんだけど
厳密なspaというよりは普通にappサーバーと同居してるやつね Vueは最近バージョン上がったばかりだから、それをどう捉えるかだよね。評価が定まってきたり熟れてくるまで採用を待つか。あるいは今採用してしまえば暫くはバージョンアップに伴うコード変更作業は発生しないから、良いタイミングかも知れない。
クライアント、サーバ間のインターフェースがREST APIとかで厳密化されるならフロントエンドのフレームワークを導入するのは良いと思うけど、そうでない状況の場合はSpring Boot ThymeleafやASP.NET Core MVCが良いと思う。
チームで良く話し合って良い方針が決まりますように。 それはフロントエンドの人があまりいないからじゃね？ >>34
お前がjsで書いたらこれだけで簡単になると
実例を示せばいい
まあそれができないわけだけどねｗ
JavaScriptのフレームワークは過剰に複雑にしているものばかり >>34
> 単純に今はフレームワーク充実してるから、フロントをSPAにしてjsだけに集中したほうが楽なんじゃないかなと思ってるんだけど
テストについてしっかりと考えているか？
HTMLやCSSは宣言的なのでテストがあればなおいいが
なくてもバグが発生しにくいんだよ
JavaScriptを使うということはコードを書くということ
それはバグを生みやすい かといってフロントの動的な部分をjQueryで各ページごとに書いてたらテストもクソもないしなあ jQueryも宣言的に書けるからバグが少なくなるんだよ
あとバグはコードの量に応じて増える
jQueryはフレームワークと違ってコードが少なくなる githubで、vue.js をguiベースでドラッグドロップでフォーム作れるリポジトリ発見した。ただしsubmitボタンが無かった。vue-frame-maker reactのcontextって親から孫に子を飛ばしてデータ渡せるけど、子コンポーネント間の(親を経由しない)受け渡しには使えないよね？ 実務でVueをtypescriptと使ってる人に聞きたいんですけど
Vue3はいつ頃乗り換える予定すか？
新しいサービスを作る必要があるのだけれど、vueの2系でやるか3系にするかめっちゃ悩む。vue3はtsでのベストプラクティスがこなれてないからいっそreactでもいいかと思ったり、、。 >>44
実務でvue3は既に使っててIEは切り捨ててる。
ウェブサイトというよりもウェブアプリって感じだからね。
2系でも composition api は使えるから、IEをサポートし続けるなら2系でスタートして、3系がIEをサポートしたらアップグレードすればいいと思う。
まぁ3系でも options api の互換性はあるからどっちで作っても良いんだけど。
3系では class based のコンポーネントをサポートしなくなっただけで、tsが使えないわけではない。型指定は普通にできる。
reactでもいいかもね。 >>45
vueは2までtsで使ってたけど
3で何があったの？ >>44
同じ辛みをかかえてて、同じようにReactに走りそうになってる。
もともと、TSはあんまり好きではない部分があって、悩んでるところ。
ただ、ReactとTSはセットにするとだいぶ良いなと思ったり。
もっとダックタイプで良いんよね。インターフェイスの実装に関してはGoみたいな雰囲気でいきたい。
仕事だとまたIE11切り捨てられないから、躊躇してるわ。 >>45
あざます！ まさにそこらへんの話が聞きたかった！
さらに聞いちゃうんですが、コンポーネント間のStateマネージメントってどうしてますか
・inject/providerでStoreパターンを作る,
・Vuex v4を使う
とかっすかね？
2系の開発だと、vuex-module-decoratorsとかでvuexをタイプセーフにしていたので
3系だとそこらへんきれいにやるにはどうしたもんかなーと思っていて。
(2系でcomposition API入れればいいのかもしれないけども) >>47
ReactとTSはいいよねぇ。
型安全だからJSX実装中にもインテリセンスが効きまくって
CSS周りのコーディングパターンが複数あって選定するのが面倒だけど。 これまで静的型付け言語しかしてなくて（言語は荒れるから書かない）
今度のプロジェクトでReact+tsを使うことを検討中
インテリセンス効きまくるということに感動されてるのが、これまでは当たり前だったことができなくなるんじゃないかという不安を煽る…
React+ts+VSCode（かな？）だと静的型付け言語と同じくらいの生産性を保てるのか
フロントサイドの開発はそこまでは望めなくてそんなもんだよ
なのかを知りたい >>50
> これまで静的型付け言語しかしてなくて（言語は荒れるから書かない）
静的型付けはネイティブ開発？ サーバーサイド？
いずれにしろ、React + tsを選定しておけば書き味は似たような感じになるので大丈夫だと思う。 >>51
ありがとう
安心した
インテリセンスが効かない環境を知らないコピペプログラマなもので。 >>53
わかりやすいサンプルコードまでありがとう〜〜。
composition APIだとシンプルな記述でreactiveになりますねぇ。よさそう。
年末年始で次のプロジェクトで使う実験してみようかな。 997 名前：デフォルトの名無しさん[sage] 投稿日：2021/01/18(月) 00:41:57.79 ID:xEqPTcle
jQueryって状態をグローバル変数で管理するしかなくて
相当辛い
その例みたいにCSSをちょこっと変えるとかならjQueryじゃなくてもほぼ同じコードでいけるし
IEが死んだ今その用途ですら使う意味はない
998 自分：デフォルトの名無しさん[sage] 投稿日：2021/01/18(月) 01:15:22.90 ID:5We8pJJc [1/2]
>>997
> jQueryって状態をグローバル変数で管理するしかなくて
jQueryのせいにするなよ
お前の実力不足じゃんか
999 自分：デフォルトの名無しさん[sage] 投稿日：2021/01/18(月) 01:19:01.91 ID:5We8pJJc [2/2]
DOM（ドキュメント"オブジェクト"モデル）なんだからDOM要素を
オブジェクトとして考えればいい。状態はオブジェクト、つまりDOM要素自身が持つ
DOM要素の属性として持たせてもいいし、data属性を使ってもいいし、
jQueryのdataメソッドを使ってDOM要素に結びつけても良い
グローバル変数で管理するしかないのは、単にお前の技術力不足ってだけ セキュリティ周り難しすぎる。
localStrageはjsから簡単に読めるから、Cookie使えまではわかるんだけど、httpOnly付けてもXSSで読まれうるとか言われて面倒くさくなってきた。
とにかく自作WebAPI用にトークン（JWTでは無い）をブラウザに安全に保存したいんだけど、もう自力でやるのは諦めてよく練られたライブラリ使ったほうが安全臭いんだよね。
Reactと相性良い認証ライブラリとかある？ 煽りあいは楽しいか？
ﾜｯﾁｮｲだったら相手するやつもまとめてNGぶっこんでやるのに 結局API用のトークンなんかどこに保存しようが一緒だからね
セキュリティチェックで文句言われる（保存しているトークンをそのままAPIのパラメータに使用した場合）ので
気休めにlocal storageに保存するときにAESで暗号化して回避したよ
これもコードまで解析すれば分かる話だがな・・・ React叩き棒にして暴れてるフロントエンド知識無しじいじも流石にここには来んやろ >>63
そのワッチョイでよくそのセリフが吐けるなw あ、React叩き棒じゃないなRust叩き棒か
>>64
ﾌﾟｰｲﾓはダメなの？ あの人議論したいわけじゃなくて、フロントへの鬱憤晴らしたいだけだからワッチョイあると不都合なんだろうね。 時々思うんだけどNextに対してGatsbyって何か優位な点ある？ Gatsbyはgraphqlを通して様々なソースから静的ページを生成する
でもNextでも出来るんだよね
Gatsby下火っぽいし >>69
やっぱそんな感じかぁ。Gatsbyと言えばGraphQLみたいなイメージあるけどNextでもできるしねぇ。 あっちで暴れてる人TSスレのアンチTSな人と同一人物かも マークダウンファイルからhtmlを生成するため何度かGatsby触ったけどNextか普通の静的サイトジェネレータで良いかなって 俺はGatsbyの本でSSG勉強したのに結局NextでSSGを採用したぜw vue の setter による変更検知が一番シンプルに思う。getter のキャッシュもこれで実現できてるわけだし。jsx も使えるしね。 もう状態管理ライブラリを別途投入しなくても useReducer & useContext で十分な気がしてきた… react始めたけど時期メッチャ悪いな
v18になったりmuiが仕様変わったりで
調べるの大変だわ 公式の資料読んでればそこまでは困らないし、変に覚えた知識切り替えなくていいから楽ちんちん、とhooks出てからReact覚えたときは思った。公式以外は……うん…… jqueryの何が悪いん？
と言うかフロントエンド技術学習コストデカすぎで頭おかしいんだよ！
PHPやララベルやNode覚えたりSQLや単なるHTMLCSSjquery覚えてgit覚えるだけで精一杯なエンジニアだって沢山いるのに
まだreact覚えろとか鬼畜かよ
今まで覚えたこと台無しになるし、そもそもweb系エンジニアなんてオブジェクト指向まともにわかってないやつ多いのに無理やりJavaScriptに対してオブジェクト指向思考持ち込むなよ！
ブラウザ側のバグなんてある程度発生してもいいし、エラー出たらガリガリ直せばいいだろうが
reactとvueとangular乱立してるしよ Reactは一回作ってしまえば部品単位ではめちゃくちゃ使いまわしが利くから既に取り入れてるとことかなら結構楽 ネタが尽きたからまた同じ燃料投下したわけか
確かにもう話題ないもんな >>79
Reactとオブジェクト指向混ぜて話すのは流石にエアプ感が凄い。30点 Remix素晴らしいからもっと流行ってくれないかな
Next前提のドキュメントばかりでつらい 技術的な内容あまり理解してないけどRemixで作ったサイトはパフォーマンスいいよね
PageSpeed Insightsのスコアはそんなだけど自分でアクセスするとすごい速く感じる Remix凄く良さそうだし、最近のNextは過剰に感じるし、やってみたいけどなぁ……で止まってる。公式ドキュメントとにらめっこしよかな…… reactのstyled-jsxをNext.js でない巣のReactの環境で動かそうと思ってるんだけど、<style jsx>タグが普通のstyleタグになってしまう。
webpackは使っているけど、自分用のコードだからbabelは使ってない。
styled-jsxのreadmeを読むと上から下までbabelを使うのが大前提みたいに見えるのですが
styled-jsxってNext.js で使う、もしくはBabelを手動で入れた環境で使うのが当たり前だったりしますか？ じいちゃんが犬を捨てに行ったら、犬が先に帰ってきた。 
