Hacker News Reader

Comment by fidotron | Hacker News Reader

Are people choosing Django for new projects much these days?

Absolutely. For what it does, Django is pretty much the best full stack Python web framework there is. It's also a great way to rapidly develop (just sticking to synchronous, which Django is best at).

One can then later consider spinning certain logic off into a separate service (e.g. in Golang), if speed is a concern with Python.

I’m not sure there’s a better full stack platform in any other language really?

Yeah, you are right. Maybe Ruby on Rails is up there? But I don't really know Ruby, and I never got into that.

Someone just sent me a job opening for an engineer to work on a startup’s PHP backend and Python “everything else”. Absolutely insane.

Where? Two of the best languages. Sign me up.

I chose Django + htmx and a small amount of Alpine.js for a full-stack software project that is currently being launched. I had zero professional experience with Django (or Python really) before starting. I was able to develop the entire application on my own, in my spare time, and had time left over to also handle infrastructure and devops myself.

I prefer Python and it's web frameworks over Typescript/React because there is a lot more stability and lot less "framework-of-the-week"-itis to contend with. It's much easier to reason about Django code than any React project I've worked on professionally. IMO when you don't have a firehose of money aimed at you, then Python is the way to go

Yes, you can do the whole web app (or web site if you will) like that without any complicated dependencies. This will be great if you touch the project only now and again e.g. the typical side project that you want to still work in the year 2030 without major changes.

Yet the approach also scales up to enterprise grade project, leveraging DRF, Django-cotton and so on (and htmx).

Yes. Still one of the best batteries included web frameworks for creating anything that's more of a website (e.g. E-Commerce) than a web app (e.g. Photoshop). No, you don't need NextJs and friends for everything ;)

What would be the same that is for a statically typed language?

Play framework with Java or Scala is similar.

Is Groovy/Grails still popular? I also remember Groovy++ but I believe its features were incorporated into Groovy. But maybe these are already present in modern Java?

LoL nah

Not answering your question, but MyPy might be a compromise.

I just rolled a backend using FastAPI and SQLAlchemy and it made me miss Django.

Too much other stuff going on in this app to incorporate Django, but it's still way ahead of the curve compared to bringing together independent micro frameworks.

Out of naive curiosity of considering your first stack vs. Django: What makes Django so way ahead of the curve?

The ORM is so so so much better designed that SQLAlchemy v2. Performing queries, joins, executing in transactions all feels clean and concise. The latter feels dated and I find it hard to believe there's not a widely accepted replacement yet.

In terms of views, route configuration and Django's class-based views are sorely missed when using FastAPI. The dependency pattern is janky and if you follow the recommended pattern of defining your routes in decorators it's not obvious where your URL structure is even coming from.

Hmmm any specific syntax examples of pain points in Sqlalchemy? Having used both, they feel similar to me so I’d love your view!

`from sqlalchemy.orm import and_`

`options(selectinload(...))`

to name a couple goofy ones

Sqlalchemy definitely is more verbose.

We could probably do with a "SQLAlchemy for Django users" article. SQLAlchemy is much more powerful and flexible than Django. After using SQLAlchemy it's hard to even consider an active record style ORM like Django an ORM at all. SQLAlchemy can truly map relational data onto objects and uses the unit of work pattern to coordinate updates. Django just feels like writing raw SQL but in nicer Python syntax. The details of relational models leak directly into the business logic and there isn't really much you can do about it. In short, SQLAlchemy is a different beast. If all you need is Django then you're probably only doing CRUD and you should just use Django.

The problem with sqla is that you need to deal with the session object all the time. Doing it right is not that easy, and never as concise.

SQLA is cleaner and more powerful, but when you just need CRUD, django wins.

Django definitely wins at CRUD because that's what it is. It calls itself a web framework but really it's a web-crud-app framework. Flask and Pyramid are web frameworks.

Dealing with the session object seems a small price to pay for the flexibility in architecture that it gets you.

It's brave trying FastAPI if you haven't tried it before. Going async is going to be quite different and you need to be more careful when designing your API. Most people will never need it.

This is why most folks just needing a plain Python API without anything else, they usually go for Flask, which is vastly simpler. For a more complete web app or site, I would recommend Django.

django-ninja will give you a fastapi like experience without the hassle

All the time.

1. Very easy to find developers for. Python developers are everywhere, and even if they haven't worked with Django, it's incredibly easy to learn.

2. Simple stuff is ridiculously fast, thanks to the excellent ORM and (to my knowledge fairly unique) admin.

3. It changes surprisingly little over time, pretty easy to maintain.

My only criticism is that die-hard django devs constantly brush aside the admin and can't stop telling people not to use it. I think it's a huge mistake.

It's extremely well-designed and extensible, there is no reason to reinvent the wheel when so much time and effort has been put into it.

They will complain of things like "eventually you will have to start over with a custom solution anyway"... but whatever gripes they have, could just be put into improving the admin to make it better at whatever they're worried about.

Personally I've not run into something I couldn't make work in the admin without having to start over. My own usecases have been CRUD for backoffice users/management and I've had great success with that at several different companies over the last ~15 years.

