33 ms·

Django 5.0

554 points by sarahboyce 3y ago

sarahboyce 3y ago
Release notes: https://docs.djangoproject.com/en/5.0/releases/5.0/ https://docs.djangoproject.com/en/5.0/releases/5.0/ Related Community Resources * New goodies in Django 5.0 [blog]: https://fly.io/django-beats/new-goodies-in-django-50/ https://fly.io/django-beats/new-goodies-in-django-50/ * What's new in Django 5.0 [video]: https://youtu.be/lPl5Q5gv9G8?feature=shared https://youtu.be/lPl5Q5gv9G8?feature=shared * Database generated columns⁽¹⁾: Django & SQLite [blog]: https://www.paulox.net/2023/11/07/database-generated-columns-part-1-django-and-sqlite/ https://www.paulox.net/2023/11/07/database-generated-columns... * Database generated columns⁽²⁾: Django & PostgreSQL [blog]: https://www.paulox.net/2023/11/24/database-generated-columns-part-2-django-and-postgresql/ https://www.paulox.net/2023/11/24/database-generated-columns... * Building a Bootstrap styled form in vanilla Django [blog]: https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_django/ https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_djang...
h4kor 3y ago
Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?
- jedi_stannis 3y ago
  They switched their versioning scheme after the 1.x. https://docs.djangoproject.com/en/dev/internals/release-process/ https://docs.djangoproject.com/en/dev/internals/release-proc...
- freedomben 3y ago
  Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment
  - ralmidani 3y ago
    Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to. Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
    - robertlagrant 3y ago
      I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.
  - h4kor 3y ago
    I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.
- DarkNova6 3y ago
  > The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
  - eYrKEC2 3y ago
    ORM's always abstract away details, but you monitor for slow queries and slow endpoints and then just fix the issues when they crop up.
  - Alex3917 3y ago
    > Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right... FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
  - belorn 3y ago
    There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries. But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query. It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
    - h4kor 3y ago
      Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet. And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.
- sarahboyce 3y ago
  The release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support. The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can. Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries. 1: https://docs.djangoproject.com/en/dev/internals/release-process/#release-cadence https://docs.djangoproject.com/en/dev/internals/release-proc... 2: https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy https://docs.djangoproject.com/en/dev/internals/release-proc... 3: https://fosstodon.org/@carlton/111300877531721385 https://fosstodon.org/@carlton/111300877531721385
- adastra22 3y ago
  Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.
- pmontra 3y ago
  The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins. I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.
  - dd82 3y ago
    tbh, any OOP paradigms used with db tables will end up in a clusterf*ck.
  - NoGravitas 3y ago
    I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.
alberth 3y ago
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.
saasjosh 3y ago
Another boring release without much innovation. I wonder what's stopping Django from releasing more useful features like other frameworks are doing. Maybe the team is stuck in the past. They've been trying to improve forms for a long time but it still sucks. I think they should just remove it at this point and let external packages solve the problem.
- Maxion 3y ago
  Not much no, but both the GeneratedField and db_default would be useful in almost all projects I've ever implemented in Django.
  - saasjosh 3y ago
    Good for you but they're niche features that most developers will never use. I certainly won't. That's why I switched to NextJS anyway. Django's implementing features voted by the board and companies who fund the project the most. They don't care about end users anymore.
- synergy20 3y ago
  can you list the features you mentioned that is lacking in django?
- collyw 3y ago
  > Another boring release without much innovation That's a good thing. A couple of articles related to the topic. https://boringtechnology.club/ https://boringtechnology.club/ https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-arent-dinosaurs-but-sharks https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-a...
brycewray 3y ago
Assuming they used Django to publish this, it’s a bit sad that there’s no `generator` tag to give their own CMS a little love. :-/
- danpalmer 3y ago
  Django isn't really a CMS. People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications, but I think most people think about a much higher level tool when they think of a CMS. It's also somewhat limiting – Django is good for building big web applications (see: Instagram, Octopus Energy) not just traditional content management based applications.
  - robertlagrant 3y ago
    > People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications No, it's because there's a CMS called Django CMS.
jmduke 3y ago
My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance. Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.
- malux85 3y ago
  Mine too - Vue and django, and the django rest framework, it’s super productive - no writing all the crud views manually for the hundreds of models I have, the django admin interface is very helpful like you say, and backend is running (a very highly customized) django celery mix, Django + REST framework takes a little more to learn than something like FastAPI, but once you understand how all the middleware, permission and query classes work, you can be hyper productive
- sprainedankles 3y ago
  Any resources/examples you'd recommend for a Vue frontend w/django? I've been pretty firmly in backend land for a while and would to experiment with the other half of the puzzle!
  - jmduke 3y ago
    I'll preface all of this with a couple esoteric design goals that I had in mind: 1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc. 2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea. --- With that in mind, some specific packages that I highly recommend: 1. Django-vite (https://github.com/MrBin99/django-vite https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model 2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful. 3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
apstats 3y ago
Django seems great but also incredibly complex. I am never able to find any good example projects that use it with react and aren't just a toy which is bit of a bummer, because I think that would be a great stack.
- Vinnl 3y ago
  In case you're interested, Firefox Relay uses that stack and is open source: https://github.com/mozilla/fx-private-relay/ https://github.com/mozilla/fx-private-relay/
