13 ms·

Why Django Sucks

271 points by kenneth_reitz 14y ago

drivebyacct2 14y ago
If you like this approach, and I certainly do (especially after finishing a very service oriented django project), I fully encourage you to check out Go standard libs combined with Gorilla. Plus you get other fun advantages of Go if you want/need them.
zeeg 14y ago
I think the title is misleading, but the slides/concepts are pretty spot on.
sparknlaunch 14y ago
> "Speaker Bio Python Overlord for Heroku. Creator of Python-Requests. Photographer. Curator of The GitHub Reflog™. Knows where his towel is." Thanks for sharing. The site has a few other interesting presentations by the same speaker.
antihero 14y ago
I love Django for making websites, but I'd go with Flask for an API. The only issue I found with Flask is I often found myself recreating stuff that Django already does, and is already done way better.
yesimahuman 14y ago
Thanks for posting this. I use Django extensively and I never really felt any pain from the tightly coupled monolithic approach, but I always like improving my tools. I will check out Flask. Any suggestions for making it easy to build REST style APIs? Is piston the #1 choice still?
- mumphster 14y ago
  Check out Tastypie. You can get a full restful API based around your models up in like 5 lines of code and it's really easy to add extra functionality. Sorry for the lack of a link I'm posting this from a phone
- papercruncher 14y ago
  Yes, still the #1 choice in my books, especially if your APIs do not match your models 1:1. Tastypie is cute but gets in your way a little too often for my liking. Django-rest is another contender but I haven't tried that yet
- philfreo 14y ago
  http://pydanny.com/choosing-an-api-framework-for-django.html http://pydanny.com/choosing-an-api-framework-for-django.html
- bdr 14y ago
  I prefer tastypie. It takes a fair bit of time investment to learn how it does things, but once you do it's powerful.
- jtchang 14y ago
  I've used all 3 and I settled on "django rest framework". http://django-rest-framework.org/ http://django-rest-framework.org/ The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call. I also had to map each and every call (GET/PUT/POST/DELETE) and there was no default out of box behavior. I felt like I was violating the DRY principle over and over. Tastypie was great when I started but I wanted to do some non-RESTful things with it. Like POSTing to /article/{id}/{action}. Yes it is not REST...I don't care. It makes a lot of sense to POST to /article/15/publish to publish an article. I had to override so much inside tastypie it was getting to me. Django restframework is a bit different. Default behavior is centered around mixins (basically multiple inheritance). I created a mixin for actions being specified and basically added it to any resource I wanted to have that. If you want to know more feel free to ask.
  - Daniel_Newby 14y ago
    > The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call. That sounds like the perfect place to use a Python function decorator, which lets you wrap a funtion in standard boilerplate.
raverbashing 14y ago
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 api server I may sound critical of Django, but I think it's a "complex framework for simple usages", I mean, if you need low flexibility go for it, you'll do what you want really quickly.
- jbm 14y ago
  I think you are being a bit harsh by using the quickness of Django as a 1 line throwaway - the entire purpose is for it to produce quick, simple applications. There is an entire class of problems (mainly enterprise-related) for which the simplicity (ORM / Auth / etc..) is great. I managed to tie Django Auth into Active Directory which made the user's experience (relatively) seamless, as opposed to the previous reality (everyone with a different password for different applications). Can't you also use Jinja templates in Django? I'm not convinced that I would use Django on a large project where I get to cooperate with 15-20 other programmers, but if the scenario is 3 people with relatively normal business requirements it makes a lot of sense. YMMV.
  - raverbashing 14y ago
    I don't disagree with you! You can certainly use Jinja2 templates on Django, for most uses Django templates are ok
  - wahnfrieden 14y ago
    You can use Jinja2 with Django, but you lose the ability to use any prebuilt Django templates. Which isn't much of an issue in practice since those are often the first thing you write yourself from reusable apps. You also can't use templatetags from reusable apps (or Django itself) but it's easy enough to write a wrapper for those that allows you to. We switched to Jinja2 for Canvas because the Django templates were atrociously slow, and it was absolutely the right decision for us.
jerf 14y ago
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 all into Flask and it will inevitably have to choose between either having the same problem, or leaving vast swathes of functionality on the table because of the refusal to let the components work together so they stay separate.
- btipling 14y ago
  You just posted what I had intended to say, only you said it better.
- anthonyb 14y ago
  Exactly, and I have exactly the same eye twitch every time someone recommends tearing out Django's ORM "because it's shit" and replacing it with SQLAlchemy. Each of those arrows from slide 25 on should have a little label: "Things that you have to write yourself in Flask."
- kmfrk 14y ago
  Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 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, it's for. They just hold on to their utopian idea of what their framework should be. Django was created for practical purposes by people who used it in publishing. I think that's a great foundation for a framework - for some people - and piling on it is just a stupid bandwagon. --- EDIT: I found a better way to put this: the author doesn't have a problem with Django; he has a problem with the concept of frameworks.
  - famousactress 14y ago
Apreche 14y ago
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. That is the fundamental problem of all micro-frameworks. They are so small they are incomplete. You may not like Django auth, but Flask has NO AUTH. You have to go get a third party auth system, or write your own. That means with Django I can get a site, with auth, up in just a few minutes. With Flask, you have to write a login page for the 1000th time in your life. It may be very simple to do that, but it's even simpler to do nothing at all.
- drivebyacct2 14y ago
  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.
  - anthonyb 14y ago
    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.
    - Orf_ 14y ago
      I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with-django http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.
      - anthonyb 14y ago
        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?
btipling 14y ago
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 more than what web.py offered, well except for all the testing tools (which look pretty cool). Sure the article has a good argument about separating components, but before you propose your alternative you should include all of those features (decoupled I suppose) that Django does for you already. In addition the patterns page[1] on the Flask documentation is basically a cookbook for things that Django already does, and by the way encourage the one code base architecture this presentation argued against. [1] http://flask.pocoo.org/docs/patterns/ http://flask.pocoo.org/docs/patterns/
- anthonyb 14y ago
  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()
  - zzzeek 14y ago
    wtf is that ? edit: using the current toolchain it's: alembic upgrade head
    - anthonyb 14y ago
      It's from Flask's recipe section: http://flask.pocoo.org/docs/patterns/sqlite3/#initial-schemas 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.
      - the_mitsuhiko 14y ago
