Live data from Hacker News

Why Django Sucks

speakerdeck.com

91–100 of 206 posts

Re: Why Django Sucks

#91
All frameworks are horrible. Because there is no 1 ring to rule them all. The more "powerful" frameworks become, the more abstract and detached from reality they become, the more you end up solving problems that exist only because you are using said frameworks.

Clearly, there are building blocks that are useful across most applications. You can gather those into libraries and reuse them over time. But, frameworks...no, there are no silver bullets, no fat-free fat, no sugar-free sugar, etc.

Re: Why Django Sucks

#92
There's no "better / worse" framework. Django and Flask are two tools that try to accomplish the same thing in different ways.

Django:Ubuntu::Flask:ArchLinux

Django gets you 90% of the way from the start, it's in the tagline: for perfectionists with deadlines. However it's difficult to change certain parts of Django.

Flask gives more control but comes at a cost. Each framework has their uses.

Re: Why Django Sucks

#93

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 is roll my own (and re-use bits of contrib.auth where appropriate, such as password hashing) using a custom auth backend and keep a separate site for the Django admin which uses contrib.auth models. As long as I don't have to use 3rd party apps that rely on auth.User I'm fine.

Re: Why Django Sucks

#95
post #62

Earlier quoted context omitted.

I've been writing web apps for a long time and for many different companies of different sizes. I've never, ever, seen a homegrown setup that was in better shape than the average rails app after a few years. Maybe your experience is different.

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.

Re: Why Django Sucks

#96
post #20

Earlier quoted context omitted.

wtf is that ? edit: using the current toolchain it's: alembic upgrade head

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.

Re: Why Django Sucks

#97
post #37
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,…

> he has a problem with the concept of frameworks I'd say it's more of a problem with frameworks as they exist today. I'd like to see a movement to REST API service frameworks with some level of cooperation to get compatibility for standard client libraries. Everything then gets built around services: from static site generation to single-page apps, third-party developer APIs to admin interfaces. Then you'd have flex…

Check out LinkJS. That's the project goal.

https://github.com/pfraze/linkjs

Re: Why Django Sucks

#98
What you're asking for is awesome, but.... it's really hard to do well. The extra abstraction is hard to get right. Instead a bunch of decoupled components playing well together, you can wind up with a bunch of chaotic components having their dependencies changed out from under them, and seriously raising the barrier to entry for newbie developers who need to figure out how to put humpty dumpty back together again to actually build an app.

Rails 2->3 tried to the general route you're talking about (but still with language API connections, not REST. That would be even harder in some ways) --- with, well, mixed success. And Rails starts out lower level (much less UI built-ins) than django, another thing that would make it even harder.

I've had many failures in personal homegrown projects. :)

Abstraction is hard. To do super high level of architecture abstraction _well_ takes experience and skill, as well as more developer resources. It's easy to go off into architecture astronaut adventures, and you end up spending all your development time trying to keep the parts working together, significantly sapping resources to actually, you know, provide new functionality.

That said, there is certainly such a thing also as too little abstraction and too much tight-coupling too, obviously. There is a happy medium.

Re: Why Django Sucks

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

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.

Re: Why Django Sucks

#100
post #81
post #37

Earlier quoted context omitted.

> he has a problem with the concept of frameworks I'd say it's more of a problem with frameworks as they exist today. I'd like to see a movement to REST API service frameworks with some level of cooperation to get compatibility for standard client libraries. Everything then gets built around services: from static site generation to single-page apps, third-party developer APIs to admin interfaces. Then you'd have flex…

Jeff Bezos recognized this 10 years ago: https://plus.google.com/112678702228711889851/posts/eVeouesv... His Big Mandate went something along these lines: 1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads…

I remember when people thought Bezos was mad for doing this.

Now it has meant that Amazon can transition internal infrastructure into external AWS infrastructure and charge for it.

It really is genius and wouldn't surprise me if this becomes the future of how enterprise companies develop software.

Post reply on HN