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/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

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

2019/03/04(月) 12:30:51.83

>>668
横から質問なんだけど
デザインが決まってない状態で
フロントエンジニア（プレゼンテーションロジック担当？）って何の作業するの？

2019/03/04(月) 12:35:52.25

>>671
詳細なデザインがないと出来ないこと以外の全部

**デフォルトの名無しさん** (ｱﾒ MM3b-Z6MB) · 2019/03/04(月) 13:01:07.29

ハハハ

2019/03/04(月) 14:17:57.52

>>671
あのさぁ、かっこいい見た目なんか作らないでいいから
動きが必要なところをさっさと作るとかあるでしょ

2019/03/04(月) 14:49:51.44

見た目のない動きか
文字列かな

2019/03/04(月) 15:18:45.40

かっこいい見た目といったのに
全く何も表示がないものと解釈するのか
馬鹿なのかな

2019/03/04(月) 15:36:50.66

僕のおちんちんも激しく動きます

2019/03/04(月) 16:46:58.11

>>672 >>674
例えばこんな感じを想定して作り始めて
https://i.imgur.com/kwOSd6U.jpg
デザイナからこれが来たら割と手戻ったりしない？
https://i.imgur.com/Q9xaols.png

他の例
https://i.imgur.com/gb8zhRE.jpg
https://i.imgur.com/EDbn41B.png
https://i.imgur.com/H1gSLxX.jpg

2019/03/04(月) 17:04:13.55

>>678
そういうのは手戻りではなく設計不足というのですよ

2019/03/04(月) 17:14:40.72

>>679
設計の段階でデザインがほぼ固まってから実装ということなら
デザイン→実装の直列作業で
同時進行じゃない気がするんだけど・・・

2019/03/04(月) 19:04:00.56

デザインとロジックの分業は分かるが
結局フロントロジックとバックロジックの分業なんてしたって無駄なんだよ

2019/03/04(月) 20:44:55.78

>>678
おれこのくらい他人のデザインも不要だしモックなくても頭の中でデザインできるからすぐにコーディングできるわ
なんなら数パターンのデザインを一つのソースで作ることもできる

さっきから言ってることだが、フルスタックはデザインもコーディングも「同時進行」で作業するんだよ
デザインしてからコーディングをやるんじゃないから

2019/03/04(月) 21:38:41.81

SPAじゃなくPWAってこれから流行るの？

2019/03/04(月) 22:18:18.82

>>678
手戻りが出ないように最初のざっくり方針を決めとこうな

2019/03/04(月) 22:19:37.95

>>682
> さっきから言ってることだが、フルスタックはデザインもコーディングも「同時進行」で作業するんだよ

同時進行で作業するが、一人でやるから時間が2倍かかるって話なんだが？

2019/03/04(月) 22:20:44.65

どうしてもデザインが完成しないとコーディングが出来ないって言うなら、

相手にデザインさせている間、自分は違う仕事をやればいいだけだし

2019/03/04(月) 22:42:20.42

>>685
何度も言うのめんどくせ
まあわからん奴にいくら言ってもわからんからどうでもいいや

2019/03/04(月) 22:51:08.65

人数増えた分だけ作業が速くなると錯覚してる大企業体質に何言っても無駄だと思うよ

2019/03/04(月) 23:01:25.29

なんで極論同士で争うんだ？
開発規模(複数プロジェクトの合計の規模も含む)が大きくなって一人じゃできないから分業が発生するってだけだろ？
みんな一人でやった方が効率がいいとわかってるし、一人じゃ限界があるってわかってるんだよな？

2019/03/04(月) 23:05:47.91

人数が増えるほど、すり合わせコストが掛かるから、単純な掛け算にならない。
意思疎通・教育コストが掛かる

仕事量 = 単位仕事量 * 人数 * (1 - すり合わせコスト)

1 - すり合わせコストが、人数が増えると、
0.8 から、0.5 まで、ドンドン下がっていく

工場で言う、段取りコスト・間接作業。
直接作業をするのに必要な、作業

