Rails は、すべてをクリーンで構造化した非常に優れたバックエンド フレームワークです。
皆さんもフロントエンドで同じことを考えたことがあると思います。
Rails のフロントエンドに MVC JavaScript フレームワークのいずれかを使用していますか?
もしそうなら、あなたはそれに満足していますか？
以前はどのようにコーディングし、どのように変化しましたか?
Sproutcore は、Rails も行う js+css+html を使用するため、Rails により適しているのではないでしょうか。カプチーノでは、これらのいずれも使用しません。
あなたの考えと経験を共有してください。なぜなら、私はこの分野に完全に未熟で、Rails でどれを使用すればよいか分からないからです。
DRY 構造とベスト プラクティスを取得するには、フロントエンドに MVC フレームワークを使用する方がよいことはわかっています。
動作中の MVC フレームワークを見るとき、SproutCore と Cappuccino を検討しました。どちらも、Apple の Cocoa フレームワークと Objective C から多大なインスピレーションを得ています。
SproutCore を使用することを選択した理由は次のとおりです。
次の理由により、カプチーノを選択しませんでした。
(覚えておいてください、私はカプチーノとオブジェクティブ J の経験があまりないので、大雑把で素朴な主張をしている場合は教えてください!)
Rails で「最もうまく機能する」ものではなく、フロントエンド フレームワークとして何を望むかをもっと検討する必要があります。どちらのフレームワークも優れています。SproutCore を選択したのは、アプリケーションのニーズとイデオロギーに適合したからです。
SproutCore のソースをざっと見てきた経験から、使用しているサーバーの実装からはかなり独立していると言えます。Lua で書かれた BOSH サーバーである Prosody を使用します。Railsを使いたい。SproutCore はすぐに使える機能を提供します:
DRY の要件については、すべてあなた次第です。フレームワークを活用して、コードを独立した DRY にしたり、密接な依存関係を持たせて繰り返したりすることができます。どちらのフレームワークも優れています。必要に応じて異なります。緊張しないでください-飛び込んで、コミュニティとそれぞれで何が起こっているかを知りましょう! 私たちは噛みません... あまり。
すでにコメントで言ったのですが、回答として投稿してほしいとのことでしたので、こちらです。:)
リッチクライアントアプリケーションを構築している場合、Railsは実際には多くを提供しません。クライアント側のWeb開発フレームワークは通常、ハードワークのほとんどをクライアントに課し、サーバーをストレージと場合によっては大量の計算（必要な場合）にのみ使用します。だから私は個人的にあなたがRailsさえ必要としないと主張します-あなたはSinatraのようなもっともっと単純なもので行くことができます。クライアントはアプリケーションの「肉」であるため、開発のほとんどはそこで行うことになります。まず、適切なクライアント側のライブラリ/フレームワークを見つけることに集中してから、サーバー側について心配してください。
そうは言っても、私は両方を試して、どちらがもっと好きかを確認します。カプチーノは非常に...違います、そして多くの人々はそれによって延期されます（主にObjective-Jのためだと思います）。私の限られたテストでは、私が使用した他のフレームワークよりもロードがはるかに遅いようにも見えました。その中に小さなアプリケーションを書いてみることをお勧めします。自分に合わないと感じた場合は、リストから外してください。
個人的には、 SproutCoreを選択します。これは、JavaScriptを既に知っていて（私が想定しているのですか？）、開発スタイルがはるかに馴染みがあるためです。また、必要なサーバー側フレームワークを使用できるようになります。
ご覧になったことがあるかどうかはわかりませんが、リッチWebアプリケーションを作成するためのもう1つの非常に人気のあるフレームワークであるExtJSもあります。私はそれを使用しましたが、それは素晴らしいことですが、ライセンスでは、ソフトウェアをオープンソースとしてリリースするか、商用ライセンスを購入する必要があります。状況はわかりませんが、これは私にとって大きな問題でした。
結局、私はあなたがそれらを試してみることをお勧めします。フレームワークがあなたの個人的な好みに合うかどうかはわかりません。
免責事項：私はSproutCoreまたはCappuccinoをテスト以外の目的で真剣に使用したことはないので、私が言うことはすべて一粒の塩で取ってください。
Rails を Cappuccino で使用しましたが、これは非常に苦痛でした。ただし、この意見は個人的な偏見が強いものです。まず第一に、objective-j に慣れていないだけです。私は客観的な c の以前の経験がなく、単純に全体のスモールトークのようなメッセージ送信が好きではありません (私は関数指向のプログラマーです)。
さらに、Rails と Cappuccino を統合したい場合は、あらゆる場所で JSON を使用する必要があるため、多くのフォーマットに対応するためにほとんどすべてをリファクタリングする準備をしてください (ユーザーのブラウザーが動作しない場合に備えて、プレーンな HTML にも対応する必要がある場合があります)。カプチーノ - または一般的にjs)。
また、Rails + Cappuccino のアプリケーションや開発者が多くなく (私の知る限り)、インターネット上で文書化されていないため、通常よりもかなり長い間問題に悩まされることになります。
最後になりましたが、objective-j でインターフェイスのすべての部分を構築するのに膨大な時間を費やすことになります。ご想像のとおり、Web UI よりもココア UI の作成に似ています (これは私にとってマイナス面です!)。その過程で役立つソフトウェア/IDE については知りません (280atlas は、いくつかの数年前に公開されましたが、一般公開されたことはありません）。
要するに、この段階では Rails + Cappuccino をお勧めしません。ただし、ただ楽しむため、または Web プログラミングについて何か新しいことを学ぶために使用する場合を除きます。