[HN Gopher] Django 4.2 Released
___________________________________________________________________
Django 4.2 Released
Author : petr25102018
Score : 123 points
Date : 2023-04-03 17:47 UTC (5 hours ago)
(HTM) web link (www.djangoproject.com)
(TXT) w3m dump (www.djangoproject.com)
| locusofself wrote:
| I've been away from python for quite some time but enjoyed using
| django on a project 5-6 years ago. I thought it was really full-
| featured and fairly intuitive, but it seemed to rely heavily on
| what seems to be considered an older paradim of submitting forms,
| and getting sent to a new page, etc, vs the "Single Page
| Application" concept.
|
| I know it was possible to do SPAs with django-rest or something,
| but I'm curious if Django has mostly stayed in this "older"
| paradigm or if its more .. modernized at this point?
| nagyf wrote:
| Does SPA concept work well with search engines? I moved away
| from web development, but SPAs used to be very bad if you
| wanted to appear in Google search.
|
| Btw I was looking into Django recently, they are still using
| the "older" paradigm you are referring to.
| petr25102018 wrote:
| You can server-side render the SPA. Not with Django, but with
| things like Nuxt or Next.
|
| Then the SEO penalty is just the increased page size (maybe
| some extra loading time). But at least the content can be
| crawled normally.
| crop_rotation wrote:
| I think Google is capable of handling SPAs these days (it can
| execute js now), so works fine mostly (might still be better
| to serve full HTMLs to start with).
| bmelton wrote:
| It technically _can_ render javascript, but there 's a
| performance penalty that negatively affects your crawl
| budget.
|
| If you're twitter or facebook, or have enough domain
| reputation already that your crawl budget is big enough to
| offset, then it doesn't matter. If you are not already a
| big deal, then it takes a lot of off-site traction to
| overcome.
|
| Practically speaking, for two otherwise-even sites just
| starting out, a statically rendered site has a pretty
| significant SEO advantage over a JS-only site.
| 411111111111111 wrote:
| (Which is why hydration is a thing)
| boolean wrote:
| The old paradigm is new again. Combining Django with HTMX, you
| get the simplicity of rendering HTML on the server side and not
| deal with bloated and over-engineered Javascript frameworks.
| Flask/Django with HTMX and Tailwindcss is a fantastic
| combination and my current preferred stack. I also add Alpinejs
| to this mix for interactivity. Really enjoying the heightened
| productivity that this setup provides.
| ryanisnan wrote:
| This looks really interesting. I haven't come across HTMX
| before, but I'll give it a look.
| soperj wrote:
| Honestly, the SPA concept is flawed, and throws away all the
| good things that HTML gave you out of the box. I'm glad people
| are starting to come to their senses and are moving away from
| it.
| Mimmy wrote:
| Do you mind elaborating on the good things HTML gives you
| out-of-the-box that SPAs throw away?
| chungy wrote:
| Like everything, they are useful as a tool in certain
| contexts, particularly the application context.
|
| Just don't try to pretend it's a "good for everything" tool.
| guggle wrote:
| A few things: 1/ "older" paradigm is still
| extremely useful in many cases 2/ we also use Django as
| a backend for SPAs. Here with Vuetify 3/ using the HTMX
| paradigm, you're both doing SPA and "older paradim of
| submitting forms"
| Gordonjcp wrote:
| Why would you want to do SPA? What does it actually do to
| improve life for users?
| viraptor wrote:
| SPA is just "a way" to do things. You're describing them as
| older/modern, but they're simply different approaches to
| achieve different things.
| samwillis wrote:
| There's a brilliant project called Django Unicorn that aims to
| be the equivalent of Laravel Livewire for Django. You should
| take a look.
|
| https://www.django-unicorn.com/
|
| That and HTMX + Alpine.js are a strong combination.
|
| (I also had a bash at building a similar tool for Django called
| Tetra but unfortunately haven't had the time needed to commit
| to it: https://www.tetraframework.com)
| cultofmetatron wrote:
| but how does it stack up against phoenix liveview? ;)
| elAhmo wrote:
| Djangi can also work well with turbolinks
| PrivateButts wrote:
| For fancier, SPA style applications we utilize Strawberry to
| add GraphQL support into Django. It's pretty enjoyable to work
| with, but I would love for GraphQL to get more love from Django
| officially.
|
| Subscriptions are still a bit thorny, but have come a long way
| now that ASGI and channels are a focus for the Django team.
| tmnvix wrote:
| You might want to look into HTMX (https://htmx.org/). It's very
| popular in the Django community.
| simonw wrote:
| I'm relieved to see that the idea that SPAs are a "modern",
| better way of doing things seems to finally be fading a little
| bit.
|
| My experience from lessons learned over the past ten years is
| that SPAs generally take longer to build, are usually slower to
| load, have much worse accessibility and are more expensive to
| debug and maintain.
|
| For a great deal of web projects you're better off with the
| "old paradigm".
|
| That said... I do think there's an argument to be made that
| Django should include core framework features that make working
| with SPAs easier, rather than farming that out entirely to
| Django REST Framework.
|
| Django 4.2 does have one nod in that direction:
| https://docs.djangoproject.com/en/4.2/releases/4.2/#django-c...
| - "ManifestStaticFilesStorage now has experimental support for
| replacing paths to JavaScript modules in import and export
| statements with their hashed counterparts".
| pen2l wrote:
| Why not just absorb DRF? Which as I understand is the leading
| choice for many, so I wonder if some effort should be
| dedicated to reducing fragmentation.
| crop_rotation wrote:
| Django is ver good if you are writing non SPA with a SQL
| backend. If you are writing a SPA without a SQL backend (any of
| the noSQL DBs), it becomes much easier to just use
| flask/quartz/fastAPI, as you don't benefit from the Django
| niceties.
| Klonoar wrote:
| It's fine even if you're writing an SPA, the "niceties" don't
| really get in the way at all.
| varispeed wrote:
| and when you find yourself actually needing "niceties" they
| are right there waiting...
|
| I've been trying those alternative libraries from time to
| time and there is always the thought "I wish I started this
| in Django" when project becomes more complex than a basic
| endpoint.
| roger20 wrote:
| https://www.django-rest-framework.org/
| epivosism wrote:
| I keep wanting to switch personal projects to use my professional
| language C#, but there still is nothing as reasonable as a django
| default admin view with CRUD for the entities you create, so I
| always go back.
| canadiantim wrote:
| I love Django, but I can't help but feel FastAPI > Django these
| days.
| thewataccount wrote:
| We use django for our websites where I work, and I use it for
| personal projects for the ORM.
|
| How do you like the ORM for FastAPI? I've wanted to try it but
| since I already know how to use django it's been hard to find a
| reason to try FastAPI. Currently I _really_ like Django's orm.
| WD-42 wrote:
| There is no official ORM for FastAPI. You have to pick one
| yourself. Probably the most common choice is Sqlalchemy,
| which is not nearly as nice to work with as Django's ORM, in
| my opinion. It's also annoying to wire up.
|
| For non-db backed projects (but let's be honest, how many
| projects don't use a DB) FastAPI is a great choice.
| Zetice wrote:
| You end up missing Django's ORM when you can't use it, as
| well. I've tried my best to recreate the experience with
| Prisma in JS but it took me awhile to get to a place where I
| felt like I wasn't duplicating schema...
| barefeg wrote:
| FastAPI doesn't come with an ORM out of the box. There's
| https://sqlmodel.tiangolo.com/ which wraps SQLAlchemy and
| allows defining the database models with pydantic-like
| classes.
|
| For me neither Django nor SQLAlcjemy hit the right spot when
| trying to define "pure" domain models that have no dependency
| (I.e. no ORM information). For that I created a repository
| pattern approach that converts "domain mode operations" into
| SQLModel query operations via filter specifications
| (https://martinfowler.com/apsupp/spec.pdf).
|
| The result is that I always need to define 2 models: one is
| my pure domain model and another is a "table model" (defined
| in SQLAlchemy) along with a mapping between the two (for
| cases where there's no 1-to-1 trivial mapping between their
| fields). Also making some of the SQLAlchemy magic (for
| example back propagating relational attributes) is messy.
|
| But if you want to produce some quick applications I think
| SQLModel+FastAPI works quite well. I don't think is as mature
| as Django though.
| miketery wrote:
| How does FastAPI compare on the ORM and serialization front? I
| enjoy using djangorestframework and it's been nice leverage for
| me, especially dealing with binary formats (eg keys).
| SCUSKU wrote:
| A good compromise I have found is to use Django Ninja [1]. It
| is inspired by FastAPI, so it has a lot of the nice things like
| the automatically generated Swagger/OpenAPI docs, as well as
| having routers as decorators, and using python types for
| automatic serialization.
|
| While I think FastAPI is great in its first class async
| support, Django has the Django ORM, plus Django Admin, which
| for me have been indisposable.
|
| [1] - https://django-ninja.rest-framework.com/
| 0cf8612b2e1e wrote:
| Is FastAPI still a bus factor of one? Last time I looked a year
| or two ago, there were quite a few "easy" unresolved PRs that
| could have been handled with a bigger team.
|
| Django may be considered boring and old school, but it does so
| many things right that the barrier to switching is quite high.
| Nextgrid wrote:
| Are there really many projects where the actual web framework
| is the bottleneck, as opposed to the DB?
| simonw wrote:
| Does Django's increasing levels of support for asyncio balance
| things back for you at all?
| tmpz22 wrote:
| Not GP but $work is DRF + React.
|
| For new projects async runtimes are enticing but its really
| hard to switch to or from a async runtime with an existing
| project. Similarly moving to or from the Django ORM or
| SQLAlchemy + Pydantic is too much work for most to justify.
|
| So whatever fully featured framework you start with will be
| the one you stick with. They all have warts and hurdles but
| should get you where you need to be from a business
| perspective.
| bbbbzzz1 wrote:
| I feel like lately js (and more importantly typescript)
| frameworks have been more popular. If someone were to start a new
| project today, how does Django standup to the current offerings?
| crop_rotation wrote:
| If you use a RDBMS then Django is a very good choice whether
| you use SPA or not.
| bshipp wrote:
| I agree, although I really wish Django and sqlAlchemy would
| have evolved similar methods/APIs. My struggle is flipping
| between projects that use one or the other and tripping over
| the syntax.
|
| Edit: grammar
| znpy wrote:
| It's boring, well documented, has a ton of modules, extensible,
| solid, robust, reliable, trustworthy.
|
| I'd pick it for these reasons.
| petr25102018 wrote:
| It is different. JS is popular because people who write SPAs
| also want to write backends in the same language.
|
| What I really like about Django and Python ecosystem in general
| is the kind of stability that it doesn't move too fast and
| break things, which happens in JS land too often. And Python is
| a nicer language of the two, for me at least.
|
| But at the end of the day, you can combine both. I work for
| Baserow now and we combine Nuxt + Django. You can also simplify
| it to Vue/React + Vite + serve it with Django, use cookies-base
| auth etc.
| surfingdino wrote:
| Django's hidden powers are its highly customisable admin UI and
| ORM. Add to it Django REST framework and you have a solid
| backend for a wide category of web apps, from the old pre-
| XMLHttpRequest apps to SPAs. Flask or FastAPI get you going
| fast, but you quickly realise that you have to write a lot of
| the code that comes with Django for free.
| zach_garwood wrote:
| Honestly, I think the generic and model views are way more
| impressive than the ORM or the admin. They take away all of
| the boilerplate usually associated with CRUD apps.
| hooverd wrote:
| I personally prefer Django Ninja over DRF for APIs, it's all
| the good parts of FastAPI mixed with Django.
| ye-olde-sysrq wrote:
| Personally I feel like I've unlocked a superpower with this one
| trick (using rails, but this applies equally to django and
| similar "old" page-load-based frameworks)
|
| 1. build your app in the normal, old way. just doing SSR for
| showing and editing boring content is so much faster than
| building it in react.
|
| 2. I have a tiny scrap of JS that digs through elements on the
| page, and if they have a class, creates a React root there and
| passes in some params. I then wrapped generating those replace-
| me-with-a-react-root elements in a Rails helper function.
|
| (2 is my "fine I'll do it myself" after Rails 7's new js stuff
| broke react-rails for me.)
|
| This might be colored by me being a backend dev and data
| engineer type of person and I have terrifically little patience
| for writing javascript. But pages where I've followed this "SSR
| + some React doodads for when you really need special sauce"
| pattern end up so much easier and faster to write than cramming
| it all into a huge SPA.
|
| I'm sure if you're building something deeply fancy then doing
| it all in React makes sense, but I find there's really only a
| couple pages that actually do end up being 100% react and the
| rest end up fine just having a text field here or there or a
| little widget thingy being the React components and the rest
| just being SSR.
|
| I'm sure this doesn't scale if you're google or something
| either but even on my most complicated pages this still loads
| visibly faster than many other sites I use.
| anyfactor wrote:
| I don't do proper web dev work and tried Django ages ago. So,
| this is a very narrow opinion. I use mainly flask and firebase
| these days as a indiehacker.
|
| I don't think currenlty there are any solid alternatives beyond
| Nestjs+Typescript, ruby on rails and laravel. The sentimemt of
| their community is that these frameworks are built for web
| development in mind. While I think for Python based web
| framework like Django the sentiment is that you are using
| Python already and here is a web framework written in Python.
| If you look at some of the Rust based web frameworks you will
| understand what I am saying. The merit of the framework is the
| language it was written in. This makes hiring web developers
| difficult as most candidates will be Python Developer who knows
| Django and not web developers who knows Python. There are very
| few people who learned Python to use Django. But everyone
| learned javascript to use nodejs, or ruby to use ruby on rails.
|
| If I am writing enterprise level where Python is used I will
| pick one of those 3 frameworks and use a Python based API
| framework like DRF or FastAPI for building internal APIs.
| winrid wrote:
| Python is literally the easiest language to learn. Any web
| dev can pick it up, and Django is much more productive than
| NestJS. Rails and Laravel are nice options too. No Rust or
| Java options come close.
| winrid wrote:
| I just got into Django after working with Node/Java for years.
| It's honestly depressing once I realized I have spent so much
| time building CRUD stuff that would have taken 10x less time
| with Django.
|
| I haven't built SPAs yet, but I'm looking into trying Unicorn:
| https://www.django-unicorn.com/
| asciii wrote:
| It just works in most cases. It is nice to be within Python's
| ecosystem as well.
|
| Overall, I've found it great for prototyping up something
| really quickly. I think this is where the "batteries-included"
| helps a lot
| matsemann wrote:
| I feel the opposite. Django is fine, but python ecosystem is
| the big problem. The lack of true multi threading means for
| even the simplest of apps you quickly need to have multiple
| deployments, celery workers etc to handle different kinds of
| workloads.
| winrid wrote:
| You could argue having workers run single threaded code is
| a lot easier than multithreading, depending on your hiring
| pool.
| varispeed wrote:
| Django Rest Framework for getting services up and running quickly
| is a godsend.
|
| If service needs extra performance then can be rewritten in
| Golang later.
| karlosos wrote:
| In what scenarios it would be beneficial to rewrite the Django
| app in Go? Do you mean something specific when saying that Go
| would be good replacement?. I/O heavy or computation heavy
| service?
| chocolatkey wrote:
| I actually did to rewrite parts of django's auth, caching in
| go in order to be compatible with a grpc-based mobile app.
| The django source code is well documented and easy enough to
| understand, so it wasn't a probablem signing sessions,
| creating users etc in go and then using them in django.
|
| For django itself, once I slapped a database caching layer on
| top and tuned gunicorn/uvicorn, there were no performance
| issues. Go is faster, but django is fast enough.
___________________________________________________________________
(page generated 2023-04-03 23:02 UTC)