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

**デフォルトの名無しさん** (ｱﾒ 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

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