4 ms·

What's the preferred Python Web Framework these days? I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, F

What's the preferred Python Web Framework these days? I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, Flask, etc. https://litestar.dev https://litestar.dev Or is the preferred web framework still Django?

Maxion 3y ago
I guess it depends entirely on what it is that you are building - there's no one-size-fits-all but for Python for me that is still Django.
whitej125 3y ago
Depends what you're solving for. Building a website that requires user authentication and basic relational DB... I default to Django. But if I'm building small internal services then I go FastAPI or Flask. Django's ORM is still dreamy. I used to like DRF (Django Rest Framework) and Django + DRF was a powerful combo to drive single-page-application sites. But DRF can get a little painful if you're not using some of the out-of-the-box classes. Painful as in... lots of code to right and very hard for someone to maintain without knowledge of how DRF magic is made under the hood.
danpalmer 3y ago
I've always felt, and this hasn't changed recently, that if you're going to need more than, say, 3 of the cross cutting concerns that Django provides for, then it'll be much more maintainable in the long run to just use Django rather than effectively building a custom solution out of parts. The flip side: if you're building a small internal API that only needs a couple of these, Django might be overkill. What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries. We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.
- BasilPH 3y ago
  I agree. I would even go so far as to say that if you need an ORM, go with Django. I've wasted too much time adding SQLAlchemy to Flask to get something that is still worse than the Django ORM.
  - danpalmer 3y ago
    Perhaps, but it depends what you're building. SQLAlchemy is much more capable, so if you need great database control and don't need all the other bits Django is bringing, then I kinda get it.
  - fbdab103 3y ago
    +1 to that. Maybe SQLAlchemy is a better product, but being a bolted on solution makes everything about the ORM experience feel worse than using Django. If nothing else, it is not just using Flask+SQLAlchemy, now it is Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties, so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.
    - BasilPH 3y ago
      Exactly. It's the migration support that I find the best feature of Django, but I keep forgetting about it until I have to migrate with some other ORM.
  - antod 3y ago
    They way I'd look at it - if your app owns the database and schema, use Django. If your app is connecting into someone else's database or databases (like in enterprises with DBA priesthoods etc), the flexibility of SQLAlchemy can fit better around arbitrary schemas etc.
- stavros 3y ago
  I half-agree with you, I've found that there are two options when choosing a framework: 1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask. 2. Otherwise, Django. Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.
filterfiber 3y ago
I know it's not "shiny and new" but Django is still serving us very well were I work. The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least). I would personally be hesitant to try something new just because django is so battle-tested at this stage, unless you just absolutely require better async support.
- aerhardt 3y ago
  > However the async is actively being worked on and does work (with some quirks) I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach until I see some good guides, codebase examples, and overall feature maturity.
  - filterfiber 3y ago
    Yeah I admittedly haven't used it much, our stuff was setup before they had async support at all, and our website doesn't benefit from it really. Async database queries would in theory be more efficient if you have many long running queries, but all of ours are reasonably fast and we have plenty of dedicated headroom so there's no incentive for us to consider changing anything. > I reverted everything to sync and re-implemented the hot functions with multi-threading... I'm curious what your workload is? If you need the requests themselves async then you normally have gunicorn/uwsgi handle that for you. Otherwise you'd send it to a work queue. Do you have a lot of long-running queries or realtime stuff? Hopefully django's async support improves. I love the ORM so much I use it for non-server based projects.
PurpleRamen 3y ago
Jetbrains Python Survey from 2022[1] has Flask, Django, Fastapi dominating the web-frameworks. Not sure how reliable this is, but I also barely see any other frameworks mentioned. So they either are in a totally different bubble, or just not popular (yet). [1] https://lp.jetbrains.com/python-developers-survey-2022/#FrameworksLibraries https://lp.jetbrains.com/python-developers-survey-2022/#Fram...
sgt 3y ago
Still Django unless you're only building a simple API.
- robertlagrant 3y ago
  Why not a complex API?
  - sgt 3y ago
    Sure, you can build a complex API in Flask, FastAPI etc. What I actually meant is for more complex scenarios where you build API's (complex or simple) in addition to using other parts of a web framework that will inevitably come in handy, such as templating, middlewares, schedulers, etc. Then Django has all the batteries included to become productive. If you discover a hot spot somewhere one can always spin that part off to its own service (which can very well be FastAPI to run it async) or rewrite that particular service in Go or Java. But I would not recommend premature optimization in most cases. First get your product out.
