But some of the advice here is dated. The architectural patterns are still valid, but the specifics have changed:
* Vite instead of create-react-app (which is unmaintained now) / webpack / babel / Parcel / etc.
* Django-ninja as a lightweight API service.
I think these are important to call out because they really simplify the frontend compared to the previous options.
However, Vite is pretty complicated. I prefer just esbuild if I don't need all the extra features of Vite, which is usually true with Django. I wrote a post[0] with an example repo[1] if anyone wants to see how everything wires up.
With Solidjs, the minimum JS payload is around 9kb, and you get access to the whole JS ecosystem if you want it.
[0] https://blopker.com/writing/07-django-islands-part-1/ [1] https://github.com/blopker/typesafedjango
I was going to ask about this with respect to DRF, but you answered it. I am re-learning Django after having been away from it and Python for ~4 years now, and my previous experience was with DRF in a somewhat toxic group so I had less than ideal feelings about it. I know PTSD is a real thing and I don't mean to sound glib about it, but I think I actually had the beginnings of it from that experience.
It's also worth noting that what Django brings to the table is getting less and less relevant in a world where frontend and backend are split.
For example, we use django-ninja. As we started using it, we migrated away from allauth and into authlib for authentication, which doesn't have a tie-in to Django.
We don't use templates, which means we don't use forms. We're moving away from external django apps because they consistently need to be extended, so we tend to copy the code into our codebase and extend directly.
The settings are untyped, which is a PITA; so we replaced them with pydantic-settings: That allows us to use .env files, type them, and we just expose them in settings.py into globals() through a couple lines of code.
Our management scripts make more sense as poetry script, so we don't go through manage.py but instead `poetry run <command>`, which is more standardized and doesn't depend on Django.
We don't even use the django dev server: In order to be more consistent between production and development, we're using uvicorn in "development" mode as a dev server which works just as well. `poetry run dev` is how we run it.
So what does that leave us with?
1. An ORM/data model definition system, which is mostly untyped and the source of many of our issues. This model system also contains weird quirks that have nothing to do with the sql model itself (for example you can't create a UUID field whose default is generated by the db; only in python). This also includes a pretty solid migrations system. 2. The great admin dashboard, which depends on the former.
I see the way the wind is blowing. And for #1, we have this now, which we haven't tested yet but makes complete sense: https://sqlmodel.tiangolo.com/
We still need migrations and and admin dashboard. Once we have those, we will likely migrate away from Django entirely and our stack will look like a few prepackaged bits of FastAPI, SQLModel, authlib, and maybe some standardized db tables.
Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.
Django suffers a lot from having packaged into itself the whole templating and forms systems. It solved a pain point years ago, but it's irrelevant now and it carries that legacy due to backwards compatibility.
Furthermore, Django also suffers due to its legacy of being database-agnostic... which was more relevant in a world where mysql was still seen as a serious competitor to postgres; but now, it's more annoying than anything else.
SQLModel uses SQLAlchemy, which is database-agnostic. Not sure why this is a problem though. The benefit of the ORM is not being agnostic, it’s in managing schema changes under source control and automatic admin interface.
In my experience, the FastAPI-grab-bag always ends in regret, wishing we’d just used Django. It just works, and it has things you don’t even know you’ll need. If you get to the point where Django is the problem, you’re still glad you picked Django because you’ll be able to modify it to suit your needs. It brings convention without being enforced, and it’s pluggable. You can just not use forms (I never have), or templates (I like htpy), or not use the ORM, or use a different ORM. Django is just a request-response handler that’s already thought of everything you might need. If you want the FastAPI/pydantic approach you can use Django-ninja.
You can piece together your own car, but you’ll get a lot further if you just pick a Toyota Land Cruiser and drive it for a couple decades.
I've done all four approaches on four different startups. Pure Django; DRF+React; FastAPI+React; Django-Ninja+React. The last one is the best, but from my experience, it does seem like SQLModel/FastAPI/React will be the route to go towards, but with some solid libraries to replace the still-useful batteries in Django: Authentication, Administration, Migration.
The thing is, Django isn't just a web framework. Django is a CRUD app framework. It's great for building CRUD apps, but that's about it. In other words, it makes the easy stuff easy, but doesn't help with the hard stuff (in fact, it often hinders it).
I think the real reason for using Django is the "app" ecosystem. You wouldn't be able to get Django-style packages with Pyramid. It's possible with Django, though, because it's a CRUD app framework.
If you're not using "apps" then I guess the only other reason is the community support that you probably won't get from Pyramid + SQLAlchemy or similar.
You get all of that with any of Pyramid, Flask, FastAPI etc.
As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most.
Yes, with fewer batteries, and so less consistency between projects, etc.
> As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most.
Not some half-baked homegrown ORM, etc. Been there, seen it fail.
There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production.
In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former.
Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.
We're just walking around in circles. Webpack originally came to be because the current (at the time) solutions were too opionated, and what was "fairly optimal configuration" changed so quickly that it seemed favorable to split out the parts that could change, so we could still use webpack but the specific areas within could move forward without waiting for the rest.
Of course this time, we really have found the optimal-optimal configuration that will surely never be updated, because this time we really did it properly.
> Also, to be clear, I'm not trying to hype Vite up.
If your comment contains all praise for a tool without bringing up any of the tradeoffs/drawbacks, then that pretty much labels your comment as "hype" for that particular tool. And if you find that you cannot find any of the tradeoffs/drawbacks, then it's clear as day that you've fully drank the koolaid :)
I also agree with everything MrJohz said about zero (or close to zero) configuration required to use vite.
Now it was some time ago since I last used webpack, but if it takes 2 minutes for your build to load (or run?), something is severely wrong and it's not because of webpack.
Migrating your build tool because you're hitting some edge-case or bug you don't understand doesn't bode well for your future use of other tools.
I suppose the patronizing attitude is the price for you sharing your wisdom with us.
FWIW I will also echo that webpack is very slow for me. For my current project, the initial build times were ~10 minutes and eventually balooned to 15+ after which I switched to rspack (~10seconds build times now). This comes with some caveats like I had ts typechecking vs swc (but I have ts watching separately, and it takes longer than rspack but is still around ~20s). For webpack 4, speed-measure-plugin used to work well (a long time ago I remember sass-loader being a bad bottleneck), but for v5 I've spent a decent amount of time trying to figure out issues, and it wasn't a simple process. The stats.json that gets generated was malformed for me, and I had to either modify it by hand, and even then it was pretty opaque. And I wasn't about to dive into profiling the node runtime to sort out the webpack issue because that time would be better spent on something like optimizing the chunks.
And I was using webpack because while the inital build times were slow, the incremental builds were really fast. Vite is horribly slow on refresh if there are a lot of files.
Beats passive aggressiveness I suppose?
> FWIW I will also echo that webpack is very slow for me.
Judging by your description, and surely missing even more context, it sounds like individual loaders/modules are/were slow, rather than webpack itself. But since you switched webpack for rspack (with assuming, the very same loaders/modules) and it got faster, that would seem webpack being the slow part, so who knows what the core problem is/was.
Personally I haven't hit any performance issues with webpack + lots of code, but then I mainly do JavaScript and try to stay away from TypeScript, maybe this could explain the difference in experience.
In the end, we use the tools that work best, and if that happen to be Vite instead of webpack (or vice-versa) for you, then there isn't really much to discuss :)
tbh this is just nitpicking, I'm not a react developer to do CRA debugging for them. They're paid by Facebook a couple orders of magnitude more than what we're making here, and if they're fine with the intact CRA configuration being that slow, while a third-party alternative rips through the massive pile of shit I'm working on while not bringing any obvious downsides, I'll just switch to the alternative.
It's a well known problem: esbuild, which is the base of vite's HMR, boasts of speeds dozens to hundreds of times faster than webpack:
1: like support for various file formats that are constantly needed by every user and it makes no sense to lazy load them