Comment by alnayyir | Hacker News Reader

Comment by alnayyir | Hacker News Reader

Parent Full thread

Forms are a fragile waste of time 80% of the time.

Only reusable modelforms + generic views really redeem them in my eyes.

The ORM is enjoyable but terrible for doing mass migrations. I've had to do some pretty ridiculous backflips just to get migrations to finish on our VPS.

The utter lack of real migrations. For. Fuck's. Sake. Makes it impossible to make any rapid changes to your models without thinking, "OH GOD WHAT AM I GOING TO BREAK!?!"

There are random and strange install-specific errors that will crop up and we'll either have to reinstall python/django, the OS, or ignore it and trudge on.

And there won't be any mentions of said problems on the mailing list to speak of either. (These kinds of things have occurred on OS X and Win32 both, so don't start pointing fingers.)

The incredible awkwardness of AJAX in Django. Utterly useless. It apparently suited Jacob and Adrian to pretend javascript didn't exist in their world.

It's opaque, doesn't support multiple databases, doesn't support non-relational databases, and it's nearly impossible to modify/rip out any given portion of the framework. It's the epitome of what people hate about full'ish stack frameworks.

I'm to the point where I no longer feel Django is saving me any time. The crippling of templates doesn't create a substantial separation of duties at work because I work with incompetents. Instead I'm left with crippled templates and whiny coworkers.

I'd rather work with Werkzeug/Web.py/Sinatra/Rails at this point. At least Rails was designed to be modular, allowing me to rip the parts I don't like out.

Absolutely agree with you on most of the points. A couple of quibbles - Django now supports multiple databases (as of 1.2) and South (http://south.aeracode.org/) is more or less the default migration tool nowadays and is OK for most jobs.

Personally, I find generic views to be useless for anything but the simplest of prototyping. Making them functions rather than callable classes was a big mistake IMHO. I very rarely use them in a serious project.

Another pet hate is UserProfiles - you have to use a separate model if you want any custom fields for your users which entails a join whenever you want to use it. It's been a ticket for years but nobody seems willing to fix it.

I agree with you 200% on templates and am in a very similar situation. Having to write convoluted code in template tags for the simplest of things is frustrating, when you can have simple function calls and template macros in Mako and Jinja2.

I'm not hugely fussed about AJAX myself - I tend to keep things simple in the views and just pass JSON back and forth and jQuery does most of the front-end work. I disliked the Rails way of binding everything to a particular JS library, not sure if it's still done that way any more.

Django is OK for certain projects. What annoys me though is that like Rails, it has gotten such mindshare in certain companies that they call themselves "Django shops" and want to use it for everything, without considering alternatives. Personally I stay well clear of it for my own projects - Pylons, Werkzeug, SQLAlchemy et al are a lot more fun to work with.

>Django now supports multiple databases (as of 1.2) and South

I don't get to use either at work.

I don't really care for SQLAlchemy either.

Ok. We're on the same track then but I would put it a little more friendly at the moment but I probably haven't got enough experience yet.

I spotted werkzeug ('tool' in German) a while ago and it definitely looked very good.

I've built 3 sites in Django now, two small ones and one larger one. The small ones worked fine, the larger one Django immediately turned from 'enabler' in to 'straightjacket'.

I hand coded the forms so they're not even part of the frustration, the ORM is definitely a limiting factor, agreed with the AJAX oversights, even the simplest stuff and you're immediately out of django in to 'roll your own' mode.

Not having multiple db connections was one of the first things I was wondering about how serious this package really was, after all almost all non-trivial setups will access multiple dbs, even if not at the same time then sequentally.

Import wasn't much of a problem for me because I did the import by talking to the DB exclusively, I had the 'export' in exactly the right format for import into the mysql django tables. But it would have been nice to have a tool handy to do that.

The admin is fine until you have more than just a toy dataset, and the way in which you configure the admin has altogether too many little 'magic' steps in it.

So far it's been a mixed bag. For small sites probably a good fit, for larger ones probably not.

Fully agreed on the template limitations, and the lame excuses around not having some basic functionality in there are really trying my patience.

But I haven't seen anything yet that I felt really was a step up from the rest.

I'll keep looking though.

>the larger one Django immediately turned from 'enabler' in to 'straightjacket'.

Yeah, I've had a bit of enlightenment regarding that. I think the trick is to eventually treat it a bit like Philosophy.

Toss aside what you encounter to be a problem, take with you what is useful.

The signals backend and request object encapsulation has proven invaluable, combined with the corpus of snippets and tricks out there.

The templates are really starting to get on my nerves. Probably going to use Jinja2 outside of work here on out.

well, it's been a step-up from what I've experienced because of a perfect storm occurring from the power of combining generic views, quick-n-easy pagination, the ORM, and template inheritance. I've become incredibly productive in Django in spite of the annoyances.

In fact, you may want to check out "annoying django" for some hacks and neat features to deal with some painpoints.

This includes an AJAX view decorator to quickly pass json back and forth.

Reply on news.ycombinator.com