Vue vs React vs Angular Part.2

**デフォルトの名無しさん** · 2019/03/09(土) 22:02:33.71

実際どうなん？
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
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください

**デフォルトの名無しさん** · 2019/04/02(火) 13:05:03.55

いや単なる素のjsやんけ
なんだこれエイプリルフールか？

**デフォルトの名無しさん** · 2019/04/02(火) 13:40:25.21

ヴァーニラ　ヴァニラ　ヴァーニラ求人

**デフォルトの名無しさん** · 2019/04/02(火) 14:11:33.61

>>241
なるほど
触ってみるかな

**デフォルトの名無しさん** · 2019/04/02(火) 16:51:32.13

いや、使ったことないってことはないだろ

**デフォルトの名無しさん** · 2019/04/02(火) 20:16:30.67

生jsとか「this」とは。。とかなんでそんな哲学せにゃならんのかって気持ちになるわ。

**デフォルトの名無しさん** · 2019/04/02(火) 20:35:43.96

生js……ｺﾞｸﾘ…

**デフォルトの名無しさん** · 2019/04/02(火) 20:37:17.25

Reactもカメラ映像からcanvasに転写して画像処理とかやった時は結構メソッドに.bind(this)とか沢山書いたけどな

**デフォルトの名無しさん** · 2019/04/03(水) 08:05:38.53

>>232
どうだろ。jQueryの優れている点は後方互換性の高さだからな。

jQueryの古臭い構文に則って書きさえすれば、最新の環境でも10年前の粗大ゴｍ…レガシーな環境でも動くけど、
モダンブラウザでの利用を前提としたvueはレガシー環境ではjQueryの代替にはなりえないかと。

あとはjQueryの馬鹿にでも覚えらる簡単さも、vueには真似できない点じゃないかな。
１日あればそれなりに読めて書けるようになるjQueryと、じっくり数週間は座学を要するvueだと、
即戦力（という名の使い捨て）を確実に揃える際にはjQueryの方がより適切なんじゃないかな。
vueは下手すりゃ時間と労力だけ消費して、結局習得できませんでしたーとか平気でありえるわ。

**デフォルトの名無しさん** · 2019/04/03(水) 09:23:59.94

ついにAngularの津耶乃本も出るのな

**デフォルトの名無しさん** · 2019/04/03(水) 10:08:11.29

フレームワーク選びのポイントは
どんな規模を作るのか、最終的にどういった
開発環境を、使えるように成りたいかによるだろう。

Vueはmvvmのテンプレートエンジンが
他よりディープに作り込まれてて、コンポーネントが他より再利用しやすいのが特長。

だけどツールとして使えるように
なるには、かなり熟達してないといけない。。

**デフォルトの名無しさん** · 2019/04/03(水) 11:37:08.30

やめてーー　>>250

**デフォルトの名無しさん** · 2019/04/03(水) 14:36:12.42

>>249
かと言っていつまでもjQueryは辛すぎるだろう。保守に必要なのはしょうがないが、インタラクティブなページだけvueに置き換えてくだけでも随分楽になるんだがなあ。フォーム周りとか特に。

**デフォルトの名無しさん** · 2019/04/03(水) 14:56:25.21

jQueryそこまで互換維持してる？結構非互換変更をやってるような気が
propとattrが分離した時なんて大混乱だったし

**デフォルトの名無しさん** · 2019/04/03(水) 15:15:33.14

> propとattrが分離した時なんて大混乱だったし
それは2011年の話。それが最初で最後の大きな変更

**デフォルトの名無しさん** · 2019/04/03(水) 16:14:03.74

サーバー側フレームワークが足してくるやつとサードパーティースクリプトとクライアント側フレームワークが使ってるやつで３種のバージョンでグチャグチャになってエラってるのに当たった
もうあんなのは嫌だ

**デフォルトの名無しさん** · 2019/04/03(水) 19:00:51.07

サーバーが足してくるって何を？

**デフォルトの名無しさん** · 2019/04/03(水) 20:17:52.28

誰かが作ったのの改修案件って事じゃない？

**デフォルトの名無しさん** · 2019/04/03(水) 21:06:42.61

