5 ms·

Kudos to everyone that contributed to Django in any way. Been using it for more than a decade and never it has disappointed me. Every release comes with excel

Kudos to everyone that contributed to Django in any way. Been using it for more than a decade and never it has disappointed me. Every release comes with excellent features and polishes. Everything in Django is well mature, properly maintained and built for maximum productivity and maintainability. One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful. Either be it async, websocket, NoSQL, fancy SPA, AMP, or any specific frontend framework integration.

Daishiman 5y ago
So much of this. I have seen so many developers switching between frameworks every two or three years, wasting away substantial accumulated knowledge and bags of tricks, the kind that allow you to make a living as a consultant because you can crank out CRUDs and REST endpoints like it's nobody's business. Some parts of the framework feel a little long in the tooth. The admin could use a rewrite with CBVs; the forms API just doesn't look so good compared to serialization abstractions in Rest frameworks nowadays. Still, it is a weapon, combined with Postgres, container-based deployments and a half dozen Django apps, there's few frameworks that come even close in terms of productivity and polish.
- slownews45 5y ago
  It's a nice combo of pretty stable, very productive, good technology. The postgresql integration is wonderful, so I like the database choice and they've had good support for postgresql for a while (a lot of other frameworks really were MySQL focused). Mix in container based deploys - great!
- Alir3z4 5y ago
  Exactly. I used pretty much many framework before settling on Django and polishing my knowledge and skills on it. Some places of Django could annoy me a bit, for instance Admin customization, but I got to conclusion that it's impossible to make Django customizable to every needs. The best would be create an admin dashboard for your own stuff. Charts, reporting, backoffice type are. Although it's possible to do so with current admin, but it's get annoying and after a while I see it be much better served if my requirements get created separately without poking around the admin so much. I usually create a separate app then include all the business requirements that don't fit in admin. Probably admin could expose a REST API? meh! Been a very long time that haven't worked with Forms, but compared with what comes out from DRF serializer etc, indeed would need some love. However, it's been years since majority of apps are built by frontend frameworks and using Django via DRF. The integration that comes with PostgreSQL and everything around Django ecosystem is mad productive. It takes a very short time to prototype and containerize the whole thing and have it on production. Fortunately or unfortunately, since I got comfortable with Django, I compare everything with it and it's really really really hard to swap it with something else.
bredren 5y ago
I like Django a lot and use it for my projects and with clients. > One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful. Django has also chosen not to get involved in tech that *has* been proven reliable and useful. For example moving to incorporate a formal API library like DRF years ago. It also has not indicated plans to adopt a type-based API library like FastAPI or Ninja. Often this idea of supporting REST API building as a battery of Django is used as a cudgel against modern front-end frameworks. The comments are generally aimed at React, but broadly anything in Javascript that requires an API. However, doing so has also been expense of making Django a first choice for microservices and ignores the important role of serving mobile app clients. Django has also been slow to discard technology that is no longer reliable or useful. For example, jQuery is still endemic in the ecosystem. I'm all for stability--I've invested a lot of time in Django and it is very productive. However, the biggest threat to this framework is the effusive self-praise for this attribute. People would do well to remember that Django displaced Drupal because Django was iterating rapidly even though it made upgrades very challenging at times. FastAPI and now SQLModel are showing how valuable adoption and use of Python's type system can be. There is no reason why a new Python-based framework (apart from Flask) could not unseat Django as the framework of choice. It wouldn't even endanger Django. People still build using Drupal today.
- soperj 5y ago
  why would you want a full framework with a admin back end for a microservice?
  - bb88 5y ago
    In fairness, you can disable the admin service if you want, then it just makes Django a big fat bloaty library. But more to the point, I feel like DRF is kind and of a weird solution anyway, like the request object is different from Django, it doesn't support schema generation without some third party libraries... Frankly, FastAPI with an orm sounds like the ultimate python microservice framework, anyway. Pgcli works as an admin interface in a pinch.

Daishiman 5y ago

So much of this. I have seen so many developers switching between frameworks every two or three years, wasting away substantial accumulated knowledge and bags of tricks, the kind that allow you to make a living as a consultant because you can crank out CRUDs and REST endpoints like it's nobody's business. Some parts of the framework feel a little long in the tooth. The admin could use a rewrite with CBVs; the forms API just doesn't look so good compared to serialization abstractions in Rest frameworks nowadays. Still, it is a weapon, combined with Postgres, container-based deployments and a half dozen Django apps, there's few frameworks that come even close in terms of productivity and polish.

slownews45 5y ago
It's a nice combo of pretty stable, very productive, good technology. The postgresql integration is wonderful, so I like the database choice and they've had good support for postgresql for a while (a lot of other frameworks really were MySQL focused). Mix in container based deploys - great!
Alir3z4 5y ago
Exactly. I used pretty much many framework before settling on Django and polishing my knowledge and skills on it. Some places of Django could annoy me a bit, for instance Admin customization, but I got to conclusion that it's impossible to make Django customizable to every needs. The best would be create an admin dashboard for your own stuff. Charts, reporting, backoffice type are. Although it's possible to do so with current admin, but it's get annoying and after a while I see it be much better served if my requirements get created separately without poking around the admin so much. I usually create a separate app then include all the business requirements that don't fit in admin. Probably admin could expose a REST API? meh! Been a very long time that haven't worked with Forms, but compared with what comes out from DRF serializer etc, indeed would need some love. However, it's been years since majority of apps are built by frontend frameworks and using Django via DRF. The integration that comes with PostgreSQL and everything around Django ecosystem is mad productive. It takes a very short time to prototype and containerize the whole thing and have it on production. Fortunately or unfortunately, since I got comfortable with Django, I compare everything with it and it's really really really hard to swap it with something else.

bredren 5y ago

I like Django a lot and use it for my projects and with clients. > One of the best thing about Django is, it's never gets involved with bubble type technologies until proven reliable and useful. Django has also chosen not to get involved in tech that *has* been proven reliable and useful. For example moving to incorporate a formal API library like DRF years ago. It also has not indicated plans to adopt a type-based API library like FastAPI or Ninja. Often this idea of supporting REST API building as a battery of Django is used as a cudgel against modern front-end frameworks. The comments are generally aimed at React, but broadly anything in Javascript that requires an API. However, doing so has also been expense of making Django a first choice for microservices and ignores the important role of serving mobile app clients. Django has also been slow to discard technology that is no longer reliable or useful. For example, jQuery is still endemic in the ecosystem. I'm all for stability--I've invested a lot of time in Django and it is very productive. However, the biggest threat to this framework is the effusive self-praise for this attribute. People would do well to remember that Django displaced Drupal because Django was iterating rapidly even though it made upgrades very challenging at times. FastAPI and now SQLModel are showing how valuable adoption and use of Python's type system can be. There is no reason why a new Python-based framework (apart from Flask) could not unseat Django as the framework of choice. It wouldn't even endanger Django. People still build using Drupal today.

soperj 5y ago
why would you want a full framework with a admin back end for a microservice?
- bb88 5y ago
  In fairness, you can disable the admin service if you want, then it just makes Django a big fat bloaty library. But more to the point, I feel like DRF is kind and of a weird solution anyway, like the request object is different from Django, it doesn't support schema generation without some third party libraries... Frankly, FastAPI with an orm sounds like the ultimate python microservice framework, anyway. Pgcli works as an admin interface in a pinch.