[HN Gopher] Django 5.0
___________________________________________________________________
Django 5.0
Author : sarahboyce
Score : 451 points
Date : 2023-12-04 13:44 UTC (9 hours ago)
(HTM) web link (www.djangoproject.com)
(TXT) w3m dump (www.djangoproject.com)
| sarahboyce wrote:
| Release notes:
| 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/
|
| * What's new in Django 5.0 [video]:
| https://youtu.be/lPl5Q5gv9G8?feature=shared
|
| * Database generated columns(1): Django & SQLite [blog]:
| https://www.paulox.net/2023/11/07/database-generated-columns...
|
| * Database generated columns(2): Django & PostgreSQL [blog]:
| 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_djang...
| h4kor wrote:
| 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 wrote:
| They switched their versioning scheme after the 1.x.
|
| https://docs.djangoproject.com/en/dev/internals/release-proc...
| freedomben wrote:
| Have you worked with ActiveRecord or Ecto? Just wondering for
| framing your comment
| ralmidani wrote:
| 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 wrote:
| 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 wrote:
| I briefly used Ecto when trying out Phoenix framework but
| have not worked enough with it to form an opinion.
| DarkNova6 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| har777 wrote:
| Simple middleware can warn you about lazy loading/N+1
| queries. Most of the time people just forget it happens.
|
| Try using: https://github.com/har777/pellet
|
| Disclaimer: I built it :p
|
| You can easily see N+1 queries on the console itself or write
| a callback function to track such issues on your monitoring
| stack of choice on production.
| dinkleberg wrote:
| That looks handy, thanks for sharing! I used to use some
| other n+1 logger, but yours actual shows the query which is
| more useful.
| fbdab103 wrote:
| Have a pitch on what differentiates this from django-
| toolbar? Just the focus on query count monitoring?
| har777 wrote:
| Yeah the query count monitoring is the main focus as N+1
| queries are super common in Django.
|
| I don't really have a pitch but here is why this was
| made:
|
| 1. we had a production DRF app with ~1000 endpoints but
| the react app consuming it was dead slow because the
| api's had slowed down massively.
|
| 2. we knew N+1 was a big problem but the codebase was
| large and we didn't even know where to start.
|
| 3. we enabled this middleware on production and added a
| small callback function to write endpoint=>query_count,
| endpoint=>query_time metrics to datadog.
|
| 4. once this was done it was quite trivial to find the
| hot endpoints sorted by num of queries and total time
| spent on queries.
|
| 5. pick the most hot endpoint with large number of
| queries, enable debug mode locally, fix N+1 code, add
| assertNumQueries assertions to integration tests to make
| sure this doesn't happen again and push to prod.
|
| 6. monitor production metrics dashboard just to double
| check.
|
| 7. rinse and repeat.
|
| For me this ability to continuously run on prod -> find
| issues and send to your monitoring stack -> alert -> fix
| locally workflow is the main selling point. Or of course
| you can just have it running locally on debug mode and
| check your console before pushing your changes but
| sometimes its just hard to expect that from every single
| engineer at your company. Then again your local data
| might not cause an issue so production N+1 monitoring is
| always nice.
| fbdab103 wrote:
| Monitoring production is the piece I was missing. Was
| thinking of it as strictly for development.
|
| Unless it adds a bunch of overhead, seems like a no-
| brainer to enable.
| har777 wrote:
| It only adds like ~5ms. Unless you have
| `query_level_metrics_enabled` as True which takes more
| time. I didn't find that particularly useful on prod and
| instead just used it locally when fixing stuff. Depends
| on what data you need populated in your callback function
| on prod.
|
| The header feature can also be useful. If you have a
| client on-call who's complaining about super slow page
| loads. Just check their network tab and see which
| response has a query count/time header which seems
| unnatural.
| Izkata wrote:
| I did this by adding every SQL query to a new log file
| (only active in development), then tailing it while
| developing. Not only is 1+N very visible as a long string
| of the same query over and over, it also lets you see in
| real time when there's a long pause from a query taking
| longer than expected.
|
| Also we often had something that was more like 1+3N,
| basically a 1+N problem but it was looping through the same
| 3 queries over and over.
| bdzr wrote:
| FWIW Sentry has recently (within the last year or so)
| rolled out support for N+1 monitoring as well.
| fbdab103 wrote:
| Non-performant code is going to eventually slip into any
| codebase. The trick is to monitor for when performance falls
| to an unacceptable level. Not toss all ORMs because some
| minority of generated queries are problematic.
|
| If maximum performance, 100% of the time was the end-goal, I
| would not be writing Python.
| DarkNova6 wrote:
| The python team I joined grew their codebase from a thin
| data access layer into a full blown application. Staff was
| full of data guys and had no idea about application
| engineering, but lots of opinions. The client was another
| company who intended the product as heart of their digital
| transformation.
|
| Guess who had to refactor this mess and steer away from
| catastrophy.
|
| I'm haunted to this day.
| fbdab103 wrote:
| That general story can happen with any tech stack.
|
| POC whipped together without good architecture. Having
| proven itself, usage increases until the application
| starts to burst at the seams. Program must be redesigned,
| avoiding performance gotchas.
|
| I still think Django + the ORM give you a lot of runway
| before performance should be a concern.
| h4kor wrote:
| I'd rather have a slow page because of lazy loading, than a
| wrong page because the related objects are not loaded (i.e.
| typeorm)
| greenie_beans wrote:
| lol been refactoring something like this
| robertlagrant wrote:
| I sort of said this elsewhere. Others are saying "that's just
| what happens" and "well, Python?" but it doesn't just happen,
| and slow database queries are nothing to do with the
| application language. The problem is Django ORM, like Ruby on
| Rails, uses the Active Record pattern. Alternate ORMs, such
| as SQLAlchemy or Hibernate, uses Data Mapper pattern, which
| avoids the pitfalls of Active Record.
| pmontra wrote:
| We can have 1+N queries in any language even without an
| ORM. Maybe an ORM facilitates mistakes because it hides
| joins but lack of experience is lack of experience. Some
| naive bad pseudocode: for book in select *
| from books: author = select * from authors
| where id == book.id print book.title author.name
|
| In the real world that nested select could be hidden many
| levels down in method or function calls or even in code run
| from the templating language. Example: Django templatetags
| can query the database from the HTML template and any
| framework or non framework I worked with can do that too.
| gen220 wrote:
| I think Django's ORM is a product of its time, when
| limitations about the expressibility of the "active record"
| concept were not fully understood.
|
| I like to describe it as Django's ORM will satisfy 80% of
| your needs immediately, 90% if you invest and sweat, 95% if
| you're quite knowledgeable in the underlying SQL. But there
| are still some rather common query shapes that are
| inexpressible or terribly awkward with Django's ORM.
|
| SQLAlchemy on the other hand never tries to hide its
| complexity (although to be fair they've become much better at
| communicating it in 2.0). On Day 1 you'll know maybe 20% of
| what you need to. You might not even have a working
| application until the end of week 1. But at the end of, idk,
| month 6? You're a wizard.
|
| The long-term value ceiling of SQLAlchemy/Alembic is higher
| than Django's, but Django compensates for it with their
| comparatively richer plugin ecosystem, so it's not so easy to
| compare the two.
| sarahboyce wrote:
| 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-
| proc...
|
| 2: https://docs.djangoproject.com/en/dev/internals/release-
| proc...
|
| 3: https://fosstodon.org/@carlton/111300877531721385
| adastra22 wrote:
| 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 wrote:
| 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 wrote:
| tbh, any OOP paradigms used with db tables will end up in a
| clusterf*ck.
| alberth wrote:
| 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
|
| Or is the preferred web framework still Django?
| Maxion wrote:
| 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 wrote:
| 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 wrote:
| I've always felt, and this hasn't changed recently, that if
| you're going to need more than, say, 3 of the cross cutting
| concerns that Django provides for, then it'll be much more
| maintainable in the long run to just use Django rather than
| effectively building a custom solution out of parts. The flip
| side: if you're building a small internal API that only needs a
| couple of these, Django might be overkill.
|
| What do I mean by "cross cutting concerns"? I'm thinking about
| ORM/models, migrations, admin UI, caching, sessions, misc
| security middleware, user accounts, validation/forms,
| templating, RSS feeds, logging, testing infrastructure, etc.
| Django's pieces all fit together well, and any time I've done
| this with Flask/etc I've found myself spending so much time
| solving issues gluing these bits together and working around
| impedance mismatches between libraries.
|
| We had a large Django site at my last place and would just
| suggest new starters worked through the Django tutorial,
| because our site basically still worked like that.
| BasilPH wrote:
| I agree. I would even go so far as to say that if you need an
| ORM, go with Django. I've wasted too much time adding
| SQLAlchemy to Flask to get something that is still worse than
| the Django ORM.
| danpalmer wrote:
| Perhaps, but it depends what you're building. SQLAlchemy is
| much more capable, so if you need great database control
| and don't need all the other bits Django is bringing, then
| I kinda get it.
| fbdab103 wrote:
| +1 to that. Maybe SQLAlchemy is a better product, but being
| a bolted on solution makes everything about the ORM
| experience feel worse than using Django. If nothing else,
| it is not just using Flask+SQLAlchemy, now it is
| Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties,
| so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.
| BasilPH wrote:
| Exactly. It's the migration support that I find the best
| feature of Django, but I keep forgetting about it until I
| have to migrate with some other ORM.
| stavros wrote:
| I half-agree with you, I've found that there are two options
| when choosing a framework:
|
| 1. You're making something with 100 lines, which you're
| absolutely sure will stay 100 lines. Go with Flask.
|
| 2. Otherwise, Django.
|
| Django is great at getting out of your way when you don't
| need its functionality, so you can just ignore most of it if
| you don't need it.
| l33tman wrote:
| Second this, if you need a database and users, Django is
| better than the headache of thinking about this yourself
| with all security pitfalls. I've built several production
| APIs around Django (like, not CMS at all) and I find it a
| good compromise between an SDK and rolling your own, this
| is partly due to Python as well of course.
|
| And I've done smaller things with Flask where it would make
| no sense to go with Django as well but those were things
| not really built around a db or CRUD API etc.
| filterfiber wrote:
| I know it's not "shiny and new" but Django is still serving us
| very well were I work.
|
| The only two things it lacks great support of is typing and
| async. However the async is actively being worked on and does
| work (with some quirks), and python's type support has only
| gotten half-mature just recently (coming from typescript at
| least).
|
| I would personally be hesitant to try something new just
| because django is so battle-tested at this stage, unless you
| just absolutely require better async support.
| PurpleRamen wrote:
| Jetbrains Python Survey from 2022[1] has Flask, Django, Fastapi
| dominating the web-frameworks. Not sure how reliable this is,
| but I also barely see any other frameworks mentioned. So they
| either are in a totally different bubble, or just not popular
| (yet).
|
| [1] https://lp.jetbrains.com/python-developers-
| survey-2022/#Fram...
| sgt wrote:
| Still Django unless you're only building a simple API.
| davepeck wrote:
| I choose between Django and Litestar these days.
|
| I wish I had a hard and fast rule for the choice, but it's
| something like:
|
| - Litestar if I know with certainty (a) the thing I'm building
| is and always will be a tiny service and (b) I probably won't
| have to evolve the backing data schema much. Wrap an ML model?
| Litestar. Have a small database I want to expose via API, read-
| mostly? Litestar.
|
| - Django if I know (a) I'm going to be building on this over a
| longer timeframe, (b) I have complex user/group auth needs, (c)
| my data schema will likely go through substantial evolution, or
| (d) I will need an admin UI in the early goings, either for the
| managing team or for customer support.
|
| I have plenty of SQLAlchemy+Alembic+Litestar backends but I
| vastly prefer the creature comforts of Django's ORM +
| migrations; it hits that 80% sweet spot so very well.
| SQLalchemy is both raw power and, often, far too much friction.
|
| I used to choose between Django and Flask, but Litestar --
| while still young -- seems to capture most of the key things I
| liked about core Flask but in a more modern package. (Maybe
| Quart, aka async Flask, will ultimately win the day; not sure.)
|
| It's not targeted at the use case, but I wonder if Datasette
| will replace my need for the Django admin UI at least in some
| limited set of cases.
|
| These days, most of my front-ends are React+Typescript+Vite.
|
| (FWIW I personally avoid FastAPI entirely. I appreciate the
| impact it had getting the python community to think about (a)
| async (b) proper use of type hints in the web context and (c)
| the need for OpenAPI support, etc. but there are a lot of
| footguns and so many issues still opened that its (amazing,
| lovely) single maintainer probably won't get to. SQLModel --
| aka the merging of Pydantic + SQLAlchemy ORM models -- is an
| even bigger trap, IMO.)
| the__alchemist wrote:
| Django; none of the new-hotness one compares. This is my no-
| bullshit answer that comparative articles and these frameworks'
| home pages dodge.
| saasjosh wrote:
| 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 wrote:
| Not much no, but both the GeneratedField and db_default would
| be useful in almost all projects I've ever implemented in
| Django.
| saasjosh wrote:
| 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 wrote:
| can you list the features you mentioned that is lacking in
| django?
| collyw wrote:
| > Another boring release without much innovation
|
| That's a good thing. A couple of articles related to the topic.
|
| https://boringtechnology.club/
|
| https://www.david-dahan.com/blog/10-reasons-mvc-frameworks-a...
| brycewray wrote:
| 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 wrote:
| 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.
| jmduke wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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). 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).
| 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) which gives your front-end routing
| information based on the Django router.
| zelphirkalt wrote:
| If you really need VueJs in the frontend, consider, that you
| can simple serve the VueJs on any page where it is actually
| needed. VueJs does not necessarily mean you must create a
| SPA. VueJs can be delivered like any other script and this is
| often the easiest way without having to commit to build a
| full blown SPA.
| jim180 wrote:
| Coming from iOS/macOS background, I've kinda enjoyed Django
| with its all time classics (forms, templates, etc.) + HTMX.
|
| Admin interface was extremely helpful, when we are trying to
| validate business idea.
| amir_karbasi wrote:
| How was the effort to migrate from DRF to Django-Ninja? I saw
| Django-Ninja mentioned in another post and am thinking of
| switching one of my projects over from DRF. After skimming
| their documentation, it looks very pleasant and simple and
| perfect for my use case.
| jmduke wrote:
| Going from 0 - 1 migrated route was "medium difficulty", I'd
| say -- there was a non-trivial amount of scaffolding I had to
| build out around auth, error codes, and so on, and django-
| ninja's docs are still a little lackluster when it comes to
| edge cases.
|
| Once I had that one migrated route, though, the rest were
| very simple. (And I am very happy with the migration
| overall!)
| crucialfelix wrote:
| I've had that on my list to try out for a while now.
| FastAPI is a joy, having generated OpenAPI is a must, so
| Ninja sounds good.
|
| I've had quite enough of DRF's tower of mixins and rails
| like magic. It always sucks up development time and fails
| too easily.
| collyw wrote:
| Agreed, the admin makes development so much easier, being able
| to easily enter and view your data.
| cdcarter wrote:
| GeneratedField looks interesting, but I'm not _really_ sure
| what gains I get over just calling annotate() on my queryset
| with some computed fields. At least on the backends where the
| computed GeneratedField isn't stored.
| radus wrote:
| It's easier to re-use if you need the same generated field in
| multiple places.
| cdcarter wrote:
| I've been in the habit of replacing the default manager for
| my model with one with an annotated query set. that way,
| any Model.objects.all() call will have the computed fields.
|
| I find this pretty easy to get used to and re-use. though I
| do admit I like them defined as actual model-fields with
| verbose names etc...
| apstats wrote:
| 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.
| bastawhiz wrote:
| 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.
| Vinnl wrote:
| In case you're interested, Firefox Relay uses that stack and is
| open source: https://github.com/mozilla/fx-private-relay/
| vangale wrote:
| Posthog uses react for front-end and django for back-end.
| https://posthog.com/handbook/engineering/project-structure
| scrollaway wrote:
| 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 wrote:
| 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 wrote:
| Mobile
| collyw wrote:
| 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.
| lagt_t wrote:
| No thanks, I prefer to drop React and use django + htmx for
| ajax.
| kbrannigan wrote:
| What do people like torturing themselves by duplicating code.
| Wouldn't it be easier to just use node all the way.
|
| Writing hundreds of lines of JS to display a Table list,
| instead of HTML sprinkled with some JS
| globular-toast wrote:
| I've gone the opposite way. Started converting views to rest
| framework viewsets and building React components on the front
| end. It just created more problems. Now the React stuff is
| considered legacy and we're using HTMX and the bare minimum of
| vanilla JS when necessary.
| BasilPH wrote:
| I'm excited to try the field group templates, I expect it to make
| handling forms styled with Tailwind much easier.
| stosssik wrote:
| can you list the features that are lacking in django?
| pphysch wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| snoopsnopp wrote:
| Totally agree, but is Ember truly the most stable? This is
| pretty much my only criteria for JS at this point.
| ralmidani wrote:
| If you want a heavyweight JS framework, Ember is the most
| stable and best supported. I enjoyed Ember when I used it in
| the 2015-2017 time frame.
|
| But I'm abandoning the heavy JS paradigm in favor of htmx.
| Aside from the fact that I don't want to duplicate routing
| and data validation across client and server, htmx is
| intentionally a single JS file with no build step, so in
| theory it should run fine as long as browsers maintain
| backward compatibility.
| mattwad wrote:
| As a full-time Node.js dev, I agree with your decision! Too
| much time is wasted on compatibility problems. I'd almost say
| it was easier when we just had browsers to deal with. At least
| you could just drop in jQuery and call it a day.
| ralmidani wrote:
| Yes, jQuery is often derided as outdated, but it worked quite
| well for a very long time, with minimal hassle for
| developers. In fact, I was working full-time on static
| Elixir/Phoenix pages with jQuery sprinkled on top as late as
| 2022... it felt a bit clunky but it worked as advertised and
| wasn't frustrating in any significant way.
| kbrannigan wrote:
| I still use JQuery because of all the syntactic sugar and
| shortcuts.
| firecall wrote:
| Me too, I prefer the API.
|
| At the end of the day I'm delivering reliable and
| productive solutions for my clients, and they don't care
| what the tech is.
|
| However the Django API, GraphQL with React front end
| stack I've inherited is an frustratingly flakey to use
| and a nightmare to develop :-/
|
| It's so bad I'm regretting all my life choices that led
| me to this point LOL
| dinkleberg wrote:
| I'm with you on this, Django + HTMX + Vanilla JS (where needed)
| just works which is a beautiful thing.
|
| Is building out the UI clunkier with Django templates than with
| JSX? Absolutely.
|
| But not having to worry about both server and client side state
| is such a time saver and you know it is going to continue to
| work.
|
| For the past few years I've been using Go (using Gin) in place
| of Django, and it works nicely and is quite a bit faster.
| However, recently I've been toying around with Django again,
| thinking about making it my default for new projects because it
| really does take care of so much that you'd otherwise have to
| deal with yourself.
| Klonoar wrote:
| An approach I've done in the past for projects that are
| publicly API-based:
|
| Django handles the database migrations and user
| accounts/models/etc - and you get the useful admin to boot,
| which is just incredible if you ever need to open up the data
| layer to someone else.
|
| Then just write the API interface in Go/Rust/your language of
| choice. It decouples the DB modeling from the API layer, but
| in practice... I've just not run into significant issues with
| it. I'm sure it could be an issue though, so YMMV.
| rigoleto wrote:
| > I'm going to skip the drama and just use htmx for the client-
| side. 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.
|
| More of a side comment, but I'm skeptical of the way HTMX
| encourages partial renders like this. It feels like a premature
| optimization that adds more complexity on the back end. `hx-
| select` takes care of it, but to me it feels like it should be
| the default (it's what Unpoly does).
| ralmidani wrote:
| There is a header that htmx injects to indicate you want a
| partial render, and it's really not that hard to add an if on
| the server-side to check for it. A larger codebase would
| probably break templates up anyway for maintainability, so
| it's just a tiny amount of extra work if you want to reduce
| the amount of HTML being sent over the wire and swapped in.
| megaman821 wrote:
| There is a package, https://github.com/carltongibson/django-
| template-partials, that is basically like server-side hx-
| select, when there is some performance concern. Overall, I
| agree with you though, hx-select is going to be fine most the
| time.
| ralmidani wrote:
| Thanks for sharing that! I also just finished watching
| Carlton's talk from DjangoCon EU (linked in the repo) and
| it is gold: https://youtu.be/_3oGI4RC52s
| winrid wrote:
| Django and django-unicorn is really nice. It feels like
| meteorjs but for Django, extremely productive. I've been
| working with the creator closely and he's awesome.
| mattgreenrocks wrote:
| django-unicorn is really impressive! So glad to see people
| pushing back on all the gunk inherent in webdev still.
| rollcat wrote:
| > 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).
|
| I've been using Django since before 1.0, and the upgrade story
| has been nothing short of fantastic for something that's been
| around this long. But still, YMMV!
|
| Depending on how ancient a project you run into, it definitely
| can be a major pain, even with the original authors' best
| intentions. For example, Django didn't have its own DB
| migration system until 1.7 (relying on third party solutions);
| this means you also have to adjust the deployment procedure,
| which means recreating an ancient setup (ideally in an easily
| repeatable fashion, because you're going to be trying that
| migration at least a dozen times).
|
| The builtin admin system is also a pretty decent CMS on its
| own, but falls short as you run into slightly more complex use
| cases (such as basically anything that requires even a single
| line of JS). The docs will encourage you to copy and override
| the builtin templates; this often becomes a pain point during
| upgrades. It's wise to get off the builtin admin system as your
| project grows.
| Alex3917 wrote:
| FWIW I've also had the same experience; the last version of
| Django where upgrading took a non-trivial amount of time was
| 1.8, because it changed how isolation is enforced within test
| cases. Since then it's rarely taken more than an hour or two,
| regardless of how big the codebase is.
| greenie_beans wrote:
| i've been using django + htmx and vanilla js where needed. it's
| great!
|
| my biggest beef with it is code organization, which will only
| get better with more experience. and it's a side project so it
| doesn't matter. i do worry about using it on a team because i
| could this stack getting messy if not done the right way.
| Keats wrote:
| I haven't used Elixir yet and mostly using flask in Python for
| work but I started with Django (and still think it's better
| than flask for most apps). If stuff like
| https://github.com/aesmail/kaffy (first thing I've found on
| google, never heard of it before) is on par with the Django
| admin, would you still use Django or Elixir and never look
| back?
| ralmidani wrote:
| I don't know if I would "never look back" to Django (I'm a
| sentimental person). But admin is one aspect, the other big
| one is auth. I also like DTL better than EEx/HEEx. And all
| the pieces of Django just fit together really nicely; where
| Ecto happens to be the preferred way to interact with a
| database from Elixir, and Phoenix happens to be the preferred
| way to build Web apps using Elixir, (maybe with Ash layered
| on top), they weren't designed by the same people, so you
| have packages like ecto_phoenix, ash_phoenix, etc. to make
| them all play together in an elegant way.
|
| I will admit, Elixir and Phoenix have better real-time and
| scalability stories.
|
| If I had a choice I would probably prefer
| Elixir/Phoenix/LiveView when joining an org to work on an
| established codebase that may have actual scalability needs
| and concerns. But I would probably prefer Django when
| starting from scratch.
| SadWebDeveloper wrote:
| 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 wrote:
| 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 wrote:
| Django is free, in all definitions and purposes of the word.
| No agenda, no VC funding, no BS.
| yuppiepuppie wrote:
| 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 wrote:
| 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?
| ds3w2 wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| It pulls together gunicorn, Celery, Redis, Postgres, esbuild and
| Tailwind with Docker Compose. It's set up to run in both
| development and production.
| 93po wrote:
| 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 wrote:
| React? Or back-end with NodeJS
| asylteltine wrote:
| 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 wrote:
| > It's so strange people still use rails
|
| Why? What makes Django better? (Genuinely curious.)
| collyw wrote:
| 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.
| dopamean wrote:
| You should learn a bit about Rails. It wont be strange that
| people still use it.
| jononomo wrote:
| 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 wrote:
| * if you can accept the flaws in Python for your usecase
| st3fan wrote:
| Type hints everywhere?
| radus wrote:
| 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
| loughnane wrote:
| 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 wrote:
| 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
| miiiiiike wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nrjames wrote:
| Not a large site, but I used django-ninja in production for
| internal tooling at a very large game dev/publishing
| company. The APIs routinely handle 1000s of calls (via an
| integration with Dagster) for moving large amounts of data
| around and into a reporting system. It's rock solid and
| fast. I'm on v0.22 however and need to do some refactoring
| to move to 1.0 because of changes to the integration with
| Pydantic.
|
| It is so easy to set up and use and it's at worth giving it
| a spin if you're curious.
| miiiiiike wrote:
| Thanks. 1,000s of calls a second/minute/day?
| nrjames wrote:
| Because of the integration with Dagster, the calls are
| made when my Dagster flows run. I also send unreasonably
| large data payloads. Anything going into Django gets
| handed to a Celery batch processing job and just returns
| the job id (Dagster monitors for failure, too). Data
| pulled out of Django is paginated. Sometimes it's 1000s
| of calls per minute, sometimes it's none at all for
| hours. I realize this isn't a normal use case, though. :)
| miiiiiike wrote:
| Thanks.
| Svetlitski wrote:
| 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 wrote:
| 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). We use Django Channels
| for WebSocket support, DRF for APIs, and ReactJS for the
| frontend.
| honestduane wrote:
| And django-timezone-field and others are not currently
| compatible, blocking upgrades.
| agumonkey wrote:
| Be sure to check out the Query base classes (Func, etc), it helps
| getting over the choice '__prop__func' as syntax.
| quantiq wrote:
| 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 wrote:
| I'd say they're the Lexuses of the web dev world. Very nicely
| appointed and rock-solid, just not very sexy.
| the__alchemist wrote:
| 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 wrote:
| 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 wrote:
| Because they know, or want to know Python
| Darmody wrote:
| Thank you, mister, but I mean from a techy point of view.
| Mystery-Machine wrote:
| How does Django compare to Ruby on Rails? Any developers in here
| that tried/used both frameworks?
| djstein wrote:
| 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 wrote:
| 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 wrote:
| 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?
| rossant wrote:
| 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 wrote:
| 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 wrote:
| Did RedwoodJS ever take off?
| MugoyaDihfahsih wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-04 23:01 UTC)