Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Django Sucks

speakerdeck.com

Post reply on HN
Print view View original

141–150 of 206 posts

Re: Why Django Sucks

#141

Post by bad_user »

UK-AL wrote: post #88
MatthewPhillips wrote: post #58

Earlier quoted context omitted.

The problem is not frameworks; the problem is object oriented programming. Simply put, OOP lends itself to kitchen-sink frameworks because it is the only way to really share code in OOP. We write these large hierarchy of objects and then, because we have to carefully maintain state, we mark most of it as private, or sealed. Then we give precise instructions on how to consume and use the code, and even more precise in…

Well that's strange because Django didn't use much OO either when I used it in the past, only for the ORM.

You must have been using a different framework called "Django" than I did.

Re: Why Django Sucks

#143

Post by its_so_on »

zeemonkee2 wrote: post #135
jshen wrote: post #103

Earlier quoted context omitted.

Ad I've still never seen a homegrown solution that ties together libraries which was better off after a few years. Your experiences may differ.

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.

Could you summarize your suggested best practices (Specifically what you suggest is a good way to avoid at least some of the problems you list in your last sentence.)

Re: Why Django Sucks

#144

Post by its_so_on »

Sorry if this is a stupid question, but are these just slides without any voice or commentary?

Also, you might be interested in this video, http://www.youtube.com/watch?v=i6Fr65PFqfk "Why I hate Django" by Cal Henderson then of Flicker. 2008 though - I'd love to know about an update about the things addressed.

Re: Why Django Sucks

#145

Post by Daniel_Newby »

jtchang wrote: post #43
yesimahuman wrote: post #6

Thanks for posting this. I use Django extensively and I never really felt any pain from the tightly coupled monolithic approach, but I always like improving my tools. I will check out Flask. Any suggestions for making it easy to build REST style APIs? Is piston the #1 choice still?

I've used all 3 and I settled on "django rest framework". http://django-rest-framework.org/ The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call. I also had to map each and every call (GET/PUT/POST/DELETE) and there was no default out of box behavior. I felt like I was violating the DRY principle over and over. Tastypie was great when I started bu…

> The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call.

That sounds like the perfect place to use a Python function decorator, which lets you wrap a funtion in standard boilerplate.

Re: Why Django Sucks

#146

Post by mattdeboard »

acdha wrote: post #76
mattdeboard wrote: post #33

Earlier quoted context omitted.

Who's piling on Django? It has flaws and weaknesses just like anything. It is a huge codebase that tries to be everything for everyone, and it succeeds about being almost everything for almost everyone, which is great. But it can be very difficult to do relatively simple things with Django sometimes, mostly in the admin pages. Admittedly, this is a pain point people bring on themselves by trying to do too much there,…

This got a lot better in 1.4: TemplateResponse and the list filter API meant some gnarly code removal on my biggest customized admin project. That said, I also chose to implement many of my admin changes at a higher level: templates which use jQuery, etc. and interact with the REST API for e.g. complex object creation are much easier than the crazy form / widget hacks I used to try.

Yeah agreed, I just started writing js apps with backbone and dropping them into wherever in the amdin

Re: Why Django Sucks

#147

Post by Xion »

tonyarkles wrote: post #51
majormajor wrote: post #34

I think the "Constraints are Good" slide is massively oversimplified. Especially the "editors vs IDEs" and "primes vs zooms" bullets. Just for one example: stepping through an IDE's debugger, integrated into the code editor, to track down a problem is incredibly handy. It's a habit I picked up while living in Eclipse doing Java work, and why most of my Rails work is now in RubyMine instead of Emacs like it was when I…

This is diverging a bit, but weaning yourself off of the debugger habit can be incredibly liberating. I used to be a debugger junkie, but I've changed to a system of carefully reading code and understanding what it does (and often writing unit tests to confirm that each pieces is doing what I think it's doing). Every time I have to go into a debugger now, I curse the person who left me with no other choice (say, due…

I wholeheartedly agree. TDD as Test-Driven Debugging is the way to go. :)

Re: Why Django Sucks

#148

Post by raverbashing »

acdha wrote: post #82
raverbashing wrote: post #7

Personally I'd say: - Error handling: Django error page is great, unless of course it's a AJAX request. Pylons does this in a much smarter way - Django ORM is awful. Easy to use yes, but awful - Django Auth is a "good intention" but awful implementation - Django templates are sloooooow. Jinja 2 is an order of magnitude faster Amongst other warts Also, the author apparently found the hard way: don't use Django as an a…

You're quick to toss out unsupported assertions: e.g. calling the ORM awful just sounds naive and microbenchmark claims about the template system assume that it's a common bottleneck, which simply isn't true. Put another way: I inherited a site where someone noticed that a view was slow and switched everything to Jinja2 for magic pixie dust speed ups. This made almost no difference but did complicate maintenance and…

"You're quick to toss out unsupported assertions: e.g. calling the ORM awful just sounds naive"

I can assure my assertions are based by a lot of benchmarking of a Django project that heavily depended on the ORM. And it's not even about the quality of the queries, Postgres was eating them like hot cakes, but the ammount of queries itself was making it slow. Even for things like user_token.delete() (this was an open source project in Django that we were adapting)

Oh sure, I don't recommend the first step of optimization to be switching to Jinja2, Django templates are fine for 99% of cases. But in my case, Django templates were being used in a very specific way (which btw was done in the original project, that is, not by me) which was very slow (think 1s per page, and that's without querying the db!)

Re: Why Django Sucks

#149

Post by raverbashing »

adorton wrote: post #84
raverbashing wrote: post #7

Personally I'd say: - Error handling: Django error page is great, unless of course it's a AJAX request. Pylons does this in a much smarter way - Django ORM is awful. Easy to use yes, but awful - Django Auth is a "good intention" but awful implementation - Django templates are sloooooow. Jinja 2 is an order of magnitude faster Amongst other warts Also, the author apparently found the hard way: don't use Django as an a…

What is wrong with django's ORM? I'm not being flip; I'm honestly curious.

If your models are simple, it's good

If you rely on model inheritance, or your models have lots of relationships, Django uses the DB really inneficiently

Like, making lots of queries (mostly repeating itself), so a simple thing takes a lot of time.

It's a little bit difficult to explain (you can imagine it was more or less difficult to figure this out as well)

Re: Why Django Sucks

#150

Post by zeemonkee2 »

its_so_on wrote: post #143
zeemonkee2 wrote: post #135

Earlier quoted context omitted.

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.

Could you summarize your suggested best practices (Specifically what you suggest is a good way to avoid at least some of the problems you list in your last sentence.)

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 run by idiot managers.

Post reply on HN