Vue vs React vs Angular

2018/12/21(金) 21:37:36.86

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/02/27(水) 23:30:28.79

>>567
その部品で閉じるような状態ならな。
二つ以上の部品にまたがる状態だってあるだろ。

2019/02/27(水) 23:47:31.09

だから2つ以上の部品にまたがる所だけで良くなるだろ

2019/02/27(水) 23:49:27.29

reduxなんて面倒くさいレベルに入らないだろ
しょぼいシステムしか作ったことがないんだろうが

2019/02/27(水) 23:52:10.20

>>571
その分け方がわかりやすいと俺は思わん。アドホックな部分が増える。

2019/02/28(木) 00:01:04.44

>>572
つまりあなたも面倒くさいって思ってるわけですよね？
このぐらいのレベルなら耐えられるって言ってるだけだし

2019/02/28(木) 00:13:22.40

Reactそのものが面倒だと思う
サーバーサイド一本の人が移動してきて、Reactのコンポーネント一つ任せたら、onclickで画面をエフェクトさせるのが出来ないとブーたれてた
cssと組み合わせてやるんですよと教えたけど、デザインとロジックが分離されてない糞フレームワークだと文句ダラダラ
結局Reduxのところだけ担当してもらった
サーバーサイドだけの人はこの世界では使い道がない

2019/02/28(木) 00:24:32.39

それはサーバーサイドしか知らないのに画面のエフェクトだデザインとロジックの分離だ言う
その人個人の問題なんじゃないかね。

2019/02/28(木) 00:30:03.58

デザインとロジックが分離されてないのは本当だろ

2019/02/28(木) 01:39:22.43

>>574
こんなのより何千倍も面倒くさいプログラミングしてきてるから面倒くさくねえ部類って言ってんの
頭イカれてんのか？

2019/02/28(木) 06:14:57.31

何千倍も難しいって、口調が前にどこかのスレで見たような気がする
確か自称ゲームプログラマーじゃなかったけ

私大文系はクズだのヴァカだの幾何学的計算が出来れば高卒でも理系とか意味不明な発言の人だった

2019/02/28(木) 06:16:05.22

バカじゃなくてヴァカという変な単語を連呼してたので覚えてる

2019/02/28(木) 06:50:50.42

てかテキストボックスのチェンジイベントでイチイチReducerだかDispatcherだかを経由してストアに書きに行くもんなの？
確定ボタン押した時でよくない？

2019/02/28(木) 06:55:29.34

>>577
デザインとロジックが分離してない上にVueみたいにコンポーネントとして独立するわけでもないっていう中途半端さがね

2019/02/28(木) 08:52:57.67

落ち着け、議論を飛び出してケンカになってるぞ。そこまでくると他の人に迷惑だから頼むから我慢して2、3日スレから離れて観て欲しい。

2019/02/28(木) 08:57:16.34

>>583
ビビんなよ。5chではよくあることだろ

2019/02/28(木) 10:41:44.71

ビジネスロジック→Service(バックエンド)
プレゼンテーションロジック→ViewModel(js)
デザイン→View(html/css)

サーバーサイドおじさんはプレゼンテーションロジックがお気に召さないらしい
ビジネスロジックとデザインだけで完結するMVCフレームワークが人気

2019/02/28(木) 10:50:58.35

>>585
そこに、ActionとAction CreatorとReducerとStoreは
どこに含まれるの？って話だよ

アーキテクチャ上、必要ないものが多すぎる

2019/02/28(木) 12:22:34.05

>>586
分類するなら全部プレゼンテーションロジックだろう
SPAとかいう誰得要件のせいでプレゼンテーションロジックが過剰に肥大化複雑化してしまった結果それらが産まれた
従来のマルチページに戻すだけでスッキリ解消される

2019/02/28(木) 12:46:03.68

誰得っていうけどブラウザアプリ作るならSPAの方がUXが劇的に向上するケースが殆どじゃないか？

2019/02/28(木) 12:49:53.87

UXが向上したということにしたいだけでは？
案外ユーザーはシンプルなMVCのほうが簡単で良いと思ってるものさ

2019/02/28(木) 13:05:42.47

シンプルなMVCかどうかの判別ってユーザーからできるの？ユーザーってもしかして顧客のこと？

2019/03/02(土) 15:08:24.35

年明けてから二ヶ月経過したけどなんだかんだ書籍出てるな
売れてるんかねぇ

動かして学ぶ！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

2019/03/02(土) 16:45:37.50