- bastawhiz 3y ago
  Django makes it dead easy to take a URL route and return HTML. Obviously there's some fussing to add a script tag that points at your JavaScript file, but what exactly are you looking for beyond that? I'm not exactly sure what you're looking for beyond that (as someone who ~only writes Django+React); that's kind of it. There's no big magic, it responds to http requests with data.
  - Izkata 3y ago
    For a full-on SPA (which I'm assuming is what they mean by "and aren't just a toy"), you'd also need at least frontend routing and an example how to make that play nice with Django URL routes, probably a data store (which at this point I think is just going to be redux), and most of the Django views would return JSON instead of HTML.
    - bastawhiz 3y ago
      None of those concerns have anything to do with Django: just have Django return your HTML for all views that don't return JSON (which is to say, set the 404 to your HTML). There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.
scrollaway 3y ago
A huge part of the work I did the past year (and still do sometimes, email in my profile) was helping people transition from a full legacy django app to a lightweight django backend with rest api and a react frontend. Django Ninja makes it especially pleasant. I think django should really embrace this in the future. Make it easier to drop the superfluous parts; forms, templates … I don’t know what that will look like but I don’t see a way back.
- number6 3y ago
  We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?
  - nprateem 3y ago
    Mobile
  - collyw 3y ago
    Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.
    - deleted 3y ago
      [deleted]
    - scrollaway 3y ago
      Github is moving to an SPA with init-time SSR.
  - scrollaway 3y ago
    Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots). I don't need to sell you on the concept though I will address your comment in depth. In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ... The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve. But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour. GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for. But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding). As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).
BasilPH 3y ago
I'm excited to try the field group templates, I expect it to make handling forms styled with Tailwind much easier.
stosssik 3y ago
can you list the features that are lacking in django?
- pphysch 3y ago
  I would point to two of the most popular plugins, Django Rest Framework (DRF) and Celery (a background task system that requires rabbitmq|kafka|redis|etc). Both add highly sought-after features, but I believe these implementations are quite poor, complicated. Django could implement MVPs in core/contrib and vastly simplify future projects for users. A builtin OIDC client abstraction would go a long way as well.
  - bdzr 3y ago
    The worst thing about DRF is the dogmatic adherence to inexplicable class hierarchies, something that is modeled after Django class based views. I think Django would fumble a DRF implementation.
    - pphysch 3y ago
      All you really need is a decent built-in JSON de/serializer for Django models. It doesn't need to be an OOP monstrosity. Golang has that built-in to what is a simpler language than Python (e.g. no class inheritance). The complexity of DRF greatly oversteps what it is offering.
ralmidani 3y ago
Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta). Meanwhile, the Ember part is “lost in time… like tears in rain”. I tried everything, downloading older versions of Node and even the now-deprecated Bower. I don’t fault Ember (which is actually the most stable of the major JS client frameworks). But the JS (especially Node) ecosystem is beyond redemption in my eyes. For my rewrite of the client, I’m going to skip the drama and just use htmx. Render Django templates server-side, include a single JS script, thrown in some HTML attributes, distinguish between full page requests vs. requests for a partial with updated data, and call it a day. No TypeScript, no Webpack, none of that nonsense. If I need special interactivity I can throw in some hyperscript. At work I’ve used Elixir/Phoenix/LiveView and it’s revolutionary, truly awesome tech. But to get to market I would rather not have to customize an auth system and build a decent admin interface myself (I tried Ash; its auth and admin are not mature enough to be compared to what “just works” with Django). Yeah, it won’t be as scalable as a Phoenix app, but to me, Django seems like the most clean and rapid way to get to a point where you’ll actually need scalability.
- cjauvin 3y ago
  I absolutely agree. Recently I had to work on a complex client app, and I could simply not believe the amount of trouble you have to go through when you want to increment the version number of things like React, MUI, webpack, TS by.. one!
  - gedy 3y ago
    > want to increment the version number of things like React, MUI, webpack, TS by.. one! To be fair, in semver that means a breaking change of some sort.
    - 3y ago
SadWebDeveloper 3y ago
IMHO... Django hold a high standard in terms for projects running beyond the infamous 5+ years of support... still have some projects that with minimal changes (mostly configs and dependencies that got redundant/integrated into django -like choices-) are working with the latest version, surely 5.0 will not be that drastic if you are already doing software "the django way". Things that are Django achilles heel are not developing software "the django way", mostly anything that needs some client-side to work is a PITA, requires lots of rewriting and custom templates that at some point you gotta start looking django as a backend more like the full stack framework that was meant to be. Also anything related onto getting things to production is another PITA that hasn't been solved or touched in years, dx deployment is one of those things almost any JS Framework out there is doing things better than what django supports.
- dexwiz 3y ago
  Isn't Developer DX mostly a way to get developers locked into your platform? I have avoided Next.js for this reason, it seems like just a way to funnel developers towards Vercel. DX is largely a service specific problem since its coupled to the service you are deploying to.
  - yunohn 3y ago
    Django is free, in all definitions and purposes of the word. No agenda, no VC funding, no BS.
    - biscotti 3y ago
      [dead]
yuppiepuppie 3y ago
3 years ago I moved to fast growing startup that was founded with fast api slap-dashed together. I jammed Django down their throats and I can safely say it was the best decision we made as an Org. The teams using Django are far far more productive than the others. When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back. Thank you mister reinhardt
- IshKebab 3y ago
  Yeah this is definitely Django's strength - it has a lot of the stuff you're probably going to need already implemented. Massive time saver when you're setting things up. Python definitely holds it back though. Does it have type hints yet?
  - yuppiepuppie 3y ago
    Why do you say python holds it back?
    - IshKebab 3y ago
      The three big problems with Python: * It's slow. 'nuff said. No the fact that Numpy exists doesn't change that. * Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml). * The infrastructure and module systems are a total mess. Literally nobody understands Python imports. There's also the fact that Python code is generally lower quality than in other languages (except maybe JS) because it's so popular with beginners.
      - yuppiepuppie 3y ago
        What is slow about python? I can onboard and have someone developing python code in our code base in <1 day because of its simplicity. I’m not sure I would call that slow…
- alfor 3y ago
ds3w2 3y ago
django is good just one thing fix .select_related('child__attribute') / .values('child__attribute') currently it removes from result set rows where 'attribute' is NULL, unlike what typical LEFT JOINs imply
- tomwojcik 3y ago
  I never run into this issue but isn't it that Django uses inner join for select related, so it does what it's supposed to do? You can always prefetch related, or even use outer=True. This will return the results you expect.
