while I'm not familiar with Grails, I am familiar with other frameworks besides Django and I've got to say, it seems like lots of the choices the Django developers made are completely backwards compared to how other frameworks manage things.
- Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
- ModelForm._meta knows it's app_label, why doesn't a regular Form
- 200-line migration files are just not fun to grok.
- ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago)
- Having a user model you're not supposed to touch
- urls.py gets way too disconnected from what they are actually routing to
- managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
- if request.method == 'POST': ...
- The `class Meta:` pattern.
SQLAlchemy is the better ORM for python.
Jinja2 is a similar template syntax but with better performance.
WTForms are easier to work with than Django forms.
Tastypie also makes a lot of dubious decisions.
I just really don't see where this framework fits in.
> Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
Because Js stuff belongs in the frontend? Django very explicitly does not do frontend logic.
> ModelForm._meta knows it's app_label, why doesn't a regular Form
Because ModelForms depend on models which depend on apps to function properly. Forms are just plain old classes.
> 200-line migration files are just not fun to grok.
No, but they allow the migrating class a lot more flexibility by letting you access the ORM within a migration with no concerns about what your current models files look like.
> Having a user model you're not supposed to touch
1.5 and on have pluggable user models. Prior to that most of the important stuff was highly overrideable.
> urls.py gets way too disconnected from what they are actually routing to
That speaks more of the issues with your routes rather than what the framework allows. There are a few well-established patterns which make the routing no less clear than any other framework.
> managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
Then you're not understanding what a Django app actually is and how it differs from a regular module.
> if request.method == 'POST'
As opposed to?
> SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms
Seriously, these are non-issues, they have been touched upon dozens of times, and you clearly have not used the framework's integration capabilities sufficiently to understand its strengths, so either use something else or learn to leverage its unique advantages.
- Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
- ModelForm._meta knows it's app_label, why doesn't a regular Form
- 200-line migration files are just not fun to grok.
- ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago)
- Having a user model you're not supposed to touch
- urls.py gets way too disconnected from what they are actually routing to
- managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
- if request.method == 'POST': ...
- The `class Meta:` pattern.
SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms. Tastypie also makes a lot of dubious decisions.
I just really don't see where this framework fits in.