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 今はtypescriptが当たり前になってきているから、typescriptを絡めることで本を作りやすそうなのになあ typescript推しはIE信奉者でMS狂信者しかいないと思ってる で?キミらはどのくらいのことができてどのくらいのものが作れるの? >>85
angularはjavascriptで書かれたオープンソースのフロントエンドWebアプリケーションフレームワークなんだよな はは、結局お前らフレームワークに振り回されてるだけじゃん
jQueryの過去の資産を大事にする方針を
見習ったほうが良いぞ スルーするな
キミらはどのくらいのことができてどのくらいのものが作れるの? >>92
ああスマンスマン
バックにLaravel置いてVue(Vuex、vue-router、axios、Bootstrap-Vue)とReact(Redux、react-router、SuperAgent、React-Bootstrap)入れた二種類のセット
それぞれ一通り機能確認するデモサイトをローカルに作ってみたって程度だよ実戦投入するのはこれから
あとNuxtとAngularはcliからプロジェクト生成してどこに何を書いて機能追加していけばいいか分かったって程度
Angularとかはコンポーネントの数多すぎて細かいところは全然
フロントエンドフレームワーク去年の後半から始めたばかりだから流石にまだまだ>>81みたいなんでもできるとは言わないよ
公式って結構公平だからサード製のモジュールに関してはこれ使えみたいな事あんま言わないじゃん
その辺に関してはやっぱ新ジャンルに手を出すなら書籍1〜2冊読んだ方が効率いいと思うんだよね >>89
jQueryを使い続けるとしても設計指針としては参考になる事柄は相当あったと思うよ
何もやらなきゃいずれは時代遅れな挙動のサイトしか作れないって事になる
せめてHTML5のAPI集くらはちゃんと読んでおいた方がいいと思うよ >>93
React-Bootstrapってv3だよ?
今さら使う意味なくね?
そしてReactstrapはまだまだ開発中
俺としてはBootstrap Nativeをオススメするなあ
自分でコンポーネント作ることにはなるけど、むしろ使う部分だけコンポーネントにするから余計なstateないしスッキリ >>95
npm install react-bootstrap@next bootstrap
@nextって付ければv4でいけるけど
https://react-bootstrap.netlify.com/getting-started/introduction
ありがとうBootstrap Nativeはちょっと調べてみるよ
ところでReduxとreact-router連携するのって何使うのがベターなの?
パっと調べた範囲で
react-router-redux
redux-first-router
connected-react-router
くらいがあるけど選定するための基準がなんとも Bootstrap Nativeってパッケージはなかったけど
これの事?
↓
Native JavaScript for Bootstrap
ReactNativeのNativeじゃなてNativeなJavaScriptって意味のNativeか
>>97
V4はV4で何かと機能増えてていいもんだよ >>96
v4はまだ開発中だしね…
あとrouterはconnected-react-routerがいい
react-router-reduxは非推奨になったから
https://github.com/reactjs/react-router-redux
>Project Deprecated
書籍ではreact-router-reduxを推してるから注意だね
>>98
そうNative JavaScript for Bootstrapのこと
どのコンポーネントライブラリも中途半端で開発中だしissueみたらバグ多いからまだ使うべきではないと思う npmのバージョンアップにより
yarnのメリットはなくなったんじゃないの? とりあえず
npm, react, babel あたり使って開発してみたらいいんじゃないかね。
それらの使い方やドキュメントの漁り方になれれば他に移るのもやりやすいでしょ。 Ionic+Angler使い続けてるけど
そろそろ乗り換えるべきか悩みますね 乗り換えに理由がない時点で何使っても駄目なんじゃね? >>106
釣られたな
Anglerだけに
なんちって vueはマジで独学は難しい。
あたかもjQueryより手軽で簡単みたいな事を謡い文句に
なってるけど絶対そんなことないと思うわ。アルゴリズムと
データ構造をカジッてないと
細々とした機能が何のためにあるのか、どうやって
道具として使われるのかが判らん。多分これはReactやAngularでも
いえることなんだろうけど。 宣言型のjQueryとは考え方が違うからね。
CSSも宣言型なので、宣言型ベースで考えてると
オブジェクト指向のvueが使いにくく感じるのは当然 >>108
まぁjQueryの様には行かないわな
他のフレームワークよりも導入しやすい点を挙げるとするなら
制御対象のDOMを<div id="app">〜</div>で囲めば元のhtmlを活かしたまま使えるって事くらい
ReactやAngularの場合はイニシャル掛けた時点でその内側のDOMはフレームワークに定義したルートコンポーネントに差し替わってしまうからね ∩___∩ |
| ノ\ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡、 |∪| | J
/ ∩ノ ⊃ ヽ
( \ / _ノ | |
.\ “ /__| |
\ /___ /
オブジェクト指向? Vueをオブジェクト指向だって言うのは別におかしくないよ vueが難しいならこれからウェブアプリの標準的な実装方法になるReactはもっと難しいことになる
しかもjQueryより楽と言われているから脳みその思考の仕方が違うんじゃねえの 思考の仕方が違うってのはあると思う
手続き型でめちゃくちゃ複雑なスパゲティプログラムを間違いなく書けるほど高度な情報処理能力を持ってるのにオブジェクト指向、関数型、宣言的プログラムはからっきしダメという人
逆にそれらを使いこなして洗練されたコードをかけるけど、手続き型のスパゲティプログラムを処理しきれない人
どっちが賢いとかではなく
たぶん脳の基本構造が違うのだと思う フレームワークだとDOM APIと違う方法を使うことになるので
新たに覚えることが多い
jQueryが楽なのはライブラリでフレームワークとしてはDOM APIと
同じだから標準を知っている人は単にAPIを置き換えただけ(と感じる)
とはいってもjQueryは宣言型なので、それを活かした書き方をしなければ
本領は発揮できない。具体的にはCSS(セレクタ)でHTMLの構造を定義して
(CSSの)クラスベースで設計する。
だけどそんなことは構わずDOM APIを置き換えただけとしても使えてしまうので
そういう人ほどjQueryは不要って言ってしまう。
まあ要するにフレームワークだと最初に覚えることが多いから敷居が高いが
やり方が強制されるのでよく理解してない人でもそれなりのコードになる。
jQueryだと(DOM API標準を知ってる人なら)APIの置き換えから入れるから
敷居は低いが、効率いい書き方にしようと思えば、宣言型であることを理解して
自分でCSSのクラスベースで設計しなければいけないということ Vue では、単一ファイルコンポーネント(SFC)と言う、独自フォーマットがあるので、
HTML, CSS, JavaScript(JS) を、1つの.vue ファイルにまとめられるから、
この3つの組み合わせを探す手間がなくなる
普通だと、各HTML, CSS, JS ファイルから、該当する組み合わせを探すのが、ものすごい手間
スコープ付き(Scoped)CSS で、他のファイル・コンポーネントと被らない、ユニークなdata属性が付く
<span class="title" data-v-aaaaaa>あ</span>
span.title[data-v-aaaaaa] { color: red; } >>116
違いがイマイチ分からんってヤツに違いを教えるのもこのスレとしては優位意だと思うがな 結 論
中 規 模 開 発 を 謡 っ と き な が ら
中 規 模 開 発 の 本 も サ イ ト も な い。
あることにはあるが
細々としたシステムは説明されてるが
実際に使ってみると対外「チンパン」する >>117
> HTML, CSS, JavaScript(JS) を、1つの.vue ファイルにまとめられるから、
> この3つの組み合わせを探す手間がなくなる
まとめたほうが本当に便利かというとそうとは限らない。
サイトのデザインを変更する時は一箇所だけじゃなくて全体を変更する必要がある
例えばお正月用デザインとかクリスマス用デザインとか。
コンポーネント一つを変えれば良いわけじゃない
それに対して標準的なやり方をしていれば1ファイルだけ変えれば良くなる
ブログサイトのように、サイトごとにデザインが変わる場合は、コンポーネント側で
デザインを矯正できないから、結局CSSはコンポーネントの外に出す必要がある。
HTMLに関しても、コンテンツすべてをSFCに入れられるわけじゃない。
というかコンポーネントとは汎用的なものだからコンテンツはSFCの中に入れない。
1つの.vue ファイルにまとめられるが、1つの.vue ファイルにまとるわけじゃない
まとめる場合と、まとめない場合が混在する。
そもそもCSSであっても適切に(CSSの)クラス設計をして
クラスごとにファイルに分ければ、探す手間なんていらない
このコンポーネントは、このファイルと決めるわけだからすぐに見つかる。
だけどそのためには設計能力が必要になる。
ただ>>115でも書いたが、そんなことは構わずに使うことも出来る。
だから最初の敷居は低い。ただし適切なやり方をしなければ本領は発揮できない。
それに対してフレームワークだと最初に覚えることが多く敷居は高いが、
やり方が強制されるのでよく理解してない人でもそれなりのコードになる。 普通、SCSS は、10個ぐらいのフォルダに、種類ごとに分けて入れる
サイト全体のデザインなら、sight とか、
ページ固有のデザインなら、pages とか
components と、全体のデザインは、分けないといけない scssをフォルダ別けするかね普通
scssフォルダ一つでいいじゃん >>123
その辺の派閥でVue派とReact,Angular派に分かれるんだと思う >>124
でも会社で使うなら、派閥起こしてる場合じゃなくね? 会社ならそれこそ会社で何使うか方針決めるんじゃない? だから会社で方針が決まれば別に会社内部で派閥が分かれる事はないだろ?
それでいいじゃん何に対して突っかかってんの? フレームワーク使いたいって言ってるのに
上に今までのやり方(jQuery)でいいやろ?って言われて
理解してくれないって突っかかってるんじゃねーの?
やるべきことはここで愚痴を垂れるんじゃなくて
「これからはフレームワークの時代なんです!」
以外のまともな理由を言うってことだよ フロンエンドフレームワークの導入しやすさってバックエンド何使ってるかにも依るよね どのサーバーサイドフレームワークでもREST対応、JSON対応してるんだから
バックエンドがアプリケーションサーバーならどれでも大差ないだろ。
ただ単なるウェブサーバーだと、クライアントでフレームワーク導入する必要はないだろうな >>130
はあ?それはねーだろ
お前は無能晒して恥ずかしくねえの? フロントフレームワーク使うことが即座にバックエンドがREST ONLYに繋がるわけではない
MVCとVueの組み合わせはかなりいい感じにまとまる
でもJSPやWebFormsでは全くミスマッチだろう >>131
データのやり取り以前に初期導入時の敷居の違いの話 >>134
そもそもバックエンドなくてもフロント作れるのがフロントフレームワークなのだが? >>135
そんなシステムとして完結してないモノを見せて凄いでしょ?とか言うヤツばっかりだからjQueryのシェアが強いまんまなんだよ
XSSやらずにバックエンドのDBとどうやり取りすればいいかとか説明できんだろ? >>136
説明できんだろ?とかテメェ何様なんだよ?
XSSごときで偉そうなカス野郎www >>137
話の主題はXSSじゃなくてデータベースの読み書きについてだが
>>135の言い分だとproxy設定とかロクに書いたことないだろ? フロントのスレだしリバースプロキシまで書かないと意味伝わんないんじゃないかな 分からない人にはリバースプロクシって言ってもやっぱ分からないんじゃないかと思うけど
入門ならそんな事しなくてもいいLaravel-Mixが楽でいいと思う 最終的には分離開発するにしても導入検討時から分離を強制してちゃ検討も進まないから結局導入されない vueのテンプレート作成
ジェネレーターみたいなモノはないよな。(๑´ڡ`๑)
簡単な文法からVueライクなHtmlタグ入りのソリューションを提示してくれるような奴 >>144
vue template generator
でググったらそれっぽいのあったよ それらしきモノって「ieoman」のことかな?
windowsの解説サイトが無くてフォルダーは手動で構築したけど
なんか半分ぐらい動く感じになった。文法は簡素な感じだけどGroovyやってる感覚になる。
yo mcs:component
ポチッとやたけど、成功パターンがそんなに
判らんので、実用的か、どうかも判らん 今のプロジェクトでangular使ってるけどvue使ってみたかった
まだangularの事全然知らないけど、コンポーネントがts,html,cssでそれぞれ別れてるせいでファイル数膨大になるのが嫌だ Vueは小規模、Angularは中規模以上
という感じがしたな。手間的にも。
Angularの方がアプリ的な作りとして
しっかりしててわかりやすいかな
ただちょっとしたことですぐに動かなくなる
Vueもちゃんとルール決めして作れば
短期間で作れるしよいね
Reactはやってないからわからん…教えて Angularを開発しているGoogleチームの敵は
別のGoogleチームかもしれない
Google、FlutterアプリをWebアプリへ変換する「Hummingbird」発表
https://www.publickey1.jp/blog/18/googleflutterwebhummingbirdwebdartflutter_live_18.html Reactで静的サイト作るならGatsbyが素晴らしいよ
モダンなSSR、Webpack、GraphQL対応してるし
かっこいいサイトのテンプレートも充実してる
Reactの勉強用として使い始めたけどGatsbyハマったわ SPAフレームワークでSSRってなんか目的を見失ってませんか?
従来のMVCフレームワークでいいじゃないですか イエス。サーバーサイドフレームワークとjQueryで十分 お前ら例に漏れずgatsbyの「SSR」を勘違いしてトンチンカンなこと言っててワロタwwwww
ヒント: gatsbyは「静的」サイトジェネレータ >>155
サイトのテンプレートって
デモサイトどこかにある? >>161
ありがと
トップページからだと
ここまでたどりつけんかった 今大手サイトのフレームワーク利用状況ってどうなんだっけ?
ニコニコ、pixiv、Amazon辺りがReact使ってた気はするけど Netflix。サービスページほぼすべてに採用。
一部ランディングページから軽量化のためにlodashなどとともに取り除かれた際はアンチから「NetflixがReactやめたw」とデマ流されるほど。
あとTwitter。
https://www.infoq.com/jp/news/2017/02/twitter-react-mobile-stack
あと当然Facebook。 そのサイトで使ってるかどうかはfirefoxのプラグインとかで分かるけどたしかにトップページにはないみたい
利用規約では検知した 任天堂SwitchのeShopがReact
ZOZOがVue
という記事を読んだことある 大手サイトじゃなくて、大手企業のフレームワーク利用状況を知りたい
特に自社で何かしらのサービスを提供してない会社の
ほぼゼロであることはわかっていってますがなにか?w JSF使ってます
SPAはオモチャみたいなアプリにしか使えないから大手企業は採用しないと思います twitterはともかくfacebookおもちゃかあれ?
すごいアプリ製作してるんだね。 Amazonって欲しいものリストの部分だけReact入ってるみたいだね WappalyzerっていうChrome拡張入れるといいよ
サイトでReact使ってたら素晴らしいしReact+Gatsby使ってたらナカマだし、違った見方でネットブラウジングできる
jqueryのみだとダサってなる(実際サイトの用途にはよるし使ってる人ごめんなさい)
他にも使ってるサーバーとかDBとかWordPressだ〜とかわかるよ vuetify使ってる人いない?
公式のマニュアルが説明不足で全然わからんのだけど、
どこで情報仕入れてる?
formのresetボタンすら動作しない
もっと見やすくてわかりやすいUIはないものか vuexに依存しないvueコンポーネントってどうやって作ってる?
頑張ってpropで渡すか、コンポーネントextendsしてメソッドオーバーライドするしか
思いつかないんだけどみんなもっと上手いことやってるの? 全般的にUIコンポーネントって部品の説明不足だよな >>174
書き方が悪かったかも知れん。現状でもvuexは使ってる。
例えばvuexにstore/user/flowerFlag:boolean がある
flowerFlag === trueなら ボタンコンポーネントの色を花っぽくにするって時にどうしてる?
1.propでflowerFlagを渡す
2.コンポーネント内にgetColoer()メソッド作って個別にextend/overwriteする
この2つの方法以外にももっといいやり方あるんかな? flowerFlagって名前が気に入らない
何をするフラグなのかさっぱり分からない
useFlowerTheme: boolean とかにしろや ■ このスレッドは過去ログ倉庫に格納されています