3 ms·

Eh, they all solve the same problems. Django has the additional requirement that you think exactly like the designers of the monolithic framework or you will s

Eh, they all solve the same problems. Django has the additional requirement that you think exactly like the designers of the monolithic framework or you will spend a lot of time swimming upstream. Ever tried to integrate Django or Celery into a project whose configuration comes from .ini files or some other method? You end up writing your own configuration layer to get something that Django approves of. Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? In the end, convention over configuration (just put your files in the magic locations, for example) is just another term for developer arrogance: of course my way is natural and everyone will want to think like me! With something like Pyramid I never find myself following a debugger down into the guts to understand why it is or isn't doing something -- I have to do this all the time with Django because some piece of magic isn't working as advertised. Ultimately, something like Django is concerned with "how can I make it work?" What professional engineers should be concerned with are questions like "what happens when it doesn't work?" and "will someone else be able to understand this?" With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. The entire work of engineering is to make it work, without also making it comprehensible to others and easily serviceable -- and do it fast. Picking Django because it makes it easy to start a new project is just satisfying one of those, unless you really understand deeply the bowels of the framework or expect to hire someone who does.

drl42 12y ago
I think that Django actually has very little "magic", given the functionality that it provides. With respect to the ORM - For standard CRUD stuff, I think the ORM just works. With respect to "Will someone else understand the code" - Having trained few engineers to use Django, the main issue always has been correct decomposition of the entire webapp into different submodules or Django "apps" - If the project has been properly modularized, then it is easy to find problems or add functionality. In short, imho writing good serviceable code does not depend upon the framework - it depends upon the team :)
gtaylor 12y ago
> Eh, they all solve the same problems. This is really the best summary. It comes down to what your individual team can be more productive with. If it's Django, use Django. If it's Flask, use Flask. > Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? There was a time when I thought much the same. But now I am glad for Django's more simple ORM. I've ended up liking ORMs less and less in general. If I'm going to use one, it's only going to be for the more simple queries. For this kind of case, Django's ORM really shines. Even our less technical staffers can get a copy of the DB and run some business analytics queries themselves. For anything else, I'd much rather write the SQL myself. It's not difficult, and you are going to do better than the ORM could. Additionally, no ORM is going to have 100% support for every feature Postgres or MySQL offers. For example, we've made great use of Common Table Expressions. > With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. Conversely, having a bunch of projects to track and update means breakages can occur in many different places for any given combination of versions. In practice, we haven't found Django to be difficult to run. Quite the opposite, really. It's a cohesive unit. If you run into an issue, you are going to find lots of mailing list/bug tracker posts walking you through the solution in most cases.
jefurii 12y ago
> Ever tried to integrate Django or Celery into a project whose configuration comes from .ini files or some other method? You end up writing your own configuration layer to get something that Django approves of. I'm doing exactly that in my current project. It wasn't so bad, just a couple lines in settings.py. ConfigParser FTW! > In the end, convention over configuration (just put your files in the magic locations, for example) is just another term for developer arrogance: of course my way is natural and everyone will want to think like me! I'd argue that Flask or Pyramid encourage a form of that too, just in a different place. Yes the Django devs have decided where you should put many of the things, but if someone new comes to your project already knowing Django they'll know where to look for things, whereas a Flask or Pyramid project may have its own idiosyncratic layout.

drl42 12y ago

I think that Django actually has very little "magic", given the functionality that it provides. With respect to the ORM - For standard CRUD stuff, I think the ORM just works. With respect to "Will someone else understand the code" - Having trained few engineers to use Django, the main issue always has been correct decomposition of the entire webapp into different submodules or Django "apps" - If the project has been properly modularized, then it is easy to find problems or add functionality. In short, imho writing good serviceable code does not depend upon the framework - it depends upon the team :)

gtaylor 12y ago

> Eh, they all solve the same problems. This is really the best summary. It comes down to what your individual team can be more productive with. If it's Django, use Django. If it's Flask, use Flask. > Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? There was a time when I thought much the same. But now I am glad for Django's more simple ORM. I've ended up liking ORMs less and less in general. If I'm going to use one, it's only going to be for the more simple queries. For this kind of case, Django's ORM really shines. Even our less technical staffers can get a copy of the DB and run some business analytics queries themselves. For anything else, I'd much rather write the SQL myself. It's not difficult, and you are going to do better than the ORM could. Additionally, no ORM is going to have 100% support for every feature Postgres or MySQL offers. For example, we've made great use of Common Table Expressions. > With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. Conversely, having a bunch of projects to track and update means breakages can occur in many different places for any given combination of versions. In practice, we haven't found Django to be difficult to run. Quite the opposite, really. It's a cohesive unit. If you run into an issue, you are going to find lots of mailing list/bug tracker posts walking you through the solution in most cases.

jefurii 12y ago

> Ever tried to integrate Django or Celery into a project whose configuration comes from .ini files or some other method? You end up writing your own configuration layer to get something that Django approves of. I'm doing exactly that in my current project. It wasn't so bad, just a couple lines in settings.py. ConfigParser FTW! > In the end, convention over configuration (just put your files in the magic locations, for example) is just another term for developer arrogance: of course my way is natural and everyone will want to think like me! I'd argue that Flask or Pyramid encourage a form of that too, just in a different place. Yes the Django devs have decided where you should put many of the things, but if someone new comes to your project already knowing Django they'll know where to look for things, whereas a Flask or Pyramid project may have its own idiosyncratic layout.