Vue vs React vs Angularat TECH
Vue vs React vs Angular - 暇つぶし2ch262:デフォルトの名無しさん
19/02/13 01:43:28.32 GHq8zte20.net
>>250
>C/C++は開発効率が悪いから。
そんなことはない。メモリリークのことを気にしているなら、デストラクタの
中で解放するように1行書くだけで、ほとんどの場合はリークしないし、
危険なこともない。

263:デフォルトの名無しさん
19/02/13 01:44:23.63 GHq8zte20.net
>>253
ネットはおかしい情報が多い。
ちゃんと本を見たほうがいいよ。

264:デフォルトの名無しさん
19/02/13 01:45:15.56 dfUEINu60.net
>>254
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。

265:デフォルトの名無しさん
19/02/13 01:45:52.84 dfUEINu60.net
ミスったw
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書き忘れた行を探し出すのに苦労することになる。

266:デフォルトの名無しさん
19/02/13 01:46:57.29 GHq8zte20.net
>>253
std や auto_ptr を使うから難しく感じるんだよ。
何度も言うが、それは C++ ではない。これはマジ。
今の std:: 系のライブラリはSmalltalk の信者が作ったものらしい。
C++ の標準化委員会がおかしなことになっていて、もはや、本来のC++
ではなくなってきており、だから、C++が難しいと感じる人が増えている
気がする。

267:デフォルトの名無しさん
19/02/13 01:47:47.99 dfUEINu60.net
>>258
え?お前C++使いこなせないの?

268:デフォルトの名無しさん
19/02/13 01:48:20.38 GHq8zte20.net
>>257
クラスが 100種類の場合、デストラクタは 100 個しかない。
だから、ソースが数10万行あっても、100箇所を調べるだけで済むよ。

269:デフォルトの名無しさん
19/02/13 01:49:31.69 dfUEINu60.net
>>260
調べる箇所が100箇所でも
何を解放し忘れたかを確認するのは大変

270:デフォルトの名無しさん
19/02/13 01:49:40.75 GHq8zte20.net
>>259
日本だと auto_ptr みたいなのが C++ だと思ってる人がいるけど、
勘違いだよ。

271:デフォルトの名無しさん
19/02/13 01:51:15.37 dfUEINu60.net
stdなんちゃらを使わなかったら
バッファオーバーランで脆弱性になるし
それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えた行を探し出すのに苦労することになる。

272:デフォルトの名無しさん
19/02/13 01:51:20.27 GHq8zte20.net
>>261
だから新しい言語を次々に覚えて C/C++ だけは覚えないで過ごしてきたのかな、
あなたは?
数十の言語を覚えるより、C/C++ を1つ覚えるだけが良いと思うよ。徹底的に
それだけを学んだほうが良い。

273:デフォルトの名無しさん
19/02/13 01:51:48.19 dfUEINu60.net
>>262
勘違いとかそうでも良いわw
auto_ptrが使えて、実際にauto_ptrが使われるがC++だから

274:デフォルトの名無しさん
19/02/13 01:53:24.20 dfUEINu60.net
>>264
はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
いろんな言語の機能をキメラのように組み合わせた言語ですから
人によって書き方がぜんぜん違う
auto_ptrを使ってるだって!?これC++じゃないよ!
って言う人がいるぐらいだから
だから開発効率が悪い

275:デフォルトの名無しさん
19/02/13 01:54:19.14 5ssU2x9I0.net
さもTypeScriptが競合であるかのように突っかかってきてるが全く的外れ。
TypeScriptのトランスパイルターゲットはJS。
競合はその他AltJS。
この中では既に天下取って安泰。
C++のコンパイルターゲットはWASM。
競合はRust、Kotlin、.NET、、、どんどん増えるぞw
がんばってな!w
もちろんナマのJSはWeb界のグルー言語として残り続けるよ。
シェルスクリプトが性能を理由に消えないようにね。

276:デフォルトの名無しさん
19/02/13 01:54:36.76 GHq8zte20.net
>>263
そうならないように、C から C++ に進化してきたんだ。
そのために、コンストラクタ、デストラクタの概念が導入された。
それだけでも十分に安全で簡単に書ける。
逆に、std ライブラリは構造が理解しにくいので難しく感じるんだろう。
auto_ptr とか使おうとすると、C++ は一気に煩雑で嫌いになってしまうと思う。
だから、auto_ptr も std:: 系ライブ来も SmallTalk 信者が作ったものであって、
C++ の流儀とは全く異なる異質なもの。C++ で SmallTalk をやろうとするので
めちゃくちゃ複雑になってしまっている。

277:デフォルトの名無しさん
19/02/13 02:22:49.78 GHq8zte20.net
>>266
>はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
C++98 まで覚えれば大体C++の基本は習得できていて、それはそんなに大変
ではない。
・auto_ptr 系は、uniq, smart など沢山ありすぎるので、初心者には難しく、
 下手に使うと、生ポインタより危険かも知れない。これらはかなり後発のものなので、
 最初は覚える必要はない。
・std:: 系ライブラリは後から習得すればよい。

278:デフォルトの名無しさん
19/02/13 03:28:22.27 NEY8ay330.net
>>229
マジで?!
だって公式のデモはiPhoneだと動かへんで?

279:デフォルトの名無しさん
19/02/13 04:23:45.97 VGvE+KfY0.net
>>270
まさかSafariとか使ってないよね?

280:デフォルトの名無しさん
19/02/13 08:13:08.13 a9PctXZid.net
C/C++は使うべき場面が決まってるから他の言語と揉めたりしないと思ってたんだが。

281:デフォルトの名無しさん
19/02/13 09:05:05.03 yk1KGOSba.net
なんかSafariだけで動くwasmの代替品独自に作ってなかったっけ?

282:デフォルトの名無しさん
19/02/13 09:40:07.95 SgfrIpbp0.net
>>271
SafariもWasmはサポートしてると読んだけど、確か。

283:デフォルトの名無しさん
19/02/13 09:53:24.60 GHq8zte20.net
TypeScript って、MSの独自言語なんだよね、知らないけど。

284:デフォルトの名無しさん
19/02/13 10:06:57.83 GHq8zte20.net
>>261
例えば、VS の VC++ で C++ ソースをデバッグモードでビルドして、できたバイナリを
デバッガで実行すると、そのアプリの終了時に、メモリーリークが起きているか
どうかがIDEの Output Pane に出力されるようになっていて、その


285:際、どのソースの 何行目で new TYPEしたオブジェクトが解放し忘れているかが、ずらずらと一覧表示される。 で、その場所が分かったら、多くの場合は、そのポインタをメンバ変数に「持っている(have a)」 class のデストラクタに、1行、delete ptr; と書くだけで、メモリーリークは直る。 例外として、複数のポインタから同じオブジェクトを参照していて、かつ、そのポインタ が永続的にグローバル変数や、何らかのクラスのメンバ変数に格納されている場合には、そこまで 単純には行かない。その場合は、プログラマが頭で考える必要がある。



286:デフォルトの名無しさん
19/02/13 10:21:08.64 uBt5bsN50.net
C++の方向性は最初から何も変わっていない
ctor/dtor, RAII, ムーブとより整理されていっただけ
1985 C++ / TYPE * (Cfront 1.0)
1986 C++ / (実装予定のtemplateなどの説明した文書が公開)
1991 C++ / T* (template可能, Cfront 3.0)
1992 C++ / auto_ptr (STL実装, 例外導入, RAII)
1998 C++ / (最初の標準化, C++98)
2011 C++ / unique_ptr (ムーブセマンティクス, C++11, auto_ptr非推奨化)
2015 Rust / 言語レベルで所有権システムを導入 (デフォルトがムーブ, Rust 1.0)
wasmに絡むとはいえスレチ気味で
しかも古いやり方の話を何レスしてるんだか・・・

287:デフォルトの名無しさん
19/02/13 12:08:13.64 ARXdU5axd.net
>>274
カバーしてる範囲が他のブラウザーに比べてかなり狭い

288:デフォルトの名無しさん
19/02/13 12:29:26.16 PdBWBPPzd.net
このスレ的にはわざわざC++使うんじゃなくてTS→wasmじゃないの

289:デフォルトの名無しさん
19/02/13 13:09:58.06 cmhWA5saM.net
tsnativeかts.net来ないとwasmにはコンパイル出来ないだろ。
せっかくAltJS戦争に勝ってブラウザのjsに対する忖度パワーをすべて手に入れたのにわざわざwasm戦争に参入する必要はないだろ。
c++の構文が古くさすぎ冗長すぎで嫌、rustの構文はキモすぎて嫌と言うならkotlinかc#にすれば。

290:
19/02/13 18:53:44.11 Wb2hS8BD0.net
>>249
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

291:デフォルトの名無しさん
19/02/13 20:56:27.69 kDMwAzYp0.net
VuexとReduxってどっちがムズイの?

292:デフォルトの名無しさん
19/02/13 20:56:51.46 kDMwAzYp0.net
もしかして考え方同じ感じ?

293:デフォルトの名無しさん
19/02/13 21:10:22.40 tuDfzjia0.net
Angularってwikipediaには「フロントエンドWebアプリケーションフレームワーク」って書かれてるけどまさにその通りだよな。javascriptのフレームワークって感じではないわ。
HTMLとCSSとjavascriptの技術を採用したweb�


294:Tイト開発フレームワークって感じ。



295:デフォルトの名無しさん
19/02/13 21:18:15.13 sgtLrhrBr.net
Reduxのほうがムズいけど、これからやるならReduxがいい

296:デフォルトの名無しさん
19/02/13 21:20:44.51 dfUEINu60.net
>>284
JavaScriptのフレームワークって感じではないって意味がわからんぞ。
普通はJavaScript製のフレームワークって意味だろ
○○(何かしらの言語)製のフレームワークなのだから
AngularはJavaScript(製)のフレームワークだ
別の言語なら、〇〇(言語)のフレームワークなんてものが存在するのか?

297:デフォルトの名無しさん
19/02/13 21:31:05.74 kDMwAzYp0.net
angularとReact、Reduxってどっちが簡単?

298:デフォルトの名無しさん
19/02/13 21:51:18.70 jwc/pNVH0.net
学生時代、英単語の暗記が得意だったやつはangular、数学が得意だったやつはreact

299:デフォルトの名無しさん
19/02/13 22:24:48.70 tuDfzjia0.net
>>286
なるほど。
ピュアjavascripで書いたら大変な記述をちゃちゃってやってくれるからスレタイの3つとかjqueryとかはjavascript(の)フレームワークって呼ばれてると思ってたんだがとんだ勘違いだったのね。

300:デフォルトの名無しさん
19/02/13 22:28:21.60 tuDfzjia0.net
冷静に考えれば>>289はライブラリか。

301:デフォルトの名無しさん
19/02/13 22:33:40.93 cHKWNBlR0.net
jqueryとreactは自称ライブラリ、vueとangularは自称フレームワーク
公式サイトのトップを見た限り

302:デフォルトの名無しさん
19/02/13 23:20:38.84 dfUEINu60.net
>>289
それを言ったら、jQueryで使うのはピュアJavaScriptだし
Angularで使うTypeScriptやReactで使うJSXは
ピュアJavaScriptではないけどさ