bangbang 14y ago
What fonts were used in this? I like.
- kenneth_reitz 14y ago
  Thanks! Titles are High Tower Text (Flask Logo Font): http://www.fontyukle.net/en/High+Tower+Text.ttf http://www.fontyukle.net/en/High+Tower+Text.ttf Text is Gaudy Bookletter 1911 (Open Source!): http://www.theleagueofmoveabletype.com/goudy-bookletter-1911 http://www.theleagueofmoveabletype.com/goudy-bookletter-1911 And code examples are Monofur: http://www.dafont.com/monofur.font http://www.dafont.com/monofur.font
  - candeira 14y ago
    I rarely say this, normally preferring a scannable transcript to one-dimensional media, but... is there a video or even audio of the presentation?
    - kenneth_reitz 14y ago
      It was recorded. I'll try to update this thread when it's posted online.
  - tmoertel 14y ago
    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.)
    - kenneth_reitz 14y ago
      Awesome, thanks for the tip :)
kaiju 14y ago
I'm really tired of seeing memes & my little pony references in presentations. I thought we were adults?
- kenneth_reitz 14y ago
  Adults can't have a sense of humor?
  - dorian-graph 14y ago
    He didn't say that.
  - deleted 14y ago
    [deleted]
  - byproxy 14y ago
    There's humor, and there's LCD pandering. Despite that, this submission did get me to try out Flask. Nice and straightforward to get started with, which is good because I'm stupid.
- blackhole 14y ago
  It's easy to make a boring but informative presentation. It is much more difficult to make a funny but informative presentation. Of course, if you have no sense of humor, I must assume you are a lost traveler from Boringland.
- onelson 14y ago
  Really, drunken pony parties are 100% relevant to a talk about django. I don't think the slide deck would be complete without it.
- vandahm 14y ago
  I think the presenter was referring to the Django Pony -- Django's widely known but unofficial mascot -- and not trying to invoke a My Little Pony meme. http://djangopony.com/ http://djangopony.com/
- amccloud 14y ago
majormajor 14y ago
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 was in school. And sure, if I had unlimited resources, and wasn't annoyed at all by having to carry around a bunch of primes, and could change lenses in an instant (or was carrying four different bodies too), I'd rather have a set of excellent primes than a zoom. Very much like how I'd love to be able to integrate (and possibly write myself) a bunch of services to perfectly fit my problem instead of using a framework. But it just isn't very practical for a lot of areas. And then the problem changes, and the purpose-built solution to be adapted... and then this happens a few more time and how perfectly have you maintained your original separations of concerns?
- tonyarkles 14y ago
  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 :)
  - Xion 14y ago
    I wholeheartedly agree. TDD as Test-Driven Debugging is the way to go. :)
- scottschulthess 14y ago
  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
- 14y ago
LaSombra 14y ago
I'm an inexperienced web programmer wannabe, but what's the difference between Flask and Sinatra?
- peregrine 14y ago
  Largest different is age and ruby vs python. That said Sinatra is built on Rack which has a ton of extensions to add things like sessions or auth. Where as flask has specific flask modules. Really apples to apples in my opinion.
- tonyarkles 14y ago
  For one, the language (Python vs. Ruby)
scottschulthess 14y ago
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.
deleted 14y ago
[deleted]
arthurbrown 14y ago
I'm not quite sure I understand slide 48 which talks about constraints. Does a text editor have more or less constraints than an IDE? I would argue that it has less constraints, however I assume he is arguing that text editors are better which implies that they have more constraints. The same goes for Pen&Paper vs digital notes. Surely being able to write in any direction at any size with any style as well as draw means there are less constraints than simply typing a digital note. Am I misunderstanding which side of these examples he's actually advocating? How does OSX v Linux enter into this whatsoever?
- tomkr 14y ago
  I was at the talk, and the way he explained it was that the first column allows for less customization. Kenneth said that if he would use Linux he would spend all day tweaking it, and not getting work done. The same goes for pen & paper notes over digital notes, once they're written down, you're not tweaking them anymore. A simple text editor does not have all the fancy functions to play with that an IDE does. So he is indeed advocating the first column, with regards to them being tools that are not as configurable as the second column.
  - gbog 14y ago
    > he would use Linux he would spend all day tweaking it That is a fatigued point. I use Linux and store the few tweak I have to do manually in a install_note file. Next time I want a fresh install I just follow the doc and in 10 mn I have a fully adapted environment. Then I do not tweak anything more at this level. All subsequent tweaks are vimrc and bashrc modifications that are pushed to bitbucket, and I guess I would do those on MacOS anyway. Being able to fiddle the config do not mean you have to, and the days are gone when Linux was not that stable. The thing I actually spend a lot of time tweaking for the few days I have a new device or OS version is my phone (Android). On these little big guys I get back the tweaking excitment I got with my first PCs (Oh! Look, you can change the prompt! Look, you can move the start bar to the top!) I think what is actually interesting with mobile phone is that they are not stabilized, a lot has to be invented for them, and each new OS version or even some apps really add new possibilities. But for Linux, Windows or Mac, no new exciting thing is in sight, and spending too much time tweaking the config just mean you have time to spare.
espeed 14y ago
Monolithic frameworks complect things -- see Rich Hickey's talk "Simple Made Easy" (http://www.infoq.com/presentations/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 paradigm emerges. We're in a period of rapid development in datastore technology. If you're locked into a relational database, it makes it difficult to switch and take advantage of these developments. Loosely coupled components like Flask follow in the Unix tradition and free you from these bounds. Django was well positioned 10 years ago when the RDBMS ruled, but with the proliferation of new DBs and data storage services, it's not well aligned with modern architectures.
- cheatercheater 14y ago
  So yeah, let's use VertexDB for auth. ...are you out of your mind?
  - espeed 14y ago
    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 http://www.infoq.com/presentations/The-Design-of-Datomic) is interesting, which is distributed and uses Amazon's DynamoDB storage service.
    - cheatercheater 14y ago
      I'm yet to see a Django based website that outgrows any old rdbms for auth. Care to back up your claim that it's bad? Same for admin. You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the models being managed that touches the database. Edit: just before my comment gets skewed, my question is: why would you ever use django for a website big enough to warrant this sort of worry? Let's recap: big websites make money which is used to hire coders. Those people are at that point probably porting your website to Agda, or some other cloudscale technology. Sounds like you're the same kind of person who complains that Bash doesn't support OpenMPI and that JavaScript doesn't do fib() well enough and that this here carpentry hammer can't break diamond. Wrong application, dude. Django is for medium-small websites, not for your Cloneddit, Clonebook, CloneSpace, or news.yclonebinator.com; get a different hammer.
