Hacker News Reader

Comment by tomwphillips | Hacker News Reader

I agree.

Unfortunately every team I’ve worked in hasn’t seen the light and prefers FastAPI/SQLAlchemy/Pydantic (before FastAPI it was Flask).

My theory is that the initial learning curves are different: with FastAPI it’s quick and easy. You barely have to read anything. Django has a steeper learning curve. There’s a lot of reading involved. Type hints aren’t a big thing in Django, but they are in FastAPI, and the average full stack dev seems to like them.

Later on it’s totally different of course. With FastAPI you’re building it all from scratch, and it’ll be much worse than the Django solution.

View on HN

Type hints are were the whole Python ecosystem is going, so using them is more integration at a deeper level than using an integrated framework, which is not relying on them.

SQLAlchemy was historically a much better ORM than Django's. It's layered architecture combined with Alembic does make a difference.

I still agree that using the integrated thing anyway is probably the right way to do it if you are working in a team. I also think Django should just adopt these components and we would not have the discussion in the first place.

> Type hints are were the whole Python ecosystem is going

I see what you’re saying, but a lot of Python users, especially those who have been using it pre-3, would say that this is unfortunate.

> I also think Django should just adopt these components and we would not have the discussion in the first place.

Oof, such a monoculture sounds terrible to me!

I think SQLAlchemy vs Django ORM was a 2007 blogging topic: https://www.b-list.org/weblog/2007/sep/04/orm-wars/

While it is not Django's responsibility to unite the Python ecosystem, continuing to rely on a tool a sizeable share of the community deems inferior to a popular alternative will keep these discussions open and results in the fragmentation OP is talking about.

Now of course it is not Django's responsibility to unite the Python ecosystem in the first place and they can value other factors and arguments as they see fit.

Although this very thread shows that there might have been something to it.

A corollary is the debate itself leads to a waste of effort that multiplies across all users. I use Rails only in anger, but to see literally nobody bike shed on the ORM is pretty amazing. Seems like you use Active Record or you write SQL and either way move on with life.

In ruby, the sequel database toolkit is vastly superior to activerecord, and that is a subject of discussion here and there. The difference is that rails is what most rubyists use at work, unlike in python, where choices are more diverse.

Why would Django move away from an ORM that works, at scale, in millions of deployed websites? They'd have to support both for many years in any case.

> a sizeable share of the community deems inferior

Well, yeah, SQLAlchemy is standalone, you can use it in a lot more situations than Django's ORM in practice, because you're not tied to using it in a Django site. But that doesn't mean it's "better"

I've had this debate with someone recently, as soon as you actually want to use FastAPI/Flask in something that's not an internal only microservice, you end up building Django on top of it anyway ad-hoc way. It also ends up in more of a mess, because while Django doesn't enforce a code structure as such, the default way of doing things is fairly good.

The main thing I miss about Django is always the DB migrations in any case. I found that pattern to be very flexible and very powerful.

Reply on news.ycombinator.com