だから、プログラマーのように難しい仕事は、単純に人数を増やしていけない。
人数効果があるのは、すごく簡単な単純作業の場合だけ

こういうのは、中小企業診断士・MBA のテキストに書いてある

2019/03/04(月) 23:06:55.42

重要なのはいかに効率よく分業するかだろ？

**690** (ﾜｯﾁｮｲ ff2c-Im2K) · 2019/03/04(月) 23:11:34.47

でも複数人数の良い点も多い

視野が広くなる。
一人じゃ気付かない事に、気付く

教育にも良い。
ペアプログラミングは、非常に効果的

一見、損に思うけど、
教育効果により品質が向上して、後で十分に取り戻せる

**デフォルトの名無しさん** (ｱﾒ MM3b-Z6MB) · 2019/03/04(月) 23:24:38.44

Web制作板行けやカス

2019/03/04(月) 23:32:05.12

>>692
辞めなければな！

2019/03/05(火) 05:46:36.86

>>694
そういう発想だから辞められるんだよ。

2019/03/05(火) 07:55:43.10

>>684
「デザイン」の定義が食い違ってるのかもね

それはデザインを先に固めるって言うんだ
同時進行してない

デザインは設計だと考えてるからこそ>>668に疑問を持ったわけ

こういったこと
https://uxdesign.cc/designchallenge-cd7bdb589855

2019/03/05(火) 11:20:44.07

>>696
ざっくり方針を決めただけなので
デザインは変わることがありますが
デザインを先に固めています。

と言いたいの？

**デフォルトの名無しさん** (ｱﾒ MM3b-Z6MB) · 2019/03/05(火) 11:43:17.86

「ざっくり方針決める」だけで給料もらえて納期遅れを下流のせいにできるなんて……

……なんていい仕事なんだ！俺がやりたい！

2019/03/05(火) 12:25:43.27

ウェブ系は楽だよなぁほんと
モダンで便利なエコシステム
ハイスペックな開発機
クラウドへのアクセスもサクサク
厳しい社内統制もなくゆるい現場
シンプルで簡単なドメイン
10年物のレガシーなんて無い

2019/03/05(火) 12:41:39.55

>>699
Java6「現役やで」

2019/03/05(火) 14:48:04.00

>>698
わざと？必死だね？

ざっくり方針を決めるのは、デザイナーとプログラマーで
並行して作業を進められるようにするためだよ。

でないと一人で作業することになって、2倍の時間がかかる

2019/03/05(火) 16:44:18.98

>>699
フロントはどんどん楽になるよね。やってて楽しいのがweb系。ただサーバサイドやDB、ネットワークはレガシーも残ってるよ。

2019/03/05(火) 20:46:44.51

>>701
その2倍ってのがおかしいって

2019/03/05(火) 23:25:03.26

たしかサーバーサイドJavaでJSPのテンプレートエンジン廃れたよね？
htmlに<if>とか<for>とか変なタグを入れるなって流れになったはずだけど
最近はJavaScriptで同じようなことしてるよなあ

2019/03/05(火) 23:42:35.99

それはJavaが廃れたんであって、Javaの世界じゃあ普通にやってるよ。

2019/03/06(水) 01:11:22.98

>>704
JSPはJAVAソースコードを出力する為のテンプレートであって、HTMLそのものでは無いよ。

JSP→解析→JAVAソースコード→コンパイル→classファイル

このclassファイルが、外部からのリクエストに対してHTMLを出力して、レスポンスで返してるんや。

