Live data from Hacker News

Why Django Sucks

speakerdeck.com

71–80 of 206 posts

Re: Why Django Sucks

#71

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

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 (as an example)

I think you're right, it is counting docstrings as code.

Re: Why Django Sucks

#72
post #62

Earlier quoted context omitted.

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

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

Re: Why Django Sucks

#73

Earlier quoted context omitted.

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

I would still recommend SQLAlchemy :-)

The point though, is that people bang on about lightweight frameworks and composability, but what's the first thing they do?

Start reimplementing^Wrecomposing Django on top of their lightweight framework.

Re: Why Django Sucks

#74

Earlier quoted context omitted.

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

Awesome, thanks for the tip :)

Re: Why Django Sucks

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

Re: Why Django Sucks

#76
post #21

Earlier quoted context omitted.

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

Who's piling on Django? It has flaws and weaknesses just like anything. It is a huge codebase that tries to be everything for everyone, and it succeeds about being almost everything for almost everyone, which is great. But it can be very difficult to do relatively simple things with Django sometimes, mostly in the admin pages. Admittedly, this is a pain point people bring on themselves by trying to do too much there,…

This got a lot better in 1.4: TemplateResponse and the list filter API meant some gnarly code removal on my biggest customized admin project.

That said, I also chose to implement many of my admin changes at a higher level: templates which use jQuery, etc. and interact with the REST API for e.g. complex object creation are much easier than the crazy form / widget hacks I used to try.

Re: Why Django Sucks

#77
post #39

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.

So … like Django except with no other users and less auditing?

I'm all for simplicity but some problems have very unfavorable cost/benefit ratios. Auth is one of them.

Re: Why Django Sucks

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

When I got into this, a great friend told me "every tool sucks to someone." I always evaluate content like this under those terms...

Re: Why Django Sucks

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

Post reply on HN