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/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も出来る訳で、レスポンスは全体的に向上する。

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

人はある処理の中でDOMのどの部分を書き換えたいかを
知っている（担当の頭の中にある）ので、必要最小限のDOM操作しか変更しない。

人の頭に依存しないように機械的に
最小限のDOM操作を特定・適用までやろうとしたのが仮想DOM系ライブラリ。

人が脳のリソース使ってやるか仮想DOMライブラリが自動でやるかの違いだけ。

2019/03/07(木) 09:27:16.66

ここで忘れてはいけないのは

> ただおかけでリアクティブという大きなメリットを手に入れた。ページ切り替えさえ差分更新してspaも出来る訳で、レスポンスは全体的に向上する。

リアクティブは本当に必要なのか？
SPAは本当に必要なのか？

ということ

世の中の多くのソフトウェアはリアクティブなんか使っていない。
それでまともに動く製品を作れている。

SPAもそうだ。ユーザーにとってはシングルページだろうが、マルチページだろうが関係ない。
シングルページだとページごとに分担して開発するのが難しくなる。
マルチページなら、ページごとに別の人が担当して開発するのが楽である。

2019/03/07(木) 09:52:31.84

リアクティブのメリットは複雑な入力フォームが分かりやすい。pc購入する際のカスタマイズ画面なんかが良い例。以前と比べて工期の短縮できて保守が凄く楽。部分的な導入も出来るからvueで試せば分かる。フォーム周りは圧倒的にリアクティブが良い。

2019/03/07(木) 09:57:57.50

>>721
リアクティブがやりやすいんじゃなくて、
以前のやり方がだめだっただけでは？

2019/03/07(木) 10:01:54.73

>>721
その例ってこんな程度でいいの？

https://www.dell.com/ja-jp/shop/serviceselection/cai401cspgmt04oo3ijp?selectionState=&;cartItemId=
https://www.dospara.co.jp/5goods_pc/pc_bto.php?h=d&;f=d&m=pc&tg=13&mc=8374&sn=3619&vn=1&lf=0

2019/03/07(木) 10:43:49.16

>>722
ある入力に対して別の複数の要素が動的に変更される場合、リアクティブだとcomputedプロパティで自動的にuiに反映されるよう設定するのがとても楽。これjqueryだと面倒だしミスも増える。

>>723
この程度って。。結構大変だよ。条件も頻繁に変わるだろうし。

2019/03/07(木) 10:54:23.39

>>724
やっぱり使い方がわかってないだけだな

ある入力に複数の要素が動的に変わるならば、
その要素の親に、クラスをつけて、
あとはCSSで、それ以下の要素の表示、非表示状態を切り替えるだけだよ

jQueryだと最低3行。あとはCSSでおしまい。

2019/03/07(木) 11:05:05.80

前から思ってるんだけど（自称）プログラマって
HTML/CSSは嫌いです。出来ません。って人多いよね。

それを毛嫌いしてるというか、CSSなんてデザイナが使うもんだろ
馬鹿にしている感じで、俺出来ないから（笑）みたいな感じで言う。
恥ずかしいと思ってないんだろう。

多くのDOM要素はCSSを使って単に見えなくしたり表示したりすればいいだけなんだが
（プログラマとしての技術力不足で）CSSを使えないから
JavaScriptでいちいち作り出したり削除するしか出来ないんだよな

2019/03/07(木) 16:04:46.19

>>720
要件を勝手に決めつけないでよ
客からユーザーから代弁して喋るなら何だって言いたい放題じゃん

2019/03/07(木) 17:22:06.09

>>727
だったら要件を決めつけてメリットだって言わないでくれ
要件によってはデメリットなんでしょ？

2019/03/07(木) 18:14:20.13

簡単にいい感じのページが作れるのはメリットの一つだと思うけどな。
例えばpythonは成果物に関してはCに対するメリットはないけど簡単に作れるから人気なわけで。

2019/03/07(木) 21:20:18.65

>>728
いやだからさ
「要件次第」で済む話を何度掘り返すのよ
スレタイ見てスレチだと思わないの？

2019/03/07(木) 22:37:46.71

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

クソプログラマは全部消して作り直す
賢いプログラマはどうDOM操作すれば最適かなどという生産性のない仕事をフレームワークに任せる

2019/03/07(木) 22:42:13.25

>>725
管理対象の状態数が増えるのがやだ
状態はできるだけ純粋で論理的な形式で管理したい
という要求がスッポリ抜けてるね

2019/03/07(木) 22:55:10.59

GoogleもこれからPWAで攻めてきそうだけどね

2019/03/07(木) 22:59:25.97

>>732
CSSは宣言型なので、
管理対象の状態数が減るんですよ

2019/03/07(木) 23:00:35.30

>>731
> 賢いプログラマはどうDOM操作すれば最適かなどという生産性のない仕事をフレームワークに任せる

もっと賢いプログラマは、必要なことしかしないんだよ。
Aを変えたいなら、Aだけを変えましょう。ってね

2019/03/07(木) 23:01:50.74

>>734
domの状態数は多すぎるよ