んで、出力されたHTMLには<%if( 条件式 ){%>なんて文字列も出てこないよ。
そもそもこの<%%>タグはHTMLの為じゃなく、JAVAソースコード生成の為に使われるから出てくるわけ無い。

2019/03/06(水) 01:43:49.00

Spring Boot のテンプレートエンジンは、Thymeleaf とかだろ

2019/03/06(水) 08:55:10.29

そういう意味ならJSFがある

2019/03/06(水) 22:12:48.11

スレ違いかもしれないけど、たまには気分転換にvueとかreactとかの話題はどうかな？

2019/03/06(水) 23:50:49.60

Reactの仮想ＤＯＭとかいうのが未だに分からん
HTMLをオブジェクトの木構造にしないで文字列のままで握ってるってことでＯＫ？

2019/03/07(木) 02:22:49.29

>>710
違う。
メモリ上に持つ実DOMの劣化レプリカ。
そして利用者は実DOMはイジらず、劣化レプリカの方をイジる。
angular react vueなどの仮想dom系のライブラリが劣化レプリカの変化から、最小の実dom操作を計算して適用。
昔は人がやってた仕事がライブラリに委譲された格好。

2019/03/07(木) 02:44:23.97

HTML のタグを javascript のオブジェクトで単純に表現しただけのもの。react であれば、createElement 関数で生成されるオブジェクトのことになる。で、そのインスタンスの変化に合わせて実際の HTML に反映してくれる。

2019/03/07(木) 03:07:16.07

>>711
HTMLElementじゃないけど似たようなのをツリーで持ってるのか
HTMLElement.clone(true)でページ全体のクローンを作って、
それをＤＯＭ操作してからdocument.documentElementに差し替えるのかと思ってた

単純にFragment使ってＤＯＭ操作するより速いのか気になる

2019/03/07(木) 07:22:52.72

やってることは実DOMの変更をバッファして
変更タイミングをいい感じでやってくれてるってことじゃないの？

2019/03/07(木) 08:43:40.11

>>713
> 単純にFragment使ってＤＯＭ操作するより速いのか気になる
速くならない

× 仮想DOMは速い
○ 仮想DOMは遅くならないように頑張っている

速い速い詐欺のどこが詐欺かって言うと
何より速いかを書いてない所

仮想DOMの最初の発想は、実DOMと同じような内容をメモリ内に保持しておいて、
仮想DOMから実DOMをすべて生成しよう！という発想

もともとはゲームから来ている発想。
ゲームは1秒間に60回ぐらいメモリ内容を元に画面全体を書き換えている。

変更があるたびにDOM全体を書き換える。
当然DOMでそんなことやったら遅いって思うよな？
そこで差分を計算して変更があった所だけ書き換える

つまり

○ 仮想DOMは画面全体を書き換える発想だが、差分だけを書き換えるから、画面全体を書き換えるより速い

と言ってるだけ

そもそも実DOMを操作しているときは、必要最小限のものしか書き換えないので
仮想DOMが差分（必要なところ）だけ書き換えるといっても、それ普通ですよね？という話でしか無い。
むしろ仮想DOMは実DOM操作よりメモリ使用量は増えるし、差分計算の分遅くなってる。

**デフォルトの名無しさん** (ｱﾒ MMdb-F75Q) · 2019/03/07(木) 08:54:40.49

実DOM操作自体の速度は当然変わらない。
人が書くか仮想DOMライブラリがやるかの違いだけ。
ライブラリは実DOM操作の回数を減らすため仮想DOM持って計算頑張ってるだけ。
「DOM操作が速くなる」とか言ってるのは全部嘘。

2019/03/07(木) 09:00:44.74

> 人が書くか仮想DOMライブラリがやるかの違いだけ

人は「全体の中から差分を計算してそこだけ書き換える」
なんてことはやってないですよ。

人はある処理の中でDOMのどの部分を書き換えたいかを
知っているので、必要最小限のDOM操作しか変更しない
（クソプログラマなら全部消して作り直すとかいう無駄してるかもしれんが）

その全部消して作り直すっていうのをやろうという発想が仮想DOMで
遅くならないように差分を計算して、必要最小限のものだけ変えよう。というふうに
自分で遅くしておいて、自分で改善した（速くした）って言ってるだけなんです

2019/03/07(木) 09:10:38.72

速度に関しては実dom直接操作よりは遅い。その辺はググればすぐ出るから見とくと良い。ただおかけでリアクティブという大きなメリットを手に入れた。ページ切り替えさえ差分更新してspaも出来る訳で、レスポンスは全体的に向上する。