1) Stability vs Development Speed
The Rails (and it seems Ruby) attitude seems to be that fairly frequent compatibility breaking changes are OK. Bundler and a well managed Gemfile (and probably RVM too) allow you to progress at a slower rate on any Gems that haven't been updated.
The Django (and Python) world seems much more careful about not making breaking changes. In other comments this thread the slow deprecation of old Pythons in Django is mentioned. For Python itself Python 3 was I think regarded as the one chance to break things before locking down compatibility to not change very much going forwards.
2) Documentation
I find the Rails Documentation pretty poor at the details such as explaining exactly what all the valid options are and their effects. Links to the source are often given in the API docs but there are often so many layers of indirection to drill though to find what options are actually supported that the value is limited. There are plenty of examples (e.g. Railscasts) to copy and learn from to get you going on hundreds of different topics but you need these resources to guide you through the massive universe.
Django is more traditionally thoroughly documented but without the really quick 'get something running in 10 minutes' guides. I think once you get proficient you could just look up what you need and it is all there for you but there is quite a lot to learn at the start.
So in my view: Rails - quick start, learn by examples, lean on package management systems heavily. Django - slightly slower start, properly documented in the details, stable long term platforms.
* Baked in migrations. * The asset pipeline
Honestly those two things alone are MAJOR headache savers.
Django and Ruby 2.x are probably more or less equivalent, but Rails 3.x (and especially the upcoming 4.x, with very cool things like cache digests) are just more modern.
I suggest testing each out and see which you prefer. Ruby and Python are similar languages but different enough that you'll want to spend some time learning each. Both will benefit you in the long run, as I work with ruby and python daily and is useful knowing both.
I will warn you that Django was easier for me to pick up than rails. Rails guys (me included) tout how easy it is to get going with rails, which is true. However, getting really good with rails is hard. Knowing exactly what's going on and why, how to extend ActiveModel or ActionController properly, monkey patching, proper testing practices, etc are quite the time sink, albeit a beneficial one in my opinion. I think if you have TDD or a client adamant about full test coverage, I've found rails support and practices are more flushed out than django's take.
EDIT: typos
http://blog.jupo.org/2011/07/30/rails-quick-start-for-django...
An older overview is available here: http://www.vaporbase.com/rails-django
&c.
For instance, if you want to use a class like it was a MySQL table, you could include a few ActiveModel classes which will make things for ActiveSupport helpers work with them.
http://api.rubyonrails.org/classes/ActiveModel.html - pick and choose what you want in your classes. This was one of the major changes in Rails 3
EDIT: just to clear it up, by ActiveModel I mean Model. Rails is convention over configuration and adheres to the MVC pattern and philosophy
Web frameworks really only differ in philosophy, and in this case, both are batteries-included, monolithic frameworks. They are practically identical solutions.
Python3 became the living branch of Python during the Bush Administration. Django has been claiming ever since that there is just so much stuff in Django that, even in early 2013, they won't be able to honestly recommend it to Python3 programmers, except for "experiments".
So with this much baggage, what chance is there that Django will soon become a sleek racehorse of a Python3 framework? It could happen, or not, but I'm probably not the only one in the market for a sleek racehorse based entirely on the living branch of Python.
Well, no.
There are basically two competing things that made this take a while, and which both stopped being issues right about the same time.
The first was that the initial Python 3 releases were not production-quality stuff. They worked, but they were there to let people get a feel for the changes and maybe start trying out the porting process. Anyone who just jumped to Python 3.0 shortly after release probably had no idea what they were doing (or had a very good idea what they were doing, but that group was a lot smaller).
The second was that we've got this thing, called a userbase :)
And, well, lots of 'em were running operating systems that were still shipping ancient stuff like Python 2.3, and we didn't really want to throw them under the bus, especially since it was mostly beyond their control -- a corporate department said "OK, we're going to go with RHEL", and that was that. So we waited a bit for that situation to start improving, and kicked off a process of deprecating one 2.x version each of the last few releases until, with Django 1.5, we're at a minimum of 2.6.
As for the "stopped being issues" part: Python 3.2 and especially Python 3.3 are very nice, much more mature releases than 3.0/3.1, added stuff that makes porting much less ugly, etc. etc., so suddenly running production stuff on Python 3 is really broadly viable. And, hey, we're on a minimum-2.6 stance now, and 2.6 is when the really nice porting and unified-codebase stuff got added!
At my last Django meetup, we did a show of hands of who was waiting for Django to move before personally switching over to Python 3, and it was basically everyone.
This pleases me greatly. No longer do I need to rely on plug-ins (and therefore, them being updated) to minimally extend the existing User model for small projects.
Go on
We’re labeling this support “experimental” because we don’t
yet consider it production-ready, but everything’s in place
for you to start porting your apps to Python 3. Our next
release, Django 1.6, will support Python 3 without
reservations.Although obviously plug ins and other components would also need to be compatible too.
- Python3 support! (supports python2.6.5+ and python3.2+ in the same code base)
- {% verbatim %} (no collision problems with mustache)
- Built-in Partial model saving