Ambos te servirán bien. Las diferencias son menores y si uno es mejor que el otro para usted depende del requisito específico para este proyecto. Señalaré algunos aquí:
En términos de implementación (que mencionó), Rails es generalmente muy fácil de implementar en estos días. En la mayoría de los casos, puede usar Apache + Passenger con muy poca configuración (unas pocas líneas en httpd.conf, eso es todo). Es muy simple porque Rack proporciona una interfaz uniforme al servidor web, y Passenger es un módulo de Apache, por lo que no tiene que configurar un proceso de demonio por separado. Si elige ejecutar Passenger Standalone o Thin o Unicorn, debe configurar otro proceso de demonio, pero al menos no se necesita configuración en la aplicación Rails, gracias a Rack. Es aún más fácil si despliegas en Herokuk, un comando, eso es todo.
Simplemente no intente usar RVM o rbenv para la implementación, quédese con la versión del sistema de Ruby y use “paquete de instalación – implementación” para localizar las gemas en el proyecto.
- ¿Cuáles son los obstáculos para hacer que las aplicaciones web sean tan buenas como las aplicaciones nativas?
- Aplicaciones web: ¿Qué aplicación web puede crear con un presupuesto de $ 7500 y desarrolladores experimentados?
- ¿Es una buena idea comprar un servidor si mi empresa tiene alrededor de 7 empleados?
- ¿Cuáles son las mejores aplicaciones web de servicio público / gubernamental?
- ¿Cuál es la vida de un desarrollador web?
Django es un poco más complicado. Probablemente usará virtualenv para la implementación de espacio aislado, que es una solución fantástica de espacio aislado y muy fácil de usar. La parte tediosa es que probablemente usarás UWSGI o gunicorn o lo que sea como el servidor de Python, todos ellos son procesos de demonios independientes fuera de Apache, por lo que hay que lidiar con archivos de configuración adicionales. También es probable que deba modificar algunos archivos de configuración en Django para que funcione, y deberá especificar la raíz virtualenv correcta para UWSGI / gunicorn / etc.
Sin embargo, todo es un momento, recuerde que hace 3-4 años tenemos que usar RVM y conjuntos de gemas y envoltorios de RVM, y sacar su cabello solo para que Ruby + RVM + RubyGem + Passenger / Thin / Unicorn funcionen. Y en el lado de Django, virtualenv aún no se ha dado cuenta, así que es más o menos cargar y usar mod_wsgi y eso es todo.
Cuando dices “complicado”, sigue siendo bastante amplio. Django y Rails son mágicos en sus propias formas.
- Django tiene django-mptt que hace la estructura de árbol en SQL.
- La API de consulta de Rails Active Record es más poderosa, creo.
- Rails es muy RESTful, puedes consumir o crear fácilmente una API REST en una aplicación Rails
- Django’s Haystack es un módulo de búsqueda de texto completo muy potente y conectable. Rails Sunspot o Tire no son tan sofisticados y solo están diseñados para un único proveedor de búsqueda (Solr y elasticSearch respectivamente). Django / Python tiende a tener un mejor soporte para cosas de tipo arcihectural / IA.
- Rails probablemente tiene un enrutamiento de URL más flexible y tiende a depender del enrutador principal. Las aplicaciones de Django en su mayoría delegan al enrutador de URL dentro de cada aplicación.
- Django tiene un marco de almacenamiento en caché conectable en el núcleo. El almacenamiento en caché del núcleo de Rails no es tan sofisticado
- Rails es compatible con AJAX desde el principio, tiene jQuery, SCSS y Coffeescript integrados, y es realmente fácil implementar el enlace de datos AJAX. Django no tiene ninguna magia AJAX incorporada.
- Rails (y Ruby en general) y toneladas de bibliotecas web front-end que se integran con widgets de Javascript, cuadros de texto de autocompletado, etc., incluso pueden integrarse con cosas más nuevas como administradores de paquetes de JavaScript y marcos de JavaScript del lado del cliente. Una gran ventaja para la aplicación web de escritorio.
- Por otro lado, si está utilizando una aplicación web de escritorio, probablemente usará un marco del lado del cliente como Backbone.js, etc. Para estos marcos del lado del cliente, Rails tiene un mejor soporte que Django pero no tan bueno como el evento basado en web asíncrono como Node.js (Javascript) o Twisted (Python) puede ser mejor.
- Python tiene un ecosistema mucho más grande fuera de Django. El ecosistema de Rails es mucho más grande que Django, pero el ecosistema de Ruby en su conjunto, aunque sustancial, no se puede comparar con Python. Probablemente encontrará bibliotecas Python más maduras para fines especializados que Ruby, especialmente cuando se trata de cosas de nivel inferior (por ejemplo, Twisted) y cosas orientadas a la investigación (por ejemplo, NLTK)
Estos están justo en la parte superior de mi cabeza, como puede ver, la mayoría de estas cosas son bastante específicas, por lo que realmente depende de su aplicación.
Pero si la “aplicación web de escritorio enriquecida” es lo más importante para este proyecto, definitivamente diría que va con Rails, ya que tiene un excelente soporte de representación del lado del cliente, una integración madura de integración mágica AJAX javascript con marcos CSS populares como Compass, Bootstrap y ZURB Foundation, y toneladas de gemas Rails que generan widgets jQuery para ti.
Definitivamente, también mire algunos de los marcos de JavaScript MVC modernos del lado del cliente (Backbone.js, Angular.js, spine.js, etc.), lo necesitará para un proyecto como este. El sitio TodoMVC es un buen punto de partida.
TodoMVC
Buena suerte.
