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?
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".
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)
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"Btw I was looking into Django recently, they are still using the “older” paradigm you are referring to.
Then the SEO penalty is just the increased page size (maybe some extra loading time). But at least the content can be crawled normally.
Subscriptions are still a bit thorny, but have come a long way now that ASGI and channels are a focus for the Django team.
I haven't built SPAs yet, but I'm looking into trying Unicorn: https://www.django-unicorn.com/
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.
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.
Edit: grammar
Overall, I've found it great for prototyping up something really quickly. I think this is where the "batteries-included" helps a lot
I’d pick it for these reasons.
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.
If I need a database and interactivity I pair NextJS with Django Restapi.
Wut? It's more a case of "everyone learned javascript to do button rollovers in the browser, and then nodejs allowed them to do more".
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.
Django may be considered boring and old school, but it does so many things right that the barrier to switching is quite high.
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.
For non-db backed projects (but let's be honest, how many projects don't use a DB) FastAPI is a great choice.
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.
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.
Like, keep the Node.js code but use Django admin.
Are there any comparable projects to Djano admin? A database model that generates an optionally customizable admin UI?
If service needs extra performance then can be rewritten in Golang later.
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.
However now doing mostly Kotlin with Ktor and loving it. Just a better language which makes it much easier to trust the compiler. Lot less unit testing needed.
And Kotlin feels really pythonic