brown9-2 14y ago
I'm confused about the assertion that Flask is only 800 lines of code. Counting Flask v0.8 with cloc yields twice that: $ perl cloc-1.56.pl flask --exclude-dir=testsuite,ext 18 text files. 18 unique files. 114 files ignored. http://cloc.sourceforge.net v 1.56 T=0.5 s (36.0 files/s, 8008.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 18 694 1748 1562 ------------------------------------------------------------------------------- SUM: 18 694 1748 1562 ------------------------------------------------------------------------------- And that doesn't include the size of Werkzeug, without which Flask cannot run: $ perl cloc-1.56.pl werkzeug --exclude-dir=testsuite,ext,debug,contrib 20 text files. 20 unique files. 126 files ignored. http://cloc.sourceforge.net v 1.56 T=1.0 s (20.0 files/s, 13460.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 20 2307 4277 6876 ------------------------------------------------------------------------------- SUM: 20 2307 4277 6876 ------------------------------------------------------------------------------- Including the contrib and debug packages of Werkzeug adds another 3000 LOC.
- the_mitsuhiko 14y ago
  I haven't done the numbers in a while but from the given ratio I would assume your line checker tool treats docstrings as code. The red part there is for the most part just documentation, not code: https://github.com/mitsuhiko/flask/blob/master/flask/app.py https://github.com/mitsuhiko/flask/blob/master/flask/app.py (as an example)
  - brown9-2 14y ago
    I think you're right, it is counting docstrings as code.
