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

171–180 of 206 posts

Re: Why Django Sucks

#171

Post by ezl »

sashahart wrote: post #166
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 ha…

agreed that it is more subtle than hammer vs spatula, but just trying to illustrate the point that this general flavor of X sucks compared to Y isn't instructive.

flask is great. but if you want the admin, then you have to build it yourself. i've used django formsets ONCE, ever, but when i needed them I'm glad that django had them instead of me having to build them on flask.

then i've used flask for awesome projects that i knew in advance i didn't need that stuff.

different needs, different tools.

Re: Why Django Sucks

#172

Post by sashahart »

jerf wrote: post #9

Problem: Django has features. These features, horrors , reuse each other's capabilities. Solution: Use something that has no features. I'm not sure myself how sarcastic I'm being, to be honest. There's some truth in there too (or I wouldn't have posted this). But of course your microframework doesn't have any dependency issues. Rip all those things out of Django and it wouldn't have any dependencies either. Put them…

To be fair to the author of the presentation: if there is a problem, it isn't features and reuse. It's tight coupling, boilerplate and overhead. (Although it is funnier to say that the problem is features and reuse, like it is more provocative to say that Django sucks).

I won't slam Django, Django is good. Its most salient traits are its mindshare, liberality with features, big plugin ecosystem. And these traits were not all present from the beginning, when it was the Django developers who were reinventing wheels and going without features. Django's top traits are historically contingent. So in an alternate history, we might be talking about CherryPy having basically the same problems, because of the inherent pain of taking on so many features so quickly, then maintaining backward compatibility, etc.

Good framework or library code takes significantly longer to develop than similar functionality inside an app. When you add goals like trying to reduce boilerplate and coupling, it gets much harder and slower. It is totally valid to question why not just charge ahead with something easier to develop and get done more quickly. There is a real issue to think about here, it's not so clear cut.

It isn't as simple as saying "Flask is only nice because it has no features, anything with features is necessarily ugly." Both features and clean design take time and if you want both, even more time. But design is hard while features earn mindshare and dollars... if they work reliably, then who is complaining?

Now, at this point, Flask actually has a significant mindshare and plugin ecosystem of its own, so it is really inaccurate to say it has no features. And actually Flask does have a number of dependencies as well, with much of its implementation tucked away in Werkzeug (which is hardly a simple library).

Re: Why Django Sucks

#173

Post by zeemonkee2 »

jshen wrote: post #168
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.

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.

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.

Re: Why Django Sucks

#175

Post by sashahart »

ezl wrote: post #171
sashahart wrote: post #166

Earlier quoted context omitted.

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 ha…

agreed that it is more subtle than hammer vs spatula, but just trying to illustrate the point that this general flavor of X sucks compared to Y isn't instructive. flask is great. but if you want the admin, then you have to build it yourself. i've used django formsets ONCE, ever, but when i needed them I'm glad that django had them instead of me having to build them on flask. then i've used flask for awesome projects…

I agree that Django vs. Flask is not a matter of what sucks or is broken.

If I think a hammer looks nice but someone informed explains that it is designed in such a way that the head will tend to fly off, I find that very instructive. The many broken spatulas on github are also instructive.

If you want a pre-built admin, Django provides for a different need, yeah... but if the needed stuff is in the large overlap between Django and Flask, you can't just say "different needs" because you are considering competition to satisfy the same needs. (For example, Flask is promoted for HTTP APIs, but Django also has some good packages for putting together HTTP APIs, so that it is hardly clear that Flask would always be the better choice for APIs).

Most of the argument (here as in emacs vs. vim) is in matters of taste or philosophy - or a dead heat between valid technical concerns. tastypie or Flask? I submit that it matters more what makes you happy and productive, so that it is entirely valid to choose Flask, or Django, or both. After all, it is your life you are spending on all this, you should be happy. If you hate emacs, there are alternatives.

Re: Why Django Sucks

#176

Post by zzzeek »

anthonyb wrote: post #122
zzzeek wrote: post #99

Earlier quoted context omitted.

Pyramid has an auth system not tied to any ORM or persistence system whatsoever: http://pyramid.readthedocs.org/en/latest/tutorials/wiki/auth... I'd say that's better than anything hardcoded to a fixed database schema. There's a whole world of development that has no interest in using a mediocre, off the shelf database schema in lieu of one that is designed exactly for the problem at hand.

Er, that looks pretty hideous to me. I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand. Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopp…

When I look at django apps they are often similarly hideous to me. (edit: such as - when hundreds of objects are pulled into memory, then filtered further, or processed one at a time, when the entire thing could be done in one query. They'll do this not only because the Django ORM isn't capable enough to do the work out on the query side, but also because the programmer isn't SQL-aware enough to know that's even how it should be done. Django's lack of capability is matched by the developers lack of awareness, and the conclusion for such a developer is "django works great!" This is why SQLAlchemy users get annoyed by Django and Django users get annoyed by SQLAlchemy. There are two totally different ways of looking at problems going on).

This whole thing is about where you're coming from and what software development traditions you subscribe to. We know full well django isn't going anywhere and you can rebut all you want, the alternatives aren't going away either.

Re: Why Django Sucks

#177

Post by zzzeek »

run4yourlives wrote: post #108
zzzeek wrote: post #96

Earlier quoted context omitted.

> not if you're using sqlite, since alembic doesn't seem to try too hard supporting it. Because its brand new, written by pretty much one person (I'll give you a hint, it's me), and also sqlite barely supports migrations itself ( http://sqlite.org/faq.html#q11 ). You're trolling pretty hard in this thread, maybe you should let other toolsets besides django have a chance.

Sorry, wait a second. You're comparing a feature built in to the core of django to something brand new that has a support team of one person and accusing the other guy of trolling? I'm sure your code is fine, but you can't possibly argue that it is on par with a major component of a major framework and be taken seriously.

alembic and sqlalchemy are not only on par with django's tools, they are generally superior. This isn't just my opinion, here's Alex Gaynor, Django core committer, saying the same thing:

https://speakerdeck.com/u/alex/p/why-i-hate-the-django-orm

Yet the developmental resources SQLAlchemy and Alembic are a tiny fraction of what Django has. It's the tremendous gravitational pull of Django and the habits of its community writing things hardcoded to Django that suck the life out of other projects in the Python community.

Re: Why Django Sucks

#178

Post by legutierr »

zeemonkee2 wrote: post #93
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…

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…

You can also subclass auth.User, which allows you to maintain compatibility with 3rd party apps.

This is how I've gotten around the user name length limitation. I have a longer field in the subclass, and implement a backend to check that. But because it's a subclass, foreign-key relations still work.

Re: Why Django Sucks

#179

Post by legutierr »

zeemonkee2 wrote: post #93
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…

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…

You can also subclass auth.User, which allows you to maintain compatibility with 3rd party apps.

This is how I've gotten around the user name length limitation. I have a longer field in the subclass, and implement a backend to check that. But because it's a subclass, foreign-key relations still work.

Re: Why Django Sucks

#180

Post by zzzeek »

hysan wrote: post #155
anthonyb wrote: post #122

Earlier quoted context omitted.

Er, that looks pretty hideous to me. I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand. Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopp…

Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this…

Chris' perception of design errors aside, there is no reason a feasible auth system not tied to a specific persistence system can't be built. My usual way of proving this is by building one but I'm really at my max number of OSS projects to be maintaining.
Post reply on HN