What I love about Django

Posted by j4mie 23 hours ago

Counter131Comment110OpenOriginal

Comments

Comment by matsemann 22 hours ago

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

Comment by adsharma 8 hours ago

If you must use Django, use it through an abstraction layer like this:

https://adsharma.github.io/django-fquery/

Your models can be plain old python data classes, declaratively mapped to Django primitives.

Comment by Oxodao 21 hours ago

I despise django-orm, doctrine is so much better. Like, who thought that using named arguments to do stuff was a proper way ??? `.filter(created_at__gte=XXXXX)` why? The rest of the framework is great but the ORM is definetly its weakest point.

Comment by zelphirkalt 21 hours ago

I find those double underscore kwargs weird too, and would prefer to simply pass a lambda instead. What is your idea, what would you suggest?

Comment by Oxodao 19 hours ago

In Doctrine the query builder can take objects that describe what you want to do [1], not the best but still way better to read and understand. There's also the DQL which is an SQL-like language that's pretty well integrated in phpstorm and is quite close to SQL [2]

[1] https://www.doctrine-project.org/projects/doctrine-collectio... (for collections but you can use them for queries too)

[2] https://www.doctrine-project.org/projects/doctrine-orm/en/3.... / https://www.doctrine-project.org/projects/doctrine-orm/en/3....

Comment by ErroneousBosh 19 hours ago

The double underscore kwargs are a bit odd, I agree, but once you know about them they're okay.

And, rather like the petrol engine, it turns out while it sucks, everything else is massively worse in some vitally important way.

Comment by JodieBenitez 21 hours ago

Having used Doctrine, hard disagree. Never again.

Comment by Oxodao 19 hours ago

I've used django-orm at my previous job for 2 years and I never have liked it, the syntax is just not nice to read. I used Doctrine for 5 years (2 before last job and 3 since I got my current one) and it's just night and day. Declaring entity is just way cleaner, you can just skim through an EntityRepository / query and understand easily what it does

Comment by DarkNova6 21 hours ago

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

Comment by senko 21 hours ago

Yes, if you attempt to use Django like you'd use your typical Java, Swift, C#, or Objective-C framework, you're not going to have a good time.

I've seen the horrors Java devs start doing on a Python project when trying to "fix" things, where by "fix" they mean use patterns they had to in previous gigs.

It's a different world.

Comment by DarkNova6 21 hours ago

Having basic defensive programming, some simple classes instead of dicts everywhere and avoiding n+1 is a "different world"?

Comment by senko 20 hours ago

Just asking these questions underscores lack of understanding how things are usually done in Django and Python in general.

In Django you'd typically use simple classes (models or forms, or even dataclasses nowadays) more than dicts everywhere; n+1 is trivially avoidable (as another sibling comment points out, and you also have multiple packages that autodetect such cases if you've missed them).

