Ask HN: PHP, Django, or Rails? Oh my
I'm working on a site that needs to be quick and secure. I've done a lot of work with PHP but from experimentation it seems like Ruby and Django have some major advantages in terms of coding efficiency. If you were in my shoes, which language would you go with? I've tried to find a recent comparison but my google abilities have failed me tonight.
10 comments
My impressions from using both Rails and Django (more rails than django to be fair):
Rails - lots of good defaults and conventions that you will not need to change for quite a while. Often leads to the idea of Rails magic which can bite you occasionally. Django - more config up front, but you can sort of fine tune it to your own style and you'll get a better understanding of what's going on behind the scenes.
Rails really enforces a one controller method per resource action - so you have individual actions in your controller for listing, creating, updating, destroying, showing your resource. This is, in part, because routes are automagic in rails - simply defining a resource in your routes.rb will wire up all the CRUD routes with standard names you could wish.
Django doesn't enforce defaults in this respect - you create your urls yourself, defining them with regex, you name them as you wish and you point them to methods as you wish. You can, if you prefer, set up one method for a resource and control all the logic in that method (check for GET or POST, check if its in the db or not, save or update etc).
Rails and Django can both be thought to implement MVC, Django, however, doesn't name it as such - equivalents are: Rails Model - Django Model Rails Controller - Django View Rails Views - Django Templates
Rails will put each resource into individual files - one model per resource, one controller per resource multiple views per resource.
Django tends towards one model file with all your models, one views file with your "controller" logic, multiple template files for your front end.
Django has the concept of "apps" within a project - I find that separating a project into multiple apps helps keep code organised nicely - you can take this to extremes and have an app per resource if you wish or go for a more domain driven ideal and have an app per domain model.
Django is much more explicit - you will write many more import statements than in Rails, where you can go for days (dare I say projects) without doing so.
Rails has built in migrations, for Django you need a bolt on (south).
Rails is a "migration first" approach. Django is a "models first" approach. By this I mean Django has explicit model definitions that you will write by hand. With Rails you will write a migration to define your models and let Rails create the explicit canonical version of your database definition (schema.rb).
With Rails, you'll quickly get sucked in to RVM or rbenv or similar to handle your ruby versions and gemsets. With Django, you'll use virtualenv.
I think the one you choose is basically down to how you view your code - if you go with Rails, fall in line with the Rails way and you'll be good to go. Don't try to buck the trend in the first instance and follow the community conventions - it's quickest to get going with rspec, even though the official docs use minitest/testunit for testing, just because there is more written about rspec out there, more examples in the wild etc. Django is great if you want more flexibility out of the box, but it comes with a price - you can tangle your code because you aren't guided quite as much as with rails. You'll spend more time considering your routing (this is good and bad).
From my perspective, I got more of an app up and running with Rails than with Django in an equivalent amount of time. But with Django I ended up with a more complete "map" of my app in my head than with Rails - for example, with Rails there's a kind of "I have a concept of books in my library, I want to add a new book so I click add....rails magic.....I end up in my new action in my controller and it (magically) renders my new.html.erb view" - the equivalent for me in Django would be "I want to add a new book so I click add and it hits my urls file and finds the route I've declared that points to my book_new function in views.py that explicitly renders my template". There's lots of Rails magic. But it's good magic. There's less Django magic, but that's also good. :)
By contrast, ASP.NET MVC is sort of inbetween the two - You declare your models explicitly, as you do in Django, it writes migrations for you from the models. The routing and view rendering is more akin to Rails than Django. However ASP version has strongly typed views (which really help with autocomplete) in contrast to both Rails and Django. It's actually fairly pleasant, though because C# is strongly typed, you'll end up with more code in general.
Rails - lots of good defaults and conventions that you will not need to change for quite a while. Often leads to the idea of Rails magic which can bite you occasionally. Django - more config up front, but you can sort of fine tune it to your own style and you'll get a better understanding of what's going on behind the scenes.
Rails really enforces a one controller method per resource action - so you have individual actions in your controller for listing, creating, updating, destroying, showing your resource. This is, in part, because routes are automagic in rails - simply defining a resource in your routes.rb will wire up all the CRUD routes with standard names you could wish.
Django doesn't enforce defaults in this respect - you create your urls yourself, defining them with regex, you name them as you wish and you point them to methods as you wish. You can, if you prefer, set up one method for a resource and control all the logic in that method (check for GET or POST, check if its in the db or not, save or update etc).
Rails and Django can both be thought to implement MVC, Django, however, doesn't name it as such - equivalents are: Rails Model - Django Model Rails Controller - Django View Rails Views - Django Templates
Rails will put each resource into individual files - one model per resource, one controller per resource multiple views per resource.
Django tends towards one model file with all your models, one views file with your "controller" logic, multiple template files for your front end.
Django has the concept of "apps" within a project - I find that separating a project into multiple apps helps keep code organised nicely - you can take this to extremes and have an app per resource if you wish or go for a more domain driven ideal and have an app per domain model.
Django is much more explicit - you will write many more import statements than in Rails, where you can go for days (dare I say projects) without doing so.
Rails has built in migrations, for Django you need a bolt on (south).
Rails is a "migration first" approach. Django is a "models first" approach. By this I mean Django has explicit model definitions that you will write by hand. With Rails you will write a migration to define your models and let Rails create the explicit canonical version of your database definition (schema.rb).
With Rails, you'll quickly get sucked in to RVM or rbenv or similar to handle your ruby versions and gemsets. With Django, you'll use virtualenv.
I think the one you choose is basically down to how you view your code - if you go with Rails, fall in line with the Rails way and you'll be good to go. Don't try to buck the trend in the first instance and follow the community conventions - it's quickest to get going with rspec, even though the official docs use minitest/testunit for testing, just because there is more written about rspec out there, more examples in the wild etc. Django is great if you want more flexibility out of the box, but it comes with a price - you can tangle your code because you aren't guided quite as much as with rails. You'll spend more time considering your routing (this is good and bad).
From my perspective, I got more of an app up and running with Rails than with Django in an equivalent amount of time. But with Django I ended up with a more complete "map" of my app in my head than with Rails - for example, with Rails there's a kind of "I have a concept of books in my library, I want to add a new book so I click add....rails magic.....I end up in my new action in my controller and it (magically) renders my new.html.erb view" - the equivalent for me in Django would be "I want to add a new book so I click add and it hits my urls file and finds the route I've declared that points to my book_new function in views.py that explicitly renders my template". There's lots of Rails magic. But it's good magic. There's less Django magic, but that's also good. :)
By contrast, ASP.NET MVC is sort of inbetween the two - You declare your models explicitly, as you do in Django, it writes migrations for you from the models. The routing and view rendering is more akin to Rails than Django. However ASP version has strongly typed views (which really help with autocomplete) in contrast to both Rails and Django. It's actually fairly pleasant, though because C# is strongly typed, you'll end up with more code in general.
I've been using some good frameworks in PHP such as CodeIgniter, Fuel, Zend, etc, but nothing can compare to Ruby on Rails.
A major advantage of ruby world is most open-source libraries and gems are actually usable and well written and maintained, whereas most PHP open sources are not maintained well or have a poor code quality.
A major advantage of ruby world is most open-source libraries and gems are actually usable and well written and maintained, whereas most PHP open sources are not maintained well or have a poor code quality.
If you're strong in PHP, there's the Slim Framework[0] which I've used on a couple of sites. It's not a full MVC framework though, but there's always an ORM[1] to get what you need out of DB integration.
If you need a full MVC, then Django and Rails are both good.
[0]: http://www.slimframework.com/
[1]: http://propelorm.org/
If you need a full MVC, then Django and Rails are both good.
[0]: http://www.slimframework.com/
[1]: http://propelorm.org/
It's totally a personal preference. I'm more of a ruby guy, I have friends that are more python people. Try both and see what fits you better.
Your only advantage is using the one you are familiar with.
Use them all? Try them out and decide for yourself? I think you'll find we are in the lucky position where we have lots of options. Each option can be a viable solution, most stuff comes down to personal knoledge, experience and preference.
Go with what you know. Just use a good framework.
Rails. Enough said :) You won't get it till you use it.
really? The same could be said of any framework though.
The "Rails magic" you mentioned above can be very powerful with "Ruby magic" if you know how to use them well.
vote for django.