303:デフォルトの名無しさん
19/02/13 23:44:57.61 D91GFqhb0.net
react捨てるにしてもreduxの考え方は学んどいて損はないよ。

304:デフォルトの名無しさん
19/02/13 23:51:17.06 jwc/pNVH0.net
hook apiとcontext apiデフォで使えるようになるから個人ユースの規模ならredux必要なくなるよ。

305:デフォルトの名無しさん
19/02/14 08:50:15.44 4Gf71Z9ua.net
>>284
Angularと比べるならVueとよりもNuxtと比べる方が合理的だな

306:デフォルトの名無しさん
19/02/14 08:51:45.88 4Gf71Z9ua.net
>>286
コーディングはすべてTypeScriptだけどね

307:デフォルトの名無しさん
19/02/14 09:00:56.39 kPGufiyx0.net
ものは試し
初心者だがAngular勉強してみるわ

308:デフォルトの名無しさん
19/02/14 11:29:40.87 MlsuSDTjr.net
reactにしとけ

309:デフォルトの名無しさん
19/02/14 12:15:57.21 nZj2/pMr0.net
React勉強したがやっぱりウェブサイトの殆どには適用できない技術だな
例えばニュースサイトにReactを導入するメリットはないだろう

310:デフォルトの名無しさん
19/02/14 12:30:22.33 mbps9XCNa.net
融通が利くのはVue

311:デフォルトの名無しさん
19/02/14 12:39:53.13 HVhxRx5Ma.net
MVC+Vueが世界最強

312:デフォルトの名無しさん
19/02/14 12:43:26.84 QUGQ3bvOr.net
>>299
画面遷移がなくなるからメリットはありだろ

313:デフォルトの名無しさん
19/02/14 13:14:13.76 kPGufiyx0.net
Reactにした
Angularバージョンで詰みそうになる感じだし
学習リソース少ないし

314:デフォルトの名無しさん
19/02/14 13:22:31.29 MhXZGfUyd.net
潰しの効かなさを除けばAngularが一番いいと思う。ガッチリした設計な分だけ迷わずに使えるしプロジェクト管理もしやすい。
ただ習得してもキャリア的なメリットが薄そうだから自分で選択する気になれん。

315:デフォルトの名無しさん
19/02/14 13:27:23.06 DBAMfZpK0.net
当分は問題ないだろうけどAngularは将来的にはどうなるんだろうな
同じくGoogle製でしかも競合となるFlutter/Hummingbirdのリリース準備が進んでるみたいだし

316:デフォルトの名無しさん
19/02/14 14:07:13.01 MlsuSDTjr.net
世の中的にはReactが主流

317:デフォルトの名無しさん
19/02/14 14:42:13.00 nZj2/pMr0.net
>>302
画面遷移をなくせなんて誰からも要望来てないんだが?

318:デフォルトの名無しさん
19/02/14 14:43:08.15 nZj2/pMr0.net
VueもReactもAngularも将来性はないよ
近い将来にWebComponentに
置き換わることが決定している

319:デフォルトの名無しさん
19/02/14 14:51:21.14 kPGufiyx0.net
>>308
逆って聞いたけど

320:デフォルトの名無しさん
19/02/14 15:15:15.70 nZj2/pMr0.net
逆って今WebComponentがないのに
今WebComponentを使ってるわけ無いだろ

321:デフォルトの名無しさん
19/02/14 15:35:58.92 MlsuSDTjr.net
>>307
お前バカだろ?
だいぶバカだな

322:デフォルトの名無しさん
19/02/14 18:38:55.70 MhXZGfUyd.net
結局ピュアjavascriptを真面目に身につければOK?

323:デフォルトの名無しさん
19/02/14 18:54:26.61 nZj2/pMr0.net
ピュアJavaScript + jQueryだな
URLリンク(w3techs.com)
73.8%に増加。今でもjQueryのシェアは圧倒的で伸び続けている。

324:デフォルトの名無しさん
19/02/14 18:58:38.20 pR+IykPzM.net
どうせwpだろwww
railsが使われてるからrubyが死にきれないのと似たようなもんwww

325:デフォルトの名無しさん
19/02/14 19:03:26.19 nZj2/pMr0.net
だから「本当にやりたいこと=WordPressでできる範囲のこと」なんだから
フレームワークもいらんし、どうせjQuery使われてるからjQueryでいいってことなんだよ

326:デフォルトの名無しさん
19/02/14 19:04:04.42 nZj2/pMr0.net
需要と供給
いくらすごいことができるようになっても
求められてないんだよ。

327:デフォルトの名無しさん
19/02/14 19:07:18.73 pR+IykPzM.net
間違ってないと思うがなぜwpのスレに籠らずこんなスレ来て啓蒙活動してるのかw
他人が勉強するのが不安で怖いんだろ?ww
そんな女の腐ったようなセコい性格だからいつまでたっても童貞なんだよwww

328:デフォルトの名無しさん
19/02/14 19:08:13.46 nZj2/pMr0.net
wpを持ち出してきたのお前じゃん?
頭大丈夫か?

329:デフォルトの名無しさん
19/02/14 19:14:23.47 pR+IykPzM.net
論理に破綻はないが?wp圧倒してるの事実だし。現状に安穏としたいならしてれば?俺らは勉強するから、ってこと。図星刺されて恥ずかしくなっちゃったのかなw
お前のやってることってテストの前に勉強してるやつをガリ勉・ダサいとレッテルはって集団でみんなで堕落しようとセコい行動する女みたいなんだよw
男でそれじゃダメだよ。

330:デフォルトの名無しさん
19/02/14 19:14:29.36 fSoz/vTj0.net
angularは勧めんな。railsもそうだがああいう丸ごと全部なものになれると
それ以外なんもできなくなる。

331:デフォルトの名無しさん
19/02/14 19:17:17.50 MlsuSDTjr.net
wpしか使えない底辺カスは死ぬまでjquery使ってろ

332:デフォルトの名無しさん
19/02/14 19:20:32.23 nZj2/pMr0.net
>>319
> 論理に破綻はないが?wp圧倒してるの事実だし。
wp圧倒してるの事実である根拠は?
事実だとしてそれがjQueryにどれだけ影響してるの?
wpのシェアなんてウェブ全体からすればたいしたことないじゃない

333:デフォルトの名無しさん
19/02/14 19:21:17.93 DfU+cSuaa.net
新しいフロントフレームワークが出た時に丸ごとすげ替えれるならなんでもいいよ
俺はMVCがベストバランスの正解だと思うがね

334:デフォルトの名無しさん
19/02/14 19:22:01.34 nZj2/pMr0.net
backboneを勉強した人は無駄になった。
Angularも1系を勉強した人は無駄になった。
jQueryは登場してから13年使われ続けている。
これが現実やで

335:デフォルトの名無しさん
19/02/14 19:25:35.68 OfZpiUzn0.net
wpの保守死ぬほど大変だけどな。てかフレームワークとwpは全く別物だろうよ。ブログのフレームワークと言えない事も無いが。

336:デフォルトの名無しさん
19/02/14 19:38:24.66 pR+IykPzM.net
>>322
ビルトインされてるよ。テーマによってはwpビルトイン版と競合を避けるため他のバージョンを別に導入する場合もある。
そしてwpのシェアはcms中では60%、全Web中では33%
だからwp除くならjQueryは40%程度だなw

337:デフォルトの名無しさん
19/02/14 19:43:27.31 nZj2/pMr0.net
> だからwp除くならjQueryは40%程度だなw
圧倒的シェアじゃないか!

338:デフォルトの名無しさん
19/02/14 19:50:59.92 pR+IykPzM.net
最初からシェア小さいとは言ってないだろw
増加してるのはwpのシェア増につられてだろうと予測しただけ。
おそらく合ってるなw
jQueryバカが威張るのは滑稽。

339:デフォルトの名無しさん
19/02/14 20:14:34.64 MlsuSDTjr.net
jqueryしか使えないバカが多い
バカのくせにバカを賛美している

340:デフォルトの名無しさん
19/02/14 20:27:26.21 nZj2/pMr0.net
所で仮想DOMのアプローチって本当に速いのかな?
仮想DOMはDOMを触らないって言うけど、
結局最終的な形にするためにDOMを構築するでしょう?
そのときに要素を作ったり削除したり
そんな事しないで、CSS使って要素を隠したり表示したほうが速いない?
jQueryはDOM操作が得意なわけだけど、DOMを作ったり削除したりするんじゃなくて
classを変更して見た目を変えることで擬似的にDOMが表示されたり消えたりするって
いうのがベストプラクティスだと思ってる。この場合はDOMの構築をやらないので
仮想DOMのアプローチよりも速いんじゃない?

341:デフォルトの名無しさん
19/02/14 20:30:52.74 RyxU72PZ0.net
cssのが早いのは当たり前だろ…
お前、こういうスレ来るのは10年早いよ。
真摯に勉強しろやマジで。スレタイ読まずに荒らしてないでさぁ

342:デフォルトの名無しさん
19/02/14 21:08:57.94 kPGufiyx0.net
VuexとReduxって難易度変わらない?

343:デフォルトの名無しさん
19/02/14 21:10:34.79 nZj2/pMr0.net
どちらも単に面倒くさいだけじゃないの?

344:デフォルトの名無しさん
19/02/14 21:11:54.44 nZj2/pMr0.net
正直Reduxとか使うよりも、カスタムイベントを使ったほうが楽だと思う

345:デフォルトの名無しさん
19/02/14 21:25:16.30 MlsuSDTjr.net
マジでお前来るなよ
スレチクソキチガイが
テメーの妄想なんかどうでもいいんだよ
勝手にjqueryスレ立ててそっちでやれバーカ

346:デフォルトの名無しさん
19/02/14 21:53:19.44 nZj2/pMr0.net
だが断る

347:デフォルトの名無しさん
19/02/15 07:48:37.76 ayjwUPM20.net
>>304
そういう観点ならNuxtでもいいと思う

348:デフォルトの名無しさん
19/02/15 08:12:30.75 +Jrl5jTr0.net
Vueが最強なんじゃね?
仕事ならReact

349:デフォルトの名無しさん
19/02/15 08:39:56.97 5wBlw8GS0.net
仕事でもnuxtつこてるわ
angularとreactは敷居が高め
他のメンバーが嫌がるのよ

350:デフォルトの名無しさん
19/02/15 08:56:20.31 EFNDTiKGa.net
そういやVueでもjsx使えるとかVueの和書の一番厚い本に書いてあったな

351:デフォルトの名無しさん
19/02/15 09:54:44.63 Nwwq6bubM.net
reactのために作ったってだけである種類の関数の入れ子をxml風に記述できるというだけの独立した仕組みだからreact関係なく使えるよ。

352:デフォルトの名無しさん
19/02/15 13:09:17.41 YF3F5Mzod.net
>>337
そうなのか。興味湧いてきたのでちょっとNuxt試してみます。

353:デフォルトの名無しさん
19/02/15 19:10:03.96 s9lB6bHor.net
ReactやVueやる奴らは当たり前だがフロントデザインやUXできるんだよな?

