Rails等のフレームワークでHTML,CSS,JavaScriptファイルに分けて開発するのは何故か

Question

開発中にいちいちファイル間の対応を確認してあっちこっちいくのが面倒です
全部一箇所にまとめちゃだめなんでしょうか？

Answer 1

別に「全部一箇所にまとめちゃだめ」な理由はなくて、まとめて作れるようなフレームワークもあります。

Riot.js
Vue.jsの単一ファイルコンポーネント

Comments

[退会済みユーザー]

で？

[maisumakun]

「全部一箇所にまとめ」るような開発スタイルが好みなのなら、そういう選択肢もある、という話です。

そして、Rails 5ではAPIモードといって、Railsはフレームワークに専念させて、フロントエンドはすべてVueなどで構築する、という選択肢も用意されています。

[退会済みユーザー]

いつも好みですませるよな
本当に理解してるの？
メリットデメリットはないのか？

[Zuishin]

ぜんぶまとめちゃだめかという質問なので、まとめてもいいというのは十分答えになっていると思います。メリットデメリットが聞きたいならフレームワークを限定した上でそう質問すべきでした。
質問が悪いので追記してちゃんとした質問にしてください。

[退会済みユーザー]

>メリットデメリットが聞きたいならフレームワークを限定した上でそう質問すべきでした。
なんででしょうか？
フレームワークによってメリットデメリットが変わるとは思えないのですが

[Zuishin]

たとえばこの回答に、まとめて作りやすいフレームワークが紹介されていますが、それを見ても変わらないと思うのですか？

[退会済みユーザー]

はい。まとめて作るかどうかのメリットデメリットがまず前提としてあります。
それをやりやすいフレームワークかどうかは別の話だと思いますが。

[退会済みユーザー]

なぜフレームワークを限定したうえで質問しなければいけなかったのかという質問に答えてもらえますか？

[Zuishin]

たとえばこの回答に、まとめて作りやすいフレームワークが複数紹介されていますが、紹介されていないフレームワークもあります。それを見ても変わらないと思うのですか？

[Zuishin]

また、やりやすいというのはメリットにはなりえないという意見ですか？

[退会済みユーザー]

うん。だからさあ、手法のメリットデメリットと特定のフレームワークでその手法がやりやすいというのは関係ないよね

[Zuishin]

その手法をどこで使うかによってメリット・デメリットは変わります。
つまりその手法を使いやすいフレームワークではメリットになり、使いにくいフレームワークではデメリットになります。
なぜ変わらないと思ったのですか？

[退会済みユーザー]

私が聞いてるのは手法自体のメリット・デメリットです。
そして誰も答えられない

[Zuishin]

すでに答えはありますが、あなたには理解できない。
多分フレームワークという意味がわかっていないのだと思いますね。

フレームワークをスポーツに、まとめて作る手法をダッシュにたとえましょうか。
ダッシュのメリットデメリットを教えてくださいと言われても、ダッシュのできるスポーツ、できないスポーツ、しやすいスポーツ、しにくいスポーツがあります。
競技を指定しなければそれ自体のメリット・デメリットは語れません。

まずフレームワークとは何かから勉強してください。

[退会済みユーザー]

は？
例えが意味不なんだが。まあのってやる。
ダッシュ自体のメリット->速い速度で移動できる。
ダッシュ自体のデメリット->疲れやすい。
これとダッシュがあるスポーツで適応可能か、は別問題です。

[Zuishin]

競技によってはメリット・デメリットはそれだけではありません。

[退会済みユーザー]

例えば？

[Zuishin]

平泳ぎなら失格になります。
自由形なら遅くなります。
まさかここまでとは。

[退会済みユーザー]

水中でダッシュできるんですか？
それはダッシュじゃない何かですよ？

[Zuishin]

ダッシュの定義にもよりますが、できないならできないというデメリットがありますね。
このように、競技を指定しなければ言及できません。

ここまでではっきりしました。
あなたにこのサイトは高度すぎます。
他の人に理解できることがあなたには理解できていません。

あなたの求める答えは既に出ていますし他の人には理解できていますので、勉強して出直してください。

[退会済みユーザー]

その例えだとできないというのはデメリットではありません。
競技による"制約"です。
私はフレームワークの"制約"について質問しているのではありません。
手法"自体"のメリット・デメリットを聞いているのです。

[Zuishin]

できないのはしたら失格になるからです。
これはデメリットです。

[Zuishin]

再度言いましょう。
あなたには高度すぎるので背伸びをせずぜひ勉強してからおいでなさい。

[退会済みユーザー]

それはある手法をある競技に適応する際のデメリットですよね。
何度も言っていますが私は手法"自体"のメリット・デメリットを聞いているのですよ。

[Zuishin]

そこのところをさっきから書いているのに理解が及ばないのはあなたにとって高度すぎる内容だからですね。

ですので勉強してからきてくださいと言っています。

あなたは何度もここで質問しましたが、その回答をほとんど理解できませんでした。
普通ならこれで身の程を知りますが、あなたの場合はそれすらわからないようです。