ウチの会社でReactのアプリを独自UIの新規開発からロジック周りまで全部できるPGは一人しかいないわ
オフショア入れて百人以上PGいるけど、みんなFlexbox使って自分でUI書けませんとか、エフェクトのアニメーションを自作できませんとか、htmlとcssで躓いてる
デザイン系が得意なPGだと今度はDBやAPIが良く分かりませんという風になる

デザインとロジックの分離が不完全なので不器用な奴には使えない
結局Reactのアプリ制作はその一人が設計構造を考えて何人かで分担して作ってる
その一人がいなくなったら改修も容易ではない

2019/03/02(土) 16:52:47.42

>>592
そう最低限なんでもできるリーダーがいなきゃ初期導入すら始まらんもんな
浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる

2019/03/02(土) 17:18:02.29

html5で独自属性を使うときはdata-*で命名する規則になってるけど
どのフレームワークも無視してるのはなぜ？

2019/03/02(土) 20:30:41.54

「知りません」は別に問題無いけど「やってみても分かりません」という奴は
PGとも呼べない半人前だと思う
でも多いんだよなそういうの

2019/03/02(土) 20:45:13.26

>>594
その属性はビルド後も残るの？

2019/03/02(土) 21:47:05.25

>>595
「よく分からないけど動いた」

2019/03/02(土) 21:51:40.27

>>592
フロント、バックエンド、DB、インフラからデザイン、写真加工、キャラ背景画作成、アニメーションまでできる俺は頂点に立てるかな？

2019/03/02(土) 22:08:26.00

>>593
> 浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる

一人でなんでもにできる人が居ないから、分業にしないとだめって話なんじゃないの？
Reactでどうやって分業するのかしらんが。

Reactは設計レベルで分業がし辛いフレームワーク

2019/03/02(土) 22:12:30.11

rails、angular、vueなら分業しやすいとでも？

2019/03/02(土) 22:15:55.89

まあそうだね。

RailsのERBはHTMLに近いから編集してもらえるし、
AngularもHTMLベースだから。

ReactとVueはJavaScriptの中にHTMLの断片が埋まってるから
それを修正して思い通りのデザインを作ってもらうのは無理だろう

2019/03/02(土) 22:24:29.37

フロントとバックは分業したほうが楽だ
どっちもできる人は多くない
いたとしても負荷がかかるから無理強いするとブラック企業になってしまう
それに分業といってもAPI(作る|呼ぶ)だけだろう
難しいとこなんて何もない

2019/03/02(土) 22:33:41.00

>>599
逆に分業じゃなっきゃできんってヤツはわざわざ勉強してまで新しい技術を導入したいとかいい出すヤツは居ないっていう話だよ

>>600
なんでRailsねじ込んできた？

2019/03/02(土) 22:40:19.17

>>594
無視ってどういう意味で？少なくともReactのアプリで使えているけど。

2019/03/02(土) 22:46:45.64

阿部寛のHPを構築するならVue、React、Angularどれがいいの？

2019/03/02(土) 22:48:37.42

>>603
意味がわからん。

仕事を一人でやるのは大変だから、分業できるようにしないと駄目って話なんだが？
新しい技術であっても、それで分業ができればいいんだよ。
というか分業ができる技術を導入するべきだ。

2019/03/02(土) 23:11:54.68

この作業がそんなに難しいことだと思えないんだけど、そんなもんかね。
>ReactとVueはJavaScriptの中にHTMLの断片が埋まってるから
>それを修正して思い通りのデザインを作ってもらうのは無理だろう

2019/03/02(土) 23:27:02.72

>>607
難しいかどうかじゃなくてやり方が全く違う。
普通はHTMLとCSSで作るんだから

2019/03/02(土) 23:47:00.54

>>604
確かにReactの場合はそういう書き方やってないよね
独自属性でもclassName以外はonClickとか元の属性と見ても違和感ないし

>>594が言ってるのはvueのv-modelとかv-onとかv-bindとか
angularでもng-modelとかそういう独自属性があるのを言ってるんだと思う

>>594
ちなみにこの辺の独自属性ってフレームワークのコアライブラリで先に処理されて仮想DOMになるからなのか
ブラウザのデバッガでは存在しないものとして表示されないんだよね
今確認したけど<input v-model="msg" />みたいに書いた場合は
ブラウザのデバッガのElements(Chrome)やインスペクター(Firefox)で見ると<input>に変わってる
BootstapのNavbarなんかでよく使うdata-toggleやdata-targetはそのまま表示されてるから
html5の独自属性とは違う位置付けだと考えた方がいいんじゃないか

2019/03/03(日) 00:02:03.36

Vueの独自属性はHTML5準拠やで
なのでdata-*にしなきゃいかんルールなどない