2019/03/07(木) 23:04:15.56

>>735
見えるか見えないかみたいな、ただの論理値を管理したいだけなのに
それをわざわざdom/cssの物理構造に縛られた迂遠な方法で管理するのは確かに賢くないな

2019/03/07(木) 23:09:46.27

まあ本当に賢いプログラマ達はフロントエンドなんてやらないんですけどね

2019/03/07(木) 23:11:14.61

>>738
それは同意

2019/03/07(木) 23:12:46.45

AしたらBを変えたいんですが？

Reactを使うと・・・・

ではBを変数に結びつけましょう。
そういうコードを書き換えます。
そうすれば変数を変えればBも変わります。
おっと待ってください。
そのために変数をSTOREに入れなければいけません。
STOREからとってきて、STOREを更新・・・いえいえいけません
新しくオブジェクトを作るのです。
そのオブジェクトを作るために～
オブジェクトを変更する関数を用意するのです！
その関数を作るための、はい、メッセージが必要ですね。

えぇ、ですからね、AしたらAction Creatorを使ってactionを生成して
Storeに対してactinonをDispatchして、ReducerがDispatchに反応して
actionタイプから今の状態から新しい状態を変更すれば、
ほら簡単にBが変わるんです！

え？普通にAイベントのハンドラでBを変えればいいじゃないかって？

ムキー！

2019/03/07(木) 23:14:47.91

>>737
> それをわざわざdom/cssの物理構造に縛られた迂遠な方法で管理するのは確かに賢くないな

だから、CSSを使うといいですね。
JavaScirptからは親となる要素にクラスを設定するだけなんですよ。
簡単。DOMがどういう構造になっているかなんて関係ない。

あとはデザインを作る人が、その状態でどう表示したいかを作るだけなんです。

2019/03/07(木) 23:23:16.99

fluxの概念を取り入れたらものすごく簡単に状態管理ができる！
って本にもキータにもみんな書いてるんだけど？

2019/03/07(木) 23:23:24.15

>>741
私が管理したいのは見えるか見えないかという2つの純粋な状態なんです
ブーリアンで済むものをわざわざスタイルシートやらクラスなどといった迂遠な方法で管理したくないんです
それはまるで物体から投影された影に干渉して、もとの物体を操ろうとするような愚かなことです

2019/03/07(木) 23:58:03.68

どっちも極端じゃないか？
バインディングならjQueryよりはVueやReact使った方がいいと思うけど、
表示非表示やアニメーションならcss側でやった方がいいと思う。

2019/03/08(金) 00:38:11.11

仮想ＤＯＭとJQueryの世代の重要な違いとして
セレクタやDOM操作を一切したくないという発想があるのではないだろうか
JSXでHTMLをそのまま書くのもセレクタを使いたくないからだろうし

2019/03/08(金) 00:47:24.38

実DOM では、IO 操作が遅い

仮想DOMでは、JavaScript内の操作だけだから、速い

2019/03/08(金) 01:03:32.93

それはHTMLFragmentがあれば事足りる話っしょ

2019/03/08(金) 10:15:11.65

>>743
> ブーリアンで済むものをわざわざスタイルシートやらクラスなどといった迂遠な方法で管理したくないんです

だからセレクタのクラスはブーリアンなんだよ

ある要素に、flagクラスというブーリアン値が
立っているか、立っていないか

2019/03/08(金) 10:16:08.10

>>746
仮想DOMを実DOMに反映させる所で
大幅に遅くなるんだよ

2019/03/08(金) 11:13:41.54

>>725
リアクティブだと一行で終わるよね。単に変数をfalseにするだけ。ミスしようがない。うーん、なんでjQueryやcssにそこまでこだわるかね。みんな散々苦労してきた末のスマートな解決方法が仮想domでありリアクティブなんだけどな。一度試してみたら？食わず嫌いしないでさ。

2019/03/08(金) 11:17:51.39

> リアクティブだと一行で終わるよね。単に変数をfalseにするだけ。

終わらねーよｗ変数みてデザインを変えるコードを書かないとだめだろ

2019/03/08(金) 11:28:53.74

>>751
そう、まさにそこがキモ。ロジックとuiが綺麗に分離されてる。
Falseになった結果どうなるかはuiの管轄でcssやdomとは本来無関係なんだよ。jQueryはそこが分離できない。

2019/03/08(金) 11:35:19.90

> そう、まさにそこがキモ。ロジックとuiが綺麗に分離されてる。

別れてないよ。JavaScriptファイルを編集してもらわないといけない

CSSだと「プログラマの俺は、この要素のクラスを設定するだけです。
デザイナーさん、あとはかっこいいデザインを作ってください！」といえる

デザイナーはJavaScriptファイルを一切触らずに
デザインを作り込むことができる。

2019/03/08(金) 11:40:36.85

jQueryで書く場合はこんな感じだね。

$('.my-component [name="switch"]').change(function() {
　$(this).closest('.my-component').toggleClass('active', this.checked);
});

コンポーネントの中にある名前がswitchのチェックボックスがONになれば
そのコンポーネントがactiveになって、
そのコンポーネント以下のデザインがactive用に変わる

