-
Is unicorn close?
https://www.django-unicorn.com/
Wouldn't be WASM based either, but most of these types of tech aren't (yet?). I'm in the livewire camp with Laravel. I found a bit discussion of a webassembly version of livewire, but I don't think it's on the cards any time soon.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
I've seen some companies using React with Django REST Framework [1], to keep the benefits of Django (I'm not a Django dev so I will have to guess, the ORM and project structure?) while having a strong separation between front and back (separate projects, teams, deploys, etc).
[1] https://www.django-rest-framework.org
-
So I actually recently dealt with this, sharing this as hopefully it helps you.
https://github.com/ospira/docker-django-react-example
In essence, you need two instances of VSCode running connected to two separate Docker container instances. As I understand it, it's one remote container per VSCode window. Thus, I found this to be best, even though it isn't strictly speaking necessary, but it ends up feeling that way because as you said the language server integration (intellisense and extensions) will not work properly if not connected to the right container.
If you load this up in vs code it should prompt you properly given the presence of the files in `.devcontainter` dir. Having two windows in VSCode is kind of annoying at first, but I found it was actually fine, especially on macOS where tabbing to the other VSCode window (as opposed to ungrouped alt+tab on windows) was painless, and also kept me more organized not having backend and frontend code right next to each other.
-
Check out https://django-bridge.org/
It allows you to use a regular Django backend with views, forms, urls, etc but render the UI with Javascript
-
> like individual loaders/modules are/were slow, rather than webpack itself
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 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:
https://github.com/evanw/esbuild?tab=readme-ov-file#why