nickjj 3y ago
Congrats on the release to the Django community! If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.
- hipjiveguy 3y ago
  nice... thanks!
- hipjiveguy 3y ago
  where do you tend to run stuff in production? and if you were a startup - any preferences?
  - nickjj 3y ago
    It depends. I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too. With no other context, if I were creating a startup today I'd likely go with DigitalOcean. AWS is also another option, especially if you think you'll be using some of their services. But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.
93po 3y ago
If someone were to look for a web developer job these days, is Django the framework to focus on if you want a project that has a decent quality of life and is easy to get a job doing? I assume it's between that and Rails. Alternatively, if I already have a ton of web framework experience and desperately want to move on to something different, what are some natural areas to extend into to stop working for agencies making crappy websites for small businesses? I guess this is off topic but it seems like people reading this may have input
- shnock 3y ago
  React? Or back-end with NodeJS
asylteltine 3y ago
I like Django rest framework a lot. It was really easy to make something with react and call Django directly however the templating engine is also great. It’s so strange people still use rails
- vanviegen 3y ago
  > It’s so strange people still use rails Why? What makes Django better? (Genuinely curious.)
  - collyw 3y ago
    I never used Rails, but people who use both said that thy were pretty similar. Python had the advantage of scientific libraries (which was useful for what I was building), while Rails was a bit more web dev focused. Rails does seem to have fallen out of favor over the last decade, while Django enjoyed a more steady level of popularity. I guess Python is a more popular language.
    - antod 3y ago
      I don't think Rails is any less favoured than Django - the hype moved on from back end oriented web frameworks in general though. Rails had a higher level of initial hype though, so maybe more of that moved on to other things leaving it closer to Django that had a slower decline. Both projects are solid mature choices though - the downside of that might be attracting enough new/younger devs. Choice comes down more to Ruby vs Python depending on which one your team knows better or if you need other libraries from that language.
      - collyw 3y ago
        Yes, Rails definitely had more initial hype, which in turn led to a bigger decline, while Django remained more steady with it's popularity. I see a lot less Rails jobs than I used to. I might b wrong but I don't see much Ruby use outside of Rails.
  - asylteltine 3y ago
jononomo 3y ago
Just FYI -- there is so much mature Django and Python code out there than ChatGPT is really an excellent partner when you're building a Django project. Django is frankly the best web framework in existence, IMHO.
- local_crmdgeon 3y ago
  * if you can accept the flaws in Python for your usecase
st3fan 3y ago
Type hints everywhere?
- radus 3y ago
  No, as I understand it, the Django project's stance on type hints is that they aren't going to be added any time soon, but they are willing to accept small PRs that are needed by external type-checkers on a case by case basis. Details here: https://github.com/django/deps/pull/65 https://github.com/django/deps/pull/65
loughnane 3y ago
I can’t tell if it’s Django or just how I use it—-I’m a mechanical engineer by training and only dabble on web dev—-but I deeply appreciate how it gives me enough abstraction to get going but doesn’t get too far ahead of itself. If I go away for a year or two then come back I still get what’s going on. Meanwhile anything I try on JS land has gone through a few half-lives.
- rglover 3y ago
  If you want a similar experience in JS check out Joystick [1]. It's being built to mimic the indefinitely stable design of stuff like Django and Rails. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
  - 0xblinq 3y ago
    Which is just yet another js framework which might disappear next month. That's the problem.
    - rglover 3y ago
      You have no reason to believe me but short of my own death halting development, no. I'm not doing it for fashion/clout/money/boredom. I'm doing it because I refuse to work with the mental illness that the JavaScript ecosystem has become.
miiiiiike 3y ago
Are there any large sites that use Django Ninja? I've been using DRF for about a decade and there hasn't been a moment of enjoyment or ease. I adore Django but wish it had an official REST contrib package. [0] With DRF dragging its feet on async (leaving it to a third-party library) I just want to quit. I'm building a new async api soon, are there any Django Ninja case studies? I can't find anything. [0]: Using Django.. Me in 2008 — "How do I get data from a PUT/PATCH request without a library?" Me in 2023 — "How do I get data from a PUT/PATCH request without a library?"
- megaman821 3y ago
  Django Ninja just hit 1.0 a few weeks ago. I think you are going to have to be patient to find large sites using it in production.
  - miiiiiike 3y ago
    I've never heard of anyone using it in production, period. The one thing FastAPI had going for it back when it was announced was a list of companies and groups with it deployed that minute. Is it a "1.0 because we think it's done and you should try using it now. Maybe it'll work." Or "This is a solid 1.0 that has been tested in production. You can expect reasonable api stability." FastAPI launched with option three: "We're going to get our friends to use it in production so we can say it's deployed by Microsoft, but, this is definitely a pre-alpha."
    - megaman821 3y ago
      I am using it myself on a branch I haven't pushed to production. I would say DRF has better documentation and more packages that extend its behavior (like exporting to Excel). Ninja is a lot cleaner though, it works better with type checkers, and if you are also using FastAPI there is basically no learning curve.
      - miiiiiike 3y ago
        Django Ninja has always looked beautiful. I've been toying with it since it was first announced, never pushed it to production tho. I've been thinking of spinning up a cluster just to dark launch it with calls from my main app to see how it performs.