hcarvalhoalves 14y ago
I've been working with Django for about 5 years now and I can say it's a great framework for a "quick win" when your use case matches its original intent - that is, if you're building public websites, with a custom CMS backend, and need the usual stuff like authentication, feeds, comments, etc. You can go a long way by just using and extending built-in apps - and for the 20%-40% left you find some great 3rd party libraries for doing what you need. From my experience, the problems arise when you begin bending it to fit your particular use case. For instance: Django is naive regarding multi-tenancy, something you usually need when building web apps, so you'll have to hack some parts in it; the coupling of most 3rd party apps with the built-in authentication app can also get in the way; etc. If your use case deviates too much from the "website" model, using Flask (or just going down to WSGI) for the plumbing and then picking best-of-breed libraries (SQLAlchemy, Jinja, etc.) can pay off in the long run as opposed to going with monolithic Django from the start because, down the line, you'll find you had to hack most parts anyway.
f0untain 14y ago
Is it possible to use DSL instead of a framework ? Could we have web DSL to easily make frameworks ?
zem 14y ago
from the ruby side of things, here's a very good write-up of the differing philosophies between rails [monolithic, batteries-included] and sinatra [small, lightweight]: http://rubysource.com/rails-or-sinatra-the-best-of-both-worlds/ http://rubysource.com/rails-or-sinatra-the-best-of-both-worl... the post goes into why there is room (and a need) for both in the ruby web ecosystem, and where you'd want to use each one.
tferris 14y ago
This is not about Django and why it sucks. It's a refreshing take on monolithic vs. micro frameworks and it's nice to see that a micro framework like Flask gets the attention it deserves. I believe that monolithic framework are aged too. Django and also Rails as monolithic as they are force you into given patterns, even if you can choose specific modules. I made my first experiences with a highly modular micro framework (Node with Express) some weeks ago and I have to say that I don't want to go back. Even if it seems that you have to reinvent the wheel sometimes (but in reality you don't) your application reflects your use case much better, it's more fun and you are again programming yourself—deciding on architecture, structure and design patterns.
bryanh 14y ago
Traitor scum! Such an intense title after such a nice conversation on the Django Podcast... [1] Of course I'm kidding because these are valid critiques. Django's code base has a bad case of introducing really hard to debug interactions. But, to be fair, those are fairly rare. However, as a Django lover I must say that Flask is missing a lot of what I love about Django: sane pre-built options for getting you to 90% functionality quickly. That last 10% can be difficult, but that is better than a more difficult 90%. One thing that is rather annoying with Django is the learning curve (there's a lot in there), but the docs are so good that it isn't that bad (and one could argue that Flask is harder to learn because it means learning SQLAlchemy, Werkzueg, etc... too). As he mentions in the slide, best tool for the job. Flask is certainly more Pythonic (IMO) and beats Django very handily for simple apps, but the ability to skip reinventing the wheel will keep a lot of people in the Django camp for the foreseeable future. [1] http://3rdaverad.io/shows/django-podcast/episodes/deployment-for-humans-with-kenneth-reitz/ http://3rdaverad.io/shows/django-podcast/episodes/deployment...
EternalFury 14y ago
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.
AncientPC 14y ago
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.
rapind 14y ago
Not trolling, but didn't we go through this with rails a few years ago and the result was, as usual, it depends upon the context?
jrochkind1 14y ago
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.
ashray 14y ago
I think something the author didn't really cover was upgrades. When elements are highly decoupled, it's easy to go and upgrade piece by piece. API changes can be factored in and dealt with relatively easily. (I believe this is something Amazon did right as well..) I know this for a fact because upgrading a massive django deployment from 1.1 to 1.4 was a huge project for us. That said, I still love all the out of box defaults that django provides and the fact that extending them is relatively painless as long as you spent a few years learning the ins and outs of the system ;)
tantalor 14y ago
What can be said of Django and Flask may as well be said of Rails and Sinatra.
sorensen 14y ago
While it is true that Django may be quite a large framework, a 'kitchen sink' in a way, I feel that many people often miss the point of what a framework is, in that you don't have to use all of it. In my few years of developing in Django I have had my frustrations and joys, many of the frustrations coming from the idea that I should do things how the framework wants me to, only to realize that it is still python that I'm writing code in. The idea of Django is not to be some utopian framework where all of your pythonic dreams come true, it is to enable you to build applications quickly and with ease. While Django may have been created to be a publishing platform, our primary use for it is a genetic analysis application, which is complicated enough without having to worry about the framework, and trust me, Django is not anywhere near a problem in the app. We also use Django for a separate report delivery system, which has API endpoints and is constantly being fed data from 3 other applications, and again, Django has never been an issue. Sure, you can roll your own libraries with something small like Flask, and reinvent the wheel many times over, but do you actually get features rolled out? Or are you constantly patting yourself on the back for keeping such a small codebase while maintaining a home-grown system and hoping you can get a feature out the door while fixing all of the bugs that not only the system may have introduced, but your features as well. Here are my biggest worries of a very customized/home grown framework: 1) Does the knowledge of the framework transfer to the next project you work on? 2) Are you writing documentation so that the next person can understand the code? If so whats the time cost for that? 3) Are you spending more time building the perfect system or rolling out features? Don't get me wrong though, I love working with small polished libraries and connecting them together, namely in node.js, but it is entertaining more than productive.
sgt 14y ago
How is Flask any different from using say, CherryPy?
powatom 14y ago
Sounds to me like this guy was using the wrong tool for the job.
markessien 14y ago
Django is just badly designed. Many things in Django don't work right from the start, and changing them is a big, big pain. When I tried Django, I had to make some changes to the authentication (I can't remember well, but I think I wanted to be able to sign in with email addresses). It was a big pain that took quite a while, and made it incompatible with the rest. In the end, as the application grew, I had to throw out most of Django and just use my own custom written code. Steep learning curve for a process that will be thrown out later anyways. A micro-framework is much better. At least you can mix and match as you want.
EnderMB 14y ago
The biggest stumbling block for me, and I imagine a lot of other users, is simply getting it installed and running. On Ubuntu I was able to do this within ten minutes, but if I choose to develop on Windows it's next to impossible to get a Django project with a PostgreSQL db running without any issues. I'm quite fond of Python and I like what I have used of Django, but I'd be willing to wager that a lot of other people from PHP land have wanted to use Django and have been put off by how hard it is to set up. Obviously, I could be doing something wrong, so if it's obvious that I'm doing something wrong please say so.
reinout 14y ago
I made a summary of Kenneth's talk at http://reinout.vanrees.org/weblog/2012/06/06/flask-django-sucks.html http://reinout.vanrees.org/weblog/2012/06/06/flask-django-su..., for some this might be nicer to read/scan than slides. The slides are more complete, though :-)
atasever 14y ago
this presentation is as true as saying "e-books are bad, books are great! Because e-books have too much functionalities"
its_so_on 14y ago
Sorry if this is a stupid question, but are these just slides without any voice or commentary? Also, you might be interested in this video, http://www.youtube.com/watch?v=i6Fr65PFqfk http://www.youtube.com/watch?v=i6Fr65PFqfk "Why I hate Django" by Cal Henderson then of Flicker. 2008 though - I'd love to know about an update about the things addressed.
stesch 14y ago
And websites that need JavaScript and don't tell you.
ezl 14y ago
sigh I understand that "why django sucks" is a better, more provocative title that will get read more than "why django isn't perfect in every way and i prefer using flask for this", so i don't fault the author for choosing that subtext. However, the general "tradition" (yes, its a tradition now) of justifying a tech/infrastructure decision with "Ah! language/framework/db made popular by others is a horribly broken mistake! you are doing it wrong!" is 1. getting old, 2. counterproductive for engineers. They are tools. There are different tasks with different requirements. They have different pros and cons and different learning curves. Some tools are better suited for some tasks. Some tools are even better suited for most tasks. Sometimes it even makes reasonable sense to use a product that isn't the best of the best of the best if you are really certain you don't care about the dimension in which your tool is not the most amazing. Hammers are bad for cooking eggs. Spatulas are bad for nailing nails. I made eggs this morning. Keep an eye out for my upcoming blog post: "Why hammers suck!!"
- sashahart 14y ago
  I completely agree with you about needlessly provocative titles. On the other hand, in the world of frameworks, it's not entirely common for the use cases to be (as) disjoint as they are for hammers vs. spatulas. More often, frameworks overlap in functionality and differ on matters of style and ideology. And this is what feeds the flame wars. For starters, you have a choice between MyKitchen and spatula. MyKitchen has everything you need to make a reasonable pasta meal for up to 8 guests. The pasta practically serves itself... even when you are making steaks. spatula is totally dedicated to scraping things out of pots, and obviously you could just use MyKitchen.SpatulaFactory(_ctx) instead (you did read the equipment manifest, didn't you?) Plus MyKitchen has a plugin which will make pork buns that practically serve themselves... why waste time with low-level stuff like spatulas? Some guy graduated from spaghetti to pizzas and he can only scoff at spatula, which is not necessary at all, since you can cook pizzas directly on the rack. Another guy made this incredible pocket-sized leatherman which includes compact versions of all the kitchen tools including a camp stove. It is true that most frameworks are better suited to some tasks than others, but for a given task one might be just plain technically inferior, or only different in some stylistic way. Not that style doesn't matter, if it makes you feel happier doing your job. Otherwise, why bother with Ruby or Python when there is already Java EE or COBOL?
tbatterii 14y ago
the "benefits" of flask vs. django can easily be attributed to any of the so-called web micro frameworks vs web full stack frameworks. it's interesting to me that django seems to be getting grief for some of the same things zope was/is. Time to reinvent the wheel again I guess. http://www.jrandolph.com/blog/2006/02/02/zope-vs-django-heres-some-gasoline-to-put-out-the-fire/ http://www.jrandolph.com/blog/2006/02/02/zope-vs-django-here... So surprise surprise, you stray from the happy path the full stack framework lays out for you, be ready for the pain.
known 14y ago
Not just Django, every framework sucks for sophisticated applications.
mikepk 14y ago
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_fieldsets/ 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
zashapiro 14y ago
But have you seen the trailer for Django Unchained?!? (new Tarantino flick) http://www.youtube.com/watch?v=rC8VJ9aeB_g http://www.youtube.com/watch?v=rC8VJ9aeB_g
ianstallings 14y ago
Meh, I like Django.
jh2007 14y ago
Your argument is just saying a blank piece of paper is the best framework.

271 points by kenneth_reitz 14y ago

