- 1 名前：デフォルトの名無しさん [2019/03/09(土) 22:02:33.71 ID:47IMMy0/.net]
- 実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
※前スレ
Vue vs React vs Angular
mevius.5ch.net/test/read.cgi/tech/1545395856/
★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
- 357 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 17:51:56.66 ID:oqNH9LQH.net]
- Google I/O 2019 (5月7日〜9日)で
Angularと対立することになる Flutter for Web (Hummingbird) の新たな発表があるそうだから
Angularを考えるのはその後にした方が良いと思うよ
- 358 名前：デフォルトの名無しさん [2019/04/13(土) 21:46:54.35 ID:Fox9b+v2.net]
- >>357
Flutter面白そうだね。たしかにクロスプラットフォーム開発はスタンダードが無いから学習するなら狙い目なのかも。現状swiftとkotlinでゴリゴリ書いてるけどどうしてもrealmが必要なんだよね。
Webアプリの弱点の一つオフラインDBをある程度解決できるなら真面目に検討したいんだが。
- 359 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 21:50:11.69 ID:XHhHrn1r.net]
- >>358
オフラインDBが弱点って具体的にどういうこと？
- 360 名前：デフォルトの名無しさん [2019/04/13(土) 22:53:34.64 ID:Fox9b+v2.net]
- >>359
ユーザデータを大量に保存してローカルで処理する系のアプリは現状webアプリだと厳しい。主に速度面で。
indexedDB+lovefieldみたいな組み合わせでsqlぽい事はできるけど、flutterがアプリ+webのクロスを狙うならソコどうするのかなって。DBの同期まではできなくても、一つのスキーマから全プラットフォームで動作するDB作れたら夢だよね。
- 361 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 23:59:03.97 ID:6byp94bf.net]
- もういい加減 "ウェブアプリ" なんてやめればいいのに
ローカルでデータを大量に処理ってそれ、
ウェブである理由はアプリのインストールとアップデートのためだけじゃん
- 362 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:10:50.46 ID:WjGL7oJM.net]
- サーバーでやっちゃだめなん？
- 363 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:30:22.71 ID:8JmU//KT.net]
- モバイル端末のストア経由っていうのが煩わし過ぎるからなぁ
- 364 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:45:03.08 ID:/V8zrPr0.net]
- >>360
ごめん、おれの経験不足なのかやっぱわからん。
>>ユーザデータを大量に保存してローカルで処理する
↑
クライアントは1台だけなのに、速度が気になるほどデータを処理する例が全く思い付かない…
- 365 名前：デフォルトの名無しさん [2019/04/14(日) 01:13:17.48 ID:jIyXk5jh.net]
- バックエンド主義の人が強引に考えたついた難癖にしか見えない
フロント処理で充分
- 366 名前：デフォルトの名無しさん [2019/04/14(日) 08:24:48.36 ID:Qhel4iVb.net]
- いやまあ、別に現状でも工夫すればできるからブラウザのローカルDBにそこまでこだわっては無いよ。課題も多いし。ユーザがいつでも削除できるとか。
ただネイティブアプリとwebアプリが同じコードとロジックを共有するなら避けられない課題だろうなと。
- 367 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 10:03:52.66 ID:U21XdTdR.net]
- ユーザーが自由に削除できることが課題？？
世の中のソフトウェア殆どがそうだけど何か困るのか？
- 368 名前：デフォルトの名無しさん [2019/04/14(日) 11:45:21.51 ID:fnTRmDnx.net]
- ほんと早くMac死んでほしい
- 369 名前：デフォルトの名無しさん [2019/04/14(日) 13:07:21.11 ID:/kyrD1Ys.net]
- >>367
indexeDBのことだよ。ブラウザのキャッシュクリアで簡単に消えちゃうだろ。間違えて消してクレームくるんだよ。
- 370 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 12:25:48.71 ID:sResMPAv.net]
- Reduxわかんね
- 371 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 18:58:19.12 ID:r0ZMOOHm.net]
- >>370
大丈夫。俺もわからん
てか、あんなの小規模なWebアプリケーションにはいらん
- 372 名前：デフォルトの名無しさん [2019/04/15(月) 20:20:50.21 ID:HmQvEiCf.net]
- Reduxわからんの？
かわいそうに
- 373 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:23:02.95 ID:S/0/c6v4.net]
- Reduxわかるの？
じゃあ、Reduxを使うことで、
どんなメリットがあったか教えて
- 374 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:25:51.20 ID:IXPbMXJW.net]
- 処理の流れが一方向なのでわかりやすい。
- 375 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:33:46.03 ID:S/0/c6v4.net]
- > 処理の流れが一方向なのでわかりやすい。
文章がつながってない。
処理の流れが一方向なのはまだいいとして、
なんでそれで、わかりやすいということになるのか？
そもそも "処理の流れ" が一方向であるならば、
何を使っても一方向にしかならないはず。
Reduxを使うことで、一方向になるわけではない。
また双方向とか一方向というのは、局所的に見るか
全体的に見るかの違いでしかないのではないか？
例えば電話での会話だって、双方向に見えても、実際には自分の通話口から
相手のスピーカー、相手の通話口から自分のスピーカーへの一方向通信だ。
一方向も双方向も大した違いはない。
- 376 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:40:44.13 ID:IXPbMXJW.net]
- まあ実際、説明の難しいところではある。
>また双方向とか一方向というのは、局所的に見るか
>全体的に見るかの違いでしかないのではないか？
これはその通りだがその違いが大きいとしか言いようがない。
treeをたどるロジックというのは一般に指定が複雑になりやすいとか、
ノード間のコミュニケーションがコールバックでつなぐと相当複雑になるとか
色々あるけれどその辺を単純化できてるようには思う。
電話の比喩を持ち込むならマイクとスピーカーが同じより違った方が良いとかになるのかな？
- 377 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:43:17.24 ID:S/0/c6v4.net]
- もう少し具体的な例を出そう。
getterとsetterと言えば、俺が言いたいことが見えてくると思うが
Reduxが言いたいことは、単にgetterは値を取得するだけ
setterは値を入れるだけにしましょうってことだろう？
まあgetter/setterは別の批判も有るから、getter/functionの方が良いか？
もう一つの例としてRESTで例えるならば、GETは何度GETしても状態は変わらない。
単にデータを取得するだけ。POSTはデータを送信するだけ。
この考えかたと同じことだろう？
これをオブジェクト指向に当てはめるならば、このメソッドはデータを更新し、
このプロパティはデータを参照するという話でしか無い。
これは普通のオブジェクト指向のベストプラクティスとなんらかわりはないんだが、
Reduxを使う必要はあるのか？ このメソッドはGETかPOST（相当）であると
ドキュメントに書けば済む話だろう？
- 378 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:49:52.40 ID:S/0/c6v4.net]
- マイクとスピーカーで分けたほうが良いという考え方は
反対しないが、まともな設計能力が有るならば、最初からそうしているわけで、
Reduxを使う理由にはならない。
まともな設計能力がない人のための矯正器具=Reduxということか？
だが矯正器具はいつまでも使っているわけじゃあるまい？
まともな設計能力がついた人にとっては、邪魔な道具でしか無い。
- 379 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:53:26.60 ID:IXPbMXJW.net]
- >>378
そうだね。あなたはredux使う必要ないと思うよ。
あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。
- 380 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:58:32.77 ID:S/0/c6v4.net]
- もちろん、Reduxが何の負担もなしに、もしくは低い負担で
ベストプラクティスを実現できるというのなら導入する価値はあるが、
一方向を得るために、Reduxのやり方で設計しろっていうのは負担が高すぎる。
Reduxのやり方はルールが多すぎて単純ではないからだ。
Reduxの設計方針を理解しないまま、Reduxを使うよりも
まずは知識をつけるのが先だろう？
このメソッドは書き込みを行うメソッド、このメソッドは読み込みを行うメソッド
明確に分けたほうが良いと。そしたらあとはメソッドのコメントに書けばすむだろう？
（普通はコメントで書くまでもなく、メソッド名からどちらであるかはわかる）
それだけのことなのに、それを矯正するためのフレームワークというのは
意味不明すぎる。便利にするためのものじゃない。矯正するためのもの
まったくもってReduxはわからん。
- 381 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:59:53.90 ID:r0ZMOOHm.net]
- スパゲッティになるならreduxは必須
でもそうならないなら本当に必要ない、とは思う
コード量多くなるからね
- 382 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:02:11.16 ID:S/0/c6v4.net]
- >>379
> あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。
だから聞いたんだよ
「どんなメリットが"あったか"教えて」
どんなメリットが "あるのか？" じゃない。"あったのか？" だ。
あんただってそれなりにまともな設計ぐらいできるだろう？
あんたの能力がどれくらいで、Reduxを使うことで
どういうメリットが、あったんだ？ なにかを矯正されたんか？
俺は矯正が必要なほど設計が下手なつもりはないんだが。
- 383 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:04:00.12 ID:IXPbMXJW.net]
- とりあえずメリットは書いたし、びっくりするほど文章読んでないのも理解できる。
- 384 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:06:15.53 ID:S/0/c6v4.net]
- Reduxがやってるのって、
1. オブジェクト指向のクラスがあります。
2. クラスから読み込み専用メソッドを抜き出します。
3. クラスから書き込み専用メソッドを抜き出します。
4. クラスに残ったものはデータのみです。これを一つのオブジェクトとしてPublicにします。
オブジェクト指向のクラスが、
読み込み専用メソッド、書き込み専用メソッド、データ の３つに分離されました。
ってだけだからな。
- 385 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:07:20.84 ID:S/0/c6v4.net]
- >>383
いうだけなら誰でもできる。
コミュニケーション取ろうぜｗ
- 386 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:33:29.21 ID:g9zAAmJv.net]
- 処理をAPI化するイメージかな必ずその経路を経由して状態を変更するからグローバル変数みたいなどこからでもアクセスできるけどちゃんとアクセス経路は限定できるみたいな
- 387 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:36:35.56 ID:S/0/c6v4.net]
- その "グローバル変数" をクラスにして、APIをクラスのメソッドにすれば
普通のわかりやすいオブジェクト指向設計になるんですが？
Reduxの存在意義って？
- 388 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:40:15.54 ID:S/0/c6v4.net]
- そしてReduxは、クラスのメソッドを抜き出すだけじゃないからね
メソッド（関数）は普通にメソッドに引数渡して普通に呼び出せるが、
Reduxは「引数つきでメソッドを呼び出すため」のデータを作って
データを投げて、そのデータ解析して（←ここ自分で作る）
そしてやっとメソッドを呼び出すという無駄なことをしてる。
- 389 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:46:24.27 ID:S/0/c6v4.net]
- 結局の所 Redux はわかりやすいものではなくて
（わかりやすい = ただのセールストーク）
オブジェクト指向 VS 関数型（？） の戦いから
俺たちはアンチオブジェクト指向で行くぜ！という派閥から
生まれたものに過ぎない。
それ自体は考え方の違いでありだとしても、
Reduxの仕組みは、それを実現するためのルールが多すぎて
百歩譲ってわかりやすいとしても、そのルールに従って
コーディングするためのコストが大きすぎて小さいプロジェクトではペイしない
（大きいプロジェクトでもはたしてペイできるかどうか）
"設計方針の違いを反映させるためだけ" でしかなくて、
それしか得られない割に、コストが大きすぎる
- 390 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:55:58.52 ID:IXPbMXJW.net]
- 別にコールバックでdom treeたどるのが大変でないならredux使う必要ないわな。
それでいいと思うよ。
てか読んでないのにコミニュケーションを要求するとか
まともに設計できる人間じゃないことはわかるよ。
- 391 名前：デフォルトの名無しさん [2019/04/15(月) 22:15:47.71 ID:HmQvEiCf.net]
- 一度Reduxで作ってみたら後は別のプロジェクトでも同じように作ればいいだけだから何も問題はない
最初だけ複雑に思うだけ
- 392 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 23:37:35.47 ID:IXPbMXJW.net]
- 確かにreduxのproviderとconnectの対応は暗黙な繋がりでわかりにくいところはあると思うんです。
reduxというかfluxの実装として他に方法はあるかもとは思う。
- 393 名前：デフォルトの名無しさん [2019/04/15(月) 23:45:03.60 ID:o5Us7+p1.net]
- vue公式からの引用で恐縮だが、、
もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。
あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。単純な ストアパターン が必要なだけかもしれません。
しかし、中規模から大規模のSPA を構築する場合は、Vue コンポーネントの外の状態をどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です:
Flux ライブラリは眼鏡のようなものです: それらが必要になったときに知るのです。
- 394 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:27:12.19 ID:+U4ppNzc.net]
- まあ大きなもの作ったことない人にはわからん世界だと思うよ。俺も学生の頃はフレームワークの必要性とかさっぱり理解できなくて制作者の自己満足だと思ってたもん。
そして必要になったことがない人にはどんなに説明しても納得してもらえないもんだよ。
- 395 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:30:35.35 ID:QBtHnjEv.net]
- 今軽くReduxググってみたけど何がしたいのかさっぱり分からんｗ
jsにprivateが無いからsetter/getterのレイヤー作ってんの？
- 396 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:42:55.64 ID:QBtHnjEv.net]
- いやfluxで調べたら少しわかった
オブジェクト指向でいちいち相互参照とか面倒くさいから
シングルトンにデータ全部詰め込んでおこうぜ見たいな話だな
- 397 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 02:31:52.71 ID:+8WSocTt.net]
- おまいら、vueの利点として、サイトの一部分のjQueryで
作っていた部分をちょこっと置き換えるのに良いって
言ってるくせに、それがいつか大規模なSPAに変わると思ってんの？
- 398 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 02:40:36.60 ID:+8WSocTt.net]
- >>393
こっちのほうがわかりやすくね？ｗ
Flux ライブラリはサスペンダーのようなものです: それらが必要になったときに知るのです。
（意味 デブになれば必要な理由がわかる。だがそもそもデブになんかならねーし、デブなのが一番の問題）
- 399 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 04:49:30.73 ID:vZMMDQFG.net]
- 猫も杓子もreduxだけどほかのflux実装の感想聞きたいわ
それなりの規模で使用した、もしくはしてるみたいな人おらんの?
つかfacebookはfacebook/flux使ってるのかね
メンテされてる感じせんけど
- 400 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 07:41:32.20 ID:9wO+Q4tD.net]
- >>397
そんなこと書くと議論がすり変わりそうだぞ。
ID:IXPbMXJWが書いてくれたことで十分でしょ。それで納得できる人もいればできない人もいる。
万人が使うものでないことは間違いないわけだし。それはスレタイの3つがそもそもそうなわけだけど。
- 401 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 08:31:26.34 ID:dFuxCqAG.net]
- よくまとまってる。
https://mizchi.hatenablog.com/entry/2018/10/04/101308
> Middleware に何を使うかで、 redux ユーザー同士の非同期のノウハウは共有できず、
> 分断されている(thunk, saga, steps, epic, no middleware)
これが一番の問題点。
- 402 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 08:57:52.42 ID:HGB3ondZ.net]
- >>401
suspence来たら全部ゴミ。
- 403 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 14:12:45.48 ID:sdqnJ2Ku.net]
- suspence見たけど状態管理をsimple-cache-providerに移動しただけな感じがする
明確なIDが無いリクエストみたいなのが渡ってくる場合だと
コンポーネントと非同期キャッシュの対応付けが面倒になりそう
コンポーネントインスタンス毎に一意ID生成してstateに保持だと本末転倒な感じだし
- 404 名前：デフォルトの名無しさん mailto:sage [2019/04/17(水) 11:15:37.77 ID:CEJ7HETE.net]
- 静的サイトジェネレーターでBlog作りたいのだが情報少ないね。
VuePressがよさげなのだが
- 405 名前：デフォルトの名無しさん mailto:sage [2019/04/17(水) 12:37:53.92 ID:q/9NxBQE.net]
- なんでvuepress？nuxtよりいいとこある？
- 406 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 01:12:24.22 ID:+Qj1NZId.net]
- ガチガチのSPA作ろうと思ったらAngularじゃねーの？
ionicでwebアプリ作ってみたけどストレスなく作れて良かったよ
- 407 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 01:21:26.96 ID:+Qj1NZId.net]
- まずフロントエンド周りに関わる仕事はしないほうがいいと思う
全てが無駄になる可能性が高い
- 408 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 07:16:50.87 ID:xDdfDEdP.net]
- reduxで一回のdispatchで2つのstateを一緒に更新したい場合ってreducerどう書くのが正解？
とりあえずreducerのreturnをjsonオブジェクトみたいにすれば良さそうではあるんだけど
- 409 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 09:46:39.79 ID:FtQwjU5R.net]
- ReactのReduxはそろそろ廃れて欲しい
ホックで何とかなるでしょ
Reduxは奇形的だと思う
- 410 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 10:58:53.81 ID:JWUHkBKS.net]
- >>405
じゃあNUXT.jsでｗ
こっちもそんなに情報ないよね
- 411 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 11:12:33.86 ID:nwidurpX.net]
- vue関係は中国語が共通言語
- 412 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 12:26:49.21 ID:+Qj1NZId.net]
- Vue vs React vs Angular
とあるがどれも学ばないというのが4の選択肢が正解じゃないか
他に時間を投資すべき
どうしても必要ならVueを摘むの適切
それでもVueを深く学習してVueメインでガチャガチャ動くサイトなんて作っちゃいけない
- 413 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 13:18:32.08 ID:PeuY0IP9.net]
- >>412
それな。どうせどれ使っても数年で消える。
jQueryだけが今もこれからも使われて続ける
- 414 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 13:28:48.77 ID:f6QMigdn.net]
- いいんだけどさ、forthスレやqbasicスレ、coqスレなんかにも「必要ないって言ってるでしょ！」ってムキになって書き込みに行ってるの？ｗ
- 415 名前：デフォルトの名無しさん [2019/04/18(木) 14:17:31.95 ID:rqGOrs8Z.net]
- 一部にvue入れるのもアリだよ。検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。俺もそこから始めた。
- 416 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 14:22:13.48 ID:+Qj1NZId.net]
- jQuery固執おじさんもいらない
- 417 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:15:08.38 ID:FtQwjU5R.net]
- jQueryが神すぎて、これは捨てられない。
- 418 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:24:16.71 ID:PeuY0IP9.net]
- >>414
いったことないで？全く知らん分野だし
- 419 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:24:58.29 ID:PeuY0IP9.net]
- >>415
> 検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。
具体例で見せてほしい
- 420 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:27:28.57 ID:uN7CTDaS.net]
- フォームはVueの練習には良いよね。
でも大きく要素が入れ替わらないTodoリストくらいだったらJQuery + HTMLのテンプレート要素で作ったほうが簡単に感じる。
テンプレート要素が適用しづらいなって思ったら使うべきか。
- 421 名前：デフォルトの名無しさん [2019/04/18(木) 16:34:11.27 ID:rqGOrs8Z.net]
- >>406
だよね。angular思ったより全然使いやすい。迷う事が少なくていい。
- 422 名前：デフォルトの名無しさん [2019/04/18(木) 16:37:48.10 ID:rqGOrs8Z.net]
- >>420
因みになんだけど、jQueryのテンプレートエンジンは何を使ってるの。俺はよくjsRender使ってた。
- 423 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:46:45.54 ID:PeuY0IP9.net]
- >>422
俺は、lodash (underscore) のtemplateだな
https://lodash.com/docs/4.17.11#template
https://underscorejs.org/#template
このライブラリはテンプレート専用じゃなくて
通常のプログラミングでも非常に便利なライブラリなので
テンプレートを使うかどうかに関係なく組み込んでる。
- 424 名前：デフォルトの名無しさん [2019/04/18(木) 16:50:16.12 ID:rqGOrs8Z.net]
- >>419
具体例いらんだろう。長くなるとスレチになりそうだし公式見てほしい。
- 425 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 17:13:10.20 ID:PeuY0IP9.net]
- >>415
残念ながらフォームを作る場合に、DOM APIよりもvueは便利だが
jQueryよりも便利ってことはないんだよ
具体例、ないだろう？そういうこと
- 426 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 20:14:06.33 ID:G2shfX5j.net]
- 廃れるものを一通り勉強するってのも乙なもんだけどね。
- 427 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 20:19:22.93 ID:IFD45nW1.net]
- jquery使うといつか必ず後悔するんだよな
- 428 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 20:29:07.13 ID:PeuY0IP9.net]
- それはないな。DOM APIを使うのと（jQueryの方が生産性が高い以外）何も変わらんのだし
- 429 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 20:31:42.05 ID:xDdfDEdP.net]
- そらWeb"サイト"作ってるところjQueryは使い続けられるだろ
元々フレームワークを使うのはWebシステムを構築する人向けなんだから
平たく言えば例えばスタンドアローンアプリをWebに置き換える様な案件向け
別にそういうモノを作る予定なんてないって人はjQueryは使い続けてても全く支障はないと思うよ
- 430 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 21:46:16.31 ID:fWketiWf.net]
- 基本jquery使う限りアングラーさんしかないのか
- 431 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 21:47:32.38 ID:FtQwjU5R.net]
- tsとjqは相性悪いからangularもビミョー
- 432 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 22:20:30.68 ID:PeuY0IP9.net]
- >>429
Webシステムじゃよくわからん。
JavaScriptを一切使わないWebシステムだって有るんだし
> 別にそういうモノを作る予定なんてないって人はjQueryは使い続けてても全く支障はないと思うよ
ずっとそれを言ってる。ウェブであちこちのサイト見て、
そのサイト、アプリで作ればいいのに？って思うことある？
そういうことだよ。ウェブで皆が見てるものの大半は、アプリ用のフレームワークなんか使っちゃダメ
- 433 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 23:11:25.60 ID:975/tdja.net]
- 流行の移り変わり前提ならAureliaになるんかね
- 434 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 23:16:27.84 ID:rt2qFRnt.net]
- >>433
なぜ？
- 435 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 00:19:18.93 ID:ZJZT2sL1.net]
- 暇な天才達がおもちゃを作り
凡人の我々が疲弊する
- 436 名前：デフォルトの名無しさん [2019/04/19(金) 00:56:42.83 ID:nz9XNE8t.net]
- 実務の世界ではwebは運用を考えないといけないから
ビルド必須なのは辛いんだよね
JAM Stackにバリバリ行きたい気持ちはあるのだが
結局はjQueryを使った無難なサイトがメインになって
しまう
エンジニアは運用の視点を忘れたらいけない
サイト制作にはjQueryが必須だと思う。
でもSPAで作る時は日本語のドキュメントがまだ出て
来てないような最前衛の実装方法で暴走するけどねw
- 437 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 01:05:48.22 ID:mPb3RkdR.net]
- いい加減>>1読め
- 438 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 07:03:38.13 ID:SkMw1Cjg.net]
- >>432
君には一生縁のない世界みたいだからおうちにおかえり
- 439 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 07:15:41.26 ID:GnXLTXUb.net]
- >>438
反論できなくなったときの言葉だねｗ
- 440 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 08:37:31.56 ID:gmGy9oTC.net]
- ちょっとしたサイトなら、jQuery, Lo-dash のテンプレートエンジンで十分。
Underscore.js のテンプレートエンジンを使ったフレームワークが、Backborn.js
フレームワークを使うのは、データベースを使うような、web アプリ
Ruby のテンプレートエンジンの ERB でも、基本は、文字列を連結していくような原始的なもの
- 441 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 08:55:09.83 ID:p/ztoCUW.net]
- 本当にちょっとしたものならそんな何万文字ものライブラリいらんだろ
const template = ctx => `
<html>
<head><title>${ctx.daimei}</title></head>
<body>${ctx.naiyou}</body>
</html>
`
const data = {
daimei: '題名',
naiyou: '内容',
}
const html = template(data)
- 442 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 10:13:16.52 ID:ZJZT2sL1.net]
- Vue試してみてるけど
Vuexってもしかして必須か
コンポーネント間の簡単な操作でも複雑に感じたわ
それならもうAngularみたいに全部入りでいいじゃんと思いました
- 443 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 10:19:03.41 ID:JukS+GDU.net]
- >>442
世界中でどれか一つに統一されるならAngularをおしたい。
慣れた時の開発効率やわかりやすさはAngularだと思う。
- 444 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 11:22:56.56 ID:GnXLTXUb.net]
- >>440
かいてることめちゃくちゃ
> ちょっとしたサイトなら、jQuery, Lo-dash のテンプレートエンジンで十分。
「ちょっとした」の意味がわからん。
そもそもテンプレートに大きいも小さいもないだろ
> フレームワークを使うのは、データベースを使うような、web アプリ
データベースならウェブアプリだけやなくウェブサイトでも使うし
それはフレームワークを使う理由にはならん。
> Ruby のテンプレートエンジンの ERB でも、基本は、文字列を連結していくような原始的なもの
文字列を連結ってなんのことを言ってるんだか。内部の実装の話なんか関係ないだろ
- 445 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 11:29:00.68 ID:nz9XNE8t.net]
- lodashのテンプレは確かに便利
これは同意する
- 446 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 11:31:53.09 ID:GnXLTXUb.net]
- >>441
> 本当にちょっとしたものならそんな何万文字ものライブラリいらんだろ
何万じゃサイズがわからん。
1万文字 = 10KB程度ってことでいいのか？
何万文字 = 数十KB、画像1枚分もなくて、
ADSLや光回線なら0.1秒以下、スマホの128kbps制限中でも
2〜3秒程度でダウンロードできるサイズ
だよね？
今度から「僅かなサイズのライブラリ」って書いてくれない？
意図的に多く見せようとしてるようにしか見えないからさｗ
- 447 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 11:35:38.96 ID:GnXLTXUb.net]
- >>441
あとそのコードは単なる文字列中の変数埋め込み
テンプレートエンジンを名乗るなら、ループと条件分岐ぐらいは
対応してないとだめだろう
- 448 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 12:33:46.65 ID:p/ztoCUW.net]
- >>447
だから簡単なものならそれで十分だろうと言ってるんだが。
そんなもの必要に応じて関数書きゃいいだろう。
- 449 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 12:37:15.37 ID:p/ztoCUW.net]
- テンプレートエンジン固有の構文覚える方がめんどいわ
- 450 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 12:53:32.50 ID:pVA6rbms.net]
- >>443
でもAngular人気ないよね
日本ではなく世界の話
https://2018.stateofjs.com/front-end-frameworks/overview/
世界二万人超の開発者に対するアンケートの結果みたいなんだけど
Angularは「使ったことあるけどもう使わない」
ってのが飛び抜けて多い
なんでこんな嫌われているのか全然わからないけど
- 451 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 13:14:05.01 ID:p/ztoCUW.net]
- 確かにせっかくの大規模アンケートなんだから理由も見たかったよな。
- 452 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 13:32:46.93 ID:ZJZT2sL1.net]
- 破壊的な変更が原因でしょう
また大幅な変更あるのではとリスクを嫌ってる
- 453 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 14:22:40.05 ID:GnXLTXUb.net]
- WebComponentsの登場で
今のフレームワーク全滅するっていうのになｗ
- 454 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 15:33:13.76 ID:y1N4KfNl.net]
- >>450
本来のjavascriptと解離が大きいのがな。
やっぱ通用するスキルが身につくことが重要よ。
- 455 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 16:06:37.80 ID:eZFOlDYz.net]
- どこぞの人気投票らしきもの
https://pbs.twimg.com/media/D31uY7qUwAISCPT.jpg
- 456 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 16:08:56.45 ID:9mBO7kZI.net]
- >>453
それも結局はXHRと一緒なんじゃない？
原始的で汎用的なものを提供するけど結局ラッピングされたものの方が使いやすいってなると思う
- 457 名前：デフォルトの名無しさん mailto:sage [2019/04/19(金) 16:21:41.87 ID:GnXLTXUb.net]
- >>456
> それも結局はXHRと一緒なんじゃない？
なんでXHRの話なんか出てくるんだ？
UIコンポーネントの話なんだが
> 原始的で汎用的なものを提供するけど結局ラッピングされたものの方が使いやすいってなると思う
そりゃラッピングされたもののほうが使いやすいでしょｗ
だからjQueryの方が使いやすいんだし。
問題は、WebComponentsをラッピングしたものは、AngularやVueやReactとは別のものになるってこと。
AngularやVueやReactもWebComponentsを考慮しつつ開発してるんだろうが、
WebComponentsが最終的にどうなるのかわからないし、
WebComponentsがない時代の設計をWebComponentsに最適化するのは大変。
どうせWebComponentsに最適化された新しいフレームワークが出るに決まってる。
そしたら今のフレームワークは全部おさらばｗ
|
 |
