5 ms·

As a both Django and Rails developer I suggest you to choose Ruby on Rails. Rails pluses: - Has a nice asset pipeline (automatic conversion of CoffeeScript, S

by ersoft 14y ago

As a both Django and Rails developer I suggest you to choose Ruby on Rails. Rails pluses: - Has a nice asset pipeline (automatic conversion of CoffeeScript, Sass, Haml, Jbuilder, etc) and concatenation + mignifying. - Really configurable database migration with a nice DSL. (Django has South which auto generates migration files, but It isn't just as easy to change them) - Rake tasks (Django also has management commands, but It's easier in using rake) - multiple environments (development, production, testing), being able to store different configurations (Django does not have this, you can achieve this using some hacks) - Railscasts.com (great screencasts by Ryan Bates) - Better release circle, as long as I know in Django didn't appear many features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings) - more OOP than Django, it really follows MVC pattern, Django is a MVT (Model View Template framework) - More libraries and more complex and configurable than django libraries. Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. - Model hooks and scopes (I know django has model hooks but they are built using Django signals, not using nice DSL as in Rails) - Concerns inclusions which guides you to a clean coding style. - Controller before_filters (very useful when you want to run a filter before multiple actions, eg: check if user is logged in), I know it can also be done using Django middlewares. Django pluses: - Django admin (Rails also has a few plugins which try to implement this, but django's is built in and also well documented in their official docs) - Django built in authentication system (Rails comes with devise library and other alternatives, which is great but not built in) - Easier to learn (Django follows Python's Zen, "Explicit is better than implicit.", all classes or methods you use must be imported, Rails pollutes global namespace with all classes and namespaces imported from libraries when Gemfile is parsed). It is easier to learn which module each class comes from and it helps you a lot at debugging if you are a begginer. - Django middleware (you) - Form based validation (each model can be validated using form class, another minus for Rails is that there was some security vulnerabilities targeting mass assignment on Models)

LeonidasXIV 14y ago
> Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This has been fixed in the upcoming Django 1.5. I don't want to argue with you, just point out this tiny detail.
legutierr 14y ago
Much of what you say is opinion (so I can't disagree with it), but I think a couple of your facts are off vis-a-vis Django (or at least out of date): > Better release circle, as long as I know in Django didn't appear many features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings) A lot has been added since 1.0, including multi-db support, admin actions, aggregates in the ORM (and other ORM improvements), class-based views, and many other features that I can't think of off the top of my head. One benefit of Django that you are leaving off your list is general stability, in the sense that the Django team is obsessed with ensuring backwards compatibility between major releases. My understanding is that the Rails team is willing to break backwards compatibility with a frequency that can impact people negatively. > Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This is changing in 1.5, the release of which is expected soon. > More libraries and more complex and configurable than django libraries. Honest question: how many of these Rails libraries implement things that are implemented in the Python standard library? In other words, are there more Rails libraries because Ruby itself is less complete than Python?
- ersoft 14y ago
  You're right, I can be out of date, I didn't code in Django in the past year, only in Ruby on Rails, but still I have the impression that things go much slower on Django release circle compared to Rails I'm glad to hear they are fixing the annoying bug in 1.5. About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example: Testing: rails built in, rspec, minitest, test-unit, bacon, etc JSON Generation for views: jbuilder, rabl Memcache: memcached, dalli And many other gems have more than one alternative, which I think it's nice.
  - dgunn 14y ago
    > About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example:... I think you're stretching the meaning of this a bit beyond it's intent. It applies to more low level things than testing or JSON generation. The standard library does have a lot of excellent (and almost default) choices but it doesn't stop people from making alternatives.

by ersoft 14y ago

LeonidasXIV 14y ago

> Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This has been fixed in the upcoming Django 1.5. I don't want to argue with you, just point out this tiny detail.

legutierr 14y ago

Much of what you say is opinion (so I can't disagree with it), but I think a couple of your facts are off vis-a-vis Django (or at least out of date): > Better release circle, as long as I know in Django didn't appear many features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings) A lot has been added since 1.0, including multi-db support, admin actions, aggregates in the ORM (and other ORM improvements), class-based views, and many other features that I can't think of off the top of my head. One benefit of Django that you are leaving off your list is general stability, in the sense that the Django team is obsessed with ensuring backwards compatibility between major releases. My understanding is that the Rails team is willing to break backwards compatibility with a frequency that can impact people negatively. > Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This is changing in 1.5, the release of which is expected soon. > More libraries and more complex and configurable than django libraries. Honest question: how many of these Rails libraries implement things that are implemented in the Python standard library? In other words, are there more Rails libraries because Ruby itself is less complete than Python?

ersoft 14y ago
You're right, I can be out of date, I didn't code in Django in the past year, only in Ruby on Rails, but still I have the impression that things go much slower on Django release circle compared to Rails I'm glad to hear they are fixing the annoying bug in 1.5. About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example: Testing: rails built in, rspec, minitest, test-unit, bacon, etc JSON Generation for views: jbuilder, rabl Memcache: memcached, dalli And many other gems have more than one alternative, which I think it's nice.
- dgunn 14y ago
  > About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example:... I think you're stretching the meaning of this a bit beyond it's intent. It applies to more low level things than testing or JSON generation. The standard library does have a lot of excellent (and almost default) choices but it doesn't stop people from making alternatives.