Svetlitski 3y ago
While I don’t use it anymore and have been out of the web dev space completely for a few years now, I personally feel I owe a lot to Django. It’s the framework behind the first software I wrote that other people actually used and depended on. While looking back at it now the first Django code I wrote was pretty awful, it’s astonishing how much the framework lets you accomplish. Without knowing much at all about web development or databases, following the Django tutorial is sufficient to get you started with a very basic web app, and you can grow from there. Couple this with the superpower that was deploying to Heroku, and it made for a fantastic introduction to web dev and shipping software to real users.
ajhai 3y ago
I've been using Django as my main choice for web projects for over ten years. The reason I like it so much is because it comes with a lot of built-in features that one needs to ship web projects to production. For example, I was first attracted to Django because of its admin interface and its straightforward views and templating system. Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins. My recent use of Django is in (https://github.com/trypromptly/LLMStack https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.
honestduane 3y ago
And django-timezone-field and others are not currently compatible, blocking upgrades.
agumonkey 3y ago
Be sure to check out the Query base classes (Func, etc), it helps getting over the choice '__prop__func' as syntax.
quantiq 3y ago
Django is such a lovely framework I can't speak higher praises of it. I'm blessed to still be able to use it in my day to day work. It's maybe not the most flashy framework out there these days but Django and Rails are really the Toyota Corollas and Honda Civics of the web dev world that often go so underappreciated for their unfussy reliability. :)
- anon373839 3y ago
  I’d say they’re the Lexuses of the web dev world. Very nicely appointed and rock-solid, just not very sexy.
  - pwython 3y ago
    The Lexus LFA would like to have a word with you.
    - anon373839 3y ago
      Touché.
the__alchemist 3y ago
Django owns! The blazingly-fast flask-alikes that come out in Python and Rust every year still can't touch it for building websites. My only beef is that the official docs and community chats make you feel like you're an outlaw or doing things wrong if you use the raw SQL API. Regarding this new version in particular, the feature that jumps out at me the most is the improved field choices. I've been using an odd workaround with the decorator API to tie them to python Enums.
Darmody 3y ago
I usually hear this question the other way around but there it goes. Why should someone consider Django instead of something like Symfony or Laravel?
- biorach 3y ago
  Because they know, or want to know Python
  - Darmody 3y ago
    Thank you, mister, but I mean from a techy point of view.
    - biorach 3y ago
      I only know laravel from skimming the docs, but I got the impression that there was not enough difference between it and Django to justify switching to a language you don't know,going either way. That said... Does Laravel have something like Django's admin view?
      - Darmody 3y ago
        I guess the equivalent would be Laravel Nova.
Mystery-Machine 3y ago
How does Django compare to Ruby on Rails? Any developers in here that tried/used both frameworks?
deleted 3y ago
[deleted]
djstein 3y ago
for those keeping up with Django’s async story the biggest updates with Django 5.0 are: The new asynchronous functions are now provided, using an a prefix: django.contrib.auth.aauthenticate(), aget_user(), alogin(), alogout(), and aupdate_session_auth_hash(). AuthenticationMiddleware now adds an HttpRequest.auser() asynchronous method that returns the currently logged-in user. [Edit: paste wasn’t the full sentence]
bdcravens 3y ago
I work in the Rails world, and perhaps my perception is colored by the big changes they tend to make, but this seems like more of a minor than a major version release? Or is this relatively big for Django?
- iamsanteri 3y ago
  I'd be also interested to hear someone proficient have an opinion about this. A 5.0 update sounds like something big. What about the rest of the async parts in Django having been in the process of being re-written since a while, as I've heard? Also has it ever been considered to build some deeper integration of Celery for enabling and handling in-memory background job processing in a more closely and "better-integrated" way akin to Rails' active job?
- Humphrey 3y ago
  Yes, relative minor update. Django is very mature and does most things needed, so there has not been need for major changes since about 2.0. Django releases are now based on a schedule, so the 5.0 label wouldn't have been chosen because of significant changes. But, I have observed that releases often look like this: - X.0 Newer shinier features - X.1 More refinement and minor features - X.2 [LTS] More refinement and minor features Which means if you stick to the point 2 releases you get longer support and subjectively more stability since the shiny new features have been polished over a couple of point releases. But in reality these days, I think it's just whatever features are ready to ship for the scheduled release date.
rossant 3y ago
What an incredibly powerful, robust, well-documented, carefully-designed piece of open source software. I love Django so much and I use it every day. A huge thanks to all developers and maintainers.
local_crmdgeon 3y ago
Is there a good JS/TS Django replacement? Something mature? I know a few were taking shots at it, but I truly hate Python and have a JS team
- local_crmdgeon 3y ago
  Did RedwoodJS ever take off?
MugoyaDihfahsih 3y ago
Been using Django starting from version 2.2 ever since then the release of new upgrades has been charming. Thanks to the team for the new improvements.
cushychicken 3y ago
Know what ChatGpT is real good at? Writing Django. Using that to my advantage lately.
kdwikzncba 3y ago
Does anyone else find this obsession with expanding database-related features weird?
PrivateButts 3y ago
I loooove Django, any project that I work on that isn't Django causes me to yearn for it greatly. However, there's two things that have been minorly bothering me about it: - The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party). - The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks compared to how baller DRF is. It's still a massive fight to get subscriptions working well. It would be nice to see the foundation throw them a bone like they did with Channels.
- patrick91 3y ago
  Hi there! I work on Strawberry GraphQL, would be interested in sending me a list of the things that we can do better? You can send me a dm on discord or open an issue on discord, I plan to spend more time on Strawberry next year, so hopefully I can make it good for you!
  - PrivateButts 3y ago
    Sure thing! We have migrated to Strawberry for all our projects going forward, next time I have my hands in those project guts for maintenance I'll document some and send it on.
nprateem 3y ago
Anyone experienced performance improvements by using pypy instead of cpython with django?
rrishi 3y ago
Coincidentally, I am just beginning to learn Django. I have experience with NextJS, Express and Flask. In the past, Django had intimidated me due to having so many official-sounding files and folder structure and settings etc. So, I had just not given it too much brain cycles. After having experience with the earlier listed frameworks, I can appreciate some of the things Django gives out of the box. It feels "industry-grade". Hoping to make fond memories with Django just like the other experiences described here! Happy holidays everyone!