サーバのフレームワークが吐くscriptだろう。ちょっと違うがカスタムしたwordpressは本当カオスだわ。もう二度とメンテしたくない。今でも元気に動いてるのが不思議。

**デフォルトの名無しさん** · 2019/04/04(木) 00:50:17.12

redux-sagaやばげ
https://qiita.com/kuy/items/716affc808ebb3e1e8ac

**デフォルトの名無しさん** · 2019/04/04(木) 01:57:56.93

今さらかよｗ何年遅れだｗｗ

**デフォルトの名無しさん** · 2019/04/04(木) 11:09:20.60

>>259
function.phpでフックするかプラグインで実装するか、直書きするか、WordPressの標準機能でやるかの4択だから見る箇所多くてな…

**デフォルトの名無しさん** · 2019/04/04(木) 15:52:23.56

このくらいデザイナーでもできるのにフロントエンジニアができないってどういうことだよ？

**デフォルトの名無しさん** · 2019/04/04(木) 19:01:35.04

研修二日、実務経験二年のペテンシ・エンジニアリング・サービス・ソリューション♪

**デフォルトの名無しさん** · 2019/04/06(土) 00:11:30.05

>>228
いいや、データの双方向的な流れがバグの温床になるって話だった
で、 reactはflux, angularはデータバスにrxjs
angular.jsのアーキテクトだったかがvue.jsのメンテナーへ
小規模なアプリはvue.js,大規模ならangularへ流れても良いと思うんだがなー
angular2が出た初期の頃みたいにボイラープレートを動かすだけに何日も掛かるような糞ではなくなったんだし

**デフォルトの名無しさん** · 2019/04/06(土) 00:14:37.44

jqueryの作者はreactへ流れてただろ
jquery的な用途で使われるのはvue.jsの方だとは思うが
reactは設定のための学習コストが高すぎて、アホなweb屋たちが使いこなせない

**デフォルトの名無しさん** · 2019/04/06(土) 01:16:21.80

reactの学習コストが高いっていうけど、
安定したもの作ろうと思ったら他のフレームワークやるとしても結局同じくらい学習コストかかると思うぞ。

**デフォルトの名無しさん** · 2019/04/06(土) 08:49:03.93

>>266
もう3年も前の話だな。それからのReactの状況はいぜんと何も変わらず
いつになったら普及するのかね？

>>267
すごいものを作ろうとしたらどれも大変
ではなくてだな、

ちょいちょいで終わるようなものを作ろうとしたら大変なんだよ
世間で必要とされるもののほとんどは、ちょいちょいで終わるようなものばかり

**デフォルトの名無しさん** · 2019/04/06(土) 09:56:04.81

>>265
実際そういう流れになってると思うよ。ただバインディングの仕組み自体がトリッキーだから、フレームワーク関係無く不安定さが付き纏うのはしょうがない。
要求に対してweb標準仕様が貧弱すぎるから、いつまで経ってもどこか不安定なのはwebの宿命だよ。

**デフォルトの名無しさん** · 2019/04/06(土) 10:46:57.59

本質的にフロントエンド要らないと思うんだよね
デバックにコストが掛かり過ぎて、コストを掛けてまで誰が欲しいのかって話で
片手間のテンプレート的に扱えたangular.jsからvue.jsへ流れると思うけど
frontendの専門部署でreactでなくてvue.jsを使う勢は単に頭が沸いてるだけ

**デフォルトの名無しさん** · 2019/04/06(土) 13:37:29.72

Reactは難し過ぎた
みんなあんなの使えてるの凄いね

**デフォルトの名無しさん** · 2019/04/06(土) 16:11:51.40

>>268
ちょいちょいでいいならexcelにボタンでもつけとったらええやんけとか思う。
まあ実際はバカ経営者に見栄えいいのを見せる目的があるから
クソみたいなフレームアピールするんだろうけどな。
心底くだらねーと思うわ。

**デフォルトの名無しさん** · 2019/04/06(土) 16:40:40.59

Reactごとき難しいってお前らエセプログラマーだろ
世の中のプログラミングの中では圧倒的に簡単なほうなんだが

**デフォルトの名無しさん** · 2019/04/06(土) 17:30:04.31

>>271
学習した教材が悪かったんじゃない？

**デフォルトの名無しさん** · 2019/04/06(土) 18:07:30.00

