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

181–190 of 206 posts

Re: Why Django Sucks

#181

Post by mikepk »

First I want to say that, in many (most) cases, when people ask me what python web framework they should use, I wholeheartedly recommend Django.

Unless... the person is a weirdo, like me.

In most cases people are looking to prove some idea and they just want the web framework equivalent of "a car that gets me from point A to point B I don't care how.", Django gets the job done and in that capacity is really nice to use.

Personally I don't like using Django. I like to fiddle. I like to tweak. (I like my string beans quarantined!) I like my systems to work exactly the way I want them to work. I have strong opinions about how things should work and am not usually willing to compromise on fundamental issues.

Django does not (in general) make this easy. I wrote a post a while back about the hoops I had to jump through (and the source I had to spelunk through) just to use form field sets and to modify the error reporting (http://mikepk.com/2010/08/python_django_forms_errors_fieldse...).

The real tipping-point for me in not using Django was the ORM. I think it's great for getting up and running quickly but I tend to be of the "ORM-as-Vietnam-of-software-engineering" camp. It's partially due to my OCD/control-freak need to have maximum control and visibility of the RDBMS. I've been converted to using an ORM by SQLAlchemy, but mainly because the philosophy of that project is not to hide the RDBMS from you but to make it easier and more pythonic to work with.

While Django is theoretically decomposable, you lose the ability to use many of the plugins, apps, etc... the moment you deviate from the standard package / install. That's what the arrows in the slides indicate. If you're willing to get something that nearly approximates the functionality you need, and don't care that's it's not exactly what you want, then Django all the way.

Teh Awesome: * Get up and running very quickly * Lots of batteries included * Great Docs * Limited config hell

The Bad: * Tight coupling of features and third party "apps" * Yes you /could/ customize things but then you lose many of the benefits of why you're using Django in the first place * Customization breaks things * Too-strict templating, almost-python-like-but-not-quite * ORM is of the "vietnam" variety

Re: Why Django Sucks

#182

Post by espeed »

cheatercheater wrote: post #138
espeed wrote: post #128

Earlier quoted context omitted.

It looks like you're new here. Make sure you understand the context before you go trolling else you might be mistaken for a chatterbot with all the non sequiturs.

I'm not new to Django or programming in general, though. Making generic statements like your original post and catering to hip trends is one thing, backing up your bs is another. Obviously you can't answer the direct and very simple questions I stated, so you resort to pointing out your paltry 3.79 karma average in an attempt to sage me. Nice.

My comment was about simplicity and paradigms, with allusions to Thomas Khun's The Structure of Scientific Revolutions (http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Rev...). You must have missed that because you're trying to pick a fight about scalability, which has nothing to do with my original comment.

Most of my work is with graphs so, for example, if you want to use a graph database to build a social graph with a Bayesian network, you wouldn't use most of Django's components such as auth and admin because they're tied to the ORM -- most of Django would just get in your way. It has nothing to with a Django-based site "outgrowing" auth.

Try to break out of your relational mindset and understand the thread before you decide to go off. And regarding my "paltry 3.79 karma average," you do realize the median for the leaderboard (http://news.ycombinator.com/leaders) is 3.975, right? Again, know what you're talking about.

Re: Why Django Sucks

#183

Post by zeemonkee2 »

legutierr wrote: post #178
zeemonkee2 wrote: post #93

Earlier quoted context omitted.

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.

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.

Re: Why Django Sucks

#184

Post by ubernostrum »

anthonyb wrote: post #55
Orf_ wrote: post #39

Earlier quoted context omitted.

I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.

But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM? I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's…

I guess I'm not sure I understand what you're getting at here.

Django's auth system requires a backend to implement an API consisting of exactly two methods. One method is passed a set of credentials and returns something "User-ish" (i.e., possessing the attributes of a Django User object), the other is passed an ID and returns a "User-ish" object corresponding to that ID.

Neither of those methods requires the use of Django's ORM, or the use of a database, or really the use of any way to store data at all.

This means that how the backend stores data, and whether it stores data, is irrelevant; if you want to use a DB and SQLAlchemy to interact with it, you can and the auth system neither knows nor cares. You could, assuming a migration plan in place, switch away from the DB and away from SQLAlchemy and store user data in flat files if for some reason you really wanted to, and the auth system would not care and would not notice anything had changed.

I fail to see how anything would be gained by somehow forcing a store-agnostic data API into this picture as part of the auth system, when the auth system currently doesn't even care whether you're storing things.

Re: Why Django Sucks

#185

Post by [deleted] »

anthonyb wrote: post #55
Orf_ wrote: post #39

Earlier quoted context omitted.

I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.

But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM? I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's…

[deleted]

Re: Why Django Sucks

#186

Post by jonknee »

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.

Have you used Django much? Some classes you run into frequently (besides Model):

* Form * HttpResponse * All middleware * Template * Etc, it's all classes except if you write function based views

Re: Why Django Sucks

#187

Post by mattdeboard »

acdha wrote: post #159
mattdeboard wrote: post #146

Earlier quoted context omitted.

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

I'm about +10 on that approach: customize the admin until you hit a difficult point, then stop trying to hammer screws.

But the only tool I HAVE is a hammer!

Re: Why Django Sucks

#188

Post by zby »

Apreche wrote: post #10

I use Django and Flask quite a bit. They are the first two things I go to for building a site. For a small site, usually without a database, I mostly use Flask. For a large site with all the common features like auth and such, I use Django. Yeah, it has its bad points, but that's ok. It's worth suffering through whatever those bad points are because it has one gigantic good point. You don't have to reinvent the wheel…

Why web frameworks tend to grow to become such unwieldy beasts?

Most of the web frameworks I know tend to do at least two things - the web stuff plus creation and initialization of all other components. This means that the framework is coupled with all of these components and this is the root of all evil in web frameworks. Of course you need a place to do that object creation and wiring work - but it is not really related to web stuff - it should have it's own place in the program, ideally in a Dependency Injection compartment, not necessarily a container based on the available libraries - but it can also be coded by hand (I might change my minde some day but for now I don't see any reasons to use DI container libraries in a dynamic language like Perl). All the arguments about using Dependency Injection apply also here, but even for someone rejecting DI it should be pretty obvious that reading config files and initializing objects is not much related to web stuff and if you buy the single responsibility principle you should split them into separate libraries.

I don't know Django or Rails too deeply - but I've observed this with Catalyst. Now, Catalyst is supposed to be decoupled from the Views or Models and other Plugins, there are many different ones in each category and you can replace them freely in your programs. But Catalyst code-base is still pretty big and then you have all these Catalyst::Models, Catalyst::Views and Catalyst::Plugins that don't really do any meaningful work - they only map one interface into another one. It could be much simpler if Catalyst only cared about the web related processing.

(copied from my blog)

Re: Why Django Sucks

#189

Post by jshen »

zeemonkee2 wrote: post #173
jshen wrote: post #168

Earlier quoted context omitted.

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

The original discussion was about a potential difference in the long term quality of a code base if they choose a framework over a homegrown solution. You aren't saying anything about that potential difference. Correct?

Re: Why Django Sucks

#190

Post by anthonyb »

zzzeek wrote: post #176
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…

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…

Well, when I see code like that, I see lots of moving parts, all with their own weird API, interacting in odd ways. You just have to know that thing X takes a string, an object and a callback function, and there are twenty thing Xs, not five.

Complexity breeds bugs like rabbits; if you can't look at something and understand what's going on (potentially drilling down into an abstraction or two), then it's going to be a maintenance nightmare.

If you can come up with something that's easy to use and powerful, like the declarative_base stuff in SQLAlchemy over the top of the Mapper/Relationship, then I'm all ears - but if complexity is the price that I have to pay for that then it's not an easy tradeoff to make, and in a lot of cases you're better off with the easier, worser solution.

A quick question: do you have any idea of how much work it would take to port SQLAlchemy to Django properly? ie. so that all of the fancy Django manage commands work. I'm assuming a fair bit, but it might be a good way to get some sort of help as far as SQLAlchemy goes. Or you might be happy to continue forging ahead solo, I don't know. Just a thought ;)

Post reply on HN