5 ms·

I've worked with Django for 12 years and I don't know why you would want to use their awful templating language. It's untyped, messy, buggy, inconsistent, ugly

I've worked with Django for 12 years and I don't know why you would want to use their awful templating language. It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload. And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).

bredren 6y ago
I don't think django tempating is as bad as you've described but one reason is that a project is long-standing and dev resources are already familiar with it. A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well. The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
- scrollaway 6y ago
  Absolutes never exist :)
aiisahik 6y ago
Totally agree with your assessment of Django in terms of its templating and SSR abilities. It's horrible and should be avoided at all costs. However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
- scrollaway 6y ago
  Yes I agree with you. My favourite stack right now is Django with DRF+Admin for backend, Typescript+NextJS (React) for frontend. I front the backend with Caddy, have django live on both admin.example.com and api.example.com with a couple of rewrites, and put cloudflare access in front of admin.example.com. Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup). The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
  - WD-42 6y ago
    You should check out FastAPI. I’ve been a Django dev for years but now that all projects have pretty much moved to client side js + drf backend anyway I’ve been using FastAPI for new projects. The way it takes advantage of Python typing is a thing of beauty!
    - scrollaway 6y ago
      Yup I've used FastAPI and love it. I'm not entirely sold on it when it comes to dealing with the ORM though, and the lack of a Django-quality admin is kind of a bummer.
      - WD-42 6y ago
        Agreed. The Django ORM is so good. SQLAlchemy ORM feels like a huge step backward. There are some new ones coming on the scene, like Dino and Tortoise, but nothing mature.
yout2 6y ago
Curious what you mean, more specifically? Django template language seems fine to me, but maybe I haven't used React enough to see where it is better.
- scrollaway 6y ago
  Honestly I don't really know how to summarize it. Django templates have a ton of gotchas. They have the dumbest safeguards, too, such as preventing you from using variables beginning with underscores. Jinja templates at least let you use normal python syntax in the tags. You can easily do something like {{ items.filter("books")[:5] }} — in Django, you would have to write a special accessor or template tag to call filter("books") as it doesn't let you specify arguments to function calls, and you'd use the awful |slice:":5" to slice it. But more than anything else, Django templates are not just untyped, they are untypeable. You can't really validate them. Best you can do is try to compile them in a CI job see if anything fails. Not to mention that the way you're outputting HTML essentially arbitrarily anywhere in the page means there is no way for the editor / tools / even yourself to know if some piece of code is syntactically or semantically valid in context. Got a list_item.html with a naked "<li>{{ item }}" inside? Why the fuck not! Could even be raw css or js outside a tag in your template, could be valid in some includes, invalid in some others. Everything goes. You can't even know whether a template is in use, as it's completely arbitrary code that calls these template inclusions, via string filenames (which therefore can be included however you want). It's impossible to create these problems with react/typescript. And react heavily encourages code reuse: creating reusable components that are as small as possible. Django templates encourage copy-pasting.
  - yout2 6y ago
    OK thank you for the explanation :)

bredren 6y ago

I don't think django tempating is as bad as you've described but one reason is that a project is long-standing and dev resources are already familiar with it. A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well. The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.

scrollaway 6y ago
Absolutes never exist :)

aiisahik 6y ago

Totally agree with your assessment of Django in terms of its templating and SSR abilities. It's horrible and should be avoided at all costs. However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.

scrollaway 6y ago
Yes I agree with you. My favourite stack right now is Django with DRF+Admin for backend, Typescript+NextJS (React) for frontend. I front the backend with Caddy, have django live on both admin.example.com and api.example.com with a couple of rewrites, and put cloudflare access in front of admin.example.com. Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup). The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
- WD-42 6y ago
  You should check out FastAPI. I’ve been a Django dev for years but now that all projects have pretty much moved to client side js + drf backend anyway I’ve been using FastAPI for new projects. The way it takes advantage of Python typing is a thing of beauty!
  - scrollaway 6y ago
    Yup I've used FastAPI and love it. I'm not entirely sold on it when it comes to dealing with the ORM though, and the lack of a Django-quality admin is kind of a bummer.
    - WD-42 6y ago
      Agreed. The Django ORM is so good. SQLAlchemy ORM feels like a huge step backward. There are some new ones coming on the scene, like Dino and Tortoise, but nothing mature.

yout2 6y ago

Curious what you mean, more specifically? Django template language seems fine to me, but maybe I haven't used React enough to see where it is better.

scrollaway 6y ago
Honestly I don't really know how to summarize it. Django templates have a ton of gotchas. They have the dumbest safeguards, too, such as preventing you from using variables beginning with underscores. Jinja templates at least let you use normal python syntax in the tags. You can easily do something like {{ items.filter("books")[:5] }} — in Django, you would have to write a special accessor or template tag to call filter("books") as it doesn't let you specify arguments to function calls, and you'd use the awful |slice:":5" to slice it. But more than anything else, Django templates are not just untyped, they are untypeable. You can't really validate them. Best you can do is try to compile them in a CI job see if anything fails. Not to mention that the way you're outputting HTML essentially arbitrarily anywhere in the page means there is no way for the editor / tools / even yourself to know if some piece of code is syntactically or semantically valid in context. Got a list_item.html with a naked "<li>{{ item }}" inside? Why the fuck not! Could even be raw css or js outside a tag in your template, could be valid in some includes, invalid in some others. Everything goes. You can't even know whether a template is in use, as it's completely arbitrary code that calls these template inclusions, via string filenames (which therefore can be included however you want). It's impossible to create these problems with react/typescript. And react heavily encourages code reuse: creating reusable components that are as small as possible. Django templates encourage copy-pasting.
- yout2 6y ago
  OK thank you for the explanation :)