2019/03/03(日) 00:05:23.14

Chromeのvue dev-toolで確認できるんじゃないの

2019/03/03(日) 00:10:23.09

>>611
それ使えば確かに見れるけどElements側に出ないって事は実DOMとしてはレンダリングされてないって事だと思う

2019/03/03(日) 00:17:30.72

単にインスペクターが無視してるだけだ
正しい属性なんだからレンダラが無視するわけにもいかんだろ

2019/03/03(日) 00:43:00.34

>>609
＞v-modelとかv-onとかv-bindとか
そうそう。data-＊ではないカスタム属性ってEclipseに警告だされてすっきりしない
だから実行時に消えるとしてもhtml5のカスタム属性としてはよくない気がする

本来ならxhtmlの名前空間みたいに*:*でカスタム属性を命名できれば良かったんだけどね

2019/03/03(日) 00:48:58.18

未だにEclipseなんてゴミを使ってるヤツが居ることに驚きなんだか

2019/03/03(日) 01:03:17.04

eclipseww

**デフォルトの名無しさん** (ｱﾒ MM3b-zhdC) · 2019/03/03(日) 01:41:00.89

実際レンダーする前のリソースなんだから
しょうがないんじゃないの
VSCodeとかでVue拡張使えばいいじゃん

2019/03/03(日) 01:46:51.51

>>613
v-ifとv-showの違いとか読んだことない？ないものはないんだよ

2019/03/03(日) 08:28:07.07

なんだ、レンダリング前のテンプレートの話か。ならHTML5に準拠してないのは当たり前じゃん。
たしかにXHTMLならその規格に準拠した中で拡張できるけどHTML5はそれと決別したしねぇ。

2019/03/03(日) 09:22:56.48

>>618
正しくDOMとして評価された後にDOMを消してるだけ
拡張属性は正しく評価されてる

2019/03/03(日) 09:29:26.03

>>620
だからその評価がBlinkやGeckoみたいなレンダリングエンジンで評価されるか
V8やSpiderMonkeyみたいなJavaScript実行エンジンエンジンで評価されるかの違いだって

2019/03/03(日) 10:40:12.55

>>608
そこまで違う作業とあんまり思ってなくて、
やってもらうとしてそんなに反感食うもんかなという風に思ってるのだが。
かなり勝手に思ってるだけだから実際の現場感覚はわからんけど。

2019/03/03(日) 11:31:27.74

UIが劇的に切り替わる様な要件じゃ
デザインとロジックを完全に分離とかそもそも不可能じゃないの

2019/03/03(日) 13:57:28.79

デザイン
プレゼンテーションロジック
↑JS+HTML+CSS
--------
↓API
ビジネスロジック

デザインとロジックを分離するって言った場合、分離するのはビジネスロジックのこと
プレゼンテーションロジックを分離するという意味ではない

2019/03/03(日) 15:00:36.37

WebまではHTML+CSSだけ分離も可能だけど
スマホWebアプリ／スマホアプリになってくると動きも含めてのUXという性質が強くなる

UI用ロジックや機能性まで考慮する「UXデザイナー」と
静止画の用意で終わるデザイナーとの差は大きい

Reactは後者のデザイナーとは相性悪いだろうね

2019/03/03(日) 15:07:16.96

デザインもUIもUXもフロントも全部やればいいじゃん
そもそもなんでできないのか不明
フロント勉強してできるようになったのならデザインも勉強すりゃいい

2019/03/03(日) 16:31:53.99

>>626
何でも一人でやる時間があればそうする

2019/03/03(日) 16:40:53.54

少なくとも難しいから分業してるわけじゃないだろうね。効率の問題。

2019/03/03(日) 17:40:54.12

>>627
時間があればじゃなく、必要だからやらなきゃいけないんだよ
最近世界的にもその必要性が言われてる

>>628
効率悪いから一人でやるべきなんだろ

・フロントデザイナはコーディングできない

・フロントエンジニアはデザインできない。デザイン貰ってもセンスゼロだからコーディングで表現できない

https://postd.cc/the-death-of-front-end-developers/

2019/03/03(日) 17:56:55.95

>>629
開発の規模とか体制によりけりだろ。
例えば自分が所属してるとこだと、フルスタックにやれる人にはデザインなんかに凝ってる時間があったら別の仕事やらせたい。

2019/03/03(日) 18:01:05.79

効率でいうなら複数のサイトを作業区分毎に分業するよりも１サイト１人でやる方がよっぽどいいと思うけどね

2019/03/03(日) 18:15:09.19