354:デフォルトの名無しさん
19/02/15 19:14:19.75 uyGcnsGR0.net
>>330
仮想domのメリットは最終的にはリアクティブ。その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、リアクティブでは単に変数をfalseするだけになる。
複雑な入力フォームも恐ろしく作りやすくなるから、一度vueの公式見るといい。

355:デフォルトの名無しさん
19/02/15 19:47:12.24 fQG3bb7RM.net
勉強しなくていい言い訳探しに来てる奴に何言ってもムダ

356:デフォルトの名無しさん
19/02/15 21:10:18.28 Tr9ixmy70.net
>>344
> その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、
あー、それがお前の根本的な間違いなんだよ。
お前っていうか、世間一般?使い方間違えてるんだよね。
そういうDOM操作なんてしません。
jQueryでは単にHTMLのclassの(例えば)activeをdeactiveにするだけになる。
複雑な入力フォームも作れるし、classを変えるだけで全く違った表示にすることができる
そのフォームを使ってる間JavaScriptは全く使用しない。
デザイナが自由に好きなデザインで作ることができる。
そしてjQueryではclassの値を変えるだけになる。

357:デフォルトの名無しさん
19/02/15 21:28:10.41 LmytZ3o2d.net
>>343
むしろそっちのが専門や

358:デフォルトの名無しさん
19/02/15 21:31:08.33 fQG3bb7RM.net
jQueryのhideはdisplay: noneだろ。
active、deactive(笑)に至っては意味不明。
jQueryではそういうときはactiveクラスをtoggleClassで付けたりはずしたりするんであって、active外してdeactive(笑)つける、deactive(笑)外してactive付ける、なんてマヌケなことはしません。
やっぱりね、自分が勉強したくないもんだから他人の足を引っ張ろうとするような女の腐ったような童貞は自分が上げてるライブラリもまともに使いこなせないwwミジメ過ぎwwwww

359:デフォルトの名無しさん
19/02/15 21:33:20.85 kkRd+/gL0.net
jQueryからreactならそこまで乗り換えコストかからんと思うけどな。

360:デフォルトの名無しさん
19/02/15 21:46:27.22 s9lB6bHor.net
>>347
合格

361:デフォルトの名無しさん
19/02/15 21:48:11.36 Tr9ixmy70.net
>>348
ん?お前俺が言ったことと大差ないよな?
activeクラスを 付けるor 外す ことで表示の切り替えを行うから
そんなことでDOM操作なんてしないってことだろ?
でそれが>>330で書いたことにつながるんだよ。
仮想DOMは最終的にDOM操作をするから遅くなるが、
jQueryではCSSによって見た目を切り替えるだけだから速いってこと

362:デフォルトの名無しさん
19/02/15 21:51:50.27 zC296ldL0.net
いやDOM APIを通じて操作するんでしょ

363:デフォルトの名無しさん
19/02/15 22:06:11.07 Tr9ixmy70.net
>>352
そりゃVueやReactだって最終的にはDOM APIを通じて操作するよ
ただしその操作の内容を、DOM要素の削除や追加じゃなくて
クラス名を変えて表示を切り替えるだけにすると速いってこと

364:デフォルトの名無しさん
19/02/15 22:07:28.91 NXuVhChr0.net
Angularの方が難しいの? Reactの方が自由に構成決めたりコーディングしたり出来る分、
自分で決めなきゃいけない事が多くなって逆に難易度高いって聞いたけど。
Angularの方が環境構築も規約も全部世話してくれるから楽だって聞いたからAngularから入ったんだけど。もしかして騙された?

365:デフォルトの名無しさん
19/02/15 22:10:09.24 I8iEDAq80.net
>>354
英語などの単語の暗記が得意だったならangular
数学が得意だったならreact

366:デフォルトの名無しさん
19/02/15 22:14:49.66 fQG3bb7RM.net
さすがjQueryバカ。伊達に名前にバカって付いてないな。
クラスの付け外しも厳然たるDOM操作。
そんなことも分からないとは…使われるjQueryもかわいそうだ。

367:デフォルトの名無しさん
19/02/15 22:20:03.31 I8iEDAq80.net
そもそもjQueryのコア機能はDOM操作なんだが…
DOM操作しないならjQuery要らねーよ。
贔屓のライブラリの存在理由否定してどうする。

368:デフォルトの名無しさん
19/02/15 22:22:45.45 Tr9ixmy70.net
>>357
DOM操作のうち、class属性を変えるだけにするということ
そしてCSSでブラウザにネイティブ処理させるから速いんだよ
要素の追加や削除は必要最小限にするのが鉄則

369:デフォルトの名無しさん
19/02/15 22:29:21.05 Tr9ixmy70.net
>>354
自分がやりたいことと、フレームワークが提供してくれる機能とのバランスだよ
業務アプリみたいに複雑なインターフェースのアプリをガッツリと大量(=画面数が多い)に
作らなきゃいけないならAngularがいいだろうけど、そうでもないなら
Reactで適当にデータ管理してやれば楽ってこと
Angularはいろんなことを面倒見てるけど、そこまでやることないじゃん?って思うならReact
更に言うならウェブサイトみたいなものはjQueryで十分ってこと

370:デフォルトの名無しさん
19/02/15 22:30:21.14 fQG3bb7RM.net
> ネイティブ処理させるから速いんだよ
だったらネイティブのDOM API使うわw
You Don't Need jQuery!
URLリンク(blog.garstasio.com)

371:デフォルトの名無しさん
19/02/15 22:33:24.44 Tr9ixmy70.net
>>360
それもバランスの問題だな。
そこ見ても分かるだろ?いずれの例もjQueryの方が短く書けている
開発効率の高さがあるからjQueryのほうが良い訳

