6👍
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.
4👍
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.
As you point today’s Javascript engines are really fast, as well as the computer they run it. Each time you sent the rendering work to the client, you save some processing time for your server and deliver faster the data.
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?
0👍
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.
As for templating in Javascript, there’s Pure. If you’re using jQuery (I’d recommend it), it already has a template engine.
0👍
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.
I agree with Ignacio, it is much better to keep just one copy of each template, so that you don’t have to write a separate one for the javascript, however there is definitely room for improvement from the approach that I’ve mentioned above.
Ideally you might want to have templates compiled into robust javascript function code as well as plain string for the output by the server.
Closure templates called Soy, solve the problem nicely but do not (perhaps just yet) work with python, but they do work with Java and Javascript. Hopefully one day there will be python support for that.
But even if that happens, the templating language will be probably more restricted as it will be tough to make things like .get_absolute_url(), filters, etc work both in python and javascript – all automatically.