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

101–110 of 206 posts

Re: Why Django Sucks

#101

Post by zeemonkee2 »

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…

> Django templates are sloooooow. Jinja 2 is an order of magnitude faster

Template execution speed is unlikely to be the bottleneck for the vast majority of sites. I prefer Jinja2 for the flexibility (macros etc) rather than the performance.

Re: Why Django Sucks

#102

Post by igorgue »

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

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

Joel didn't write that article.

Re: Why Django Sucks

#103

Post by jshen »

zeemonkee2 wrote: post #95
anthonyb wrote: post #72

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.

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.

Re: Why Django Sucks

#104

Post by cheatercheater »

espeed wrote: post #65

Monolithic frameworks complect things -- see Rich Hickey's talk "Simple Made Easy" ( http://www.infoq.com/presentations/Simple-Made-Easy ). Monoliths also lock you into a certain paradigm. Django locks you into a RDBMS if you want to hook into all of Django's components like auth, admin, etc. And being locked into a paradigm limits the types of problems you can solve and makes it difficult to shift when a new paradig…

So yeah, let's use VertexDB for auth.

...are you out of your mind?

Re: Why Django Sucks

#105

Post by run4yourlives »

drivebyacct2 wrote: post #16
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…

I think his point is that this: "You have to go get a third party auth system" is a good thing. That way if the auth implementation needs to change, it can more easily if it's loosely coupled to the application.

So basically, you're going to do more work now because it might pay off in the future under certain circumstances?

Talk about solving problems you don't have yet. There may be a very good reason for using a third party anything, but to suggest that this is always the "right thing to do" is ludicrous.

Re: Why Django Sucks

#106

Post by cheatercheater »

anthonyb wrote: post #17
btipling wrote: post #12

The benefits of using Django include not having to rebuild a lot of boiler plate features again and again. Things like the admin panel for example. When I used web.py I always had to build some kind of way to manage users easily. Login pages, logout pages, error pages. I do not know much about Flask and it looks like it has some bare bones middleware and context processor tools, but it doesn't look like it does much…

Heh. Who needs python manage.py syncdb when you can write a function: from contextlib import closing def init_db(): with closing(connect_db()) as db: with app.open_resource('schema.sql') as f: db.cursor().executescript(f.read()) db.commit()

Who needs a one-line schema migration command that can be rolled back when you can just copypaste boilerplate which doesn't do anything nearly as useful or sophisticated and requires you to go and actually write out the table definitions? You're right, dude. Great idea.

Re: Why Django Sucks

#107

Post by nupark2 »

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

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.

Mine do differ. Anecdotal evidence, after all.

Re: Why Django Sucks

#108

Post by run4yourlives »

zzzeek wrote: post #96
anthonyb wrote: post #25

Earlier quoted context omitted.

It's from Flask's recipe section: http://flask.pocoo.org/docs/patterns/sqlite3/#initial-schema... edit: not if you're using sqlite, since alembic doesn't seem to try too hard supporting it.

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

Re: Why Django Sucks

#109

Post by espeed »

cheatercheater wrote: post #104
espeed wrote: post #65

Monolithic frameworks complect things -- see Rich Hickey's talk "Simple Made Easy" ( http://www.infoq.com/presentations/Simple-Made-Easy ). Monoliths also lock you into a certain paradigm. Django locks you into a RDBMS if you want to hook into all of Django's components like auth, admin, etc. And being locked into a paradigm limits the types of problems you can solve and makes it difficult to shift when a new paradig…

So yeah, let's use VertexDB for auth. ...are you out of your mind?

Evidently you may be trapped inside yours -- I made no mention of VertexDB nor did I suggest any particular database.

However, for example, Datomic (http://www.infoq.com/presentations/The-Design-of-Datomic) is interesting, which is distributed and uses Amazon's DynamoDB storage service.

Re: Why Django Sucks

#110

Post by tluyben2 »

famousactress wrote: post #29
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…

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 into stuff 'most companies' need. And that's 'your company' as well; you can think you are different, but that's not really true. If you try to be different, you mostly do a lot of work which you shouldn't have. Yes, there is Google. Yes there is Facebook. But you are not those. And you won't become those. Also most companies are not IT companies; non-IT companies benefit even more from frameworks and rigidity; in most cases it's better to remake or form your business process to the framework/software than the other way around. Other people did that heavy lifting already; why should you try to do that again?

I'm not sure where you work, but this is my experience from using 'wysiwyg' clipper & dbase software in the 80s to Delphi frameworks in the 90s to web frameworks. People think they are very different from the start and then (usually after a management change) they notice the same stuff happens everywhere.

Post reply on HN