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

161–170 of 206 posts

Re: Why Django Sucks

#161

Post by ezl »

sigh

I understand that "why django sucks" is a better, more provocative title that will get read more than "why django isn't perfect in every way and i prefer using flask for this", so i don't fault the author for choosing that subtext.

However, the general "tradition" (yes, its a tradition now) of justifying a tech/infrastructure decision with "Ah! language/framework/db made popular by others is a horribly broken mistake! you are doing it wrong!" is 1. getting old, 2. counterproductive for engineers.

They are tools. There are different tasks with different requirements. They have different pros and cons and different learning curves. Some tools are better suited for some tasks. Some tools are even better suited for most tasks. Sometimes it even makes reasonable sense to use a product that isn't the best of the best of the best if you are really certain you don't care about the dimension in which your tool is not the most amazing.

Hammers are bad for cooking eggs. Spatulas are bad for nailing nails. I made eggs this morning. Keep an eye out for my upcoming blog post: "Why hammers suck!!"

Re: Why Django Sucks

#162

Post by sashahart »

anthonyb wrote: post #125
UK-AL wrote: post #88

Earlier quoted context omitted.

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

Also this is Python, so you can poke the internals however you like :)

You can, but that doesn't mean you should. It's brittle. If your app or library breaks because a minor update to a dependency changed those internals completely, you can't say you weren't warned.

Re: Why Django Sucks

#163

Post by Confusion »

kmfrk wrote: post #151
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,…

I have no problem with criticism of Django, but to write a presentation called "Why Django Sucks" is bombastic, misguided link bait - replete with rage comics and whatnot. It's just not constructive for the discussion, interesting as it may be.

'replete' with a few Reddit-style comics, of which exactly one could be argued is a Rage comic (though it actually isn't).

Re: Why Django Sucks

#164

Post by zeemonkee2 »

kmfrk wrote: post #151
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,…

I have no problem with criticism of Django, but to write a presentation called "Why Django Sucks" is bombastic, misguided link bait - replete with rage comics and whatnot. It's just not constructive for the discussion, interesting as it may be.

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

Re: Why Django Sucks

#165

Post by zeemonkee2 »

acdha wrote: post #160
zeemonkee2 wrote: post #95

Earlier quoted context omitted.

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

Which has an interesting balance: you're then using things developed in isolation, which can give you better parts but it definitely means you have to provide interconnect conventions and that new developers have to get used to your particular combination of parts. If you think you can do this better than the Django community, this can work out well but I'd say more often than not when I've heard about it people were…

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.

Re: Why Django Sucks

#166

Post by sashahart »

ezl wrote: post #161

sigh I understand that "why django sucks" is a better, more provocative title that will get read more than "why django isn't perfect in every way and i prefer using flask for this", so i don't fault the author for choosing that subtext. However, the general "tradition" (yes, its a tradition now) of justifying a tech/infrastructure decision with "Ah! language/framework/db made popular by others is a horribly broken mi…

I completely agree with you about needlessly provocative titles.

On the other hand, in the world of frameworks, it's not entirely common for the use cases to be (as) disjoint as they are for hammers vs. spatulas. More often, frameworks overlap in functionality and differ on matters of style and ideology. And this is what feeds the flame wars.

For starters, you have a choice between MyKitchen and spatula. MyKitchen has everything you need to make a reasonable pasta meal for up to 8 guests. The pasta practically serves itself... even when you are making steaks. spatula is totally dedicated to scraping things out of pots, and obviously you could just use MyKitchen.SpatulaFactory(_ctx) instead (you did read the equipment manifest, didn't you?) Plus MyKitchen has a plugin which will make pork buns that practically serve themselves... why waste time with low-level stuff like spatulas?

Some guy graduated from spaghetti to pizzas and he can only scoff at spatula, which is not necessary at all, since you can cook pizzas directly on the rack.

Another guy made this incredible pocket-sized leatherman which includes compact versions of all the kitchen tools including a camp stove.

It is true that most frameworks are better suited to some tasks than others, but for a given task one might be just plain technically inferior, or only different in some stylistic way.

Not that style doesn't matter, if it makes you feel happier doing your job. Otherwise, why bother with Ruby or Python when there is already Java EE or COBOL?

Re: Why Django Sucks

#167

Post by tbatterii »

the "benefits" of flask vs. django can easily be attributed to any of the so-called web micro frameworks vs web full stack frameworks.

it's interesting to me that django seems to be getting grief for some of the same things zope was/is. Time to reinvent the wheel again I guess.

http://www.jrandolph.com/blog/2006/02/02/zope-vs-django-here...

So surprise surprise, you stray from the happy path the full stack framework lays out for you, be ready for the pain.

Re: Why Django Sucks

#168

Post by jshen »

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.

I'm not sure you addressed the issue at hand. Others are arguing that using a framework will make your codebase worse in the long wrong. I'm asserting that all of the homegrown codebases I've worked with are worse than the ones using a framework, after a few years.

Re: Why Django Sucks

#169

Post by Fledeskum »

zeemonkee2 wrote: post #150
its_so_on wrote: post #143

Earlier quoted context omitted.

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.

One of the factors I considered when I switched jobs earlier this year was that the new place has a policy of devoting 2 months a year to refactoring :)

Re: Why Django Sucks

#170

Post by raverbashing »

acdha wrote: post #157
raverbashing wrote: post #148

Earlier quoted context omitted.

"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 so…

I would argue that the main problem is so many queries: rather than arguing about ORM dispatch speed it's almost always better to make fewer queries and/or retrieve less data as you can cut out a ton of unavoidable overhead intrinsic to shipping a query to another process (possibly on another system), executing it and handling the results. ORM improvements can only address either end of that process. Similarly, 1s to…

>> "I would argue that the main problem is so many queries: rather than arguing about ORM dispatch speed it's almost always better to make fewer queries"

In Python there aren't many queries! That's the issue!

Let me explain better. Django ORM is converting a few lines (and sometimes ONE - like user_token.delete() ) of python to tens of queries. These tens of queries take around 200ms (or more) because each query takes around 3ms/10ms

user_token.delete() was taking 300ms (I wish I was kidding)

"Similarly, 1s to render a template sounds rather unusual - if that's not just something like not using the cached loader on a slow filesystem it's screaming for logic to move into the view or a template tag."

No, not cached loader, not slow filesystem. It's a for with an inner include.

Post reply on HN