If you like this approach, and I certainly do (especially after finishing a very service oriented django project), I fully encourage you to check out Go standard libs combined with Gorilla. Plus you get other fun advantages of Go if you want/need them.

zeeg 14y ago

I think the title is misleading, but the slides/concepts are pretty spot on.

sparknlaunch 14y ago

> "Speaker Bio Python Overlord for Heroku. Creator of Python-Requests. Photographer. Curator of The GitHub Reflog™. Knows where his towel is." Thanks for sharing. The site has a few other interesting presentations by the same speaker.

antihero 14y ago

I love Django for making websites, but I'd go with Flask for an API. The only issue I found with Flask is I often found myself recreating stuff that Django already does, and is already done way better.

yesimahuman 14y ago

Thanks for posting this. I use Django extensively and I never really felt any pain from the tightly coupled monolithic approach, but I always like improving my tools. I will check out Flask. Any suggestions for making it easy to build REST style APIs? Is piston the #1 choice still?

mumphster 14y ago
Check out Tastypie. You can get a full restful API based around your models up in like 5 lines of code and it's really easy to add extra functionality. Sorry for the lack of a link I'm posting this from a phone
papercruncher 14y ago
Yes, still the #1 choice in my books, especially if your APIs do not match your models 1:1. Tastypie is cute but gets in your way a little too often for my liking. Django-rest is another contender but I haven't tried that yet
philfreo 14y ago
http://pydanny.com/choosing-an-api-framework-for-django.html http://pydanny.com/choosing-an-api-framework-for-django.html
bdr 14y ago
I prefer tastypie. It takes a fair bit of time investment to learn how it does things, but once you do it's powerful.
jtchang 14y ago
I've used all 3 and I settled on "django rest framework". http://django-rest-framework.org/ http://django-rest-framework.org/ The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call. I also had to map each and every call (GET/PUT/POST/DELETE) and there was no default out of box behavior. I felt like I was violating the DRY principle over and over. Tastypie was great when I started but I wanted to do some non-RESTful things with it. Like POSTing to /article/{id}/{action}. Yes it is not REST...I don't care. It makes a lot of sense to POST to /article/15/publish to publish an article. I had to override so much inside tastypie it was getting to me. Django restframework is a bit different. Default behavior is centered around mixins (basically multiple inheritance). I created a mixin for actions being specified and basically added it to any resource I wanted to have that. If you want to know more feel free to ask.
- Daniel_Newby 14y ago
  > The issue I have with piston is that it didn't turn my objects into JSON automatically for me when I returned from the call. That sounds like the perfect place to use a Python function decorator, which lets you wrap a funtion in standard boilerplate.

raverbashing 14y ago

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 api server I may sound critical of Django, but I think it's a "complex framework for simple usages", I mean, if you need low flexibility go for it, you'll do what you want really quickly.

jbm 14y ago
I think you are being a bit harsh by using the quickness of Django as a 1 line throwaway - the entire purpose is for it to produce quick, simple applications. There is an entire class of problems (mainly enterprise-related) for which the simplicity (ORM / Auth / etc..) is great. I managed to tie Django Auth into Active Directory which made the user's experience (relatively) seamless, as opposed to the previous reality (everyone with a different password for different applications). Can't you also use Jinja templates in Django? I'm not convinced that I would use Django on a large project where I get to cooperate with 15-20 other programmers, but if the scenario is 3 people with relatively normal business requirements it makes a lot of sense. YMMV.
- raverbashing 14y ago
  I don't disagree with you! You can certainly use Jinja2 templates on Django, for most uses Django templates are ok
- wahnfrieden 14y ago
  You can use Jinja2 with Django, but you lose the ability to use any prebuilt Django templates. Which isn't much of an issue in practice since those are often the first thing you write yourself from reusable apps. You also can't use templatetags from reusable apps (or Django itself) but it's easy enough to write a wrapper for those that allows you to. We switched to Jinja2 for Canvas because the Django templates were atrociously slow, and it was absolutely the right decision for us.

jerf 14y ago

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 all into Flask and it will inevitably have to choose between either having the same problem, or leaving vast swathes of functionality on the table because of the refusal to let the components work together so they stay separate.

btipling 14y ago
You just posted what I had intended to say, only you said it better.
anthonyb 14y ago
Exactly, and I have exactly the same eye twitch every time someone recommends tearing out Django's ORM "because it's shit" and replacing it with SQLAlchemy. Each of those arrows from slide 25 on should have a little label: "Things that you have to write yourself in Flask."
kmfrk 14y ago
Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 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, it's for. They just hold on to their utopian idea of what their framework should be. Django was created for practical purposes by people who used it in publishing. I think that's a great foundation for a framework - for some people - and piling on it is just a stupid bandwagon. --- EDIT: I found a better way to put this: the author doesn't have a problem with Django; he has a problem with the concept of frameworks.
- famousactress 14y ago

Apreche 14y ago

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. That is the fundamental problem of all micro-frameworks. They are so small they are incomplete. You may not like Django auth, but Flask has NO AUTH. You have to go get a third party auth system, or write your own. That means with Django I can get a site, with auth, up in just a few minutes. With Flask, you have to write a login page for the 1000th time in your life. It may be very simple to do that, but it's even simpler to do nothing at all.

drivebyacct2 14y ago
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.
- anthonyb 14y ago
  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.
  - Orf_ 14y ago
    I wrote my own to use SQLAlchemy models you define: http://tomforb.es/using-a-custom-sqlalchemy-users-model-with-django http://tomforb.es/using-a-custom-sqlalchemy-users-model-with... Its really not that bad or hard to do at all.
    - anthonyb 14y ago
      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?

btipling 14y ago

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 more than what web.py offered, well except for all the testing tools (which look pretty cool). Sure the article has a good argument about separating components, but before you propose your alternative you should include all of those features (decoupled I suppose) that Django does for you already. In addition the patterns page[1] on the Flask documentation is basically a cookbook for things that Django already does, and by the way encourage the one code base architecture this presentation argued against. [1] http://flask.pocoo.org/docs/patterns/ http://flask.pocoo.org/docs/patterns/