React2018年初めからV字回復してんな。なんかあったっけ？
https://cdn-images-1.medium.com/max/2600/1*4zlVkNSR8T8KivcDaOD5Dw.png

**デフォルトの名無しさん** · 2019/04/06(土) 18:59:25.24

ライセンスの修正じゃないかな。
その前に急落したのもライセンスが問題にされ始めたころじゃないかと思う。

**デフォルトの名無しさん** · 2019/04/06(土) 19:40:00.22

>>275
2017後半-2018前半頃のトレンドって言ったらPython/機械学習に注目が集まった時期かな

**デフォルトの名無しさん** · 2019/04/06(土) 21:39:49.85

>>275
Angularが今後、死ぬ運命ということだけはわかった

**デフォルトの名無しさん** · 2019/04/06(土) 22:41:07.31

世界中の華橋・華人を動員した結果GitHubスター数はReactを抜いたVueとデッドヒートしてるじゃんｗ
誇っていいだろ

**デフォルトの名無しさん** · 2019/04/06(土) 23:29:44.99

>>276
それだ！
落ち込み、反転、両方説明がつく。
スッキリしたありがとう。

**デフォルトの名無しさん** · 2019/04/06(土) 23:33:50.04

そのうちページ全体が<canvas>になる時代がくるんだろうか

**デフォルトの名無しさん** · 2019/04/07(日) 00:33:24.05

ははは。そんなことありえない。
ウェブアプリなんて一部でしか作られてないよ
殆どはウェブサイト。だからjQueryが使われ続けている。

**デフォルトの名無しさん** · 2019/04/07(日) 10:22:09.78

>>273
React特有のpropが変わると再描画という形がキツかった
普通に部分的な動きをさせたいだけで全部その形にしなきゃいけないのが不自然
不要な部分の更新まで行われてしまったり何回も同じ更新が走ってまくってしまって原因調べるのがきつい

**デフォルトの名無しさん** · 2019/04/07(日) 14:30:36.12

shouldComponentUpdateでfalse返してもダメなパターン？

**デフォルトの名無しさん** · 2019/04/07(日) 15:05:55.66

何らかのアンチパターンやってるケースでしょ
設計思想とか、中の仕組みを想像出来ないとやらかしてしまうのは分かる
うちのメンバーでそういうのあった

**デフォルトの名無しさん** · 2019/04/07(日) 15:40:34.34

逆にreactのコンポーネントを使わずにreduxで更新をやるって感じで
入門するのはどうなんだろうか？こっちのがわかりやすいんじゃなかろうか。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:26.91

react+reduxは考え方としてはいいんだが、素のreactではコンポーネントのstoreに
閉じていたようなデータまでstore内に混在するのがなんとなく気持ち悪い。
MとVMを分離できたらよかったんだがなぁ。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:32.93

content apiで十分。

**デフォルトの名無しさん** · 2019/04/07(日) 17:22:49.73

contextだった

**デフォルトの名無しさん** · 2019/04/07(日) 18:45:56.70

javascript歴浅めのものです。
この手のフレームワークのデータバインディンクの仕組みって、buildした後のjavascript的にはどう実現されてるの？
{{data}}とかでマークアップされた箇所にイベントハンドラ付きのjavascriptが挿入されてる感じなんかな？

**デフォルトの名無しさん** · 2019/04/07(日) 19:40:14.89

>>290
簡単な例ならtwo way binding javascriptでググると沢山出てくると思う。ただこれに仮想domやコンポーネントが絡むからずっと複雑。深追できないしするべきじゃない。

**デフォルトの名無しさん** · 2019/04/07(日) 20:09:39.22

two way bindingねえ

例えばvar helloのバインディングならglobal(window)にsetter/getterのhello()を追加して、
helloのsetterが呼ばれて値が変わったら<input>.valueにもそれを代入し、
<input>要素にはイベントリスナーで値が変わったときにバインディング変数(hello)に同じ値をセットしてるのかな

**デフォルトの名無しさん** · 2019/04/07(日) 20:10:59.60

あ、でもそれじゃ無限ループするか（てへぺーろ

**デフォルトの名無しさん** · 2019/04/07(日) 20:13:30.94

逮捕されんぞ