554 points by sarahboyce 3y ago

Release notes: https://docs.djangoproject.com/en/5.0/releases/5.0/ https://docs.djangoproject.com/en/5.0/releases/5.0/ Related Community Resources * New goodies in Django 5.0 [blog]: https://fly.io/django-beats/new-goodies-in-django-50/ https://fly.io/django-beats/new-goodies-in-django-50/ * What's new in Django 5.0 [video]: https://youtu.be/lPl5Q5gv9G8?feature=shared https://youtu.be/lPl5Q5gv9G8?feature=shared * Database generated columns⁽¹⁾: Django & SQLite [blog]: https://www.paulox.net/2023/11/07/database-generated-columns-part-1-django-and-sqlite/ https://www.paulox.net/2023/11/07/database-generated-columns... * Database generated columns⁽²⁾: Django & PostgreSQL [blog]: https://www.paulox.net/2023/11/24/database-generated-columns-part-2-django-and-postgresql/ https://www.paulox.net/2023/11/24/database-generated-columns... * Building a Bootstrap styled form in vanilla Django [blog]: https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_django/ https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_djang...

h4kor 3y ago

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?

jedi_stannis 3y ago
They switched their versioning scheme after the 1.x. https://docs.djangoproject.com/en/dev/internals/release-process/ https://docs.djangoproject.com/en/dev/internals/release-proc...
freedomben 3y ago
Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment
- ralmidani 3y ago
  Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to. Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.
  - robertlagrant 3y ago
    I think SQLAlchemy is better, personally. Still just model files, but it's data mapper pattern means you won't be hitting all the issues people do with active record.
- h4kor 3y ago
  I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.
DarkNova6 3y ago
> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...
- eYrKEC2 3y ago
  ORM's always abstract away details, but you monitor for slow queries and slow endpoints and then just fix the issues when they crop up.
- Alex3917 3y ago
  > Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right... FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
- belorn 3y ago
  There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries. But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query. It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.
  - h4kor 3y ago
    Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet. And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.
sarahboyce 3y ago
The release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support. The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can. Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries. 1: https://docs.djangoproject.com/en/dev/internals/release-process/#release-cadence https://docs.djangoproject.com/en/dev/internals/release-proc... 2: https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy https://docs.djangoproject.com/en/dev/internals/release-proc... 3: https://fosstodon.org/@carlton/111300877531721385 https://fosstodon.org/@carlton/111300877531721385
adastra22 3y ago
Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.
pmontra 3y ago
The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins. I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.
- dd82 3y ago
  tbh, any OOP paradigms used with db tables will end up in a clusterf*ck.
- NoGravitas 3y ago
  I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.

alberth 3y ago

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.

saasjosh 3y ago

Another boring release without much innovation. I wonder what's stopping Django from releasing more useful features like other frameworks are doing. Maybe the team is stuck in the past. They've been trying to improve forms for a long time but it still sucks. I think they should just remove it at this point and let external packages solve the problem.

Maxion 3y ago
Not much no, but both the GeneratedField and db_default would be useful in almost all projects I've ever implemented in Django.
- saasjosh 3y ago
  Good for you but they're niche features that most developers will never use. I certainly won't. That's why I switched to NextJS anyway. Django's implementing features voted by the board and companies who fund the project the most. They don't care about end users anymore.
synergy20 3y ago
can you list the features you mentioned that is lacking in django?
collyw 3y ago
> Another boring release without much innovation That's a good thing. A couple of articles related to the topic. https://boringtechnology.club/ https://boringtechnology.club/ https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-arent-dinosaurs-but-sharks https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-a...

brycewray 3y ago

Assuming they used Django to publish this, it’s a bit sad that there’s no `generator` tag to give their own CMS a little love. :-/

danpalmer 3y ago
Django isn't really a CMS. People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications, but I think most people think about a much higher level tool when they think of a CMS. It's also somewhat limiting – Django is good for building big web applications (see: Instagram, Octopus Energy) not just traditional content management based applications.
- robertlagrant 3y ago
  > People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications No, it's because there's a CMS called Django CMS.

jmduke 3y ago

My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance. Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.

malux85 3y ago
Mine too - Vue and django, and the django rest framework, it’s super productive - no writing all the crud views manually for the hundreds of models I have, the django admin interface is very helpful like you say, and backend is running (a very highly customized) django celery mix, Django + REST framework takes a little more to learn than something like FastAPI, but once you understand how all the middleware, permission and query classes work, you can be hyper productive
sprainedankles 3y ago
Any resources/examples you'd recommend for a Vue frontend w/django? I've been pretty firmly in backend land for a while and would to experiment with the other half of the puzzle!
- jmduke 3y ago
  I'll preface all of this with a couple esoteric design goals that I had in mind: 1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc. 2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea. --- With that in mind, some specific packages that I highly recommend: 1. Django-vite (https://github.com/MrBin99/django-vite https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model 2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful. 3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.

apstats 3y ago

Django seems great but also incredibly complex. I am never able to find any good example projects that use it with react and aren't just a toy which is bit of a bummer, because I think that would be a great stack.