People will say "it's only for admins you trust" yet it has very extensive permissions and form/model validation systems heavily used in the admin and elsewhere, and they are easily extensible.

I use the heck out of the admin. I wouldn't say I'm super experienced with Django, but my solution to users being overwhelmed by doing things there is to build a bit of extra UI just for the stuff they need to do, more Rails style. Meaning: I don't go into fighting too much with the admin when what it can do out of the box is not feasible for some. But even if the admin ends up being used only by devs and some trained folks, I think it has amazing utility.

Absolutely!

I've been saying the same thing for decades (checks calendar - almost literally!)

The admin is at least 75% of why I choose Django over another framework.

LLMs are experts at Django, as there's 20 years of training data on it as well as just being written in the world's most popular language. LLMs can pump out full featured Django sites like anything.

I don't know why anyone would use any other framework.

We've used (and continue to use) Django for bespoke applications for a decade and a half now. It continues to be the most well-supported, well-governed, well-documented, batteries-included, extensible web framework of all the ones we've tried. Finding developers with experience using it (or upskilling them) is easy. As a choice of web technology, it's one of those that we've never regretted investing in.

For a complete solution requiring many traditional high-level components like templating, forms, etc, then yes, clearly Django. But for something looking more like a REST API, with auto-generated documentation, I would nowadays seriously consider FastAPI, which, when used with its typed Pydantic integration, provides a very powerful solution with very little code.

Django Ninja?

Works great, I've been using it in production for a few years. DRF was one of my least favorite bits of the Django world and Ninja has been an excellent alternative.

I still love Django for greenfield projects because it eliminates many decision points that take time and consideration but don't really add value to a pre-launch product.

Not in my org. Though we did choose it for _one_ new project recently, mostly because we re-used some code from another Django project we had, and we wanted to lean on some readily available functionality from jazzband libs.

We have a few FastAPI services, but are mostly moving away from Python for projects > 1kloc.

What are you moving towards? Node/TS? Golang?

next.js + TS for front ends, C# for pure back-end services. Golang was a close second but we have some team experience with C# and like it's lack of ecosystem fragmentation, as that was another gripe we had with Python. The Dapper "micro-orm" is also refreshing after years of struggling to make Django's ORM do the right thing.

Why moving away from Python at that threshold?

The threshold is arbitrary, and likely higher in reality. But we found that we want something with more sound type checking and mypy has lots of rough edges. The Python ecosystem has a lot of catching up to do here.

You bet. Still the easiest (IMO) for websites, perhaps of any language.

It easy but having separate app spaces by default instead of just one like Laravel makes it slightly harder for just a website case.

Concur. The multiple app paradigm doesn't fit any site I've built in Django. I make one called main.

Idk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc.

It makes it easy to compartmentalize the business logic in terms of module imports.

This sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app.

Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.

Yeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled.

For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.

Have you tried the monolithic composite approach instead?

I haven't heard of this, and my searches are failing for an exact hit. Do you have a link or can you give a brief explanation please?

It is quite vanguard technology.

A composite is a structure of many pieces that work together.

Thus, a composite monolith is this arrangement of components in a way that they work together as a monolith. Separate modules, but working together as a single thing.

That's the same as what people are calling a modular monolith, no? The key thing with composition is the bits sit next to each other, there's no inheritance or dependencies between the components. In my idea you'd have a bunch of "pure service" apps that are focused on individual areas of the business or processes. Then you'd have one or more UI apps (either user-facing HTML or APIs) that compose those services to do what needs to be done, e.g. a "create order" endpoint might compose the create order service from fulfilment and the send notification service from comms to put an order on the fulfilment backlog and send notifications. Is this what you had in mind?

That sounds to me like good old "replaceable parts oriented programming".

Replaceable parts can have inheritance, but often what is good about them is the composability. Each part can connect to each other in different ways. We call these boundaries "connectors".

It's quite a fascinating tech.

You can use a single app, and it is probably the best way to go for the majority of projects - definitely the case for simple ones.

If it's the kind of project that is going to run against one PostgreSQL database then I'd probably start a new project with Django just for its database migration support. That doesn't mean everything in the project has to be Django.

Is pretty equivalent to alembic autogenerate, no?

Didn’t Meta build Threads.com on Django?

(Since Threads was based on the IG tech stack, and IG is a modified Django stack)

That's sort of like asking if people choose Python for new projects these days.

just did, and I really like it.

yes

Just like Python itself, unfortunately yes.

Would love to hear an honest discussion of why Django and/or Python is a bad solution for any given problem. Is it because they are old technologies? Do they lack support for something in particular? Are they too expressive/not expressive enough?

Because assembly language or if you must go higher level, fortran exist and all the 10x coding intergalactic scalers say everything else is bad.

(Love django in spite of Python here)

- Imports are a mess - No control of mutation in function signatures, and in general it's still a surprise when things mutate - Slow - Types and enums have room for improvement

You just need to work around those and get used to it. Then you can build nice Python projects that keep growing - but Django really helps you do that. Python however is always going to be "10-100x" slower than something like an API written in Go, Rust and so on. That's fine in most cases.

Reply on news.ycombinator.com