**デフォルトの名無しさん** · 2019/04/07(日) 20:22:59.94

一般のGUIでも常套手段だが、値が変わらなかったらそれ以上伝播しないってことでいいんじゃね。

**デフォルトの名無しさん** · 2019/04/07(日) 20:41:31.99

>>292
>>295
なるほど、やっぱそれくらいのコード書かないとできないのですね。
となるとリッチなwebアプリケーション作るとなると、どれかしらのフレームワーク使いたくなりますな。

**デフォルトの名無しさん** · 2019/04/07(日) 20:46:11.81

徐々にだとしても、今後webブラウザベースのアプリが増えるはずと思っていろいろ勉強中なんです。

**デフォルトの名無しさん** · 2019/04/07(日) 21:25:39.30

>>283
そこ海外フォーラムとかで議論されてるから見ればいい

>>284
それ完全ではないから
あと配列は浅い更新しかみてないから注意

>>286
さすがに全部Reduxにする必要はない

**デフォルトの名無しさん** · 2019/04/07(日) 21:46:10.88

いじめはどこの町にもあるが島本町は特に酷い
「大阪府三島郡島本町のいじめはいじめられた本人が悪い」なんて
公言する町は他に無い

**デフォルトの名無しさん** · 2019/04/07(日) 23:01:30.03

>>297
アプリというか、アプリの様に動作するwebサイトだね。storeに登録しない。個人的に最難関はDBのオフライン対応+同期だと思う。
firestoreもあるがフレームワーク側で対応して欲しい。魔境なので難しいとは思うが。。

**デフォルトの名無しさん** · 2019/04/07(日) 23:38:09.79

>>300
個人的にはオフラインDBは諦めるのがスジがいいと思うけどな。ネットに繋がってて当たり前の時代じゃないですか。

**デフォルトの名無しさん** · 2019/04/08(月) 01:33:01.06

>>300
> アプリというか、アプリの様に動作するwebサイトだね。

それは増えない。アプリの様に動作するwebサイトはjQuery Mobileが
失敗したことからも必要とされていないことがわかっている

※ jQuery Mobile は jQueryとは違うもので、
jQuery UI（こちらもjQueryではない）がデスクトップ用のUIなのに比べて
jQuery Mobile はスマホ用のUIを作るもの

webブラウザベースのアプリが増えるとしても、それはwebサイトからの
変更ではなく、PCアプリ・スマホアプリから、ウェブアプリへの変更となる。

ウェブサイトからウェブアプリに変更したいという要求は
本質的に違うものへの変更になるから生まれてこないんだよ。
PCアプリ・スマホアプリから、ウェブアプリの場合は、
本質的に同じもので動くプラットフォームが拡大されるからそういう要求はある。

**デフォルトの名無しさん** · 2019/04/08(月) 01:51:55.70

>>302
そうか？office365とかgoogle documentとか成功してるじゃん。

**デフォルトの名無しさん** · 2019/04/08(月) 01:53:28.98

いや、そう言ってるのか。

**デフォルトの名無しさん** · 2019/04/08(月) 01:56:14.66

>>302はいったい何を否定しようとしたんだ？webサイトという言葉の使い方がおかしいということなのか？

**デフォルトの名無しさん** · 2019/04/08(月) 02:16:44.05

>>303
> そうか？office365とかgoogle documentとか成功してるじゃん。

それらは、もともとデスクトップアプリだったもの
ウェブサイトだったわけじゃない。

>>305
> webサイトという言葉の使い方がおかしいということなのか？

アプリのように動作するウェブサイトという
変なインターフェースは誰も求めてないという話。
例えるならば、ジョイスティックで操作し、美麗な3Dゲームのような
新聞ビューワーみたいなもの。誰もそんなので新聞を読みたいなんて思わんだろ？

**デフォルトの名無しさん** · 2019/04/08(月) 08:10:05.44

>>306
ん？だったら例えばoffice365はアプリのように動作するwebサイトで成功してるじゃん。

**デフォルトの名無しさん** · 2019/04/08(月) 09:08:14.77

>>302
jQueryMobileは単純にBootstrapとかにとって代わられただけじゃん

**デフォルトの名無しさん** · 2019/04/08(月) 09:15:13.85

>>307
どうせ使ったことないだけじゃね？