Vinnl 3y ago
In case you're interested, Firefox Relay uses that stack and is open source: https://github.com/mozilla/fx-private-relay/ https://github.com/mozilla/fx-private-relay/
bastawhiz 3y ago
Django makes it dead easy to take a URL route and return HTML. Obviously there's some fussing to add a script tag that points at your JavaScript file, but what exactly are you looking for beyond that? I'm not exactly sure what you're looking for beyond that (as someone who ~only writes Django+React); that's kind of it. There's no big magic, it responds to http requests with data.
- Izkata 3y ago
  For a full-on SPA (which I'm assuming is what they mean by "and aren't just a toy"), you'd also need at least frontend routing and an example how to make that play nice with Django URL routes, probably a data store (which at this point I think is just going to be redux), and most of the Django views would return JSON instead of HTML.
  - bastawhiz 3y ago
    None of those concerns have anything to do with Django: just have Django return your HTML for all views that don't return JSON (which is to say, set the 404 to your HTML). There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.

scrollaway 3y ago

A huge part of the work I did the past year (and still do sometimes, email in my profile) was helping people transition from a full legacy django app to a lightweight django backend with rest api and a react frontend. Django Ninja makes it especially pleasant. I think django should really embrace this in the future. Make it easier to drop the superfluous parts; forms, templates … I don’t know what that will look like but I don’t see a way back.

number6 3y ago
We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?
- nprateem 3y ago
  Mobile
- collyw 3y ago
  Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.
  - deleted 3y ago
    [deleted]
  - scrollaway 3y ago
    Github is moving to an SPA with init-time SSR.
- scrollaway 3y ago
  Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots). I don't need to sell you on the concept though I will address your comment in depth. In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ... The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve. But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour. GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for. But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding). As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).

BasilPH 3y ago

I'm excited to try the field group templates, I expect it to make handling forms styled with Tailwind much easier.

stosssik 3y ago

can you list the features that are lacking in django?

pphysch 3y ago
I would point to two of the most popular plugins, Django Rest Framework (DRF) and Celery (a background task system that requires rabbitmq|kafka|redis|etc). Both add highly sought-after features, but I believe these implementations are quite poor, complicated. Django could implement MVPs in core/contrib and vastly simplify future projects for users. A builtin OIDC client abstraction would go a long way as well.
- bdzr 3y ago
  The worst thing about DRF is the dogmatic adherence to inexplicable class hierarchies, something that is modeled after Django class based views. I think Django would fumble a DRF implementation.
  - pphysch 3y ago
    All you really need is a decent built-in JSON de/serializer for Django models. It doesn't need to be an OOP monstrosity. Golang has that built-in to what is a simpler language than Python (e.g. no class inheritance). The complexity of DRF greatly oversteps what it is offering.

ralmidani 3y ago

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta). Meanwhile, the Ember part is “lost in time… like tears in rain”. I tried everything, downloading older versions of Node and even the now-deprecated Bower. I don’t fault Ember (which is actually the most stable of the major JS client frameworks). But the JS (especially Node) ecosystem is beyond redemption in my eyes. For my rewrite of the client, I’m going to skip the drama and just use htmx. Render Django templates server-side, include a single JS script, thrown in some HTML attributes, distinguish between full page requests vs. requests for a partial with updated data, and call it a day. No TypeScript, no Webpack, none of that nonsense. If I need special interactivity I can throw in some hyperscript. At work I’ve used Elixir/Phoenix/LiveView and it’s revolutionary, truly awesome tech. But to get to market I would rather not have to customize an auth system and build a decent admin interface myself (I tried Ash; its auth and admin are not mature enough to be compared to what “just works” with Django). Yeah, it won’t be as scalable as a Phoenix app, but to me, Django seems like the most clean and rapid way to get to a point where you’ll actually need scalability.

cjauvin 3y ago
I absolutely agree. Recently I had to work on a complex client app, and I could simply not believe the amount of trouble you have to go through when you want to increment the version number of things like React, MUI, webpack, TS by.. one!
- gedy 3y ago
  > want to increment the version number of things like React, MUI, webpack, TS by.. one! To be fair, in semver that means a breaking change of some sort.
  - 3y ago

SadWebDeveloper 3y ago

IMHO... Django hold a high standard in terms for projects running beyond the infamous 5+ years of support... still have some projects that with minimal changes (mostly configs and dependencies that got redundant/integrated into django -like choices-) are working with the latest version, surely 5.0 will not be that drastic if you are already doing software "the django way". Things that are Django achilles heel are not developing software "the django way", mostly anything that needs some client-side to work is a PITA, requires lots of rewriting and custom templates that at some point you gotta start looking django as a backend more like the full stack framework that was meant to be. Also anything related onto getting things to production is another PITA that hasn't been solved or touched in years, dx deployment is one of those things almost any JS Framework out there is doing things better than what django supports.

dexwiz 3y ago
Isn't Developer DX mostly a way to get developers locked into your platform? I have avoided Next.js for this reason, it seems like just a way to funnel developers towards Vercel. DX is largely a service specific problem since its coupled to the service you are deploying to.
- yunohn 3y ago
  Django is free, in all definitions and purposes of the word. No agenda, no VC funding, no BS.
  - biscotti 3y ago
    [dead]

yuppiepuppie 3y ago

3 years ago I moved to fast growing startup that was founded with fast api slap-dashed together. I jammed Django down their throats and I can safely say it was the best decision we made as an Org. The teams using Django are far far more productive than the others. When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back. Thank you mister reinhardt

IshKebab 3y ago
Yeah this is definitely Django's strength - it has a lot of the stuff you're probably going to need already implemented. Massive time saver when you're setting things up. Python definitely holds it back though. Does it have type hints yet?
- yuppiepuppie 3y ago
  Why do you say python holds it back?
  - IshKebab 3y ago
    The three big problems with Python: * It's slow. 'nuff said. No the fact that Numpy exists doesn't change that. * Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml). * The infrastructure and module systems are a total mess. Literally nobody understands Python imports. There's also the fact that Python code is generally lower quality than in other languages (except maybe JS) because it's so popular with beginners.
    - yuppiepuppie 3y ago
      What is slow about python? I can onboard and have someone developing python code in our code base in <1 day because of its simplicity. I’m not sure I would call that slow…
alfor 3y ago

ds3w2 3y ago

django is good just one thing fix .select_related('child__attribute') / .values('child__attribute') currently it removes from result set rows where 'attribute' is NULL, unlike what typical LEFT JOINs imply