anthonyb 14y ago
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()
- zzzeek 14y ago
  wtf is that ? edit: using the current toolchain it's: alembic upgrade head
  - anthonyb 14y ago
    It's from Flask's recipe section: http://flask.pocoo.org/docs/patterns/sqlite3/#initial-schemas 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.
    - the_mitsuhiko 14y ago

bangbang 14y ago

What fonts were used in this? I like.

kenneth_reitz 14y ago
Thanks! Titles are High Tower Text (Flask Logo Font): http://www.fontyukle.net/en/High+Tower+Text.ttf http://www.fontyukle.net/en/High+Tower+Text.ttf Text is Gaudy Bookletter 1911 (Open Source!): http://www.theleagueofmoveabletype.com/goudy-bookletter-1911 http://www.theleagueofmoveabletype.com/goudy-bookletter-1911 And code examples are Monofur: http://www.dafont.com/monofur.font http://www.dafont.com/monofur.font
- candeira 14y ago
  I rarely say this, normally preferring a scannable transcript to one-dimensional media, but... is there a video or even audio of the presentation?
  - kenneth_reitz 14y ago
    It was recorded. I'll try to update this thread when it's posted online.
- tmoertel 14y ago
  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.)
  - kenneth_reitz 14y ago
    Awesome, thanks for the tip :)

kaiju 14y ago

I'm really tired of seeing memes & my little pony references in presentations. I thought we were adults?

kenneth_reitz 14y ago
Adults can't have a sense of humor?
- dorian-graph 14y ago
  He didn't say that.
- deleted 14y ago
  [deleted]
- byproxy 14y ago
  There's humor, and there's LCD pandering. Despite that, this submission did get me to try out Flask. Nice and straightforward to get started with, which is good because I'm stupid.
blackhole 14y ago
It's easy to make a boring but informative presentation. It is much more difficult to make a funny but informative presentation. Of course, if you have no sense of humor, I must assume you are a lost traveler from Boringland.
onelson 14y ago
Really, drunken pony parties are 100% relevant to a talk about django. I don't think the slide deck would be complete without it.
vandahm 14y ago
I think the presenter was referring to the Django Pony -- Django's widely known but unofficial mascot -- and not trying to invoke a My Little Pony meme. http://djangopony.com/ http://djangopony.com/
amccloud 14y ago

majormajor 14y ago

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 was in school. And sure, if I had unlimited resources, and wasn't annoyed at all by having to carry around a bunch of primes, and could change lenses in an instant (or was carrying four different bodies too), I'd rather have a set of excellent primes than a zoom. Very much like how I'd love to be able to integrate (and possibly write myself) a bunch of services to perfectly fit my problem instead of using a framework. But it just isn't very practical for a lot of areas. And then the problem changes, and the purpose-built solution to be adapted... and then this happens a few more time and how perfectly have you maintained your original separations of concerns?

tonyarkles 14y ago
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 :)
- Xion 14y ago
  I wholeheartedly agree. TDD as Test-Driven Debugging is the way to go. :)
scottschulthess 14y ago
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
14y ago

LaSombra 14y ago

I'm an inexperienced web programmer wannabe, but what's the difference between Flask and Sinatra?

peregrine 14y ago
Largest different is age and ruby vs python. That said Sinatra is built on Rack which has a ton of extensions to add things like sessions or auth. Where as flask has specific flask modules. Really apples to apples in my opinion.
tonyarkles 14y ago
For one, the language (Python vs. Ruby)

scottschulthess 14y ago

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.

deleted 14y ago

[deleted]

arthurbrown 14y ago

I'm not quite sure I understand slide 48 which talks about constraints. Does a text editor have more or less constraints than an IDE? I would argue that it has less constraints, however I assume he is arguing that text editors are better which implies that they have more constraints. The same goes for Pen&Paper vs digital notes. Surely being able to write in any direction at any size with any style as well as draw means there are less constraints than simply typing a digital note. Am I misunderstanding which side of these examples he's actually advocating? How does OSX v Linux enter into this whatsoever?

tomkr 14y ago
I was at the talk, and the way he explained it was that the first column allows for less customization. Kenneth said that if he would use Linux he would spend all day tweaking it, and not getting work done. The same goes for pen & paper notes over digital notes, once they're written down, you're not tweaking them anymore. A simple text editor does not have all the fancy functions to play with that an IDE does. So he is indeed advocating the first column, with regards to them being tools that are not as configurable as the second column.
- gbog 14y ago
  > he would use Linux he would spend all day tweaking it That is a fatigued point. I use Linux and store the few tweak I have to do manually in a install_note file. Next time I want a fresh install I just follow the doc and in 10 mn I have a fully adapted environment. Then I do not tweak anything more at this level. All subsequent tweaks are vimrc and bashrc modifications that are pushed to bitbucket, and I guess I would do those on MacOS anyway. Being able to fiddle the config do not mean you have to, and the days are gone when Linux was not that stable. The thing I actually spend a lot of time tweaking for the few days I have a new device or OS version is my phone (Android). On these little big guys I get back the tweaking excitment I got with my first PCs (Oh! Look, you can change the prompt! Look, you can move the start bar to the top!) I think what is actually interesting with mobile phone is that they are not stabilized, a lot has to be invented for them, and each new OS version or even some apps really add new possibilities. But for Linux, Windows or Mac, no new exciting thing is in sight, and spending too much time tweaking the config just mean you have time to spare.

espeed 14y ago

Monolithic frameworks complect things -- see Rich Hickey's talk "Simple Made Easy" (http://www.infoq.com/presentations/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 paradigm emerges. We're in a period of rapid development in datastore technology. If you're locked into a relational database, it makes it difficult to switch and take advantage of these developments. Loosely coupled components like Flask follow in the Unix tradition and free you from these bounds. Django was well positioned 10 years ago when the RDBMS ruled, but with the proliferation of new DBs and data storage services, it's not well aligned with modern architectures.