davepeck 3y ago
I choose between Django and Litestar these days. I wish I had a hard and fast rule for the choice, but it's something like: - Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar. - Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support. I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction. I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.) It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases. These days, most of my front-ends are React+Typescript+Vite. (FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)
the__alchemist 3y ago
Django; none of the new-hotness one compares. This is my no-bullshit answer that comparative articles and these frameworks' home pages dodge.
rossdavidh 3y ago
If you are doing something that is basic CRUD (which, to be honest, is most of the business world, although it's not very sexy), then Django is the best. If you want to do something that doesn't fit very well into that idea, then Flask is good for "just give me a web wrapper and get out of my way".
mands 3y ago
Have been a big Django user over the past 10 years at my startups, but we decided to do all new projects in Litestar going forwards - typing, async, and a better REST API story made it the preferred choice for us.

Maxion 3y ago

I guess it depends entirely on what it is that you are building - there's no one-size-fits-all but for Python for me that is still Django.

whitej125 3y ago

Depends what you're solving for. Building a website that requires user authentication and basic relational DB... I default to Django. But if I'm building small internal services then I go FastAPI or Flask. Django's ORM is still dreamy. I used to like DRF (Django Rest Framework) and Django + DRF was a powerful combo to drive single-page-application sites. But DRF can get a little painful if you're not using some of the out-of-the-box classes. Painful as in... lots of code to right and very hard for someone to maintain without knowledge of how DRF magic is made under the hood.

danpalmer 3y ago

I've always felt, and this hasn't changed recently, that if you're going to need more than, say, 3 of the cross cutting concerns that Django provides for, then it'll be much more maintainable in the long run to just use Django rather than effectively building a custom solution out of parts. The flip side: if you're building a small internal API that only needs a couple of these, Django might be overkill. What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries. We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.

BasilPH 3y ago
I agree. I would even go so far as to say that if you need an ORM, go with Django. I've wasted too much time adding SQLAlchemy to Flask to get something that is still worse than the Django ORM.
- danpalmer 3y ago
  Perhaps, but it depends what you're building. SQLAlchemy is much more capable, so if you need great database control and don't need all the other bits Django is bringing, then I kinda get it.
- fbdab103 3y ago
  +1 to that. Maybe SQLAlchemy is a better product, but being a bolted on solution makes everything about the ORM experience feel worse than using Django. If nothing else, it is not just using Flask+SQLAlchemy, now it is Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties, so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.
  - BasilPH 3y ago
    Exactly. It's the migration support that I find the best feature of Django, but I keep forgetting about it until I have to migrate with some other ORM.
- antod 3y ago
  They way I'd look at it - if your app owns the database and schema, use Django. If your app is connecting into someone else's database or databases (like in enterprises with DBA priesthoods etc), the flexibility of SQLAlchemy can fit better around arbitrary schemas etc.
stavros 3y ago
I half-agree with you, I've found that there are two options when choosing a framework: 1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask. 2. Otherwise, Django. Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.

filterfiber 3y ago

I know it's not "shiny and new" but Django is still serving us very well were I work. The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least). I would personally be hesitant to try something new just because django is so battle-tested at this stage, unless you just absolutely require better async support.

aerhardt 3y ago
> However the async is actively being worked on and does work (with some quirks) I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach until I see some good guides, codebase examples, and overall feature maturity.
- filterfiber 3y ago
  Yeah I admittedly haven't used it much, our stuff was setup before they had async support at all, and our website doesn't benefit from it really. Async database queries would in theory be more efficient if you have many long running queries, but all of ours are reasonably fast and we have plenty of dedicated headroom so there's no incentive for us to consider changing anything. > I reverted everything to sync and re-implemented the hot functions with multi-threading... I'm curious what your workload is? If you need the requests themselves async then you normally have gunicorn/uwsgi handle that for you. Otherwise you'd send it to a work queue. Do you have a lot of long-running queries or realtime stuff? Hopefully django's async support improves. I love the ORM so much I use it for non-server based projects.

PurpleRamen 3y ago

Jetbrains Python Survey from 2022[1] has Flask, Django, Fastapi dominating the web-frameworks. Not sure how reliable this is, but I also barely see any other frameworks mentioned. So they either are in a totally different bubble, or just not popular (yet). [1] https://lp.jetbrains.com/python-developers-survey-2022/#FrameworksLibraries https://lp.jetbrains.com/python-developers-survey-2022/#Fram...

sgt 3y ago

Still Django unless you're only building a simple API.

robertlagrant 3y ago
Why not a complex API?
- sgt 3y ago
  Sure, you can build a complex API in Flask, FastAPI etc. What I actually meant is for more complex scenarios where you build API's (complex or simple) in addition to using other parts of a web framework that will inevitably come in handy, such as templating, middlewares, schedulers, etc. Then Django has all the batteries included to become productive. If you discover a hot spot somewhere one can always spin that part off to its own service (which can very well be FastAPI to run it async) or rewrite that particular service in Go or Java. But I would not recommend premature optimization in most cases. First get your product out.

davepeck 3y ago

I choose between Django and Litestar these days. I wish I had a hard and fast rule for the choice, but it's something like: - Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar. - Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support. I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction. I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.) It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases. These days, most of my front-ends are React+Typescript+Vite. (FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)

the__alchemist 3y ago

Django; none of the new-hotness one compares. This is my no-bullshit answer that comparative articles and these frameworks' home pages dodge.

rossdavidh 3y ago

If you are doing something that is basic CRUD (which, to be honest, is most of the business world, although it's not very sexy), then Django is the best. If you want to do something that doesn't fit very well into that idea, then Flask is good for "just give me a web wrapper and get out of my way".

mands 3y ago

Have been a big Django user over the past 10 years at my startups, but we decided to do all new projects in Litestar going forwards - typing, async, and a better REST API story made it the preferred choice for us.