3 ms·

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 th

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 3y ago
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.
- Keats 3y ago
  Interesting, I was thinking of the exact same thing. Glad to see it works!
  - Klonoar 3y ago
    Sidenote - thank you for Zola!
- mixmastamyk 3y ago
  It's not a bad idea, but the tradeoff is usually you'll have to define your models twice. For whatever reason, that tends to happen anyway, so not that big a drawback in practice.
  - Klonoar 3y ago
    Eh, in my case I prefer writing raw SQL for the API side of things - it's more apparent what's going on in code that I actually tend to wind up debugging down the road. As a result I don't really feel like I'm writing models twice - I model then code, then just read it directly, if that makes sense. You are ultimately still right, I think - just a personal nuance I guess.

Klonoar 3y ago

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.

Keats 3y ago
Interesting, I was thinking of the exact same thing. Glad to see it works!
- Klonoar 3y ago
  Sidenote - thank you for Zola!
mixmastamyk 3y ago
It's not a bad idea, but the tradeoff is usually you'll have to define your models twice. For whatever reason, that tends to happen anyway, so not that big a drawback in practice.
- Klonoar 3y ago
  Eh, in my case I prefer writing raw SQL for the API side of things - it's more apparent what's going on in code that I actually tend to wind up debugging down the road. As a result I don't really feel like I'm writing models twice - I model then code, then just read it directly, if that makes sense. You are ultimately still right, I think - just a personal nuance I guess.