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

51–60 of 206 posts

Re: Why Django Sucks

#51

Post by tonyarkles »

majormajor wrote: post #34

I think the "Constraints are Good" slide is massively oversimplified. Especially the "editors vs IDEs" and "primes vs zooms" bullets. Just for one example: stepping through an IDE's debugger, integrated into the code editor, to track down a problem is incredibly handy. It's a habit I picked up while living in Eclipse doing Java work, and why most of my Rails work is now in RubyMine instead of Emacs like it was when I…

This is diverging a bit, but weaning yourself off of the debugger habit can be incredibly liberating. I used to be a debugger junkie, but I've changed to a system of carefully reading code and understanding what it does (and often writing unit tests to confirm that each pieces is doing what I think it's doing). Every time I have to go into a debugger now, I curse the person who left me with no other choice (say, due to design choices or laziness). Sometimes... the person I curse is me :)

Re: Why Django Sucks

#52

Post by jerf »

mattdeboard wrote: post #28
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…

You sound institutionalized. Django is indeed awesome for having a ton of features immediately. Of course, once you need to start changing those features you realize you have to dislocate your shoulder to do so. Django is badass for what it is intended to do: be a kitchen sink. Flask is badass for what it is intended to do: be a platform for composable applications. If you ever need to reason about the internals of y…

"You sound institutionalized."

I'm not sure what that even means, but I suspect the thing that disproves it is "The last website I built was in Yesod.". And while it may be in some sense targeted to fill the Django space, at the present time (and certainly at the time I worked in it) it was more like Flask and a couple of things lightly tacked on.

No, my main point is that Django is what Django is, and while that may not be perfect, it isn't useless, it doesn't "suck", it just doesn't meet all needs any more than anything else does. Flask doesn't meet all needs either. Don't complain that water is tasteless when what you wanted was mustard. Being tasteless doesn't make the water suck, it just makes it water. Complaining about its watery nature is just silly.

If Django actually sucked I'd probably not have said anything, but it's more successful at actually bringing together all those things than most of its competition. (Though since there are roughly 1000 web frameworks out there I'm sure there's better things somewhere.)

Re: Why Django Sucks

#53

Post by scottschulthess »

Having what is essentially one app split into multiple apps is going to introduce a whole lot of complexity to the business that isn't necessarily unless the amount of developers on your team is very large.

Re: Why Django Sucks

#54

Post by tmoertel »

kenneth_reitz wrote: post #24
bangbang wrote: post #18

What fonts were used in this? I like.

Thanks! Titles are High Tower Text (Flask Logo Font): http://www.fontyukle.net/en/High+Tower+Text.ttf Text is Gaudy Bookletter 1911 (Open Source!): http://www.theleagueofmoveabletype.com/goudy-bookletter-1911 And code examples are Monofur: http://www.dafont.com/monofur.font

The typography in your presentation is great, but there's one thing you could do to make it better: don't use a left single quotation mark (U+2018) when what's needed is an apostrophe. For that need, the preferred character is a right single quotation mark (U+2019). "Keep ‘em Separated", for example, ought to be "Keep ’em Separated". (Zoom in a billion times to see the difference.)

Re: Why Django Sucks

#55

Post by anthonyb »

Orf_ wrote: post #39
anthonyb wrote: post #19

Earlier quoted context omitted.

Django's auth system is not that hard to hack on if you need to - in most cases you just need to write a custom backend and implement a few methods on it. It's certainly comparable to writing your own, or downloading something and integrating it.

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 ORM for day to day stuff?

Re: Why Django Sucks

#56

Post by scottschulthess »

majormajor wrote: post #34

I think the "Constraints are Good" slide is massively oversimplified. Especially the "editors vs IDEs" and "primes vs zooms" bullets. Just for one example: stepping through an IDE's debugger, integrated into the code editor, to track down a problem is incredibly handy. It's a habit I picked up while living in Eclipse doing Java work, and why most of my Rails work is now in RubyMine instead of Emacs like it was when I…

ruby-debug takes a little bit more work to learn in the beginning but in the end is more satisfying and flexible than any of the GUI debuggers I've used (eclipse, visual studio).

Command line interfaces are cool especially for stuff you do all the time

Re: Why Django Sucks

#57

Post by scottschulthess »

majormajor wrote: post #34

I think the "Constraints are Good" slide is massively oversimplified. Especially the "editors vs IDEs" and "primes vs zooms" bullets. Just for one example: stepping through an IDE's debugger, integrated into the code editor, to track down a problem is incredibly handy. It's a habit I picked up while living in Eclipse doing Java work, and why most of my Rails work is now in RubyMine instead of Emacs like it was when I…

Agreed on the "changing service oriented architecture" parts. Once you split once big app into two medium sized apps, it can be hard to make radical changes to the application architecture. It adds a lot of complexity, like (deployment, caching, testing, configuring)

Re: Why Django Sucks

#58

Post by MatthewPhillips »

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

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 instructions on how to extend it.
Post reply on HN