Django のような Web アプリ開発の容易さと、優れた展開、デバッグ、その他のツールを組み合わせたものがあるのではないかと考えています。
Django は、コンテンツの多いサイトを構築するための非常に生産的なフレームワークです。私が試した中で最高のものであり、そこにあるいくつかのJavaの怪物と比較して新鮮な空気を吸っています. ただし、Python で記述されているため、デプロイ/パッケージ化、デバッグ、プロファイラー、およびアプリケーションの構築と保守をはるかに容易にするその他のツールに関して、実際のサポートはほとんどありません。
Ruby にも同様の問題があり、私は Python よりも Rubyの方が好きですが、アプリの管理/サポートに関しては、Rails は Django とほぼ同じボートに乗っているという印象を受けます。
重要なプロジェクトで Django と Grails (または他の Web フレームワーク) の両方を試した人はいますか? 彼らはどのように比較しましたか？
あなたは、Grails と Django の両方を使用する人を求めました。私は大きなプロジェクトのために両方の仕事をしました。ここに私の考えがあります：
IDE: Django は Eclipse で非常にうまく機能し、Grails は IntelliJ Idea で非常にうまく機能します。
デバッグ: 実質的に同じです (Grails には IntelliJ を使用し、Python には Eclipse を使用すると仮定します)。ステップのデバッグ、変数の検査など...どちらにもprintステートメントは必要ありません。django のエラー メッセージは役に立たない場合もありますが、通常、Grails のエラー メッセージは非常に長く、解析が困難です。
単体テストの実行時間: django: 2 秒。Grails: 20 秒 (テスト自体はどちらもほんの一瞬で実行されます。残りの部分はフレームワークをロードして実行する部分です...ご覧のとおり、Grails のロードはイライラするほど遅いです)。
デプロイ: Django: 1 つのファイルをコピーして apache 構成に貼り付けます。再デプロイするには、コードを変更して apache をリロードするだけです。Grails: .war ファイルを作成し、Tomcat にデプロイし、すすぎ、再デプロイを繰り返します。
プログラミング言語: Groovy は本当に素晴らしいです。Python よりも好きです。しかし、私は確かに不満はありません。
プラグイン: Grails: 壊れたプラグインがたくさんあります (これまでのすべての Java ライブラリを使用できます)。Django: 安定したプラグインがいくつかありますが、必要なことのほとんどを行うには十分です。
データベース: Django: South を使用したスキーマの移行、および一般的に直感的な関係。Grails: スキーマの移行はありません。デフォルトでは、起動時にデータベースが削除されます... WTF
使用法: Django: スタートアップ (特に Gov 2.0 スペース)、独立した Web 開発ショップ。Grails: エンタープライズ
それが役立つことを願っています!
Grails。
GrailsはRails（Ruby）のように見えますが、Javaよりも単純なgroovyを使用しています。これはJavaテクノロジーを使用しており、問題なく任意のJavaライブラリを使用できます。
また、単純さよりもGrailsを選択し、java lib（jasper report、jawrなど）がたくさんあります。SpringSourceに参加してベースをしっかりとしたことをうれしく思います。
ただし、Python で記述されているため、デプロイ/パッケージ化、デバッグ、プロファイラー、およびアプリケーションの構築と保守をはるかに容易にするその他のツールに関して、実際のサポートはほとんどありません。
Pythonには次のものがあります：
したがって、このことについて心配する必要はありません。PythonとDjangoを使用して、幸せに暮らしてください:-)
幸運なことに、Django の最新バージョンはJythonで実行されるため、Java エコシステム全体を置き去りにする必要はありません。
フレームワークといえば、今年評価したのは次のとおりです。
このフレームワークはどれも、Django や Ruby on Rails の能力に匹敵するものはありません。私の同僚の意見に基づいて、kohanaフレームワークをお勧めします。欠点は、PHP で書かれており、私の知る限り、PHP にはアプリのデバッグ、プロファイリング、およびパッケージ化のための優れたツールがないことです。
編集:これは、Python アプリ(特に Django アプリ)のパッケージ化と展開に関する非常に優れた記事です。現在、Django コミュニティで話題になっています。
私には、もともとRuby on Railsを使用してアプリケーションを書き始めた友人が2人いますが、いくつかの問題と制限に遭遇しました。約8週間の作業の後、彼らは他の代替案を調査することにしました。
彼らはCatalystFrameworkとPerlに落ち着きました。それは約4か月前のことであり、アプリケーションがどれだけ優れているか、そしてどれだけ柔軟性があるかについて繰り返し話し合っています。
Perlを使用すると、多数のツールに加えて、すべてのCPANを利用できます。少なくとも、それを見てみることをお勧めします。
Pythonの場合の「適切なデプロイメント」の問題には、Javaの場合のような深い意味はありません。
DjangoのPythonデプロイメントは、基本的に「ファイルの移動」です。必要に応じて、subversionトランクディレクトリから直接実行できます。
汗をかくことなく、Python distutilsを使用して、DjangoアプリをPythonのサイトパッケージに入れる配布キットを自分で作成できます。私はそれの大ファンではありませんが、それは本当に簡単です。
私のものはLinuxで実行されるので、Subversionディレクトリからディレクトリにものを移動する単純な「install.py」スクリプトが/opt/thisあり/opt/thatます。Apache構成で明示的なパス設定を使用して、アプリケーションが存在するディレクトリに名前を付けます。
パッチを適用するには、ファイルを所定の場所で編集します。（悪いポリシーです。）私はSVNの場所で編集し、小さなインストールを再実行して、実際にすべてのファイルが制御されていることを確認することを好みます。
個人的には、Djangoを使用してかなり大きなプロジェクトを作成しましたが、比較できるのは、前述の「モントロシティ」（Spring、EJB）およびTwistedのような実際に低レベルのものだけです。
インタプリタ言語を使用するWebフレームワークは、ほとんどが初期段階にあり、それらすべて（つまり、アクティブに維持されている）は、日々改善されています。
「適切なデプロイメント」とは、単一のファイルを J2EE サーバーにアップロードすることで Web アプリケーションをデプロイできる Java の EAR ファイルと比較しているのでしょうか? (そして、それほどではありませんが、WAR ファイル。EAR ファイルは、依存プロジェクトの WAR ファイルを持つことができます)
Django や Rails はまだそこまで到達していないと思いますが、間違っている可能性もあります... zuber は、Python 側の詳細が記載された記事を指摘しました。
Capistranoは Ruby 側で役立つかもしれません。
残念ながら、私は Python も Ruby もあまり使ったことがないので、プロファイラーやデバッガーを手伝うことはできません。
Cakephp.org
Cakephp は非常に優れており、Ruby on Rails (1.2) に非常に近いです。それはphpであり、共有ホストで非常にうまく機能し、実装が簡単です.
唯一の欠点は、ドキュメントがやや不足していることですが、すぐに入手してすぐにクールなことを始められます。
私は完全にcakephpをお勧めします。