HN Explorer

Ask HN: How Is Django “Bloated”?

7 points by pbhowmic ↗ HN
I am a long time Django dev, I have been for ~8 years now. I am also a contractor and have been so for roughly the same period. Every time I have moved from one client to another, it has been a recurring theme that there are some (many) devs in the client company who consider Django "bloated" - yes that exact word has been used to describe Django - but few if any can quantify or even identify the "bloat". I realise I am not an objective observer on this matter, I like Django and I like DRF even more so. So I am hoping some folks here at HN can shed more light on the subject of Django's bloat? For the sake of simplicity, let's confine the discussion to comparisons with other Python web frameworks such as FastAPI, Flask, bottle etc

5 comments

[ 3.6 ms ] story [ 21.7 ms ] thread
detaro
I assume they are talking about how Django contains lots of stuff by default, whereas many other "frameworks" include much less. E.g. Flask doesn't come with a database layer, or session management, or pretty much anything.

Now if that constitutes "bloat" or "fully-featured so I don't need to coble lots of libraries together" is a matter of taste and use case.

MattGaiser
There are devs out there who obsess over making sure their builds/programs/whatever are small in terms of bytes so they don't like anything that imports more than they need.

Django has everything. It is "batteries included." Well, many devs find many of those batteries to be useless, a.k.a bloat.

jonathaneunice
Bloat, like beauty, is often in the eyes of the beholder. Always ask: "By what measure?" or "Compared to what?"

Django is large, encompassing, and opinionated, so much "bigger" than "micro" web frameworks like Flask. But it's comparable in scope and cohesion to other "batteries-included" web frameworks such as Ruby on Rails or Laravel for PHP. As always, YMMV.

megaman821
This has only ever made sense when Django is not being used as a web framework. A person may want to use just the templating engine in a script, or the ORM in another framework. I could see how installing all of Django in those scenarios to use some small portion of it could be considered bloat.

It is imaginable that Django the web framework could be made up of sub-packages for the admin, templates, ORM, etc, but it was created at a time where Python package managers didn't really exist. Being a single package was (and probably still is) easier.

dyeje
You see this across technologies all the time. Engineers overvalue simplicity, which leads them to pick the lightweight framework (e.g. Flask vs Django, Sinatra vs Rails). The project grows in complexity and they end up having to reinvent the more full featured framework.