**デフォルトの名無しさん** · 2019/04/08(月) 11:34:53.34

>>301
そうなんだよね。オフライン対応って無理がありすぎるんだよね。
以前firebaseのrealtime database使ったが、オフラインからの同期処理に制限が多すぎて厳しい。更新が時系列を保証せず最終更新分だけ同期するとか、かなりクセがある。
WebworkerとindexedDBで効率よくキャッシュする方が当面は幸せになれそう。

**デフォルトの名無しさん** · 2019/04/08(月) 13:53:28.07

>>307
office365はアプリのように動作するウェブアプリであって
ウェブサイトじゃないんだよ

**デフォルトの名無しさん** · 2019/04/08(月) 13:57:09.46

まあこれでも読んで勉強して。IBMだからそれなりに信用できるでしょ？

第 1 回 Web サイトと Web アプリケーションの違い
https://www.ibm.com/developerworks/jp/web/library/wa-websiteapp/index.html

**デフォルトの名無しさん** · 2019/04/08(月) 14:49:09.97

excelで作ったドキュメントをなるべくそのままの形でhtml化する方法は無いでしょうか？
excelでhtml形式で保存すると裏側が汚いです
Gatsbyのプラグインにそれらしきモノがあったので試してみたら、色もセル結合もフォントサイズも全部落ちてしまいました

まぁ自分で自作すればいいんでしょうが、気が遠くなるくらいたくさん作り込まねばならず、皆さんはexcelドキュメントをそのままWeb化したいとか要望された事はありませんか？

**デフォルトの名無しさん** · 2019/04/08(月) 15:43:06.23

>>311
いやだから>>305でwebサイトという言葉の使い方がおかしいということなの？って聞いたのによくわからん回答されたから混乱してるんだが…
で、結局webサイトという言葉の使い方がおかしいってことなのね。

**デフォルトの名無しさん** · 2019/04/08(月) 15:49:10.83

要は、office365のようなものをwebサイトと呼ぼうがwebアプリと呼ぼうが話の本筋には何の影響もないのに、>>302の長文で謎の語りが入ったから話がグチャッとなっちゃったって事実に気づいて欲しい。

**デフォルトの名無しさん** · 2019/04/08(月) 15:51:36.81

>>313
スレチだけどレスすると、
htmlにせずGoogleDocsとかにインポートして公開した方がいいんじゃね
こういうの
https://www.howtonote.jp/google-document/open/index1.html

**デフォルトの名無しさん** · 2019/04/08(月) 20:15:16.81

オフラインデータはクッキーをいじり回すことしか出来ないのね
せめて画像を確実にローカルに保存できればオフラインでも動かせる
アプリが作れるだろうに

**デフォルトの名無しさん** · 2019/04/08(月) 20:22:17.47

>>317
Webストレージで画像保存できるじゃん

**デフォルトの名無しさん** · 2019/04/09(火) 07:41:13.08

reactは覚える事は少ないけども設計力が必要
宣言型プログラミングと同じで高い論理性が要求されるから苦手な人は多いかもね

**デフォルトの名無しさん** · 2019/04/09(火) 23:06:06.17

悲しいのはAngularの勢いが無くなり、横ばいのAngularJSの方が残りそうなところ
もうAngularはGoogle Graveyard入りだろ。どうすんだよAngularで作ってる新規プロジェクト

**デフォルトの名無しさん** · 2019/04/10(水) 00:47:58.78

Angular1の方が好評だったってこと？ｗ

**デフォルトの名無しさん** · 2019/04/10(水) 00:52:39.92

angular使うくらいならvueの方がええわなぁ
reactは論理性高いから日本人には不向きやろなぁ

**デフォルトの名無しさん** · 2019/04/10(水) 01:08:10.98

ググってみたけどreactはhtml側ではあまり小細工しない感じだねえ
論理的というのがいまいち分からないけど

**デフォルトの名無しさん** · 2019/04/10(水) 02:32:35.33

個人的にはbackbonejsが好きなんだけどなあ。自分で自由に作れるし
有名どころ使ってるのに、扱いが微妙

**デフォルトの名無しさん** · 2019/04/10(水) 10:00:46.62

そういえばchromium版Edgeのプレビュー出たけどおまえら使ってみた？