372:デフォルトの名無しさん
19/02/15 22:34:33.79 fQG3bb7RM.net
せっかくだから日本語版
jQueryは必要ない(You Don't Need jQuery)
URLリンク(github.com)

373:デフォルトの名無しさん
19/02/15 22:37:44.38 Tr9ixmy70.net
フレームワークの欠点は単純なウェブサイトでは
生産性を落とすという大きな問題があるってこと

374:デフォルトの名無しさん
19/02/15 22:38:05.96 s9lB6bHor.net
URLリンク(i.imgur.com)

375:デフォルトの名無しさん
19/02/15 22:38:49.90 Tr9ixmy70.net
ついでだから、jQueryは必要ない(?)から一例を抜粋
8.7 slideToggle
スライドを伴って、エレメントの表示・非表示を切り替えます。
// jQuery
$el.slideToggle();
// Native
let originHeight = '100px';
el.style.transition = 'height 3s';
let { height } = el.ownerDocument.defaultView.getComputedStyle(el, null);
if (parseInt(height, 10) === 0) {
el.style.height = originHeight;
}
else {
el.style.height = '0px';
}

376:デフォルトの名無しさん
19/02/15 22:41:31.02 fQG3bb7RM.net
css tricksのYou Might Not Need jQuery
URLリンク(css-tricks.com)
その翻訳
URLリンク(coliss.com)

377:デフォルトの名無しさん
19/02/15 22:43:21.30 s9lB6bHor.net
DOMにノードを追加すると、DOM APIと直接対話するVanillaを1回呼び出すだけで済みますが、jQueryは多くの操作を実行します(スタックが長すぎて画像に収まりません)。違いは明らかです。
Vanilla:4ミリ秒
jQuery:95.3ミリ秒
Vanilla Javascriptは、追加時のjQueryよりも約25倍高速です。

378:デフォルトの名無しさん
19/02/15 22:44:41.61 Tr9ixmy70.net
>>367
いや、だからそんなことをしないで、クラスの書き換えだけを
やることで高速化できるって言ってるんだよ
話ついてきてね

379:デフォルトの名無しさん
19/02/15 22:48:19.07 zC296ldL0.net
>>359
使い分けって言いながらフレームワーク要らないって言うから意味不明になるんだよ
「自分の仕事では」要らないって話だろ?

380:デフォルトの名無しさん
19/02/15 22:51:08.66 s9lB6bHor.net
>>368
class追加するだけでもjqueryより10倍速いんですが?
URLリンク(i.imgur.com)

381:デフォルトの名無しさん
19/02/15 22:51:38.93 7RVZ/4z70.net
削除はともかく、追加がクラスの書き換えだけの訳ないわな。その書き換える対象がまだ無いんだから。

382:デフォルトの名無しさん
19/02/15 22:51:58.45 fQG3bb7RM.net
jQueryはネイティブに比べて遅い上にサイズも大きすぎる。
画像でもないのに数十kBとかアホか。
短く書けりゃいいのならnanoなど代替ライブラリもある。
nanoのコード例:
$(".someClass").css("background-color:green;").html("Hello World");
$('#c').animate('2.3', '1.2','0','1','1','0','0', '0','0','1').css('background-color:red').text('Hello');
$("#a").on("click", function(){
$("#someDiv").css("background-color:green;color:#fff;");
})
nanoは0.6kB。
jQueryは100倍もコード容量かけて何やってんのwwwww

383:デフォルトの名無しさん
19/02/15 22:54:11.02 I8iEDAq80.net
ボコボコでワロタw
我が物顔でスレチ荒らしするからこうなるww

384:デフォルトの名無しさん
19/02/15 22:54:50.30 Tr9ixmy70.net
>>372
じゃあnano使えば良いんじゃないですか?
フレームワークよりも大幅に小さいし

385:デフォルトの名無しさん
19/02/15 22:56:00.99 Tr9ixmy70.net
ウェブサイトではフレームワークは重すぎで生産性を下げるという
大きな問題があるが、jQueryやnanoはDOM APIの冗長性を省くだけだから
生産性は上がるしか無いというのが大きなメリットなんだよ

386:デフォルトの名無しさん
19/02/15 22:59:32.27 fQG3bb7RM.net
まあjQueryがいらないのは確かだね。
要素のstyle操作程度ならなおさらね。
「DOM操作しない方がいい」って言ってたし、じゃあDOM操作ライブラリのjQueryはいらないねw
え、やっぱりDOM操作したい?そして短く書きたいって?
100倍軽いnanoがあるよw

387:デフォルトの名無しさん
19/02/15 23:04:02.60 Tr9ixmy70.net
nano信者か・・・

388:デフォルトの名無しさん
19/02/15 23:05:15.16 Tr9ixmy70.net
そういやzeptoとかもあったけど、
今までの経験上、軽いだけの代替ライブラリは
結局本家を超えることって無いんだよな
nanoが普及すると良いね

389:デフォルトの名無しさん
19/02/15 23:09:04.09 ca0WBun30.net
すまん、ガチで話についていけてないんだが、>>351でjQueryは速いって書いてあるからjQueryは速いのか!って思ってたんだけど結局遅いの?

390:デフォルトの名無しさん
19/02/15 23:11:01.96 zC296ldL0.net
何をもって速いとするかに依る

391:デフォルトの名無しさん
19/02/15 23:11:48.08 ca0WBun30.net
>>380
速さを求めるときに使うもの?

392:デフォルトの名無しさん
19/02/15 23:12:36.21 fQG3bb7RM.net
GitHubがjQuery辞めたので URLリンク(ushirock.hateblo.jp)
jQuery が DOM 操作の際に eval() を多用しているため CSP を safe モードで使えないらしい
これは jQuery の核になる部分の仕様らしく、 .html() はどんな時でも任意のコードを実行する可能性があると
やっぱり jQuery といえば Sizzle でのセレクタ解析が遅いとか(querySelectorが使える場合優先されるらしい)ネイティブへの置き換えとかに目が行きがちだけどもこういう深い話でのデメリットもあるんだなと

393:デフォルトの名無しさん
19/02/15 23:14:27.13 Tr9ixmy70.net
>>379
jQueryが速いなんて言ってないんだが?
ファイルサイズではフレームワークよりも小さいから
初回ダウンロードは速いだろうけど。
速いって言う話はDOM操作で要素を消したり作ったりするよりも
classを変更するだけにしてCSSで表示したり見えなくしたりするほうが
速いだろうってこと。

394:デフォルトの名無しさん
19/02/15 23:15:42.26 fQG3bb7RM.net
jQuery。それは、
・遅い
・重い
・アンセキュア
なDOM操作ライブラリ。

395:デフォルトの名無しさん
19/02/15 23:16:58.62 Tr9ixmy70.net
>>382
ソースコードざっと見たけど、evalが見当たらないんだけど何行目にある?
URLリンク(code.jquery.com)

396:デフォルトの名無しさん
19/02/15 23:17:08.57 NXuVhChr0.net
jQueryを使うのって、速さ云々より一つのコードがどんな環境でも同じ様に動くって所なんじゃないの?
ブラウザの種類やバージョンでJavascriptの挙動の違いがあるから、それを吸収する為にjQueryを使うんじゃない?

397:デフォルトの名無しさん
19/02/15 23:17:55.89 zC296ldL0.net
>>381
はっきり言ってjQueryが遅いとは思わない
熟練した人が地道に管理すれば十分速い
それが手間じゃねぇの?ってのがフレームワークの意義

398:デフォルトの名無しさん
19/02/15 23:21:18.07 Tr9ixmy70.net
>>384
jQueryってDOM APIを使ってるだけなのに
なんでアンセキュアになるの?

399:デフォルトの名無しさん
19/02/15 23:21:36.55 ca0WBun30.net
>>383
そうか、なんかすまん。
>仮想DOMは最終的にDOM操作をするから遅くなるが、
>jQueryではCSSによって見た目を切り替えるだけだから速いってこと
この部分読んで仮想DOMは遅くてjQueryは速いのか!って解釈しちゃったんだが仮想DOMに比べて速いだけでjQueryも速くないんだな。

400:デフォルトの名無しさん
19/02/15 23:25:42.00 ca0WBun30.net
>>387
>>367の結果だけ見ると遅すぎ(10回やると1秒!?)って思っちゃったんだが……
webは基本的には静的コンテンツだから気にならない世界なのかな。
とりあえず俺にはこのスレの会話を理解する能力が足りないっぽい。

401:デフォルトの名無しさん
19/02/15 23:28:54.96 ca0WBun30.net
まあ1つの処理に4ミリ秒って時点で衝撃的な遅さだしweb開発の世界はそんなもんなのか。

402:デフォルトの名無しさん
19/02/15 23:31:51.99 I8iEDAq80.net
jQuery使うと100ミリ秒になるけどなw

403:デフォルトの名無しさん
19/02/16 00:34:30.68 oKtXVOCjd.net
vue.jsが
やたらめってら、もてハヤサれる昨今だけど
ぶっちゃ毛v-forが仕様としてオワッテると思うわ。
それとuidの生成パターンをC言語なら「ポインターが理解でないワケ」や
「ポインター徹底攻略」、、、JAVAならデザイパターン本みたいな
分厚い本で説明しなきゃ
いけないのに、それを全くやってないよな。
俺が考えるvue.jsが広まらないワケだよ。コンポーネントをどうユーザーが
受けとるべきかも、簡単な再帰などを使ってイラストレートしなきゃいけないのに
これも全くやってない。細々としたシステムは売り込んでるけど
vueの長所が全くされてない

404:デフォルトの名無しさん
19/02/16 00:34:57.77 fcnsYPNW0.net
早い遅いじゃなくて開発効率の話だろ。domを直接指定して操作云々はもう止める、最小限にするて事。今後確実にそうなるのは皆分かってると思うが。

405:デフォルトの名無しさん
19/02/16 00:44:30.53 HVh9Xg4td.net
実行速度の話をしてる人たちに、いきなり開発効率の話をしだすのは草。なんの関係もないじゃんw

406:デフォルトの名無しさん
19/02/16 01:34:13.23 SPTGalft0.net
実行速度については、DOM要素を作成したり削除したりするよりも
CSSで表示したり隠したりしたほうが速いんじゃないかってだけのこと
それをやるにはVue/React/AngularよりもjQueryの方が楽ってこと
DOM操作がネイティブよりも速いなんて話はしてない。
CSSによる表示切り替えの方が速いって話をしてる。
そのCSSによる表示切り替えを楽にやる(開発効率が良い)のは
jQueryってだけのこと

407:デフォルトの名無しさん
19/02/16 01:47:37.10 P5gjDjW+0.net
DOM要素の追加削除とCSSの表示切り替えって役割が違わね?

408:デフォルトの名無しさん
19/02/16 01:49:25.92 P5gjDjW+0.net
CSSの表示切り替えは既に存在する要素に対して行うのに対してDOM要素の追加は動的に要素を追加するためにやるもんだと思うんだが。
この2つは比べるべきものなの?

409:デフォルトの名無しさん
19/02/16 01:59:26.44 P5gjDjW+0.net
スレタイの3つとかはSPAのような高性能なブラウザアプリを作成するものでしょ。例えばofficeとかslackとか。CSSの切り替えだけでいけるの?

410:デフォルトの名無しさん
19/02/16 02:11:14.67 yZTjSyit0.net
相手せんでええよキチガイだから。

411:デフォルトの名無しさん
19/02/16 04:00:16.99 H80q57B70.net
>>354
難しいというより学習コストが高い=最低限として覚えなきゃいけない事が多い
その反面必要な機能をサードパーティーから探してくる必要性がかなり低い

412:デフォルトの名無しさん
19/02/16 04:05:31.34 H80q57B70.net
>>379
普通にUIとして使う分にはそんなに気になるほどの事でもないけど
Canvasに連続的に描画とか行う場合はダイレクトにその遅さが目立つってくらいかな

413:デフォルトの名無しさん
19/02/16 06:51:31.57 fcnsYPNW0.net
早いからじゃなくて便利だからjQueryを使うんだろ。なんで今更速度の話になってんの?

414:デフォルトの名無しさん
19/02/16 07:10:24.28 H80q57B70.net
最近ブラウザでWebRTCとかやるのもわりとあるケースだし遅いってのは無視できない問題でもあるよ

415:デフォルトの名無しさん
19/02/16 07:20:20.26 Ka3Sv0NV0.net
>>403
jQueryは仮想DOM操作より早いと信者が言い出したから。

416:デフォルトの名無しさん
19/02/16 08:04:12.49 SPTGalft0.net
>>405
デマ乙
>>330を見れば分かるが仮想DOMよりも
classの変更で表示・非表示の切り替えをしたほうが速いって言ってる

417:デフォルトの名無しさん
19/02/16 08:58:01.91 P5gjDjW+0.net
もう一度聞くけど、classの変更でできることって限られてるでしょ?見た目の操作だけかな?
それが仮想DOMより速くてもどうしようもなくないか?役割が違うんだから。
なんか自分の間違いを認めたくないから無理やり話をすり替えようとしてるようにしか見えないんだが…

418:デフォルトの名無しさん
19/02/16 09:01:46.50 mve


419:ZudXk0.net



420:デフォルトの名無しさん
19/02/16 11:06:01.11 fcnsYPNW0.net
スレタイから逸脱しすぎてると思ったらjQueryと比較してる奴がいるのか。。もう何年


421:も前に通り過ぎた話題だぞ。前見ようぜ。



422:デフォルトの名無しさん
19/02/16 11:13:52.65 jR4qOrfsr.net
ReactとかVueすら使えない超低レベルなクソジジイが騒いでるだけだから

423:デフォルトの名無しさん
19/02/16 11:14:50.85 SPTGalft0.net
>>407
> もう一度聞くけど、classの変更でできることって限られてるでしょ?見た目の操作だけかな?
要素の追加削除の代わりに見た目を変更するっていうのは、
単に要素を追加削除するコストだけではなく
イベントハンドラの設定のコストも減らせる
もともとjQueryはデリゲートが簡単にできるから、要素が増えたり減ったりしても
イベントハンドラは最初に一回だけ設定すれば良いんだが、
それを使わなくても例えば要素のonclick属性とかに直接やる場合でも
要素が追加したときに新たにイベントハンドラを設定しなくてすむ
仮想DOMではDOM操作を最適化して必要な場合だけ実行するが
速度の話をするならそもそもDOM操作自体を減らそうという発想にしたほうが良いと思う
要素ごとにイベントハンドラを設定するよりも、
要素の親に一つだけイベントハンドラ設定したほうがいいわけだし

424:デフォルトの名無しさん
19/02/16 11:35:47.92 H80q57B70.net
こっちでやったら?
Webフロントエンドで脱jQueryを目指すスレ
スレリンク(tech板)

425:デフォルトの名無しさん
19/02/16 11:38:28.40 auHH3gBua.net
使える使えないと使う使わないは別のこと
jQueryが殆どの場合最適解でSPAが勝てる領域はかなり狭いという事実を見失っちゃいかん

426:デフォルトの名無しさん
19/02/16 11:41:22.10 SPTGalft0.net
SPA、シングルページアプリケーションであって
シングルページウェブサイトじゃないからな
アプリケーションの時点で、ならネイティブアプリにしろよって
言われる時代

427:デフォルトの名無しさん
19/02/16 11:52:58.50 R2hmaITu0.net
勝手にそんな時代を作るな

428:デフォルトの名無しさん
19/02/16 11:56:31.80 H80q57B70.net
まぁ正直フレームワークは知らなくてもいいかも知れんがNodeを知らないと確実に困る時代にはなってくると思う

429:デフォルトの名無しさん
19/02/16 12:00:35.69 auHH3gBua.net
ネイティヴアプリは環境差異とデプロイメントがめんどくさいんだよね
dockerがGUIをサポートしてくれたら乗り気になるかもしれんがな

430:デフォルトの名無しさん
19/02/16 12:09:05.56 SPTGalft0.net
>>417
それはウェブでも変わらん。カメラ使おうと思ったら
ブラウザごとに使うAPIは違うし、端末ごとに対応してる
解像度も違うし散々だったぞ
dockerってLinuxの話してる? それならSnapsやFlatpakなどが登場してる。
Dockerはあくまで開発者向けで自分で作ったアプリをデプロイするときに使うもの。
一般ユーザー向けにアプリを配布するならSnapsなどを使う
GUI対応でディストリ非依存のパッケージ管理システム

431:デフォルトの名無しさん
19/02/16 12:16:07.61 H80q57B70.net
>>417
ネイティブの面倒なところはそこよりも
OSの差異で動かなくなったりするところだな特にiOSとか

432:デフォルトの名無しさん
19/02/16 12:19:58.87 auHH3gBua.net
>>418
Snapsってdockerのように依存関係や実行時の環境もカプセル化してくれんの?

433:デフォルトの名無しさん
19/02/16 12:34:18.62 msvpDp2N0.net
>>419
その差異をブラウザは吸収できないんだよね
だからみんなネイティブアプリにする

434:デフォルトの名無しさん
19/02/16 12:41:53.08 R2hmaITu0.net
みんなって誰だよ
勝手に決めるな

435:デフォルトの名無しさん
19/02/16 12:43:59.75 P5gjDjW+0.net
>>411
具体例をお伝えした方がいいのだろうか?
例えばサーバーのDBに対して検索かけてとってきた要素を並べてコンテンツだすとかclassだけでなんとかなるの?
そもそも要素を出したし消したりでなんとかなるような簡単なものにReactとか使わないものじゃね?

436:デフォルトの名無しさん
19/02/16 12:47:43.95 P5gjDjW+0.net
サービス提供する側としてはネイティブよりSPAの方がよいケースはままあるでしょ。
例えばインストーラーが不要、そもそも技術者がいない、今までの資産をそのまま流用できる、とかとか。
ハードを


437:限定しないソフトウェアの提供形態って殆どの場合は都合できまるもんだと思う。



438:デフォルトの名無しさん
19/02/16 12:50:25.75 0+4MW20ta.net
ネイティブはストアにリリースすんのがイチイチめんどくさい

439:デフォルトの名無しさん
19/02/16 13:05:39.77 jR4qOrfsr.net
jqueryしか使えない無能の自己紹介はいらん
消えろカスジジイ

440:デフォルトの名無しさん
19/02/16 13:13:23.51 dSQ6SPUO0.net
Angular習得した後にjQueryで書かれたコード見たら吐き気がしてくるわ。
「こんなコードわざわざ書かなくても取ってきたデータバインディングすりゃ良いのに」って思う箇所が多々ある…。
まぁ、古いブラウザでも動くようにしなきゃならないからjQuery使ってんだけどね。

441:デフォルトの名無しさん
19/02/16 13:19:34.25 H80q57B70.net
>>427
Windows7のサポートが切れればなぁ

442:デフォルトの名無しさん
19/02/16 14:02:04.13 msvpDp2N0.net
>>427
お前が書くコードがクソなだけw

443:デフォルトの名無しさん
19/02/16 16:10:27.79 dSQ6SPUO0.net
>>428
サポート切れてても「壊れてないから」とか「投資できる余裕がない」とか「基幹システムが新しいOSに対応していないから」って理由で
古いOSと機械を使い続ける客もいるんだよなぁ。あんまりよろしくは無いんだけど。
>>429
jQueryベースでデータバインディングみたいなコード書けるん?
書けるなら書き方教えてくれや。こちとら嫌々でもjQueryとは付き合っていかなきゃなんねーんだよ。

444:デフォルトの名無しさん
19/02/16 16:16:01.06 sYjKK7tj0.net
イベント使え

445:デフォルトの名無しさん
19/02/16 17:30:33.50 fcnsYPNW0.net
>>430
使ったことないが、backboneやKnockoutやらのIE7でも動くライブラリ使ってみれば?ただ今更勉強する意義を考えると辛いなあ。。

446:デフォルトの名無しさん
19/02/16 18:08:11.34 auHH3gBua.net
旧ブラウザサポートはお高くなりますよ?
これでほとんどの客が黙る

447:デフォルトの名無しさん
19/02/16 19:11:18.01 LE6s3aZE0.net
やっすい案件ほどクソ要求してきやがる。

448:デフォルトの名無しさん
19/02/16 19:38:01.61 H80q57B70.net
>>430
少なくともイントラではなグローバルサイトではサポート切れたOSの対応は打ち切っていいだろ

449:デフォルトの名無しさん
19/02/16 19:40:47.09 msvpDp2N0.net
Androidだとサポート切れといっていいOSはどれ?

450:デフォルトの名無しさん
19/02/16 20:08:25.91 4RfOpqIfr.net
>>433
最新バージョンのreact使ってるけどIE11で問題なく動作しとる

451:デフォルトの名無しさん
19/02/16 21:03:12.87 H80q57B70.net
正直互換性の点ではIE11よりもEdgeの方が癖があるんだよね
まぁEdgeもChromiumベースになる計画があるらしいしEdgeのChromium化とWindows7のサポート打ち切りが来ればパブリックサイトは随分シンプルになるんじゃないかと思う

452:デフォルトの名無しさん
19/02/16 22:09:54.11 gLKxbWo30.net
chromiumになってもなんかしらイレギュラーがありそう
信用できない

453:デフォルトの名無しさん
19/02/17 08:20:58.26 O/E0SKNM0.net
フロントエンドなんてそんなもんだとしか言いようがない。

454:デフォルトの名無しさん
19/02/17 09:26:47.38 x12h9xDW0.net
逆に言えば進化の余地ありありと言うこと。でもフレームワーク競争もひと段落して数年は安定じゃないかな。ブラウザもChromiumとSafariに収束されつつあるし。あとはiOS safariにpush通知実装されればなあ。

455:デフォルトの名無しさん
19/02/17 09:30:51.46 Y22Zw0Bq0.net
プログラマには、Apple機がなくなった方が楽になると思われている。
IEが消滅して言ったのと同じ状況がApple機に対しても起きつつあると思う。
iPhoneは売れなくなった。

456:デフォルトの名無しさん
19/02/17 09:44:50.06 E0TCVuWu0.net
フロントエンドは端末とブラウザの進化の影響をもろに受けるからねぇ…。
クロスプラットフォームの分野でも、SPAが技術的に枯れる前にどんどん新しいフレームワーク出て来るからな。最近だとFlutterとか。
SPAだけでも選択肢多いのに、xamarinだのcordovaだのFlutterだのと。
こっちとしては「クロスプラットフォームアプリ開発するなら結局どれ選べばいいんだよ」的な状態だわ。

457:デフォルトの名無しさん
19/02/17 09:48:46.68 Y22Zw0Bq0.net
結局、大きい組織が作ったものを使っていくようになるんだろう。

458:デフォルトの名無しさん
19/02/17 09:49:49.70 eXZp7YPc0.net
Apple機さえ無視すれば、プログラミングが色々便利になる。

459:デフォルトの名無しさん
19/02/17 10:25:00.47 vi4O111wa.net
>>443
どれでもいい
フロントは使い捨て
簡単に乗り換えできるようにビジネスロジックと疎結合に作る
そこだけ死守すればなにを使ってもいい

460:デフォルトの名無しさん
19/02/17 10:44:59.94 1mijhG+I0.net
cordova使うならIonicでいいんじゃない?
最近はAngularだけじゃなくVueにも対応したらしいし
そういやReactNativeにもVue版出てたな

461:デフォルトの名無しさん
19/02/17 15:29:11.35 KFkN1Yft0.net
vueはreactパクってばっかだな。
storybookもパクってなかったか?
nuxtもnextのパクりだろ?
さすが中国人プロジェクトw

462:デフォルトの名無しさん
19/02/17 16:09:57.46 E0TCVuWu0.net
別にパクっていてもそれで良くなるなら別に何でもいいけど。ただvueは元Google社員とはいえ中国人でしかも個人開発だろあれ。
いつ開発が止まるかもわからない、信用のない国の人間が作ったもんを率先して基礎にしたがる奴なんているのかな。
vue使いたがる奴なんて、vueを使いたいから使うんじゃなく、技術力低いからvueしか選択肢が無いんじゃないかと。

463:デフォルトの名無しさん
19/02/17 16:17:22.57 YF9uE98b0.net
技術力低くても使えるなんてコスト低くて最高だな

464:デフォルトの名無しさん
19/02/17 18:12:29.77 jxnSJIL40.net
どうせWebComponentsが完成したら
またガラリと世界が変わるんだから
どれ使っても一緒

465:デフォルトの名無しさん
19/02/17 18:17:28.09 1mijhG+I0.net
>>451
過大評価しすぎ

466:デフォルトの名無しさん
19/02/17 19:04:36.50 vi4O111wa.net
何れにせよあっという間に時代遅れになることは確かだ

467:デフォルトの名無しさん
19/02/17 19:11:48.12 8CydzgAW0.net
金融系取引先においてある、およそ10年前に作られた当時先端のActionScript製RIA業務システムを見るとふふってなる。

468:デフォルトの名無しさん
19/02/17 19:15:44.06 jxnSJIL40.net
10年前、2009年か。なら当時最先端のAngularJSを使っていればよかったのに

469:デフォルトの名無しさん
19/02/17 19:19:23.16 jxnSJIL40.net
Reactは2013年だから10年前には選べない
Vueも2014年だから無理
Backboneは2010年だからギリ間に合うか?
Knockoutも2010年だな
10年前の最先端は、すべからくオワコン
ReactもVueもあと5年程度の命だろ

470:デフォルトの名無しさん
19/02/17 19:27:54.46 GfPZMs79M.net
*すべからく

471:デフォルトの名無しさん
19/02/17 19:39:34.68 6yF6+Ynsr.net
Reactオワコンだからこれからはjqueryオススメ

472:デフォルトの名無しさん
19/02/17 20:02:00.60 4TiEHd4P0.net
>>448-449
やっぱ、Aureliaだな

473:デフォルトの名無しさん
19/02/17 20:17:50.30 1mijhG+I0.net
>>459
この前のレスで気になってたから今ちょうどインストールしてた
何気にAngularの一番厚い本(アプリケーションプログラミング)で主要なフレームワークとして挙がってるのな
>>448
パクリから始まったのは確かだけど今やNuxtはSSRの為だけのものじゃなく
Vueベースのフルスタックフレームワークなんだよな

474:デフォルトの名無しさん
19/02/17 20:40:36.87 SrJ5Oa/9p.net
Reactがオワコンって即ちjsがオワコンって事だと思うんだけどそれはないんじゃないか?

475:デフォルトの名無しさん
19/02/17 21:28:50.33 6yF6+Ynsr.net
ReactがオワコンになってjsもオワコンになってjQueryだけが使われると思ってるクソジジイが一匹いるけど

476:デフォルトの名無しさん
19/02/17 21:36:36.53 1mijhG+I0.net
jQueryは別にいいんだけどWebpackは知らんとこの先ついて行けんくなると思うよホント
今やブラウザでなんでもできる時代やしなんでも作らないかんくなるから何も勉強しなくても余裕とは思わん方がいい

477:デフォルトの名無しさん
19/02/17 22:05:35.95 x12h9xDW0.net
jQueryが長生きなのは認める。

478:デフォルトの名無しさん
19/02/17 22:23:23.44 jxnSJIL40.net
babel使うんだからwebpackぐらい使うだろ?

479:デフォルトの名無しさん
19/02/17 22:57:23.05 6yF6+Ynsr.net
普通に使うよな

480:デフォルトの名無しさん
19/02/17 23:02:22.78 1mijhG+I0.net
もしかしてAureliaってCliでプロジェクト作っても碌にデモ画面も表示されない?

481:デフォルトの名無しさん
19/02/17 23:57:17.64 AOpTaf3U0.net
単刀直入に質問。Vue.jsとReactを勉強するための書籍を探してる。今は
両方のチュートリアル見たりしながら写経しつつ、我流で勉強中。
●Vue.jsは技評のVue.js入門と基礎から学ぶシーアンドアールのVue.jsで迷ってる
●Reactはどれも評価高いものがなくて迷ってるが今は見送り?
ちなみにJSの知識だが、今までjavascriptは紫の山田本一通り通したことがあり、AngularJS1.5で簡単な
検索システム組んだことあるぐらい。いちおうjQueryも一通り触れてプログラムに
色々システムを手書きで組み込めるレベルはある。

482:デフォルトの名無しさん
19/02/18 00:24:29.50 ZveW3gOd0.net
>>468
vueだけど、俺は「基礎から学ぶvue.js」買ったよ。技評の方は読んでない。公式webとその本で十分網羅されてると思う。

483:デフォルトの名無しさん
19/02/18 00:32:34.18 PvqzGaNZ0.net
おお、サンクス。なら、そっちも買うか

484:デフォルトの名無しさん
19/02/18 01:01:22.40 qsq8EO4j0.net
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17
基礎から学ぶ Vue.js、mio、2018/5/29
Node.js超入門、掌田津耶乃、2017
Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017

入門 React ―コンポーネントベースのWebフロントエンド開発、2015
Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
URLリンク(github.com)

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発、オライリー、2017
JavaScript 第6版、2012、David Flanagan

485:デフォルトの名無しさん
19/02/18 01:12:07.61 TCe7B/Jv0.net
↓Reduxに関しては一番詳しく書いてあるけどサンプルプログラムの入手先が本誌に書いてない・やっぱちょい古い
React入門 React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで
↓構成は悪くないしサンプルプログラムがしっかりしてる点はいいがバージョンが古いのとRedux�


486:ェ載ってない いまどきのJSプログラマーのための Node.jsとReactアプリケーション開発テクニック ↓これはやめといたほうがいい React開発 現場の教科書 とりあえず一番上がいいかな



487:デフォルトの名無しさん
19/02/18 01:14:46.55 TCe7B/Jv0.net
>>471
Node.js超入門は全然役に立たんし買う必要ないと思う
てか全般的に2017年以前の書籍勧めちゃいかんだろ

488:デフォルトの名無しさん
19/02/18 01:17:18.50 TCe7B/Jv0.net
>>470
基礎からは著者のサポートサイトも併せて見るとやりやすい

489:デフォルトの名無しさん
19/02/18 08:10:58.01 3Fbf7ypjr.net
フロントは更新や淘汰が速すぎるから書籍だと情報が古くなるのは仕方ない

490:デフォルトの名無しさん
19/02/18 08:44:20.46 WLtbirMY0.net
SproutCoreとかもう名前が挙げられることもないからな。
なぜかmeteorは今更挙げられることがあるが。

491:デフォルトの名無しさん
19/02/18 22:14:52.84 WoGhDUeR0.net
逆にフレームワークを本買ってまで勉強する必要あんのかな。
公式のチュートリアル一通りやればどう書けばいいかは大体想像付くし、
あとは自分でお題決めて、わからん事は公式ドキュメントやstackoverflowとにらめっこしてれば、大抵の物は作れるだろ。

492:デフォルトの名無しさん
19/02/18 22:20:39.28 788tab2z0.net
>>477
そう。英語勉強したほうがマシ。マジで。

493:デフォルトの名無しさん
19/02/18 22:38:28.05 dNYL//qB0.net
フレームワーク本を1週間で読めるとして、
英語を勉強するのとどちらが速いと思いますか?

494:デフォルトの名無しさん
19/02/18 22:44:57.01 3Fbf7ypjr.net
英語は10年やっても無理だがフレームワークなら1日で覚えられる

495:デフォルトの名無しさん
19/02/18 22:53:31.84 788tab2z0.net
ウンコ訳で周回遅れの邦訳に付き合わなくてよくなるぞ。
英語なら電子版無料公開してるような書籍でも日本では印刷してボッタくっている。

496:デフォルトの名無しさん
19/02/18 22:56:21.87 7ubWqY/W0.net
理解できなけりゃ金払ってでも理解すりゃ良いんだよ。

497:デフォルトの名無しさん
19/02/18 23:01:29.12 PvqzGaNZ0.net
理系じゃないんで抽象的な表現が苦手なんだよな。なので、ひとつ何か
コンポーネント指向がわかる手ほどき書がほしかったわけで
今、基礎から学ぶ読んでるけど、デザイナー向けに書かれてるだけあって
わかりやすくていい
>>478
むしろ、英語は読める口(ニュースサイトの記事や英語版Wikipediaの記事とかは
だいたいわかる)なんだけどね

498:デフォルトの名無しさん
19/02/18 23:10:58.27 6vaPKOJl0.net
話題になり始めたらとりあえずgithub見に行くな
必要なものは大抵その中か、そこからのリンクにある

499:デフォルトの名無しさん
19/02/18 23:17:17.71 2Q4jbH6wM.net
>>483
はぁ、コンポーネント指向を…
Atomic Design ~堅牢で使いやすいUIを効率良く設計する くらいしか知らないな。この本で使ってたのはReact。

500:デフォルトの名無しさん
19/02/19 01:42:29.59 qmiILQOL0.net
>>468
Vue本は両方買った
ある程度動けばいい実践派は猫本
理論から入りたい理屈派は技評本ってとこ
俺は技評の方が性にあった

501:デフォルトの名無しさん
19/02/19 02:51:16.21 QF2NWP5xr.net
China開発者が作ったvueと、Facebookが作ったReactは将来性も含めてどっちがオススメ?

502:デフォルトの名無しさん
19/02/19 09:00:05.79 8ne5Wfny0.net
vueはちょいと手を広げすぎな気はする。

503:デフォルトの名無しさん
19/02/19 09:01:38.38 494Vj+cBa.net
もしかしてAngularって本当に淘汰されてる?

504:デフォルトの名無しさん
19/02/19 09:14:50.98 jwE8w3hJ0.net
Angularのシェアが落ちてると言うより、angular採用するまでも無いサイトが他を使用してるだけだろう。vueなんかは小さく始められるから入力フォームにだけ利用もできるしjQueryと共存もできるしね。俺もフォームから始めたな。随分スッキリした。

505:デフォルトの名無しさん
19/02/19 13:47:21.51 YsDFh+D0d.net
vueの良さが今日
ようやく判ったな。コンポーネントという単位で
分けることにバックエンドとフロントエンドとミックスできて
しかもjQueryまで使える。よぼどvueを
知ろうとしないとこの境地には辿りつけないけど

506:デフォルトの名無しさん
19/02/19 15:11:28.48 QF2NWP5xr.net
React終わったな
もはやvueの勢いにはどうあがいても勝てない

507:デフォルトの名無しさん
19/02/19 15:40:44.07 SwtNBaDUM.net
※スターの半分以上は中国人です

508:デフォルトの名無しさん
19/02/19 15:46:05.13 g2OPfq0o0.net
中国人がどんどんcomponent作ってくれるから楽できる

509:デフォルトの名無しさん
19/02/19 16:37:04.20 wezyZP0ya.net
Alibaba vs Facebook

510:デフォルトの名無しさん
19/02/19 18:19:10.23 QwJoWSeKd.net
俺は中国人の勢いにかけるぜ

511:デフォルトの名無しさん
19/02/19 19:06:32.74 sMCHYB6e0.net
>>495
アリババの勝ちだな。

512:デフォルトの名無しさん
19/02/19 19:10:40.62 Qqrvi8yYa.net
Aurelia試してみたけどcliでプロジェクト作ってもhttp-serverインストールした上必要なファイル手動で追加せんとデモ画面もろくに表示されんとかこりゃ流行らんの当たり前やん

513:デフォルトの名無しさん
19/02/19 21:08:49.53 sMCHYB6e0.net
中間とってビュアクトにしたらいいのでは。

514:デフォルトの名無しさん
19/02/19 22:32:39.35 E9aKyrSX0.net
>>490
AngularはAngularJSでやらかしたのがデカイんじゃない?
一生懸命AngularJS勉強して「さあこれから本格的に開発していこう!」って矢先に互換性のないAngular 2発表、
AngularJSはオワコン化じゃ、次何が出ようと「誰がお前らのフレームワークの習得に投資するんだよ」ってなるわ。

515:デフォルトの名無しさん
19/02/20 01:13:44.34 1A7mnZWV0.net
>>496
わからない時は英語じゃなくて
中国語で検索しないといけなくなるのかな?

516:デフォルトの名無しさん
19/02/20 02:18:36.91 23FEoZns0.net
>>500
ほんまそれだわ、3年前Angular2で別物になったと思えば、もう6とかいってるし…
数年でもう5まで行ったLaravelも大概じゃないがそれよりひどい

517:デフォルトの名無しさん
19/02/20 02:27:40.92 23FEoZns0.net
あと、フルスタックじゃないAngularJSのような気軽さがないとね…。
ReactとRedux、Vueとnuxtみたいな関係が必要だ。門戸は広く、奥行きは深くすべき
ReactはVueに影響されたか、だいぶ記述はわかりやすくなったから、前よりは
とっつきやすくなったと思う

518:デフォルトの名無しさん
19/02/20 07:17:02.34 SpCnH/g70.net
おいreactに来たhooks apiめっちゃいいやんけ。クラスなんていらんかったんや!

519:デフォルトの名無しさん
19/02/20 07:59:55.95 zvYiCp4Or.net
クラスでええやん

520:デフォルトの名無しさん
19/02/20 13:47:47.60 n2p9Q1hFd.net
>>502
7やろ

521:デフォルトの名無しさん
19/02/20 14:20:15.26 B6NZYAeG0.net
>>503
> ReactとRedux、Vueとnuxtみたいな関係
言いたい事は分かるが一応訂正。reactとnext.jsに対応するのはvueとnuxt.js。ステート保持はreactがredux、 vueがvuex。

522:デフォルトの名無しさん
19/02/20 19:48:50.57 CEoya/3z0.net
HooksってReduxとの相性どうなの

523:デフォルトの名無しさん
19/02/20 20:13:36.83 SGVVPurF0.net
Reduxが要らなくなるのがHooksなんじゃないの?

524:デフォルトの名無しさん
19/02/20 20:17:31.57 hK+DOQwsM.net
context apiと組み合わせれば。
デカイアプリはまだまだreduxじゃないかな?
しかし確実にstate管理の枠組みにも変革を促すであろう。
post reduxにどんなのが出てくるのか楽しみ。

525:デフォルトの名無しさん
19/02/20 20:24:09.86 SGVVPurF0.net
ということで、またオワコンが一つ増えますね。Reduxはオワコン。
ほれ、また次だぞ。チキンレースは終わってないぞ!

526:デフォルトの名無しさん
19/02/20 20:36:00.91 hK+DOQwsM.net
まあreduxはめんどくさすぎるからな。
小規模アプリでも必須みたいな風潮が異常だった。

527:デフォルトの名無しさん
19/02/20 20:47:56.19 IrLSPTwba.net
>>507
現状nuxtは大きくなりすぎたからnextと比較するのは不毛

528:デフォルトの名無しさん
19/02/20 22:17:55.07 zvYiCp4Or.net
まじか
いまReduxつこてるのに

529:デフォルトの名無しさん
19/02/21 16:37:13.46 QuFAf9ehr.net
reactでブラウザの戻るに一つしか履歴が登録されない
意味不明

530:デフォルトの名無しさん
19/02/21 17:02:23.80 f8G92//U0.net
ヒステリーAPIを使え

531:デフォルトの名無しさん
19/02/21 17:08:39.36 QuFAf9ehr.net
ヒストリー使ってるんだけど
・createBrowserHistoryライブラリ(IE対応のため)
・redux
・react-redux
・connected-react-router
これら使ってなんとか構築してるんだが一つしか履歴残らん
てか解説サイトがほとんどない…

532:デフォルトの名無しさん
19/02/21 18:31:50.74 ++Eueb0Rd.net
>>516
ヒステリーAPIは草

533:デフォルトの名無しさん
19/02/21 20:33:12.61 P4oXdJL20.net
>>515
これのexampleの構成をよく見た方がいい
URLリンク(github.com)

534:デフォルトの名無しさん
19/02/22 03:02:07.44 y9srh0J/p.net
>>516
まあまあ
落ち着けよw

535:デフォルトの名無しさん
19/02/22 12:59:46.42 CkzBv4Her.net
とりあえずhistory直す
なんかわからんがLink使うとhistoryの履歴が3つ登録される
SPAはここがめっちゃめんどくせぇ
なんでブラウザの操作までjsで組まなきゃいけないんだか

536:デフォルトの名無しさん
19/02/22 13:22:14.53 nIPzShw8a.net
てかオッペケってReactマスターやなかったんかい

537:デフォルトの名無しさん
19/02/22 13:32:15.20 9C0ENtC1M.net
別にSPAにせず普通にページ遷移してもいいんだがな。誰もやらないだけで。したがってサンプルも転がってないw

538:デフォルトの名無しさん
19/02/22 14:06:18.79 CkzBv4Her.net
>>522
すまん、App.jsのコンストラクタ内でthis.props.history.listen使ってしまっておった
これやめたら直りました
dispatchで初期化するのにつかってたのが間違い

539:デフォルトの名無しさん
19/02/22 21:03:06.66 wU2NQYd9a.net
>>519
サンプルここにあんじゃん

540:デフォルトの名無しさん
19/02/22 21:06:35.12 Q1wbj0yj0.net
Reactはホント人によって使うフレームワークやライブラリが全然違うな。
ちょっと興味あったけど、これじゃどっから始めたらいいか全然分からん。
てか、ReduxだのNextだの、第三者が作ってるであろうフレームワークの開発なりサポートなりが終わってしまったら、代わりはどうすんだ?

541:デフォルトの名無しさん
19/02/22 21:14:42.59 QkaGMiSY0.net
極力公式か大きめの企業がメンテしてるものだけで作る
コミッタが少ないものは使わない
ライブラリへの依存が散らばらないよう自コードで軽くラップして使う

542:デフォルトの名無しさん
19/02/22 21:19:43.61 wU2NQYd9a.net
まぁ本当にSSR必要かってのもあるけどね
最近自分の関わってる案件だと会員サイトの認証済み領域の情報は一切検索エンジンにヒットさせる必要ないからSSRとは無縁なんだよな

543:デフォルトの名無しさん
19/02/22 21:24:17.86 LKaW/yz70.net
スペシャルスーパーレア?

544:デフォルトの名無しさん
19/02/23 00:29:55.26 tE6+E9hM0.net
>>526
大丈夫。その前にReactが終わる。VueもAngularも
あと数年後は今存在してないフレームワークが使われてるよw

545:デフォルトの名無しさん
19/02/23 07:14:02.54 6swyBY50a.net
数年後も残ってるのはjQueryだけ
MVC+jQが正解なんだよ

546:デフォルトの名無しさん
19/02/23 09:37:08.18 2sBO9l/X0.net
いやreact vue angularについては長生きすると思う。ここ数年は本当酷かったフレームワーク戦争も落ち着いたしあと5年は使えるんじゃないか?ようやく腰を据えて安心して学べる状態になった。

547:デフォルトの名無しさん
19/02/23 10:08:06.99 tE6+E9hM0.net
あとたった5年(笑)

548:デフォルトの名無しさん
19/02/23 10:16:15.94 tE6+E9hM0.net
お前ら、RADツールって知ってるか?
ウェブの世界じゃあまり知られてないかもしれないが
デスクトプアプリの世界じゃ20年以上前から存在してるものだよ
VBとか有名だな
で、reactなどは近い将来RADツールに置き換わる。
RADはツールであってフレームワークではないから
正確に言うとRADツールを作りやすいフレームワークになるということ
コンポーネントは作ってパーツとして使える。
使いやすいコンポーネントが最初から揃っている。
GUIでマウスで操作するだけで簡単にコンポーネントが配置できる
まあここまではUIエディタ(HTMLエディタ、JSXエディタ)と
変わらんわけだがここからがJavaScript
コンポーネントを選ぶんで書きたいイベントを選ぶとイベントハンドラが生成される
自分で紐づけとかしなくて良いんだよ。JSXとか書かなくていい。
イベントハンドラ名もデフォルトで自動生成、プログラマはイベントの中身を書くだけ
データのバインドとかもRADツールで紐付けるべきものの名前を書くだけ
20年前のVBはすでにこういった世界だったんだよ?

549:デフォルトの名無しさん
19/02/23 10:34:55.14 6swyBY50a.net
だが滅んだ

550:デフォルトの名無しさん
19/02/23 10:55:53.84 awIWFh910.net
マウス1つでレスポンシブデザインまで対応出来るなんて
夢みたいなツールじゃん

551:デフォルトの名無しさん
19/02/23 11:17:14.46 tE6+E9hM0.net
レスポンシブはブレークポイントを複数定義して
デフォルトからの差分みたいな感じでデザインするんだろうね

552:デフォルトの名無しさん
19/02/23 11:17:41.85 XpMOEioH0.net
選択肢の一つをあたかも統合されるかのような詭弁はNG。
ポトペタASP.NETが密結合過ぎてわざわざOSS界隈に歩み寄った歴史を思い出せ。

553:デフォルトの名無しさん
19/02/23 11:25:13.71 6swyBY50a.net
技術がなく判断できない企業はノンプログラミングという言葉に騙されやすいのだろうね

554:デフォルトの名無しさん
19/02/23 11:32:23.19 RWE+nJx90.net
>>539
WIXはそんなに悪くないが一般的には酷いの多いよね

555:デフォルトの名無しさん
19/02/23 12:15:44.69 tE6+E9hM0.net
>>539
ノンプログラミングはだめだろうね。
今のRADはGUIのエディタで作ってもいいし、
コードで書いたとしてもGUIに反映されるようになってる

556:デフォルトの名無しさん
19/02/23 12:23:17.31 n0LspLEFd.net
>>538
Web Formsね

557:デフォルトの名無しさん
19/02/23 12:37:28.79 K/uRyWeBM.net
WebFormは一瞬でページ作れるから
ものによっては便利だが

558:デフォルトの名無しさん
19/02/23 12:41:54.25 6swyBY50a.net
単純なページはスキャフォールディングでええやんけ

559:デフォルトの名無しさん
19/02/23 12:45:12.12 tE6+E9hM0.net
スキャフォールディングはページを作るものではなくて
ベージの一番最初のコードを生成するだけです。
その後に生成したコードを修正して作っていかなければいけません。

560:デフォルトの名無しさん
19/02/23 12:52:56.11 6swyBY50a.net
修正すればええやんけ
ポトペタより簡単でソースも綺麗やで
ポトペタなんてマウス操作とアイコン探しの悪魔的苦行の繰り返しやないか
あれが楽とかマゾでもよう言わんで

561:デフォルトの名無しさん
19/02/23 13:01:24.38 K/uRyWeBM.net
いやちゃんとしたい時はMVCなんだが
WebFormの存在理由もそれなりにある

562:デフォルトの名無しさん
19/02/23 13:09:09.75 K/uRyWeBM.net
さすがにVueとかにはくっつけられないから
スレ違いだったな
RazorPagesはくっつくかな

563:デフォルトの名無しさん
19/02/23 21:37:53.78 QCtZNWil0.net
>>538
MVCやSignalRも知らないおバカさん

564:デフォルトの名無しさん
19/02/24 02:35:29.23 7mFkjhD10.net
>>549
RADの話が出たからWebFormsみたいなクソが消えた歴史を考えろっつってんのに、何がSingnalRだよ。文脈読め。

565:デフォルトの名無しさん
19/02/24 02:58:24.82 O4f1RypY0.net
>>550
ASP.NET=Web formsっていう発想自体が頭おかしいんだよ

566:デフォルトの名無しさん
19/02/24 03:19:47.26 wTcw/8fo0.net
お、お、お、おちけつよ!

567:デフォルトの名無しさん
19/02/27 15:11:35.98 XUj+n7600.net
Reactというかredux?見てて思うのは、
お前らネットワークプロトコルでも作ってるのかよって話
普通にメソッド実行すればいいのに、
パケットデータ作って、そのパケット解析して処理実行す�


568:� メソッド一つ実行すりゃ終わりなのに 関数型にしたいのかどうか知らんが、目的を履き違えてる。 バグを減らすために関数型にする。そのために複雑にしてバグを作りやすくしてどうする 関数型じゃなくていい、バグを減らすためにシンプルにしろよ



569:デフォルトの名無しさん
19/02/27 15:24:17.37 PVZtgHDGr.net
>>553
しかしflux概念は世界的に認められてるから広く使われるわけで、キミの主張vs世界中の開発者の同意でキミが勝てるわけないよね
そのへんどうすんの?

570:デフォルトの名無しさん
19/02/27 16:07:14.12 XUj+n7600.net
反論しないで、世界に広める方法を聞く
変なレスだなぁw

571:デフォルトの名無しさん
19/02/27 16:34:28.95 XUj+n7600.net
ところでさ、
function foo() {
 return { hoge: 1, hage: 2 };
}
expect(foo()).toEqual({ hoge: 1, hage: 2 });
みたいな意味のないテスト書いてないよな?
固定の連想配列返す関数のテスト書いても意味ないぞ
二度手間なだけで、それを避けるためにどうせコピペするんだろうし

572:デフォルトの名無しさん
19/02/27 17:20:11.35 fbQufi7O0.net
>>553
メソッド実行するって具体的にはどういう形?
dispatchの前処理と後処理を自分で追加したメソッドを
ストア(↓)に生やすようなのをイメージしたけど合ってる?
URLリンク(github.com)

573:デフォルトの名無しさん
19/02/27 17:45:18.46 XUj+n7600.net
>>557
ようするに、
Actionみたいな「処理の内容をパラメータ化したオブジェクト」を
いちいち作らせるのをやめてくれ、
Reducerみたいな、switchでActionのパラメータみて分岐して処理する
ようなおのをいちいち作らせるのやめてくれ
ってことだよ。
onclickにincrementメソッド書いたら、+1するincrementメソッドが呼ばれます。
でいいじゃねーか。直感的だろ?それで別にテストできないわけじゃないんだし

574:デフォルトの名無しさん
19/02/27 17:50:17.86 avwBchUKa.net
IOモナド不要論に近いものを感じる
単にReactを選択しなければいいだけなのにね
選択肢の中に一つでも気に入らないものが混じってると全否定を始めるんだからもう

575:デフォルトの名無しさん
19/02/27 17:53:11.18 XUj+n7600.net
IOモナド不要論というか、IOモナド至上主義じゃないってだけ
副作用排除は素晴らしいよ?でも複雑にしてまでやることじゃない。
バグは副作用でも増えるだろうが、複雑にしても増えるんだよ
書くものが増えれば増えるほど、書き間違いも増えテストも増えるんだから

576:デフォルトの名無しさん
19/02/27 17:58:32.64 fbQufi7O0.net
>>558
その形なら単にReduxを使わなければ良いだけでは?
使用を強制されてるのなら何とも言えないけど
ちなみにうちは本開発でReduxを使ってない
別に嫌ってるわけでもなく、とりあえずバニラなReactでやってるうちに
Contextが来たのもあって特に入れたい状況にもならずって感じ

577:デフォルトの名無しさん
19/02/27 18:03:11.05 XUj+n7600.net
>>561
たぶんReduxは捨てろって流れになるだろうね。
それが可能になるContext
行き過ぎた関数型ブームなんだろうな。
だいたい行き過ぎて戻ってやっと最適な状態になる。
あと別に使用を強制されてない。
React自体使ってないものw

578:デフォルトの名無しさん
19/02/27 18:13:46.28 gzx7LPiYa.net
>>553
ていうかまず状態って言うほどサイト全体で持つ必要あるのか?って思うね
大体の場合はコンポーネントの中で閉じててもいい場合が多いし
本当にサイト全体で持ちたいデータはリロードとかて吹っ飛ばないようにlocalstrageにでも書いた方がいいんじゃないかとか

579:デフォルトの名無しさん
19/02/27 18:21:13.76


580:U+okKr8Fa.net



581:デフォルトの名無しさん
19/02/27 19:19:39.92 6a6tMlMF0.net
どのコンポーネントが状態持ってるのか探す方がめんどくさいじゃん。

582:デフォルトの名無しさん
19/02/27 19:36:24.78 haTnnqieM.net
reactは好きだけどreduxめんどくさい論は大賛成!
hooks + contextに大期待!!

583:デフォルトの名無しさん
19/02/27 20:01:14.80 gzx7LPiYa.net
>>565
その部品の情報がその部品で閉じてるなら探す必要ないじゃん?

584:デフォルトの名無しさん
19/02/27 20:20:53.09 33VvYXhGp.net
Redux使わずcontextAPIのみでアプリ作ったけど、なかなか良い感じ
シンプルisベストだね

585:デフォルトの名無しさん
19/02/27 22:38:29.67 U+okKr8Fa.net
マルチページ+Vueがベスト

586:デフォルトの名無しさん
19/02/27 23:30:28.79 6a6tMlMF0.net
>>567
その部品で閉じるような状態ならな。
二つ以上の部品にまたがる状態だってあるだろ。

587:デフォルトの名無しさん
19/02/27 23:47:31.09 XUj+n7600.net
だから2つ以上の部品にまたがる所だけで良くなるだろ

588:デフォルトの名無しさん
19/02/27 23:49:27.29 PVZtgHDGr.net
reduxなんて面倒くさいレベルに入らないだろ
しょぼいシステムしか作ったことがないんだろうが

589:デフォルトの名無しさん
19/02/27 23:52:10.20 6a6tMlMF0.net
>>571
その分け方がわかりやすいと俺は思わん。アドホックな部分が増える。

590:デフォルトの名無しさん
19/02/28 00:01:04.44 IYEK0cme0.net
>>572
つまりあなたも面倒くさいって思ってるわけですよね?
このぐらいのレベルなら耐えられるって言ってるだけだし

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

592:デフォルトの名無しさん
19/02/28 00:24:32.39 PBjHM/k00.net
それはサーバーサイドしか知らないのに画面のエフェクトだデザインとロジックの分離だ言う
その人個人の問題なんじゃないかね。

593:デフォルトの名無しさん
19/02/28 00:30:03.58 IYEK0cme0.net
デザインとロジックが分離されてないのは本当だろ

594:デフォルトの名無しさん
19/02/28 01:39:22.43 FLrrxMk0r.net
>>574
こんなのより何千倍も面倒くさいプログラミングしてきてるから面倒くさくねえ部類って言ってんの
頭イカれてんのか?

595:デフォルトの名無しさん
19/02/28 06:14:57.31 WHNbTV5sp.net
何千倍も難しいって、口調が前にどこかのスレで見たような気がする
確か自称ゲームプログラマーじゃなかったけ
私大文系はクズだのヴァカだの幾何学的計算が出来れば高卒でも理系とか意味不明な発言の人だった

596:デフォルトの名無しさん
19/02/28 06:16:05.22 WHNbTV5sp.net
バカじゃなくてヴァカという変な単語を連呼してたので覚えてる

597:デフォルトの名無しさん
19/02/28 06:50:50.42 6H8i6ZZe0.net
てかテキストボックスのチェンジイベントでイチイチReducerだかDispatcherだかを経由してストアに書きに行くもんなの?
確定ボタン押した時でよくない?

598:デフォルトの名無しさん
19/02/28 06:55:29.34 6H8i6ZZe0.net
>>577
デザインとロジックが分離してない上にVueみたいにコンポーネントとして独立するわけでもないっていう中途半端さがね

599:デフォルトの名無しさん
19/02/28 08:52:57.67 jOvvow1Ud.net
落ち着け、議論を飛び出してケンカになってるぞ。そこまでくると他の人に迷惑だから頼むから我慢して2、3日スレから離れて観て欲しい。

600:デフォルトの名無しさん
19/02/28 08:57:16.34 w/cn9HKca.net
>>583
ビビんなよ。5chではよくあることだろ

601:デフォルトの名無しさん
19/02/28 10:41:44.71 6x03bq62a.net
ビジネスロジック→Service(バックエンド)
プレゼンテ


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



603:デフォルトの名無しさん
19/02/28 10:50:58.35 GdwBglQC0.net
>>585
そこに、ActionとAction CreatorとReducerとStoreは
どこに含まれるの?って話だよ
アーキテクチャ上、必要ないものが多すぎる

604:デフォルトの名無しさん
19/02/28 12:22:34.05 qWkUq+5ha.net
>>586
分類するなら全部プレゼンテーションロジックだろう
SPAとかいう誰得要件のせいでプレゼンテーションロジックが過剰に肥大化複雑化してしまった結果それらが産まれた
従来のマルチページに戻すだけでスッキリ解消される

605:デフォルトの名無しさん
19/02/28 12:46:03.68 jOvvow1Ud.net
誰得っていうけどブラウザアプリ作るならSPAの方がUXが劇的に向上するケースが殆どじゃないか?

606:デフォルトの名無しさん
19/02/28 12:49:53.87 qWkUq+5ha.net
UXが向上したということにしたいだけでは?
案外ユーザーはシンプルなMVCのほうが簡単で良いと思ってるものさ

607:デフォルトの名無しさん
19/02/28 13:05:42.47 jOvvow1Ud.net
シンプルなMVCかどうかの判別ってユーザーからできるの?ユーザーってもしかして顧客のこと?

608:デフォルトの名無しさん
19/03/02 15:08:24.35 IgVX/rLT0.net
年明けてから二ヶ月経過したけどなんだかんだ書籍出てるな
売れてるんかねぇ
動かして学ぶ!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

609:デフォルトの名無しさん
19/03/02 16:45:37.50 yWxTFA8Fp.net
ウチの会社でReactのアプリを独自UIの新規開発からロジック周りまで全部できるPGは一人しかいないわ
オフショア入れて百人以上PGいるけど、みんなFlexbox使って自分でUI書けませんとか、エフェクトのアニメーションを自作できませんとか、htmlとcssで躓いてる
デザイン系が得意なPGだと今度はDBやAPIが良く分かりませんという風になる
デザインとロジックの分離が不完全なので不器用な奴には使えない
結局Reactのアプリ制作はその一人が設計構造を考えて何人かで分担して作ってる
その一人がいなくなったら改修も容易ではない

610:デフォルトの名無しさん
19/03/02 16:52:47.42 IgVX/rLT0.net
>>592
そう最低限なんでもできるリーダーがいなきゃ初期導入すら始まらんもんな
浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる

611:デフォルトの名無しさん
19/03/02 17:18:02.29 mksg7qZ+0.net
html5で独自属性を使うときはdata-*で命名する規則になってるけど
どのフレームワークも無視してるのはなぜ?

612:デフォルトの名無しさん
19/03/02 20:30:41.54 b3M+C2mw0.net
「知りません」は別に問題無いけど「やってみても分かりません」という奴は
PGとも呼べない半人前だと思う
でも多いんだよなそういうの

613:デフォルトの名無しさん
19/03/02 20:45:13.26 ujIKCjUH0.net
>>594
その属性はビルド後も残るの?

614:デフォルトの名無しさん
19/03/02 21:47:05.25 gbDUCVtH0.net
>>595
「よく分からないけど動いた」

615:デフォルトの名無しさん
19/03/02 21:51:40.27 Fdvrrf47r.net
>>592
フロント、バックエンド、DB、インフラからデザイン、写真加工、キャラ背景画作成、アニメーションまでできる俺は頂点に立てるかな?

616:デフォルトの名無しさん
19/03/02 22:08:26.00 Lvrdovo/0.net
>>593
> 浸透すらしてないのにフロントとバックを分業分業言い過ぎだとは常々思ってる
一人でなんでもにできる人が居ないから、分業にしないとだめって話なんじゃないの?
Reactでどうやって分業するのかしらんが。
Reactは設計レベルで分業がし辛いフレームワーク

617:デフォルトの名無しさん
19/03/02 22:12:30.11 bakyLAA50.net
rails、angular、vueなら分業しやすいとでも?

618:デフォルトの名無しさん
19/03/02 22:15:55.89 Lvrdovo/0.net
まあそうだね。
RailsのERBはHTMLに近いから編集してもらえるし、
AngularもHTMLベースだから。
ReactとVueはJavaScriptの中にHTMLの断片が埋まってるから
それを修正して思い通りのデザインを作ってもらうのは無理だろう

619:デフォルトの名無しさん
19/03/02 22:24:29.37 20MtSIx6a.net
フロントとバックは分業したほうが楽だ
どっちもできる人は多くない
いたとしても負荷がかかるから無理強いするとブラック企業になってしまう
それに分業といってもAPI(作る|呼ぶ)だけだろう
難しいとこなんて何もない

620:デフォルトの名無しさん
19/03/02 22:33:41.00 IgVX/rLT0.net
>>599
逆に分業じゃなっきゃできんってヤツはわざわざ勉強してまで新しい技術を導入したいとかいい出すヤツは居ないっていう話だよ
>>600
なんでRailsねじ込んできた?


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch