Live data from Hacker News

Why Django Sucks

speakerdeck.com

151–160 of 206 posts

Re: Why Django Sucks

#151
post #21

Earlier quoted context omitted.

Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 . In a way, frameworks are inherently stupid, but who's to decide where between assembly language and x layer abstraction people should work in? I think people who criticize Django have yet to make up their minds about what a framework is all about, and what, if anything,…

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.

Re: Why Django Sucks

#152
post #133

Earlier quoted context omitted.

Django is a single python package but is really fairly modular. You can readily use anything in lieu of it's ORM (e.g SQLAlchemy), anything for template rendering (e.g jinja), you're absolutely not forced to use the provided auth component (it's not even enabled by default) nor the admin (but the admin of course only works with django models). Don't take my word for it, all of this is actually written in multiple pla…

"but the admin of course only work with django models" I think you missed the point. In Rails, ActiveSupport does a whole lot of automatic magic with ActiveRecord. But it is not limited to ActiveRecord, as most of that functionality is factored out into ActiveModel - implement those interfaces and your link helpers and whatnot will happily support nonAR models. I use this quite often to represent things that doesn't…

The point I was making was with regard to the article, which goes down on Django because it would supposedly not be barebones enough. I was expliciting that although one does an apparently monolithic (easy_install|pip install) django, one can readily use only the project+url+view part and have something as barebones as Flask in which you could use other components. Additionally you could readily use only Django templates or the Django ORM, and use e.g Flask for the view part (or no view part at all if you're not doing web stuff)

As for the comparison with Rails, faking models is the same in Django, as both leverage duck-typing features of their underlying language. In Django, a model is just a class, and many things are just queried via introspection. Many parts just query model_instance.pk. Additionally populating Model.meta and you even get yourself some deeper model introspection features. To me the true important part of ActiveRecord, ActiveModel and ActiveSupport is rather that you have a set of modules that you can readily include/extend into your fake models to inject complete model behavior, and that is something Django lacks.

You name the example of link helpers, and interestingly this is an example of the difference of philosophy between Rails and Django (see [0]). Django parts are coupled more loosely than Rails parts, a possible rationale being that creating coupling between two distant parts such as URLs and models could enforce constraints on each, thus reducing their potential to independently shine and coercing possible alternatives of each to the provided model. Another example: with Django you explicitly create a request object (whether directly constructed or encapsulated into a helper method) to be returned by the view function while Rails does magic for you in the controller.

Interestingly you bring the problem of forms and this is again an area where Rails and Django differ. Rails wants both form and data to be handled by a single model, whereas Django separates form models and data models. The rationale here is that they are two different problems and that they ought to be solved by two different components (yet they share a great deal of similarity, and code).

FWIW I worked extensively with both (although my current job is in a Ruby shop, I worked with Django at my previous job and since I'm more of a Python guy I keep myself up to date on that front too), and am in no way saying that one is better than the other. Choose what works for you.

[0] http://stackoverflow.com/questions/61451/does-django-have-ht...

Re: Why Django Sucks

#154

Earlier quoted context omitted.

Amen. I've seen quite a few projects that start out by rerolling the ORM, routing and templating, then grind to a halt under the weight of all the bugs before getting any significant features out the door.

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

I wouldn't, and I'm sure you wouldn't... but there are people who do.

Case in point: OpenERP. Serious business software doing serious business things, so of course they can't use any of those other toy ORMs, they have to spend 5000 lines of code writing their own: http://bazaar.launchpad.net/~openerp/openobject-server/trunk...

Hey, it might not be so great, but at least they have tests for all of that code: http://bazaar.launchpad.net/~openerp/openobject-server/trunk...

Er...

I know of other projects in a similar state, but they're smaller teams or solo coders, so I don't know that they're quite as fair game for finger pointing...

Re: Why Django Sucks

#155
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…

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 case, we didn't."

So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.

Re: Why Django Sucks

#156

Earlier quoted context omitted.

It's difficult to refute this line of thinking, except in practice. In practice, I think large frameworks are eventually pretty terrible. It's too easy to compromise your business needs in small ways because the framework offers you something close-enough. Whether those compromises come in the form of over-coupling (which they always do with these frameworks), or in other ways like compromised URL design, query perfo…

I have been creating software for 20+ years and I have personally never seen a case where 'in the end' it wouldn't have been better to use a framework. And mostly actually a framework which is as opinionated and feature rich as possible. These frameworks don't grow randomly; they are based on actual needs. When they are young they answer mostly to acute needs of the developer, when they grow they automatically grow i…

Are you talking about frameworks or software products? There is a very good argument around building custom software versus buying a product that matches your argument. In that case, I strongly agree. You should find products that either match your business process or change your process to match the products.

With regards to frameworks. I find it hard to believe that none of them would work out in the long run. I wonder if you are under-estimating the cost involved from the developers to replace or create these frameworks from scratch. This also seems like a selection problem more than an inability of frameworks to meet any development need. I mean they do exist for a reason.

That said, most software products are pretty horrible. Many frameworks are equally bad. Does this mean you should custom build everything? Of course not, you company is not going to be able to afford the time it takes you to write your own ORM, your own web framework, your own logging library, etc... It is your job to make compromises that will allow your company to achieve its goals.

Re: Why Django Sucks

#157
post #82

Earlier quoted context omitted.

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 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 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.

I will also note in both cases these started out as general assertions which were then qualified to refer to specific edge cases. Again, without describing the exact code being benchmarked it's a disservice to through out performance advice to people who might take it as a general rule rather than understanding that it's unlikely to be a significant problem for most users.

Re: Why Django Sucks

#158
post #82

Earlier quoted context omitted.

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

[deleted]

Re: Why Django Sucks

#159
post #76

Earlier quoted context omitted.

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

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

Re: Why Django Sucks

#160

Earlier quoted context omitted.

Amen. I've seen quite a few projects that start out by rerolling the ORM, routing and templating, then grind to a halt under the weight of all the bugs before getting any significant features out the door.

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 weren't actually able to spend enough time on this as they'd hoped and keep falling further and further behind Django and other frameworks.

Post reply on HN