Python in general has a more "consenting adults" than "defensive programming" attitude (which doesn't mean exessive coupling or spaghetti, but the approach is different from the Java or C# mindset).

There's no one THE correct style of programming.

Comment by matsemann 1 hour ago

> Just asking these questions underscores lack of understanding how things are usually done in Django and Python in general.

No, it doesn't. It's fair to criticize the consequences of this approach to coding.

Comment by JodieBenitez 21 hours ago

> BEGS you to cause n+1 problems

select_related, prefetch_related. n+1 problems be gone.

Comment by DarkNova6 21 hours ago

You misunderstand. And that is exactly the problem.

We did do that and that's why our queries ended up being several lines long. But if you missed just one model? You openly walk a knife again.

It's a mess and it only gets longer and longer. I ended the project with having some proper aggregates, only for that to be thrown out of the window by the guy after me.

Comment by infamia 12 hours ago

If you want to just prefetch everything throughout a project or just on a per-Queryset basis, all that is coming in the next release of Django.

https://docs.djangoproject.com/en/dev/releases/6.1/#model-fi...

That's the great thing about Django, it's been around so long and the quality bar is so high that eventually all the major rough edges get sanded away usually in a really well considered manner.

Comment by JodieBenitez 19 hours ago

> our queries ended up being several lines long

Which is... perfectly normal for non-trivial needs.

> I ended the project with having some proper aggregates, only for that to be thrown out of the window by the guy after me.

How is that a Django problem though ? Sounds like a skill issue on your successor.

I get what you say, there's plenty of debates about ActiveRecord vs. AnythingElse, but in the end this one has its use and obviously has served many of us just fine. Different strokes... you know the drill.

Comment by lozenge 14 hours ago

I think there's an argument for throwing AttributeError instead of silently going to N+1 behaviour.

Comment by JodieBenitez 3 hours ago

See sibling comment about fetch modes in coming 6.1 (https://docs.djangoproject.com/en/dev/topics/db/fetch-modes/), you can have a FieldFetchBlocked.

Comment by ranger_danger 16 hours ago

It still selects all fields by default. Very often I have to use defer() or only() to get rid of expensive columns like blob/text that are rarely used and greatly hurt performance when grabbing them.

Then it got to where I had to make a reflective function that I use like Model.objects.defer(*all_fields_except(Model, ['field1', 'field2'])), and then add another all_fields_except() for every select_related and prefetch_related.

Even save() by default re-writes every single field. You have to use save(update_fields=['field1']) instead.

Comment by ErroneousBosh 19 hours ago

What would you have used instead?

Comment by kitsune_ 21 hours ago

The ORM is really not good in my opinion because it is ActiveRecord'ish and has all its downsides. I wouldn't use Django for any moderately complex domain. But even with simpler CRUD style apps I don't really see the point in it.

Comment by rtpg 19 hours ago

The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want.

It can take a while to wrap your head around what fields get used in aggregates and the like, but when working with big models with like 65 fields and juggling a bunch of stuff, not having to futz with serialization/deserialization and "just" expressing your problem in the dumb way is nice.

I want to say this all comes back to bite you in the end but honestly it's more just having wide tables that comes to bite you. A service layer wouldn't really save you. Meanwhile you save yourself a bunch of tedium in the mean time

Comment by ErroneousBosh 19 hours ago

> The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want.

And if you can't make the ORM make the SQL query you want, you can just write it as a SQL query, like this godawful monstrosity:

      x = Site.objects.raw("select id, name, lat, lon, 111.045*degrees(acos(cos( \
        radians(latpoint))*cos(radians(lat)) \
        *cos(radians(lngpoint)-radians(lon)) \
        +sin(radians(latpoint))*sin(radians(lat)))) \
        as distance from sites_site join \
        (select %s as latpoint, %s as lngpoint) as p on 1=1 \
        order by distance limit 5", [float(lat), float(lon)])
... which calculates the Haversine distance from where you are now to the five nearest points.

I am in roughly equal parts proud of and horrified by this creation.

Comment by rtpg 7 hours ago

Site.objects.annotate( distance=Degrees(ACos(Cos(.....))), latpoint=float(lat), lngpoint=float(lon), ).order_by("distance")[:5]

for function calls, look at django.db.models.functions, you can find a bunch of stuff in there or create custom ones super easily (like "two lines of codes" easily)

I mean you have a thing that works in theory so it's a bit of navel gazing, though.

Comment by ranger_danger 16 hours ago

I'm not seeing anything that can't be done here without using raw() though?

Comment by ErroneousBosh 13 hours ago

Yeah I'm not clever enough to do that.

How would you have approached it?

Comment by braiamp 20 hours ago

What would you have done Instagram from instead of Django?

Comment by nesarkvechnep 20 hours ago

Elixir and Phoenix.

Comment by physicsguy 20 hours ago

You'd have written Instagram which was released in 2010 in Elixir which wasn't released to the public til 2012?

Comment by pmontra 19 hours ago

So Rails or some PHP framework. It was slightly too early to go full Node. Django was a little unusual too among the developers I knew. Java was still a thing but more for finance related projects.

Comment by FranOntanaya 19 hours ago

Well 2010 PHP and the frameworks at the time were still going through the 5.x desert journey, and the prospects weren't entirely clear with the cancellation of PHP 6, so you wouldn't fault your 2010 self for not trying to push some Drupal/Joomla/Magento to that scale.

Kinda took until Facebook showing off Hacklang in 2014 for people to believe in getting more canonical programming features into PHP and make it more performant. So it would have been a good decision if one could predict 10 years into the future, but nobody can.

Comment by dofm 18 hours ago

Rails was fully into growing pains and maintainability crises (some large rails codebases took years to migrate) and PHP was in transition; some good things by then but it was not what it is now.

Comment by thunky 18 hours ago

All of the gripes OP has with Django are arguably worse in Rails.

Comment by worldthruword 16 hours ago

I think Threads could have been done in Elixir.

Comment by ErroneousBosh 19 hours ago

Why would you have chosen these? What are the advantages?

Comment by sgt 19 hours ago

I mean if you're doing it this way, you're really not applying best practices as a developer (never mind as a Django developer).

> Models being passed around everywhere, queries happening everywhere.

No, as a developer you still need to be 100% aware of the underlying queries and potential performance issues. No excuse for N+1 problems. ORM is not an excuse to be lazy, but I admit it will probably catch quite a few developers.

Those same developers would probably make a mess out of any other framework or technology though.

Comment by strogonoff 18 hours ago

Django allowing queries to be anywhere is more or less in line with Python’s overarching “we’re all consenting adults here” ethos. There’s probably one correct way to do it, but if you want to shoot yourself in the foot then here’s your gun.

It definitely takes a bit of discipline. The key layers are somewhat easy to manage—middleware, context processors, views, template tags—but I’ve seen some hairy lasagne further obscuring where the queries happen on top of that. A well-documented abstraction can be useful, but if it is possible to keep it simple and obvious then that’s the way to go.

(Third-party dependencies can further complicate things, but at least you can expect a library using ORM to be in the installed apps list.)

Comment by sgt 14 hours ago

I'm semi-assuming we're talking about professionals who'd excel with their products in any framework and language.

It's highly productive if you do it right.

Comment by JodieBenitez 22 hours ago

Most loved feature, for me: No dramatic changes, just sane and careful evolution.

Comment by almost 20 hours ago

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

Comment by JodieBenitez 17 hours ago

I have twenty years projects, no breakage when upgrading major versions. What a treat in the web app world !

Comment by dzonga 19 hours ago

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

Comment by gls2ro 13 hours ago

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

Comment by dzonga 16 hours ago

also 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-contro...

Comment by saaspirant 21 hours ago

Django for Startup Founders: A better software architecture for SaaS startups and consumer apps: 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.

Comment by giancarlostoro 19 hours ago

Have you seen django-bolt? Might interest you, your setup sounds like it would benefit from it.

https://github.com/dj-bolt/django-bolt

Comment by stuaxo 22 hours ago

Nice.

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.

Comment by cudder 14 hours ago

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

Comment by ErroneousBosh 19 hours ago

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

Comment by Klonoar 22 hours ago

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

Comment by zelphirkalt 20 hours ago

How 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?

Comment by Klonoar 19 hours ago

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

Comment by tclancy 19 hours ago

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

Comment by 0x4d4c 22 hours ago

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

Comment by thraxil 21 hours 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.

Comment by tclancy 19 hours ago

Pylons was a long time ago. Definitely Python 2. The era just after (?) or maybe same as TurboGears and CherryPy.

Comment by 0x4d4c 18 hours ago

Yup, Python 2. I don't recall the exact stack, pretty sure I have it somewhere though. Circa 2009/2010

Comment by whateverboat 21 hours ago

I 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

DjangoCon 2008 Keynote: Cal Henderson

Comment by tclancy 19 hours ago

I too often think of things as frozen in time two decades ago.

Comment by vb-8448 21 hours ago

what's wrong nowadays w/ django?

Comment by tonyedgecombe 22 hours ago

I haven’t used Django for a long time but when I did I found it one of the best documented projects out there.

Comment by zelphirkalt 20 hours ago

Sometimes I find the examples lacking a bit. For example: 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.

Comment by phn 21 hours ago

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

Comment by tclancy 19 hours ago

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

Comment by phn 18 hours ago

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

Comment by fmind-dev 20 hours ago

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

Comment by giancarlostoro 19 hours ago

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

Comment by harrouet 21 hours ago

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

Comment by daft_pink 14 hours ago

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

Comment by zelphirkalt 21 hours ago

What 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/com...

[2]: https://codeberg.org/ZelphirKaltstahl/django-website/src/com...

Comment by tinodb 21 hours 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?

Comment by jbarham 21 hours ago

Yeah, I wondered about that too as normally Django "actions" mean 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 (same author)

Comment by stana 20 hours ago

There 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/contenttyp...

Comment by thraxil 19 hours ago

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

Comment by cryo32 22 hours ago

My favourite part of Django is it's not Rails :)

Comment by 0x4d4c 22 hours ago

Why is that? What's wrong with Rails?

Comment by panzerboy 22 hours ago

It's made by DHH.

Comment by cryo32 19 hours ago

Actually I didn't know he was a prick. I'm not sure he is either - I haven't checked. I just really really don't like Ruby or Rails.

Ruby is like someone mashed up python and perl whilst on cocaine one day.

Comment by 0x4d4c 22 hours ago

And great bunch of other, awesome people.

I can take an argument of not buying a Tesla in order to avoid supporting Elons financial empire, but not using Rails because DHH made it is really hard to comprehend.

Comment by owebmaster 21 hours ago

Why is it hard? Elon got all the power he wanted. Not giving DHH the same free passes Elon got is a very reasonable take.

Comment by 0x4d4c 18 hours ago

And boycotting open source project is the way to go?

Comment by brazukadev 18 hours ago

why not? there are so many available.

Comment by Nextgrid 21 hours ago

Some people are just looking to be offended. You don’t have to read or agree with his drivel to use his software.

(Do you also check out the blogs/social media of every dev involved in every library you use?)

Comment by BoumTAC 22 hours ago

The DHH hate is absolutely crazy on HN.

I don't understand how people can be so out of touch.

Comment by _old_dude_ 21 hours ago

It's not hate, it's not wanted to be associated with:

see https://victorwynne.com/dhh/

Comment by rob 20 hours ago

I need to go look up the CEO of my refrigerator, dishwasher, couch, car, cell phone, TV, shirt and jeans, and oat milk to see if they said anything I disagree with on social media so I can boycott them.

Comment by jasoncartwright 19 hours ago

Do they have prominent blogs that are good to read to keep up in the industry you work in?

Comment by mystifyingpoi 19 hours ago

Unironically, AI could automate the boycott.

Comment by zbentley 19 hours ago

I mean, that might not be the worst thing?

Like, if you have something you regularly spend a lot of money on, it might be worth spending 2min on the Wikipedia article about it’s manufacturer to verify that it’s not made by child slaves or someone who sends all their profits to the KKK or whatever.

Doing that seems like basic prudence for an interconnected world, and a far cry from like … digging around Reddit threads looking for reasons to be outraged.

I have no opinion on DHH. I do think it’s good, actually, that lots of people are incorporating politics into their product use/purchase choices these days. Those decisions always had political consequences, so it’s good that people are now considering that.

Some people definitely have rubrics for making those decisions that I think are stupid, and some people do it dishonestly (e.g. performative public outrage over a random OSS contributor’s transphobic tweet while spending money on Harry Potter shit). But the fact that people are increasingly considering the social context of product use is still good, dumbasses would find other ways to be dumb regardless.

Comment by earthnail 19 hours ago

I read the original post DHH links to. I don’t think it warrants the kind of hate he gets.

DHH has always been very outspoken in his opinions. That’s why he bashed Heroku so badly when he introduced Kamal. It’s what makes Rails such a clear minded framework.

In his political blog, he’s raising an issue that’s occupying all of western politics. And he’s very aggressive about it - just how he was very aggressive when he said “stop paying ridiculous amounts for stupid managed clouds”.

Instead of arguing where he’s wrong, people - including the blog post you cite - write “that’s hateful and racist” and refuse to engage beyond that. That is the very shut-up mentality he writes about.

It frustrates me so much to see this here on HN. HN is supposed to be a place to discuss, not blame others. This resistance to engage in a constructive discussion, even if the person with the differing opinion isn’t articulating them well, or has errors in their reasoning that upset you, is super harmful. It’s what gives all these far right parties their rise to power. They occupy the subjects then that their voters have on their mind, because everyone else doesn’t dare to talk about it.

We could have constructive discussions around such topics. But if we don’t, all that happens is that those who don’t feel heard - in this case rightfully so, because we chose not to hear them - will develop more and more extreme ideas.

Comment by blactuary 17 hours ago

There is no "constructive discussion" to have with racists

Comment by brazukadev 18 hours ago

> Instead of arguing where he’s wrong, people - including the blog post you cite - write “that’s hateful and racist” and refuse to engage beyond that. That is the very shut-up mentality he writes about.

What a weird statement. He has a platform, people that think his content is hateful and racist don't have a platform. He writes about kicking out normal people living their lives from places that he is not even from. Antagonizing people in position of power with this kind of mentality is what every sane person should do.

Comment by sylario 17 hours ago

I did not really knew why DHH was controversial until a few month ago. He was heavily promoting the en translation of an old super far right french book. It is from the 70's and it is absurdly far right when you look up who wrote it and who promoted it in France at that time.

He is probably at a KKK level of racism.

Comment by panzerboy 21 hours ago

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

Comment by 0x4d4c 18 hours ago

I presume, that you're not shopping anything on shopify?

Comment by panzerboy 18 hours ago

Good question, I don't know. I usually buy stuff online from a few big websites that are specific to my country.

Comment by owebmaster 21 hours ago

Do you think DHH is out of touch too?

Comment by explorigin 18 hours ago

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

Comment by dzonga 17 hours ago

look at litestar [0] - if you want something more coherent than fast api

[0]: https://litestar.dev

Comment by sinpif 21 hours ago

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

Comment by Maxion 22 hours ago

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

Comment by aitchnyu 22 hours ago

If the DRF stack seamless like Ninja now?

Comment by zelphirkalt 20 hours ago

Ninja is quite a heavyweight in terms of dependencies (depends on Pydantic, which is itself heavyweight). Not everyone wants that in their project.

Comment by angusj1 21 hours ago

[flagged]

Comment by stavros 23 hours ago

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

Comment by weatherlite 22 hours ago

Just wanted to say I saw your last stand up , you're hilarious!

Comment by ustad 21 hours ago

Stavros Halkias! Very funny guy. And also a maker and HN god! Never would have thought.

Comment by stavros 22 hours ago

Thanks, my love of comedy is only surpassed by my love of Django.

Comment by weatherlite 22 hours ago

Naa you lie you love twinkies more than Django

Comment by DoctorDabadedoo 21 hours ago

What a random way to find out a stand up comedian I see now and then share a craft!

Comment by alexbelyanin 21 hours ago

[flagged]

Comment by songhonglei1985 22 hours ago

[flagged]