Rails(Sinatra / Ramaze / Camping)よりも軽いフレームワークを使用したいのですが、そうすることで、プラグインの形でRailsに合わせて調整された多くの共有ライブラリを使用できなくなるのではないかと心配しています。これは大きな懸念事項ですか、それともこれらのプラグインのほとんどはさまざまなRubyフレームワークで使用できますか?
Rails以外のRubyフレームワークを使用することで他に潜在的な欠点はありますか?
Rails(Sinatra / Ramaze / Camping)よりも軽いフレームワークを使用したいのですが、そうすることで、プラグインの形でRailsに合わせて調整された多くの共有ライブラリを使用できなくなるのではないかと心配しています。これは大きな懸念事項ですか、それともこれらのプラグインのほとんどはさまざまなRubyフレームワークで使用できますか?
Rails以外のRubyフレームワークを使用することで他に潜在的な欠点はありますか?
あなたが言及したすべてのフレームワークでまだ宝石を使用できるので、たくさんのものが再利用可能です。新しいORMに交換したいのですが、問題ありません。派手なshmacy構文の強調表示が必要です。問題はありません。Railsは、古いプラグインモデルから離れて、gemを排他的に使用するように大きく前進しています。
他のフレームワークの1つがニーズに合っている場合は、それを使用することをお勧めします。ドキュメントとサンプルに関しては、railsにはもっと多くのものがあることに注意してください。
もし私がRubyを学んでいて、Webフレームワークを試してみたいと思ったら、おそらくRailsが優れているからではなく、はるかに優れたツールとドキュメントが得られたからです。
sinatra、camping などの他のフレームワークを使用するときに発生する問題の 1 つは、Rails がアプリケーション内のファイルの実証済みの構造を提供することです。小規模なフレームワークは非常にオープンで無料です。
これは、複数の開発者と作業している場合、単純に規則に従うのではなく、規則の作成について話し合う必要があるため、マイナス面になる可能性があります。
Rails で使用されるほとんどの Ruby モジュール (ActiveRecord を含む) は、Rails なしで使用できます。しかしそうすると、Rails が提供する統合の利点を失うことになります。選択したフレームワークに Ruby モジュールを接着するために、特別な努力が必要になる場合があります。また、Rails で使用される Ruby モジュールに関するドキュメントのほとんどは、Rails でそのモジュールを使用する方法のみを説明していることにも注意してください。
Ruby を使用してから 1 年未満の場合は、Rails に固執してください。ただし、他のフレームワークのいずれかで処理したほうがよいという非常に明確な必要性がある場合を除きます。
より軽量なフレームワーク、特に Sinatra は、必要なものを正確に知っていて、未使用のコードによる追加のオーバーヘッドを許容できない人々に人気がある傾向があります。基本的に、Rails が提供するものに固執するのではなく、ツールチェーンを選択します。(そうです、Rails では ActiveRecord などを他のライブラリに置き換えることができますが、それは簡単なことではありません。)したがって、より軽量なフレームワークは大幅に自由度を高めますが、多くの場合、かなり多くの作業を行う必要があります。
ネットワーク効果が少し役割を果たします。
ActiveRecord プラグイン (acts_as_nested_set など) を除いて、代替フレームワークのいずれでもすぐに使用できる Rails プラグインはないと思います. ORM にはDataMapperをお勧めします。ActiveRecordよりも高速であるだけでなく、非常にモジュール化されており、プラグインは簡単にインストールできる実際の gem です。違いとして、ActiveRecord プラグインはほとんどがモンキー パッチであり、新しいバージョンごとに機能しなくなる傾向があります。
Sinatra には、「グッズ」、Rakefile、スケルトン、スクリプト/生成は付属していませんが、実際にはそれが目的で書かれています。余分なものをすべて徐々に「組み込む」ことができます。いくつかの基本的なレイアウトとデフォルトを備えた sinatra アプリのスケルトンもあります。これらが役立つ場合があります。