Hacker News new | ask | show | jobs
by SiliconAlley 2473 days ago
I have worked extensively in both frameworks and would add to this:

* Django has comparatively limited I18n and localization faculties compared to Rails (with Django’s i18n built atop gettext, which I always found kind of brittle with .po files/string-based keys)

* No intelligent/efficient class reloading in development. The whole development server just restarts when you make changes

* No reloader for the shell (horrible for developer ergonomics - you can't just type "reload!", you have to restart the shell to pull in any change)

* Caching faculties in Django are much more limited - no template digests (to make template fragment caching much more robust)

* ActiveSupport has also always been a god-send for productivity. It may seem small but things like “Array#to_sentence” and the time functions (i.e. 1.day.ago) are incredibly useful.

* No default assumption of multiple environments (no default development/testing/production configuration files, environment detection, etc). This is pretty ridiculous for a web application framework.

* No built in credential encryption (makes keeping a team in-sync with keys for integrations a comparative pain)

* Dependency management is much more challenging in Python. The de-facto virtualenv + requirements.txt combo is lossy (no dependency graph) and awkward compared to bundler. There are other solutions here but something so foundational shouldn’t be so hard.

Django was the first web application framework I learned and I still work with it professionally from time to time (as recently as ~2 months ago). I am just a bit stunned by how much it has fallen behind in terms of its broad state of maturity, community/ecosystem, productivity, etc.
2 comments
batiste 2473 days ago
For once a fair criticism of Django by someone who seems to know the framework well.

I don't quite share the same experience with i18n though. I always found Django statical code analysis to extract translation keys to be superior in many ways to other translation systems. It is giving useful context that are stored in the PO files and good translation tools use them. I also never had any issue with string based keys. You can chose an english based key or an abstract whatever you prefer.

Some of the annoyance you mentioned, that I agree completely, are more of a language issue like: reloader, or dependency management.

For multiple environments there is a very simple pattern you can put in place using an environment variable and conditional imports. something like:

  from settings.base import *
  
  if env == 'prod':
    from settings.prod import *
link
e12e 2472 days ago
A bit funny (sad) about the dependencies - zope, the early web application server - brought much to python (eg: eggs) - and essentially worked more like bundler + Gemfile/Gemfile.lock - with its zc.buildout dep (and more) manager. And like with ruby/rails, it could be difficult to get it to converge on "known good sets" of dependencies.

Take a look at this dated doc for zope 4 - anyone who's had to fight with bundler should see some similarities - good and bad i think:

https://docs.plone.org/4/en/old-reference-manuals/buildout/b...

You can still use it today, too (but you probably don't want to):

http://www.buildout.org/en/latest/

link