4 ms·
What I love about Django
- stavros 2mo agoI agree, Django is just fantastic. Nothing is perfect, but Django is just really well-designed, with components that fit together naturally into a balanced whole.
- weatherlite 2mo agoJust wanted to say I saw your last stand up , you're hilarious!
- stavros 2mo agoThanks, my love of comedy is only surpassed by my love of Django.
- weatherlite 2mo agoNaa you lie you love twinkies more than Django
- DoctorDabadedoo 2mo agoWhat a random way to find out a stand up comedian I see now and then share a craft!
- ustad 2mo agoStavros Halkias! Very funny guy. And also a maker and HN god! Never would have thought.
- JodieBenitez 2mo agoMost loved feature, for me: No dramatic changes, just sane and careful evolution.
- almost 2mo agoThis is so important. I've been using Django for around 20 years and my current code base is 10 years old. Not having to do major rewrites or stick on outdated versions really matters.
- JodieBenitez 2mo agoI have twenty years projects, no breakage when upgrading major versions. What a treat in the web app world !
- Maxion 2mo agoDjango is boring, which is why it works well. Use the ORM together with DRF serializers and an OpenApi generator and you can create TS types and TS client directly from your API. Works incredibly well almost straight out of the box for even quite large applications. Once you start to grow out of it, it's easy to bypass the ORM and write raw sql queries. You also won't be re-writing your backend every few years, the cost of which techbros often ignore.
- aitchnyu 2mo agoIf the DRF stack seamless like Ninja now?
- zelphirkalt 2mo agoNinja is quite a heavyweight in terms of dependencies (depends on Pydantic, which is itself heavyweight). Not everyone wants that in their project.
- angusj1 2mo ago[flagged]
- tonyedgecombe 2mo agoI haven’t used Django for a long time but when I did I found it one of the best documented projects out there.
- zelphirkalt 2mo agoSometimes I find the examples lacking a bit. For example: https://docs.djangoproject.com/en/6.0/ref/class-based-views/generic-editing/ https://docs.djangoproject.com/en/6.0/ref/class-based-views/... Each view deserves an example, that uses the most relevant fields to specify the behavior of that view, and perhaps a minimal template example for rendering that view, and at least one of the examples should be using forms. This is where asking an LLM for an example is very useful, but ideally, I should be able to find the available fields and their explanation and when to use them at a glance in the docs. In general the docs are good, just examples could be better.
- stuaxo 2mo agoNice. I've been meaning to do my own Django post, on some other bits we take for granted - I should do it. People should be using Django, the best parts are so useful you don't notice them until you switch platforms and implement them badly. Every app that used a more narrow solution ultimately ends up implementing parts of Django badly. The best way to solve this from Djangos side would be to have official ways of: - Using the ORM outside of Django - Doing single file Django apps Both of these have various 3rd party solutions, which shows demand. In the past other bits of Django have been split off by 3rd parties but those two are the places to start.
- ErroneousBosh 2mo agoI'm sure there must be a way to just set up enough of the Django environment to mangle about at objects in your models in a program. It's something I find myself using the Django shell often enough to want to do from outside there.
- cudder 2mo agoShout out to nanodjango, I researched all the single file options I could find some time ago and it had the best ergonomics imo. Not affiliated, just a fan. https://nanodjango.dev/ https://nanodjango.dev/
- cryo32 2mo agoMy favourite part of Django is it's not Rails :)
- 0x4d4c 2mo agoWhy is that? What's wrong with Rails?
- panzerboy 2mo agoIt's made by DHH.
- BoumTAC 2mo agoThe DHH hate is absolutely crazy on HN. I don't understand how people can be so out of touch.
- owebmaster 2mo agoDo you think DHH is out of touch too?
- panzerboy 2mo agoI don't hate the guy (I don't know him personally so I cannot hate him), I just disagree with his opinions and I personally don't want to use anything that he makes or endorses. Easy as that. I know that there are other people contributing to Rails, and that's their choice. Other people stopped contributing once DHH showed his true nature.
- 0x4d4c 2mo agoI remember, when I used it for the very first time in commercial project. Client briefed me in the afternoon, the next day, before the noon, she got ugly app, but with fully working admin backend. She was sold. But I also remember, that some non-standard requirements were really difficult to implement or get around. Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support. Since them I'm on Rails.
- thraxil 2mo ago> Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support. How long ago was this? I feel like unicode has kind of been a solved problem in Python since python3 came out. In the python2 days it was, indeed, miserable.
- matsemann 2mo agoI really like the ORM and the migrations, but some parts I really dislike. They're maybe not Django's fault, but how it's used most places: * Models being passed around everywhere, queries happening everywhere. I prefer having a dedicated service/selector layer to do those things. Then convert to pydantic objects or something that's passed around further. * Corollary, but adding stuff to querymanagers quickly goes out of control. Sure, it's nice to reuse MyModel.objects.annotate_something().annotate_something_else().... but it can quickly become unwieldy and even wrong with exploding joins. And it promotes doing queries in places they shouldn't happen. * It's veeery easy to make spaghetti. Very easy to query across boundaries, into other apps. Fine on smaller projects, but in huge codebases it quickly makes things hard to control, especially since it's all stringly typed. If I want to modify my model, it's hard to know if someone else have done a query where they did theirmodel__some_relation__another_relation__mymodel__some_field. Blows up in production. * For some reason it's very common in Django/python projects to have types.py, models.py, selectors.py, views.py, services.py etc. And then each of those end up with lots of unrelated things in the same python file, while related stuff is spread over many files. Django apps doesn't really solve this cleanly either.
- DarkNova6 2mo agoI seriously don't get why Django ORM is using the Active Record pattern. This is such a stupid footgun that trivially causes horrible performance and BEGS you to cause n+1 problems. Never in my life did I have a problem with lazy loading causing unbearable performance until I joined a Python Django team. I really tried to find sympathy for the "dynamically typed" folks (please spare me saying Python is technically statically typed), but coming from writing apps and backends in Java, Swift, C#, Objective-C and PHP, Python with Django was the worst experience bar none. I worked on the project for 10 months, could at least refactor the project to something semi-sane where obvious mistakes (which would not be possible in other languages) could not happen. Then along comes a "good Python dev" and threw it all out of the window and start doing SQL queries all over the place (typically 3-6 lines long), remove the domain objects and cause the same problems I started with to begin with. But his approach was saying that the other developers were "not good enough". Yeah, have fun with schema changes going forward. Good riddance.
- songhonglei1985 2mo ago[flagged]
- Klonoar 2mo agoI feel sufficiently old after having read South in this article. Good god what a throwback. Django is hands down one of my favorite frameworks ever created, and the only one I still reach for in some contexts. For a lot of projects I use it to drive database migrations, and stand up an easy admin portal for others to use - then anything else is driven by an API layer written in (e.g) Rust. I haven't had to care about Django's performance in years but still get to reap some of the benefits.
- zelphirkalt 2mo agoHow do your API calls get into the Django app(s)? Do you define the API as well on the Django side (duplicating the API)? Or is there some tool that translates the Rust API calls for Django efficiently?
- tclancy 2mo agoGoing to guess they explicitly map the database tables (and do it all as read-only perhaps) to allow admins to view and report on data from the API.
- Klonoar 2mo agoIn practice, I've found you never want to be duplicating full models on the API side - you're only querying specific fields so you end up with custom/ad-hoc structs instead of ORM objects like you'd have in Django. Just read from the database and treat Django as a DB builder/migrator/inspector.
- tinodb 2mo ago> 3. Actions It is somewhat explained as a convention or something built-in, but I can't find much about it elsewhere. Is it the author's own convention or am I missing something?
- jbarham 2mo agoYeah, I wondered about that too as normally Django "actions" mean admin actions (https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/ https://docs.djangoproject.com/en/dev/ref/contrib/admin/acti...). But in this case it seems the blog post is referring to this pattern: https://www.jmduke.com/posts/in-praise-of-actions.html https://www.jmduke.com/posts/in-praise-of-actions.html (same author)
- harrouet 2mo agoAh the old debate about function-based views and class-based views. I totally understand why the OP would use only FBV, however when writing REST APIs you will want CBV to reuse base classes such as ListView.
- alexbelyanin 2mo ago[flagged]
- whateverboat 2mo agoI really like django, but since being involved in it from early days, whenever someone now praises Django, I am reminded of this talk: https://www.youtube.com/watch?v=i6Fr65PFqfk https://www.youtube.com/watch?v=i6Fr65PFqfk DjangoCon 2008 Keynote: Cal Henderson
- saaspirant 2mo agoDjango for Startup Founders: A better software architecture for SaaS startups and consumer apps: https://web.archive.org/web/20210624040717/https://alexkrupp.typepad.com/sensemaking/2021/06/django-for-startup-founders-a-better-software-architecture-for-saas-startups-and-consumer-apps.html https://web.archive.org/web/20210624040717/https://alexkrupp... This article is very useful. I use DRF but not serializers and write validations by hand because it is too abstract for me. My views just call services and return the result.
- giancarlostoro 2mo agoHave you seen django-bolt? Might interest you, your setup sounds like it would benefit from it. https://github.com/dj-bolt/django-bolt https://github.com/dj-bolt/django-bolt
- sinpif 2mo agoMigration churn adds up over the years but overall it's nice and site-specific code is usually so small it fits very nice in LLM context.. easy to work with.
- zelphirkalt 2mo agoWhat I like about Django are the following things: (1) It seems whenever I need to adjust how something works, there is some field or method, that I can override, or meta class attribute to set. None of it seems too inflexible. Overriding or changing how things work somehow always feels like someone already thought of this special case I have, and has made it mostly easy to do. Often when I have such a customization case, I have this feeling: "AH, that's how it is supposed to be done in Django." instead of having a feeling of having to fight the framework. (2) Just being able to use a normal template engine (I always use Jinja2 with Django), instead of having some wannabe HTML lookalike thing. I don't want to have to encode control flow inside HTML attributes. Why then make it look like HTML in the first place, if some JS framework then picks it apart? It is unnecessarily cumbersome to do that, and Django doesn't engage in that. (3) The ORM is good, and flexible. Some traps for many queries though. But also escape hatches, which let one write ORM calls, that will translate to efficient SQL in most cases. (4) Django makes it so easy (comparatively) to write a phenomenal searching and ranking function for ones database entities. Check for example the code of my blog [1]. One page of code, very adjustable to ones needs. (5) Handling of routes is easy. `reverse` is very useful to not have to hardcode routes. (6) Even when using third-party things like django-allauth it is easy to override templates, without having to modify the dependency itself. With foresight there exists a way to put ones own templates in a place that is discovered before the other package's templates. (7) Adjustable django admin. I often have some "Tags" in my models, which are many-to-many. For example Posts-TagAssignment-Tag, where TagAssignment is a "throught table". In Django admin one can have a nice little modification [2] to make a very usable widget appear for assigning tags. In short: It very much gets out of ones way. [1]: https://codeberg.org/ZelphirKaltstahl/django-website/src/commit/71ae8fc27c935962087ae67918c382b94c905999/website/app/utils/search.py https://codeberg.org/ZelphirKaltstahl/django-website/src/com... [2]: https://codeberg.org/ZelphirKaltstahl/django-website/src/commit/71ae8fc27c935962087ae67918c382b94c905999/website/app/admin.py#L31-L39 https://codeberg.org/ZelphirKaltstahl/django-website/src/com...
- phn 2mo agoThe only part I don't really agree with, is the avoidance of app separation and signals. It's one of the cleanest ways to decouple your modules and keep some level of sanity in a medium-sized codebase. It comes down to deciding what parts really need to depend on others and be very explicit about that. I generally end up with a few core apps with the main data objects that a lot of other "parallel" ones depend on, a bit "star shaped". And then a few "aggregator" apps that cover functionality that needs to work across multiple of these domains. I see it all as an extension of how you think about your data model.
- tclancy 2mo agoI always wonder about signals. I found them incredibly attractive from a code cleanliness standpoint, but every team I’ve joined avoided them either because they got burnt by them or because of superstition from blog posts by people who got burnt by them. It may be a cognitive load thing, that in smaller codebases it’s easy enough to remember “these three things fire a signal when saved”, but bites you in the ass when trying to make a quick patch for a bug in production late in the day because a customer called up screaming.
- phn 2mo agoI do understand the "invisible side effects" side. I do try to be conservative in what I do in signal listeners. I do what I must in the atomic context, and trigger celery tasks for everything else.
- stana 2mo agoThere are a lot of things to like about Django. Remember being blown away when I discovered Django Content Types[1]. Basically generic foreign keys to any model type. [1]: https://docs.djangoproject.com/en/6.0/ref/contrib/contenttypes/ https://docs.djangoproject.com/en/6.0/ref/contrib/contenttyp...
- thraxil 2mo agoAs someone who's used Django since 0.97 and loves it, Content Types are one of those features that I recommend avoiding. It looks amazing at first but you will eventually regret it.
- fmind-dev 2mo agoI'd love Django, if they had a better async story ... I used it for a recent project. While the framework is overall amazing, I had to switch to Go for better performance and easier async support.
- giancarlostoro 2mo agoDjango-Bolt is one of the interesting projects I found recently that helps boost RPS for Django by handling HTTP requests via Rust. https://github.com/dj-bolt/django-bolt https://github.com/dj-bolt/django-bolt
- dzonga 2mo agoDjango while opinionated is very flexible too. unlike Rails. that means you can mold it to fit your use case easily - don't like the ORM - you can plug SQLalchemy and use a different 'architecture'. + you can use multiple different databases if you think that's the right path. in Django there's no 'the rails way' - you choose your own path. Django-admin by itself saves so much work specially If you're doing B2B stuff & you gotta onboard users. I guess Django is not the best thing, but not the worst thing either. so a perfect middle ground.
- dzonga 2mo agoalso Rails largely sits in a world where most apps are CRUD based or everything is CRUD e.g [0] - which for that purpose Rails has nice ergonomics. whereas Django though it also provides almost similar abstractions in terms of CRUD - it doesn't assume your app will only do CRUD stuff - hence the flexibility e.g there's many apps where you only have a handful of endpoints that are user accessible maybe at most 15, then of course management of users via Django-admin but everything else is non CRUD e.g calling other systems [0]: https://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/ https://jeromedalbert.com/how-dhh-organizes-his-rails-contro...
- gls2ro 2mo agoRails is flexible too. Everything that you mentioned here can also have the sample flexibility in Rails: You can use Arel and skip AR, you can use Plex instead of HTML and so on. The Rails Way is a response to people changing too much Rails and making it super custom. In the last 4 years alone I touched codebases ranging from Rails Way to Rails and everything dry.rb, to Rails and Grape and Sorbet, to Rails and service objects everywhere and a lot more combinations.
- explorigin 2mo agoDjango makes simple things easy and complex things hard. Django breaks the zen of Python with much "magic". I like DjangoORM but prefer FastAPI for the webby bits.
- dzonga 2mo agolook at litestar [0] - if you want something more coherent than fast api [0]: https://litestar.dev https://litestar.dev
- daft_pink 2mo agoI like Django too, but find it difficult to deploy. While frontend frameworks can be easily deployed via a cdn and some microservice backends on something like cloudflare or aws, I find Django very difficult to deploy because it needs an underlying server running 24/7.