cheatercheater 14y ago
So yeah, let's use VertexDB for auth. ...are you out of your mind?
- espeed 14y ago
  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 http://www.infoq.com/presentations/The-Design-of-Datomic) is interesting, which is distributed and uses Amazon's DynamoDB storage service.
  - cheatercheater 14y ago
    I'm yet to see a Django based website that outgrows any old rdbms for auth. Care to back up your claim that it's bad? Same for admin. You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the models being managed that touches the database. Edit: just before my comment gets skewed, my question is: why would you ever use django for a website big enough to warrant this sort of worry? Let's recap: big websites make money which is used to hire coders. Those people are at that point probably porting your website to Agda, or some other cloudscale technology. Sounds like you're the same kind of person who complains that Bash doesn't support OpenMPI and that JavaScript doesn't do fib() well enough and that this here carpentry hammer can't break diamond. Wrong application, dude. Django is for medium-small websites, not for your Cloneddit, Clonebook, CloneSpace, or news.yclonebinator.com; get a different hammer.

brown9-2 14y ago

I'm confused about the assertion that Flask is only 800 lines of code. Counting Flask v0.8 with cloc yields twice that: $ perl cloc-1.56.pl flask --exclude-dir=testsuite,ext 18 text files. 18 unique files. 114 files ignored. http://cloc.sourceforge.net v 1.56 T=0.5 s (36.0 files/s, 8008.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 18 694 1748 1562 ------------------------------------------------------------------------------- SUM: 18 694 1748 1562 ------------------------------------------------------------------------------- And that doesn't include the size of Werkzeug, without which Flask cannot run: $ perl cloc-1.56.pl werkzeug --exclude-dir=testsuite,ext,debug,contrib 20 text files. 20 unique files. 126 files ignored. http://cloc.sourceforge.net v 1.56 T=1.0 s (20.0 files/s, 13460.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 20 2307 4277 6876 ------------------------------------------------------------------------------- SUM: 20 2307 4277 6876 ------------------------------------------------------------------------------- Including the contrib and debug packages of Werkzeug adds another 3000 LOC.

the_mitsuhiko 14y ago
I haven't done the numbers in a while but from the given ratio I would assume your line checker tool treats docstrings as code. The red part there is for the most part just documentation, not code: https://github.com/mitsuhiko/flask/blob/master/flask/app.py https://github.com/mitsuhiko/flask/blob/master/flask/app.py (as an example)
- brown9-2 14y ago
  I think you're right, it is counting docstrings as code.

hcarvalhoalves 14y ago

I've been working with Django for about 5 years now and I can say it's a great framework for a "quick win" when your use case matches its original intent - that is, if you're building public websites, with a custom CMS backend, and need the usual stuff like authentication, feeds, comments, etc. You can go a long way by just using and extending built-in apps - and for the 20%-40% left you find some great 3rd party libraries for doing what you need. From my experience, the problems arise when you begin bending it to fit your particular use case. For instance: Django is naive regarding multi-tenancy, something you usually need when building web apps, so you'll have to hack some parts in it; the coupling of most 3rd party apps with the built-in authentication app can also get in the way; etc. If your use case deviates too much from the "website" model, using Flask (or just going down to WSGI) for the plumbing and then picking best-of-breed libraries (SQLAlchemy, Jinja, etc.) can pay off in the long run as opposed to going with monolithic Django from the start because, down the line, you'll find you had to hack most parts anyway.

f0untain 14y ago

Is it possible to use DSL instead of a framework ? Could we have web DSL to easily make frameworks ?

zem 14y ago

from the ruby side of things, here's a very good write-up of the differing philosophies between rails [monolithic, batteries-included] and sinatra [small, lightweight]: http://rubysource.com/rails-or-sinatra-the-best-of-both-worlds/ http://rubysource.com/rails-or-sinatra-the-best-of-both-worl... the post goes into why there is room (and a need) for both in the ruby web ecosystem, and where you'd want to use each one.

tferris 14y ago

This is not about Django and why it sucks. It's a refreshing take on monolithic vs. micro frameworks and it's nice to see that a micro framework like Flask gets the attention it deserves. I believe that monolithic framework are aged too. Django and also Rails as monolithic as they are force you into given patterns, even if you can choose specific modules. I made my first experiences with a highly modular micro framework (Node with Express) some weeks ago and I have to say that I don't want to go back. Even if it seems that you have to reinvent the wheel sometimes (but in reality you don't) your application reflects your use case much better, it's more fun and you are again programming yourself—deciding on architecture, structure and design patterns.

bryanh 14y ago

Traitor scum! Such an intense title after such a nice conversation on the Django Podcast... [1] Of course I'm kidding because these are valid critiques. Django's code base has a bad case of introducing really hard to debug interactions. But, to be fair, those are fairly rare. However, as a Django lover I must say that Flask is missing a lot of what I love about Django: sane pre-built options for getting you to 90% functionality quickly. That last 10% can be difficult, but that is better than a more difficult 90%. One thing that is rather annoying with Django is the learning curve (there's a lot in there), but the docs are so good that it isn't that bad (and one could argue that Flask is harder to learn because it means learning SQLAlchemy, Werkzueg, etc... too). As he mentions in the slide, best tool for the job. Flask is certainly more Pythonic (IMO) and beats Django very handily for simple apps, but the ability to skip reinventing the wheel will keep a lot of people in the Django camp for the foreseeable future. [1] http://3rdaverad.io/shows/django-podcast/episodes/deployment-for-humans-with-kenneth-reitz/ http://3rdaverad.io/shows/django-podcast/episodes/deployment...

EternalFury 14y ago

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.

AncientPC 14y ago

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.

rapind 14y ago

Not trolling, but didn't we go through this with rails a few years ago and the result was, as usual, it depends upon the context?

jrochkind1 14y ago

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.

ashray 14y ago

I think something the author didn't really cover was upgrades. When elements are highly decoupled, it's easy to go and upgrade piece by piece. API changes can be factored in and dealt with relatively easily. (I believe this is something Amazon did right as well..) I know this for a fact because upgrading a massive django deployment from 1.1 to 1.4 was a huge project for us. That said, I still love all the out of box defaults that django provides and the fact that extending them is relatively painless as long as you spent a few years learning the ins and outs of the system ;)

tantalor 14y ago

What can be said of Django and Flask may as well be said of Rails and Sinatra.

sorensen 14y ago

