The (massive) advantage of sticking with Django templates is that you only need to use one templating language, which retains the same capabilities regardless of the page you wish to generate. If you find that you’re having performance issues then you should consider looking into caching template fragments.
I don’t think an hybrid client and server templating architecture is bad. As long as you code a template only in one of the environment.
Every time you generate a page server side, an amount of processing time and some network bandwidth is consumed. This is what you pay if you use hosted servers.
While the user’s browser is awaiting idle on a generally idle computer for the response.
If you send the template on the client(HTML + JS), they can be cached, for the session or even days, if the user do not delete them.
This reduces the network traffic to deliver the same content various times. As the data are generally smaller than their equivalent rendered HTML.
We’re at the other extreme side, as we run all on the client and that’s why we created PURE for an ultra-fast client rendering. Our app looks very fast as a result of this decentralisation.
- Django Channels VS Django 3.0 / 3.1?
- Pycharm (Python IDE) doesn't auto complete Django modules
- Django's get_current_language always returns "en"
- Django Forms: Foreign Key in Hidden Field
- Is the Global Request variable in Python/Django available?
Why do you pass the HTML as JSON? Just send back the HTML and use jQuery’s
$.html() function to put it in the
<div> or whatever.
It may be possible to make templates of dual purpose – to that they could be rendered into placeholders for the replacement by js and at the same time they could be rendered normally for the server output. Only a few templates will need to be of dual purpose like that – the fragments that are to be replaced by the js.
But even if that happens, the templating language will be probably more restricted as it will be tough to make things like