>>630
>デザインなんかに

そこの認識なんだよなあ
プログラマはデザインわかってないからデザインなんかにという言葉が出てくる

2019/03/03(日) 18:45:41.76

>>632

2019/03/03(日) 18:47:22.33

>>632
うーん、なんか噛み合わないな。デザインは大事だと思うから分業して欲しいと思うんだよね。そしてエンジニアが楽しいからってデザインに凝るのをよくないと思ってる。

2019/03/03(日) 18:49:08.31

>>632
まぁ例えば
プログラミングレベルが１０で
デザインレベルが５とかの人材の場合
どちらかと言えばデザインよりコーディングやって貰った方が効率いいってはあるんじゃない？

2019/03/03(日) 18:51:32.92

>>631
それは否定しないがその人材を安定して確保しようとするといくら払えばいいの？という話にならないか？

2019/03/03(日) 18:54:01.18

>>636
確保するんじゃなくて育てようって気がないのかね
これだから衰退するんだよ

2019/03/03(日) 18:54:24.45

>>634
デザイン凝るっていう判断はどこでしてるの？
仕様として必要ならやるよな
それともそのフルスタックエンジニアの独断でやってるのか、デザインわかってない奴が決めてるのかにもよる

2019/03/03(日) 18:58:26.46

>>637
育てること考えると余計に分業したくなるだろ。2人を両方フルスタックにするのと、それぞれ専門持たせて育てるのどっちが現実的なのか考えてくれよ。
なんか理想論でマウントとられても困る。

2019/03/03(日) 18:59:34.47

人材云々の話は経営者が判断すべき問題であって
勉強しなくていいとかそういう問題じゃないでしょ

2019/03/03(日) 19:01:59.76

>>592みたいに1人が抜けたらヤバイっていう状況はホントにヤバイから
できるうちに育てた方がいいよホント

2019/03/03(日) 19:03:05.35

>>638
まあそれはそうだ。
仕様がガッチリ決まってるようなデザイン作成ってのを見たことないから故の思い込みかもしれんが、UIとなると必要以上に時間がかかってしまうという思い込みが自分のなかにあるのは確かだ。

2019/03/03(日) 19:04:53.82

>>640
勉強すべきかどうかという話だったの？だとしたら俺も勉強すべきだと思うよ。

2019/03/03(日) 19:08:50.10

ちなみに俺は>>630で体制によりけりと書いてるように、少数のとこならエンジニアのスキルや素質に合わせればいいと思ってる。少数でイキのいいベンチャーとかなら有能が多数派ってこともあるだろうしね。
おそらく仕事量に対する有能人材の割合が重要なんだと思う。

2019/03/03(日) 19:17:40.56

規模が大きくて大人数じゃないと作れませんねぇ、じゃあどこで分担しましょうか？

って考えればいい。

2019/03/03(日) 19:35:22.77

業務系だとそういう場合はレイヤーじゃなくてコンテキストで分けるのが主流だね
レイヤーで分ける企業はかつて見たことない

2019/03/03(日) 20:04:17.44

規模が大きくて大人数じゃないと作れませんねぇ、じゃあどこで分担しましょうか？

え？分担したら効率が悪いだろって？

じゃあ、2人で2ヶ月の仕事を、あなた1人で2ヶ月でやってくださいね。
効率がいいんだから2倍ぐらいやれるでしょ？
でも給料は変わりませんから。

2019/03/03(日) 20:12:49.02

>>647
そうなる
エンジニアスキルはできない奴に比べて何倍も差あるからな
だから給料もそれに比例する

2019/03/03(日) 20:33:30.24

> だから給料もそれに比例する

夢見るのやめとけｗ

2人で2ヶ月も、1人で2ヶ月も
働く期間が2ヶ月なら給料は同じだ

2019/03/03(日) 21:11:25.76

スケールしない作業だと言われればそうかもなとしか言えんな。
できるなら起業しとる。

2019/03/03(日) 21:42:00.62

Rails と、Node.js + Express は、全く同じ。
Bundler と、npm, yarn も、全く同じ。
ERB と、EJS も、全く同じ

Webデザイナーの仕事を楽にする! gulpではじめるWeb制作ワークフロー入門、中村勇希、2018/5/29

Node.js超入門、掌田津耶乃、2017

Junichi Ito (伊藤淳一)
Rails 5.1で作るVue.jsアプリケーション～Herokuデプロイからシステムテストまで～
https://youtu.be/ycOeM2umXkY

2019/03/03(日) 22:00:40.86

>>651
死ね

2019/03/03(日) 22:01:29.06

Heroku使うメリットってなに？