While it is true that Django may be quite a large framework, a 'kitchen sink' in a way, I feel that many people often miss the point of what a framework is, in that you don't have to use all of it. In my few years of developing in Django I have had my frustrations and joys, many of the frustrations coming from the idea that I should do things how the framework wants me to, only to realize that it is still python that I'm writing code in. The idea of Django is not to be some utopian framework where all of your pythonic dreams come true, it is to enable you to build applications quickly and with ease. While Django may have been created to be a publishing platform, our primary use for it is a genetic analysis application, which is complicated enough without having to worry about the framework, and trust me, Django is not anywhere near a problem in the app. We also use Django for a separate report delivery system, which has API endpoints and is constantly being fed data from 3 other applications, and again, Django has never been an issue. Sure, you can roll your own libraries with something small like Flask, and reinvent the wheel many times over, but do you actually get features rolled out? Or are you constantly patting yourself on the back for keeping such a small codebase while maintaining a home-grown system and hoping you can get a feature out the door while fixing all of the bugs that not only the system may have introduced, but your features as well. Here are my biggest worries of a very customized/home grown framework: 1) Does the knowledge of the framework transfer to the next project you work on? 2) Are you writing documentation so that the next person can understand the code? If so whats the time cost for that? 3) Are you spending more time building the perfect system or rolling out features? Don't get me wrong though, I love working with small polished libraries and connecting them together, namely in node.js, but it is entertaining more than productive.

sgt 14y ago

How is Flask any different from using say, CherryPy?

powatom 14y ago

Sounds to me like this guy was using the wrong tool for the job.

markessien 14y ago

Django is just badly designed. Many things in Django don't work right from the start, and changing them is a big, big pain. When I tried Django, I had to make some changes to the authentication (I can't remember well, but I think I wanted to be able to sign in with email addresses). It was a big pain that took quite a while, and made it incompatible with the rest. In the end, as the application grew, I had to throw out most of Django and just use my own custom written code. Steep learning curve for a process that will be thrown out later anyways. A micro-framework is much better. At least you can mix and match as you want.

EnderMB 14y ago

The biggest stumbling block for me, and I imagine a lot of other users, is simply getting it installed and running. On Ubuntu I was able to do this within ten minutes, but if I choose to develop on Windows it's next to impossible to get a Django project with a PostgreSQL db running without any issues. I'm quite fond of Python and I like what I have used of Django, but I'd be willing to wager that a lot of other people from PHP land have wanted to use Django and have been put off by how hard it is to set up. Obviously, I could be doing something wrong, so if it's obvious that I'm doing something wrong please say so.

reinout 14y ago

I made a summary of Kenneth's talk at http://reinout.vanrees.org/weblog/2012/06/06/flask-django-sucks.html http://reinout.vanrees.org/weblog/2012/06/06/flask-django-su..., for some this might be nicer to read/scan than slides. The slides are more complete, though :-)

atasever 14y ago

this presentation is as true as saying "e-books are bad, books are great! Because e-books have too much functionalities"

its_so_on 14y ago

Sorry if this is a stupid question, but are these just slides without any voice or commentary? Also, you might be interested in this video, http://www.youtube.com/watch?v=i6Fr65PFqfk http://www.youtube.com/watch?v=i6Fr65PFqfk "Why I hate Django" by Cal Henderson then of Flicker. 2008 though - I'd love to know about an update about the things addressed.

stesch 14y ago

And websites that need JavaScript and don't tell you.

ezl 14y ago

sigh I understand that "why django sucks" is a better, more provocative title that will get read more than "why django isn't perfect in every way and i prefer using flask for this", so i don't fault the author for choosing that subtext. However, the general "tradition" (yes, its a tradition now) of justifying a tech/infrastructure decision with "Ah! language/framework/db made popular by others is a horribly broken mistake! you are doing it wrong!" is 1. getting old, 2. counterproductive for engineers. They are tools. There are different tasks with different requirements. They have different pros and cons and different learning curves. Some tools are better suited for some tasks. Some tools are even better suited for most tasks. Sometimes it even makes reasonable sense to use a product that isn't the best of the best of the best if you are really certain you don't care about the dimension in which your tool is not the most amazing. Hammers are bad for cooking eggs. Spatulas are bad for nailing nails. I made eggs this morning. Keep an eye out for my upcoming blog post: "Why hammers suck!!"

sashahart 14y ago
I completely agree with you about needlessly provocative titles. On the other hand, in the world of frameworks, it's not entirely common for the use cases to be (as) disjoint as they are for hammers vs. spatulas. More often, frameworks overlap in functionality and differ on matters of style and ideology. And this is what feeds the flame wars. For starters, you have a choice between MyKitchen and spatula. MyKitchen has everything you need to make a reasonable pasta meal for up to 8 guests. The pasta practically serves itself... even when you are making steaks. spatula is totally dedicated to scraping things out of pots, and obviously you could just use MyKitchen.SpatulaFactory(_ctx) instead (you did read the equipment manifest, didn't you?) Plus MyKitchen has a plugin which will make pork buns that practically serve themselves... why waste time with low-level stuff like spatulas? Some guy graduated from spaghetti to pizzas and he can only scoff at spatula, which is not necessary at all, since you can cook pizzas directly on the rack. Another guy made this incredible pocket-sized leatherman which includes compact versions of all the kitchen tools including a camp stove. It is true that most frameworks are better suited to some tasks than others, but for a given task one might be just plain technically inferior, or only different in some stylistic way. Not that style doesn't matter, if it makes you feel happier doing your job. Otherwise, why bother with Ruby or Python when there is already Java EE or COBOL?

tbatterii 14y ago

the "benefits" of flask vs. django can easily be attributed to any of the so-called web micro frameworks vs web full stack frameworks. it's interesting to me that django seems to be getting grief for some of the same things zope was/is. Time to reinvent the wheel again I guess. http://www.jrandolph.com/blog/2006/02/02/zope-vs-django-heres-some-gasoline-to-put-out-the-fire/ http://www.jrandolph.com/blog/2006/02/02/zope-vs-django-here... So surprise surprise, you stray from the happy path the full stack framework lays out for you, be ready for the pain.

known 14y ago

Not just Django, every framework sucks for sophisticated applications.

mikepk 14y ago

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_fieldsets/ 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

zashapiro 14y ago

But have you seen the trailer for Django Unchained?!? (new Tarantino flick) http://www.youtube.com/watch?v=rC8VJ9aeB_g http://www.youtube.com/watch?v=rC8VJ9aeB_g

ianstallings 14y ago

Meh, I like Django.

jh2007 14y ago

Your argument is just saying a blank piece of paper is the best framework.