**デフォルトの名無しさん** · 2019/04/10(水) 10:11:11.18

>>320
これ以上進化する予定のないものが残るわけないじゃん

**デフォルトの名無しさん** · 2019/04/10(水) 12:23:01.13

>>326
進化させるのは自分の設計、コーディング次第なのがbackbonejsの思想だけど
フルスタックじゃないから足りない部分は自分たちで補えばいいし
そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

昨今のフレームワークは全部入ってるから良いと思ってる
Railsやcakeみたいに作るのが簡単ならわかるけど、複雑化したら折角のフルスタックフレームワークがゴミになるだけ

**デフォルトの名無しさん** · 2019/04/10(水) 12:30:50.16

これ読むと良いかも。
フレームワークとライブラリの違いがわかってない人は特に

フレームワークは善か悪か，その両方か？
https://www.infoq.com/jp/news/2019/04/frameworks-libraries-axon

**デフォルトの名無しさん** · 2019/04/10(水) 13:13:49.79

>>327
AngularJSの話してんだけどアンカ先くらい見ようや

**デフォルトの名無しさん** · 2019/04/10(水) 13:50:22.69

>>327
> そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな

https://backbonejs.org/#changelog

1.3.3 ? Apr. 5, 2016 ? Diff ? Docs
～それから3年の月日が流れようとしていた～
1.4.0 ? Feb. 19, 2019 ? Diff ? Docs

ほぼ死んどるがなｗ
1.4.0リリース作業の前のコミットは2018年5月だし、
ドキュメントや些細なミスを除けば、機能追加は2017年じゃないか？

**デフォルトの名無しさん** · 2019/04/10(水) 16:27:07.49

>>328
ひと言で説明すりゃいいのにくどくどとしつこい内容だな

**デフォルトの名無しさん** · 2019/04/10(水) 22:25:31.68

>>322
その文からは、お前さんに論理性が無い事しか分からんな。

**デフォルトの名無しさん** · 2019/04/11(木) 00:19:20.16

フレームワークは、先に全体の構造が決まっていて、そこにはめ込む部品を作る。
全体の構造が決まっているから、プロ向き

ライブラリは必要な都度、組み込んで、部分から先に作っていくから、
全体の構造が最後まで決まらないので、スパゲッティ・泥団子になりやすいので危険！

**デフォルトの名無しさん** · 2019/04/11(木) 00:20:57.76

全体の構造なんて先に決めればいいだけやんｗ

**デフォルトの名無しさん** · 2019/04/11(木) 00:26:50.15

>>333
フレームワークに任せとけば安心って思考停止して、結局何と何が依存してるか
わからなくなってそのフレームに閉じ込められるパターン。

**デフォルトの名無しさん** · 2019/04/11(木) 01:02:55.46

>>335
Angularの悪口はそこまでだ！！

**333** · 2019/04/11(木) 02:29:16.00

全体の構造を、各人が決めたら、ダメ！
各人によって、構造に違いがあるから、他人と思いを共有できない

Aが作った構造を、Bが気に入らないなど、トラブルになる

だから、Rails などの既成のフレームワークを使う。
そのフレームワークの構造を共有できるから

多くのフレームワークも、Rails を基本としている

**デフォルトの名無しさん** · 2019/04/11(木) 02:33:37.60

nuxtの出力jsが乱数名みたいになるのなんとかならんのかな

**デフォルトの名無しさん** · 2019/04/11(木) 03:23:58.52

>>337
> Aが作った構造を、Bが気に入らないなど、トラブルになる
> だから、Rails などの既成のフレームワークを使う。

だからその「既成のフレームワーク」を作ったのAで
それを使うBが気に入らないってトラブルになってるんだろ？

**デフォルトの名無しさん** · 2019/04/11(木) 03:24:46.97

Rails 作ったやつは他人なんだから
思いを共有できないわな

**デフォルトの名無しさん** · 2019/04/11(木) 08:16:15.03

>>335
規約に則って書きさえすれば、チームのスキル差を減らして、一定の品質が担保できるのがフレームワークのメリットじゃない？

フレームワークに閉じ込められるって表現してるけど、それ単にチームで設けた規約に不満を述べてるだけかと。

もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、
発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。