JavaScriptフレームワーク選定の議論 - Qiita
2017/08/02 21:00:27
takogawa
"気になるJavaScriptのフレームワークで要件を小さくしたプロトタイプを作って試し、それを元に議論する"
2017/08/02 21:07:36
inouetakuya
さすがに azu さんが書いただけあって、よくまとまっている
2017/08/02 22:46:45
efcl
JavaScriptのフレームワーク選定やTypeScript/Flowといった言語の選択について。 それぞれのカテゴリにどのような選択肢があり、どのように選択していくのかについて
2017/08/02 23:16:55
hush_in
わかりやすい
2017/08/03 01:23:47
solidstatesociety
広いかどうかは業務で再利用なければ気にする点ではない。
2017/08/03 02:45:34
gnufrfr
あーもうフロントエンドついていけんわー
2017/08/03 04:07:49
mirucons
よくまとまってんなぁ。相変わらず混沌とした世界だ
2017/08/03 04:35:05
odakaho
長期のメンテ考えると採用には至らないのもあるな。
2017/08/03 05:40:20
psfactory
JavaScriptフレームワーク選定の議論 - Qiita
2017/08/03 06:23:33
kamei_rio
定期
2017/08/03 07:42:33
cl-gaku
やっぱりJQueryだな
2017/08/03 08:35:48
PerolineLuv
「まとまった結果」をまとめると答えは「絶望」
2017/08/03 09:02:21
Kesin
さすがの良まとめ。フレームワークというタイトルだったので御三家の比較かと思ったけどもっと広い話だった
2017/08/03 09:34:28
for-g
復習用にブクマです。
2017/08/03 09:44:40
yosuke_furukawa
「フレームワーク」と呼んだ時にも各々が思ってるものが違いそう。
2017/08/03 09:53:21
raimon49
メンテナンスコストの観点から「選ばなくて良い」ケースを教えてくれるのが大変ありがたい。
2017/08/03 09:53:24
progrhyme
azuさんのまとめ
2017/08/03 10:13:06
kaipu1224
この辺の技術を使ったシステムを5年後にメンテとなった場合、楽にできるもんなのだろうか
2017/08/03 10:17:02
sigeharucom
Backbone/Marionetteは全く触れられてなかった。世の中的には終わったことになってる。自分は今でも『丁度良くて』好きだけど。
2017/08/03 10:17:28
su_zu_ki_1010
こういうのを読むとさっぱりわからんので、古き良きjsp+JQuery+Ajaxでいいやって気持ちになる。
2017/08/03 10:32:26
cats_nukui
いまの時代、このくらいやらんとだめらしいよ。
2017/08/03 10:45:55
xlc
最近のJavaScriptでの開発は無闇に複雑化して誰も得していない。環境をいじくり回すことが目的化している。
2017/08/03 10:48:43
fikah
具体的な案件例とそれに合わせた選択例が欲しい。「案件に合わせて選んでね」だけだと、「結局何が正解なのよ・・」って感じでつらみ。
2017/08/03 10:55:35
lyiase
ブコメみて驚いたけど、これって別にバックエンドのスタックに比べて多くないよね。Javaならみんなmavenもspringもjunitも使わずに書いてるの?あとjQueryは最近は使いどころが難しい。下手に使うと大混乱を招く…。
2017/08/03 11:00:37
otchy210
つまるところ、Web フロントエンドの世界も Java の世界と変わらないような感じになってきたという事なんだろう。Java を個人プロジェクトで使う気が起きないのと同様、これら全部を個人で使う気は起きない。
2017/08/03 11:01:15
rgfx
Javaの世界みたいに各フレームワークがご長寿で、頻繁に車輪の再発明に走らずに腰を据えてやってる、というわけでもなかろうよ。スタックの数だけ見てJavaと比較するのは色々と足りないんじゃなかろか。
2017/08/03 11:16:52
coppieee
質問側からしたら「で、どれがいいの」ってなりそう。てか「TypeScriptとFlowのどちらがいいか」の質問に答えてない。
2017/08/03 11:30:05
t-wada
手を出すべきところ、スルーで良いところがわかっていて納得度が高い。テスト関係のところが特にそう。さすが azu さん。
2017/08/03 11:38:17
UDONCHAN
参考になる
2017/08/03 11:57:48
Dai_Kamijo
JavaScriptフレームワーク選定の議論 by @azu_re on @Qiita — 上條 大 (@Dai_Kamijo) August 3, 2017 from Twitter https://twitter.com/Dai_Kamijo August 03, 2017 at 11:52AM via IFTTT
2017/08/03 12:22:12
adwd118
まずSPAにするかしないかで大きく別れると思うんだけど、当然SPAにするって選択なの?SPAにしないならReactもAngularも選択肢に上がってこないはず
2017/08/03 12:44:26
dozo
つまりReactはクソ
2017/08/03 13:56:24
t32k
“storybook”
2017/08/03 13:59:48
mizchi
backboneの時代は抽象jquery層だとしても管理は無理だったということで終わってますよ
2017/08/03 14:37:54
tzt
活きのいいフロントエンド小僧が入ってくれるならともかく、js片手マンしかいない状況のままならどんな選択をしたところで辛い結果になりそう。。
2017/08/03 14:48:49
Nfm4yxnW8
"変更を加えることが難しくメンテナンスコストが高い" "サーバサイドをやってる人が片手間で書くJavaScriptといった状況" 道具じゃなくて人を入れ替え。。。
2017/08/03 17:46:07
garage-kid
535
2017/08/03 18:07:30
mmmpa
まぁぶっちゃけ spa 作るときは「ふるきよき」って全くよくないんだよな。
2017/08/03 19:06:40
fukken
この記事が注目される事自体、みんな「で、どれがいいの?」って思ってるって事だよなぁ。JSフレームワークや環境周りの情勢はカオスすぎる。
2017/08/03 22:08:40
razokulover
めっちゃまとまっててよい
2017/08/03 22:41:04
akabekobeko
カテゴリー分けすることで取捨選択を判断しやすくなる。他のプラットフォーム知見の転用で理解するのにも有用。この中だと私はテスト系でユニット テスト以外は捨ててる。
2017/08/04 09:39:24
okusa75
見やすい。でも、「メンテナンスしやすいもの」ならJavaScriptは選ばないなぁ。今後長期にメンテナンスするならなおさら。
2017/08/04 10:12:56
idr_zz
「JavaScriptフレームワーク選定の議」でタイトル見切れて見えたので一瞬、皇居の行事かと(笑) JavaScriptフレームワーク選定の議論 by @azu_re on @Qiita
2017/08/04 10:50:10
snjx
なんでこう、フロントエンドは冥府魔道になっちゃったんだろうか
2017/08/05 01:30:58
massa142
“数のカテゴリを同時に扱えるツールのメンテナンスが難しくなる理由としては、破壊的な変更が多くなることと、そのツール作者側のメンテナンスコストの問題で放置されること”
2017/08/05 22:02:45
mizdra
良い
2017/08/07 13:03:14
masaru_b_cl
丁寧な言語化 / そしてGUIはメンドクサイという感じ