tomwojcik 3y ago
I never run into this issue but isn't it that Django uses inner join for select related, so it does what it's supposed to do? You can always prefetch related, or even use outer=True. This will return the results you expect.

nickjj 3y ago

Congrats on the release to the Django community! If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.

hipjiveguy 3y ago
nice... thanks!
hipjiveguy 3y ago
where do you tend to run stuff in production? and if you were a startup - any preferences?
- nickjj 3y ago
  It depends. I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too. With no other context, if I were creating a startup today I'd likely go with DigitalOcean. AWS is also another option, especially if you think you'll be using some of their services. But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.

93po 3y ago

If someone were to look for a web developer job these days, is Django the framework to focus on if you want a project that has a decent quality of life and is easy to get a job doing? I assume it's between that and Rails. Alternatively, if I already have a ton of web framework experience and desperately want to move on to something different, what are some natural areas to extend into to stop working for agencies making crappy websites for small businesses? I guess this is off topic but it seems like people reading this may have input

shnock 3y ago
React? Or back-end with NodeJS

asylteltine 3y ago

I like Django rest framework a lot. It was really easy to make something with react and call Django directly however the templating engine is also great. It’s so strange people still use rails

vanviegen 3y ago
> It’s so strange people still use rails Why? What makes Django better? (Genuinely curious.)
- collyw 3y ago
  I never used Rails, but people who use both said that thy were pretty similar. Python had the advantage of scientific libraries (which was useful for what I was building), while Rails was a bit more web dev focused. Rails does seem to have fallen out of favor over the last decade, while Django enjoyed a more steady level of popularity. I guess Python is a more popular language.
  - antod 3y ago
    I don't think Rails is any less favoured than Django - the hype moved on from back end oriented web frameworks in general though. Rails had a higher level of initial hype though, so maybe more of that moved on to other things leaving it closer to Django that had a slower decline. Both projects are solid mature choices though - the downside of that might be attracting enough new/younger devs. Choice comes down more to Ruby vs Python depending on which one your team knows better or if you need other libraries from that language.
    - collyw 3y ago
      Yes, Rails definitely had more initial hype, which in turn led to a bigger decline, while Django remained more steady with it's popularity. I see a lot less Rails jobs than I used to. I might b wrong but I don't see much Ruby use outside of Rails.
- asylteltine 3y ago

jononomo 3y ago

Just FYI -- there is so much mature Django and Python code out there than ChatGPT is really an excellent partner when you're building a Django project. Django is frankly the best web framework in existence, IMHO.

local_crmdgeon 3y ago
* if you can accept the flaws in Python for your usecase

st3fan 3y ago

Type hints everywhere?

radus 3y ago
No, as I understand it, the Django project's stance on type hints is that they aren't going to be added any time soon, but they are willing to accept small PRs that are needed by external type-checkers on a case by case basis. Details here: https://github.com/django/deps/pull/65 https://github.com/django/deps/pull/65

loughnane 3y ago

I can’t tell if it’s Django or just how I use it—-I’m a mechanical engineer by training and only dabble on web dev—-but I deeply appreciate how it gives me enough abstraction to get going but doesn’t get too far ahead of itself. If I go away for a year or two then come back I still get what’s going on. Meanwhile anything I try on JS land has gone through a few half-lives.

rglover 3y ago
If you want a similar experience in JS check out Joystick [1]. It's being built to mimic the indefinitely stable design of stuff like Django and Rails. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- 0xblinq 3y ago
  Which is just yet another js framework which might disappear next month. That's the problem.
  - rglover 3y ago
    You have no reason to believe me but short of my own death halting development, no. I'm not doing it for fashion/clout/money/boredom. I'm doing it because I refuse to work with the mental illness that the JavaScript ecosystem has become.

miiiiiike 3y ago

Are there any large sites that use Django Ninja? I've been using DRF for about a decade and there hasn't been a moment of enjoyment or ease. I adore Django but wish it had an official REST contrib package. [0] With DRF dragging its feet on async (leaving it to a third-party library) I just want to quit. I'm building a new async api soon, are there any Django Ninja case studies? I can't find anything. [0]: Using Django.. Me in 2008 — "How do I get data from a PUT/PATCH request without a library?" Me in 2023 — "How do I get data from a PUT/PATCH request without a library?"

megaman821 3y ago
Django Ninja just hit 1.0 a few weeks ago. I think you are going to have to be patient to find large sites using it in production.
- miiiiiike 3y ago
  I've never heard of anyone using it in production, period. The one thing FastAPI had going for it back when it was announced was a list of companies and groups with it deployed that minute. Is it a "1.0 because we think it's done and you should try using it now. Maybe it'll work." Or "This is a solid 1.0 that has been tested in production. You can expect reasonable api stability." FastAPI launched with option three: "We're going to get our friends to use it in production so we can say it's deployed by Microsoft, but, this is definitely a pre-alpha."
  - megaman821 3y ago
    I am using it myself on a branch I haven't pushed to production. I would say DRF has better documentation and more packages that extend its behavior (like exporting to Excel). Ninja is a lot cleaner though, it works better with type checkers, and if you are also using FastAPI there is basically no learning curve.
    - miiiiiike 3y ago
      Django Ninja has always looked beautiful. I've been toying with it since it was first announced, never pushed it to production tho. I've been thinking of spinning up a cluster just to dark launch it with calls from my main app to see how it performs.

Svetlitski 3y ago

While I don’t use it anymore and have been out of the web dev space completely for a few years now, I personally feel I owe a lot to Django. It’s the framework behind the first software I wrote that other people actually used and depended on. While looking back at it now the first Django code I wrote was pretty awful, it’s astonishing how much the framework lets you accomplish. Without knowing much at all about web development or databases, following the Django tutorial is sufficient to get you started with a very basic web app, and you can grow from there. Couple this with the superpower that was deploying to Heroku, and it made for a fantastic introduction to web dev and shipping software to real users.

