zeemonkee2's comments

All other things being equal, a "homegrown" project by coders who know what they're doing is going to be better than a framework project by coders who don't. Yes, I understand your reason, and given coders of equal ability it may be true; but I've seen Django projects written so badly the framework made very little difference to maintenance overhead (and as Django becomes more popular and mainstream we're going to see more examples of this).

I said it makes no difference.

What if you want to get rid of the username field altogether?

For example, my typical use case: unique email address for logins, no usernames:

I suppose you could subclass User with a longer username, and sync the username with the email address using a signal, for example.

Still, it's a chunk of workaround I end up doing one way or another with each new project. Hopefully soon (based on discussions on django-developers group) we'll see some kind of pluggable User model.

I'm not arguing against using a framework, if it fits your project requirements, and we can argue the day long about micro-vs-full-stack. There are good arguments for both, they suit different people and projects.

My own observation is that bad codebases are the result of bad development practices regardless of framework. In my last job the code quality was so poor (and the management processes so broken) that whether they'd used Django, Flask or roll-your-own would not have made a whit of difference.

Sure, if you did it completely on your own. More likely you use Flask or Pyramid which provide the plugins/entry points/templates to make wiring these components together quite easy.

It's a long-standing tradition for DjangoCon to have a "Why Django Sucks" presentation. And a healthy one IMHO.

Really, it's more of a management problem than a coding problem. Short-term thinking, bad hiring/outsourcing practices, and poor client expectations management, among others. A framework or language isn't magic pixie dust that will make these problems go away.

At this point I'd prefer to work on a well-managed, professionally coded project written in PHP than one written using <insert-python-framework-du-jour-here> run by idiot managers.

Most codebases I've seen that are badly maintained or managed over the years are horrible messes - whether Django, Rails or anything else. The last codebase I worked on - written in Django - was appallingly bad. That's no fault in any way of Django, but no framework is going to save you from poor coders, last-minute rushed requirements, chronic technical debt, or lack of investment in refactoring.

> I think people who criticize Django have yet to make up their minds about what a framework is all about, and what, if anything, it's for. They just hold on to their utopian idea of what their framework should be.

No, they have a different idea of what a framework should do or not do. Doesn't mean they have some utopian idea just because it's not Django.

> Django templates are sloooooow. Jinja 2 is an order of magnitude faster

Template execution speed is unlikely to be the bottleneck for the vast majority of sites. I prefer Jinja2 for the flexibility (macros etc) rather than the performance.

In Python, you wouldn't reroll your own ORM, routing and templating - you'd use SQLAlchemy, Werkzeug, Jinja2/Mako/whatever.

Agree on Django auth; it's horribly designed - need an extra field - use a separate UserProfile - really? Need to login with unique email address - which EVERY SINGLE client asks for - you're going to go down a rabbit hole. A group/permissions system almost nobody uses outside the admin.

Django auth was designed around the typical use case ca. 2005. The world's moved on a bit since then.

What I end up doing nowadays is roll my own (and re-use bits of contrib.auth where appropriate, such as password hashing) using a custom auth backend and keep a separate site for the Django admin which uses contrib.auth models. As long as I don't have to use 3rd party apps that rely on auth.User I'm fine.

Sounds like a good idea, however to sell at BigCo:

- you really need contacts. As the OP points out, this involves working with them some time (in the inside, as contractor, selling to them, whatever). If you haven't, find a salesman who has the right contacts and experience: "don't call X, he's retiring next year and doesn't want to rock the boat with a new purchase. He'll just string you along. Call Y instead, he's new to the company and wants to prove himself - I play golf with him next Saturday".

- decision making at BigCo is at a frustrating, glacial pace. If you're used to the instant feedback of throwing something up in an app store or HN or whatever, you'll be disappointed.

- lots and lots and lots of meetings. Incredibly inane and the lead times are ridiculous.

- once you've proven yourself, it can be a real gravy train.