もう一度言いましょう。
あなたが理解できないのはあなたの知識レベルが低すぎるのが原因です。
そこをおぎなわなければ何度質問しても同じでしょう。

[退会済みユーザー]

なんか、たぁのしくなってきたねぇ。ねぇ？

Answer 2

要点を省略していないおおよそ誰でも理解できそうな文章が読めないようなので回答に書きますね。

この質問についてはそのような構造になっているフレームワークの作者に直接聞くのがベスト。

他の誰でもない作者が一番知ってるんだから。
作者が公開されている著名なフレームワークの話でしょ？Railsとか。

作者が一番しっくりくる答えを持っているのだから。それは当たり前。

そこまでして知りたい内容なら誰が答えるとも分からない（自分が求めているレベルの見識を持っている人がいるかすらも分からない）ようなQAサイトを使うのは賢明ではありません。

軽はずみな興味であればその場にあわせた態度でないと得たい回答は得られません。
ただの荒らしです。

いいですか？
誰が答えるとも分からない（自分が求めているレベルの見識を持っている人がいるかすらも分からない）ようなQAサイトを使うのは賢明ではありません。

もっと言えば、
おそらくあなたが満足するような答えを持っている人はいたとしても、
あなたのような態度の人に答えたいとは誰も思いません。
なぜならこれまでのやり取りからきちんと通るはずの回答であっても
難癖つけあげた挙句、結局全く別の方法で自己解決にしてしまうからです。
例え「難癖つけられる」があなたお得意の指摘である「妄想」だとしても
これまでの態度から「難癖つけられそう。面倒くさい」と思われても仕方ありませんよ。
自身がこれまでやってきたことの報いです。

というか、teratailはそういう場ではないです。あなたには圧倒的に合いません。

Comments

[sazi]

mts10806さん
いつも通りのサクッとした質問へのコメントで良しとしましょうよ。
初見の方なら多少のコメントの遣り取りはあるかもしれませんが、改善してくれる人は長々とコメントが続く人では無いと思います。
mts10806さんの貴重な時間を浪費されないで下さい。

[m.ts10806]

フォローありがとうございます。ちょっと救われました。
お騒がせしました。

Answer 3

maisumakun さんの回答へのコメントより引用します。

fao 2018/06/15 18:33
はい。まとめて作るかどうかのメリットデメリットがまず前提としてあります。
それをやりやすいフレームワークかどうかは別の話だと思いますが。

どうぞ。

• 一元管理 分散管理 メリット デメリット - Google 検索

Rails等のフレームワークでHTML,CSS,JavaScriptファイルに分けて開発するのは何故か

「Rails等のフレームワークでHTML,CSS,JavaScriptファイルに分けて開発」云々は関係ない問題のようですので、質問文を修正して下さい。
質問にノイズが入っている事が望み通りの回答が来ない原因です。

Re: fao さん

Answer 4

あーのさぁ、よくわかんなくなってきたんだけど、質問内容は

HTML,CSS,JavaScriptファイルに分けて開発するのは何故ですか？

だったけど、やりとりを見てると

メリット・デメリットは何ですか？

みたいに変わってきてるじゃん。
良い子の質問の意図が今ひとつ見えないんだけど、もしかしてさ、本当に聞きたいのは

###Q: Railsとか、何でこんなバカみたいな設計になってるの？

って事なんじゃないの？
でも、良い子が歯に衣を着せて猫かぶって始めちゃったから今ひとつ伝わらなくて行き違いが発生してるんじゃないのかな？
もっと、単刀直入に聞いたほうがよかったような。

もしそうなら、回答としては、

###A: それはRails作った奴がアホだからです。

になるんだけど。

一応、良い子の考えてる事とはちょっと違うにしても、Railsの設計とか猿設計だよ。
あんなん、プロトタイプを作るためのフレームワークでまともなシステム作ろうとしたら使い物にならないね。
そういう意図で作ってある設計だから、そりゃ、不便だよ。

なんか、とりあえず同じ種類で纏めとけば気持ちいいでしょ？みたいな浅いところでああなってるけど、あんな纏め方じゃ、纏める意味ほとんどないってのは、良い子が考えてる通りで正しいね。

それでも、CakePHPとかSymfonyとかよりは随分マシだけど。

こんな感じでいいのかな？

Comments

[退会済みユーザー]

>とりあえず同じ種類で纏めとけば気持ちいいでしょ？みたいな浅いところでああなってるけど、あんな纏め方じゃ、纏める意味ほとんどない
ですよね

Railsができたのは2004年で当時はアレでも褒められたんでしょう
JS,CSSも今ほど使ってないでしょうし大した問題でも無かったんでしょうね
今のRailsはAPIモードを突っ込んだりwebpackを突っ込んだりActionCableを突っ込んっだりして対応しようとしてるけど無理がある感が出てきてますよね
現代で通用する新世代のプロトタイプ用フレームワークがあってもいいんじゃないかと思いますね。