ajhai 3y ago

I've been using Django as my main choice for web projects for over ten years. The reason I like it so much is because it comes with a lot of built-in features that one needs to ship web projects to production. For example, I was first attracted to Django because of its admin interface and its straightforward views and templating system. Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins. My recent use of Django is in (https://github.com/trypromptly/LLMStack https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.

honestduane 3y ago

And django-timezone-field and others are not currently compatible, blocking upgrades.

agumonkey 3y ago

Be sure to check out the Query base classes (Func, etc), it helps getting over the choice '__prop__func' as syntax.

quantiq 3y ago

Django is such a lovely framework I can't speak higher praises of it. I'm blessed to still be able to use it in my day to day work. It's maybe not the most flashy framework out there these days but Django and Rails are really the Toyota Corollas and Honda Civics of the web dev world that often go so underappreciated for their unfussy reliability. :)

anon373839 3y ago
I’d say they’re the Lexuses of the web dev world. Very nicely appointed and rock-solid, just not very sexy.
- pwython 3y ago
  The Lexus LFA would like to have a word with you.
  - anon373839 3y ago
    Touché.

the__alchemist 3y ago

Django owns! The blazingly-fast flask-alikes that come out in Python and Rust every year still can't touch it for building websites. My only beef is that the official docs and community chats make you feel like you're an outlaw or doing things wrong if you use the raw SQL API. Regarding this new version in particular, the feature that jumps out at me the most is the improved field choices. I've been using an odd workaround with the decorator API to tie them to python Enums.

Darmody 3y ago

I usually hear this question the other way around but there it goes. Why should someone consider Django instead of something like Symfony or Laravel?

biorach 3y ago
Because they know, or want to know Python
- Darmody 3y ago
  Thank you, mister, but I mean from a techy point of view.
  - biorach 3y ago
    I only know laravel from skimming the docs, but I got the impression that there was not enough difference between it and Django to justify switching to a language you don't know,going either way. That said... Does Laravel have something like Django's admin view?
    - Darmody 3y ago
      I guess the equivalent would be Laravel Nova.

Mystery-Machine 3y ago

How does Django compare to Ruby on Rails? Any developers in here that tried/used both frameworks?

deleted 3y ago

[deleted]

djstein 3y ago

for those keeping up with Django’s async story the biggest updates with Django 5.0 are: The new asynchronous functions are now provided, using an a prefix: django.contrib.auth.aauthenticate(), aget_user(), alogin(), alogout(), and aupdate_session_auth_hash(). AuthenticationMiddleware now adds an HttpRequest.auser() asynchronous method that returns the currently logged-in user. [Edit: paste wasn’t the full sentence]

bdcravens 3y ago

I work in the Rails world, and perhaps my perception is colored by the big changes they tend to make, but this seems like more of a minor than a major version release? Or is this relatively big for Django?

iamsanteri 3y ago
I'd be also interested to hear someone proficient have an opinion about this. A 5.0 update sounds like something big. What about the rest of the async parts in Django having been in the process of being re-written since a while, as I've heard? Also has it ever been considered to build some deeper integration of Celery for enabling and handling in-memory background job processing in a more closely and "better-integrated" way akin to Rails' active job?
Humphrey 3y ago
Yes, relative minor update. Django is very mature and does most things needed, so there has not been need for major changes since about 2.0. Django releases are now based on a schedule, so the 5.0 label wouldn't have been chosen because of significant changes. But, I have observed that releases often look like this: - X.0 Newer shinier features - X.1 More refinement and minor features - X.2 [LTS] More refinement and minor features Which means if you stick to the point 2 releases you get longer support and subjectively more stability since the shiny new features have been polished over a couple of point releases. But in reality these days, I think it's just whatever features are ready to ship for the scheduled release date.

rossant 3y ago

What an incredibly powerful, robust, well-documented, carefully-designed piece of open source software. I love Django so much and I use it every day. A huge thanks to all developers and maintainers.

local_crmdgeon 3y ago

Is there a good JS/TS Django replacement? Something mature? I know a few were taking shots at it, but I truly hate Python and have a JS team

local_crmdgeon 3y ago
Did RedwoodJS ever take off?

MugoyaDihfahsih 3y ago

Been using Django starting from version 2.2 ever since then the release of new upgrades has been charming. Thanks to the team for the new improvements.

cushychicken 3y ago

Know what ChatGpT is real good at? Writing Django. Using that to my advantage lately.

kdwikzncba 3y ago

Does anyone else find this obsession with expanding database-related features weird?

PrivateButts 3y ago

I loooove Django, any project that I work on that isn't Django causes me to yearn for it greatly. However, there's two things that have been minorly bothering me about it: - The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party). - The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks compared to how baller DRF is. It's still a massive fight to get subscriptions working well. It would be nice to see the foundation throw them a bone like they did with Channels.

patrick91 3y ago
Hi there! I work on Strawberry GraphQL, would be interested in sending me a list of the things that we can do better? You can send me a dm on discord or open an issue on discord, I plan to spend more time on Strawberry next year, so hopefully I can make it good for you!
- PrivateButts 3y ago
  Sure thing! We have migrated to Strawberry for all our projects going forward, next time I have my hands in those project guts for maintenance I'll document some and send it on.

nprateem 3y ago

Anyone experienced performance improvements by using pypy instead of cpython with django?

rrishi 3y ago

Coincidentally, I am just beginning to learn Django. I have experience with NextJS, Express and Flask. In the past, Django had intimidated me due to having so many official-sounding files and folder structure and settings etc. So, I had just not given it too much brain cycles. After having experience with the earlier listed frameworks, I can appreciate some of the things Django gives out of the box. It feels "industry-grade". Hoping to make fond memories with Django just like the other experiences described here! Happy holidays everyone!