DOMの構成がどうなっているか一切気にする必要がないんだよ。

2019/03/08(金) 13:46:44.51

>>753
デザイナはスクリプトをいじる必要全くない。例えば
<div v-if=“isShow”></div>
というテンプレに対してスクリプトでは、
isShow=false
とするだけ。これだけでリアクティブになる。どっちがミスが少ないか分かるだろう？

2019/03/08(金) 13:50:05.53

すまん途切れた。どっちがミスが少ないか、分業しやすいか分かると思うんだが、どうかね？

2019/03/08(金) 13:55:12.54

> <div v-if=“isShow”></div>

すいませーん、デザイナーさーん。
今度から、v-ifってのを覚えてくださいー。

いままでCSSで表示切り替えしてたでしょー？
それ、今度からやめてくださいねー。

リ・ア・ク・ト。やり方覚えてくださいね。
やり方変えたんですよ。こっちのやり方にね。
え？他にも色々ありますよ。勉強してくださいー。

2019/03/08(金) 13:57:57.43

Javascript(Data/Model) - Javascript(UI/DOM) - HTML/CSS
デザイナーが真ん中の層を如何にやるのかという話だろう
HTML内にv-bindとか属性で埋め込むのもJQueryを書かせるのも同じこと
仮想DOMのフレームワークによって真ん中が無くなったとは言えないだろうし

2019/03/08(金) 14:02:22.95

jQueryはプログラマが使って、
イベントに反応してクラスを変更するだけなんだよ。

あとはDOMの構造とかCSSとか完全にデザイナーに
任せることができる。

デザイナーはデザイナーの流儀でやれるし、
JavaScriptフレームワークの流儀を押し付けることもない

2019/03/08(金) 14:05:09.01

>>758
HTMLのタグはDOMですか？
CSSで指定する色や配置はUIですか？

2019/03/08(金) 14:11:29.15

>>758
いや随分コード減るぞ。当然ミスも減る。デザイナも楽になる。
>>757
うむ、リアクティブの方が良い事は理解できたようだね。あとは君がデザイナや上司を説得するんだよ。そこは別問題。

2019/03/08(金) 14:12:44.22

jQueryはすべてデザイナーがやるべき
ボタンをクリックしたらどのタグの色が変わるのか、それを知っているのはデザイナーだけで良い

2019/03/08(金) 14:20:09.62

>>761
> いや随分コード減るぞ。当然ミスも減る。デザイナも楽になる。

jQueryの方が少ないですね。

嘘だと思うならこれ同じことを実際に動くのに必要な分、書いてみてください。

[JavaScript]
$('.my-component [name="switch"]').change(function() {
　$(this).closest('.my-component').toggleClass('active', this.checked);
});

[HTML]
<div class="my-component">
　<input type="checkbox" name="switch">switch
</div>

[CSS]
.my-component.active {
color: red;
}

jQuery版の実際に動くコードですよ。
https://jsfiddle.net/eu2wm3tk/

2019/03/08(金) 14:20:12.96

ほらほらだからこうなるって何度も言っただろ
フロントはフルスタックじゃないとこの程度ですら揉めるんだよ
もう一度言うぞ

デザインできないフロントエンジニアはクソ
エンジニアリングできないフロントデザイナーはクソ

お前ら言い争ってる時点で無能だと自覚しろ

2019/03/08(金) 14:20:13.82

>>761
＞いや随分コード減るぞ。当然ミスも減る。デザイナも楽になる。
そう、デザイン側のJSコードは減る。それはたしかだし、データ側JSとの繋ぎかたもはっきりとするね
欠点はHTML内に変なのをたくさん突っ込むのはいかがなものかってことかな

2019/03/08(金) 14:20:59.66

>>762
> jQueryはすべてデザイナーがやるべき
JavaScriptのライブラリなのにデザイナーって意味不明ｗ

ボタンを押したら、ここのタグにこういうクラスがつきます。
って伝えるだけで、あとはそれぞれ作業ができる。

これが分業っていうんだよ。

2019/03/08(金) 14:28:57.63

>>757
どっちかというとその場合デザイナーに必要なのはv-showじゃなくてisShowだから
どういうモードの時変数の設定値を何にすべきかという一覧表があればいいだけじゃね？
てかその辺のコード化はデザイナーじゃなくてフロントエンジニアの仕事だろ

2019/03/08(金) 14:31:25.36

> てかその辺のコード化はデザイナーじゃなくてフロントエンジニアの仕事だろ
フロントエンジニアがHTMLを書くから
分業できないってことなんですよ

2019/03/08(金) 14:33:21.35

>>757
いや、お前がデザイン覚えろよwwww

2019/03/08(金) 14:36:15.92

>>766
プログラマーはcssに書かれたclassの名前まで知らなくていい
その方がデザイナーが変更してもプログラマーが対応しなくて済むだろ？

2019/03/08(金) 14:54:21.66

デザイナーはロジックレスな一枚ずつのhtmlと画像素材のcss作ってりゃそれでいいじゃん