2019/03/03(日) 22:24:37.66

>>649
フロントデザイナーとフロントエンジニアがいても完成しない（デザインをコーディングで実現できないから）
しかしフロントフルスタックエンジニアがいれば何倍も早く完成する

何倍も早く完成するなら給料高くて当たり前
キミはどんなクソな会社で奴隷やってんの？
そもそもキミはフロントフルスタックエンジニアなのか？

2019/03/03(日) 22:34:10.60

寧ろフルスタックエンジニアって中小にこそ居るからな
待遇良くないってのもまぁあると思う

2019/03/03(日) 22:54:37.37

Heroku を使うのは、圧倒的にわかりやすいからだろう

それで、プログラマーの人件費が節約できる

2019/03/03(日) 23:07:55.84

>>654
逆にどういった組織を想定しているのか聞きたい。
1人にやらせた方が効率がいいのは当たり前だが、高給払えるような利益あげてる企業で、そんな体制で運営できるような小さなプロダクト扱ってる会社ってそんなにあるのか？

2019/03/03(日) 23:09:14.73

慣れてしまえばLinuxでの鯖構築なんて難しい事なんもないけどな
特定の会社のインフラに依存するのってなんか怖いよね

2019/03/03(日) 23:14:25.71

>>658
動かすまではともかく、商用運用するとなると結構ハードルあがるから需要はあるんじゃない？
安定稼働、セキュリティ、費用計算、etc.

2019/03/03(日) 23:56:16.49

>>629
デザイナのコーディングは昔からの課題だよな。
ただcssやdomが打てるなら、vueだとかなりスッキリ分業出来ると思うけどな。社内か社外かの方が問題大きい。

2019/03/04(月) 01:06:09.78

>>657
フロントフルスタックがほとんどいないから仕方なくフロントデザイナーとフロントエンジニアを雇っているわけじゃん？
てことは当たり前だけど2人分の給料払ってるのは事実だよな
それが小さな会社だろうが大きな会社だろうが2人分払ってる

しかしそこにフルスタックが入って2人より速く作れて品質高いなら、2倍払っても納期早まるんだから安くなるじゃん

そいつは高給かもしれないがむしろ人件費安くなるんだけど？

2019/03/04(月) 01:26:05.61

>>661
なんか勘違いしてないか？

・早く作れるとしても2倍の速度にはならない。
・なぜなら仕事量は2倍になるから
・でも給料が2倍になることはない
・儲けは会社のもの

2019/03/04(月) 01:28:05.52

・早く作れるとしても2倍の速度にはならない。
・なぜなら二人の仕事を一人でやるので仕事量は2倍になるから
・でも給料が2倍になることはない
・仕事量が増えても納期は伸びない
・儲けは会社のもの

2019/03/04(月) 03:24:32.08

>>662
お前が勘違いしてるだろ

・分業の場合
フロントデザイナーがデザインする
↓
フロントエンジニアがコーディングする
↓
デザインセンスないからコーディングできない
↓
納期遅れる

・フルスタック1人の場合
フルスタックがコーディングとデザイン両方を同時にやる

2019/03/04(月) 06:33:24.10

>>626
＞フロント勉強してできるようになったのならデザインも勉強すりゃいい

これなんかいい勉強法ってある？

2019/03/04(月) 07:36:10.51

2倍くらいはなるだろ上手く行かなきゃ進捗出ない事なんてザラにあるだろうし

>>665
イラストレーターとかが1からUIデザインするサイトとかじゃない限りはCSSフレームワーク使えりゃいいんじゃない？

2019/03/04(月) 09:49:24.20

>>665
自分で言っといてすまんけど、正直デザインセンスっていくら勉強してもなかなか向上しないんだよね
ベースとなるデザインの勉強はそのへんの学校に通いつつ、普段はひたすらUI/UXの情報みたり（海外系サイトおすすめ）して
構造や配色などの知見を増やし、あとはフロントデザイナーに金払って教えてもらう

2019/03/04(月) 11:00:17.97

>>664
それただのウォーターフォールやん
分業は同時進行するんだよ

2019/03/04(月) 11:02:34.38

・フルスタック1人の場合
フルスタックがデザインする（その間コーディングできない）
↓
フルスタックがコーディングする（その間デザインできない）
↓
一人でやるから同時に作業できなくて時間がかかる
↓
納期遅れる

・分業の場合
フロントデザイナーとフロントエンジニアが両方を同時に作業を始める

2019/03/04(月) 12:14:16.79

でも分業するとインターフェースの協議に時間がかかるからそれがなかなかペイできないんだよね