1đź‘Ť
No, you shouldn’t.
AJAX calls should only contain the requested resource in a standard format and not some custom HTML, for example if I do a request for /cars
I expect to get a list of instances of car
in a standard format (JSON or XML), the backend server shouldn’t know nor care how I present that data.
Also it’s a good idea to generate the HTML on the client side to avoid transmitting unnecessary data over the wire, let’s say I request some /cars
and get a few hundred thousands of them, each one with an HTML table markup… that’s a lot of unnecessary markup that can be added on the client side without having to transmit it over the wire, so it saves bandwidth and that’s important, especially for mobile users.
Finally the controllers for the endpoints called via AJAX should be simple and not contain any view-related code, first to cut a few milliseconds off the response time, and second so that if you want to change the UI you’ll change it in your HTML/CSS/JS files which, depending on the complexity of your solution may be part of a different app altogether (what if your app only serves to provide an API for a third party webapp ? You’ll want the third party app to control the presentation while you only provide the raw data).
Regarding your edit, I really don’t see what is the problem with adding potentially infinite amounts of HTML elements to the page… You don’t need to have each element declared in advance in the HTML file, you can create an infinite amount of them on the fly via Javascript and then insert them wherever you want.
For your “how would I do an AJAX-powered newsfeed” question, it depends on my motivation and it ca go between a basic server-generated page with optional AJAX refresh (the template lives both in the server and in the Javascript to present the AJAX data) to a complete Ember app with the server just providing a JSON API.
1đź‘Ť
Rendering on server side is probably faster than on client side. However it requires more performance on your server.
If you’ve already wrote your templates in django you could save development time by returning with complete html data. Otherwise you have to write your own rendering methods in JS.
In this case if you change anything in django, you have to duplicate yourself on the client side code.
Personally I think rendering on server is safer and simplier.
0đź‘Ť
I think it’s important to step back a bit, and break out some terminology here. Rendering, as you are using it, could refer to a couple of things:
- Rendering html tags and css rules in a browser to create a view of a web page for the user, based on data received from a server or servers.
- Rendering data to some sort of response on the server side, to be consumed by the client’s browser, or any other tool that happens to follow the protocol being used (HTTP in this instance).
These are distinct activities that really aren’t related, but I think the ability to use the same term to mean both may be confusing you. Django will render a response to an HTTP query asking for a resource, whether this response contains HTML or JSON or plain text doesn’t matter much.
Now, that said, whether you want to do more of the work in creating the webpage to look a certain way on the server side (the template) or the client side (js) is more of a style question (with some allowance for the practicalities that can arise from your particular use case, of course).
For my own purposes, I generally prefer to render general data (perhaps an organization name, variables about navigation, etc) in the template, and if I’m displaying an unknown or large amount of data pulled from a db, I’ll fire off an AJAX call for that and show the user an indication the data is loading.
But experience will be your guide for what is appropriate and when.
0đź‘Ť
Thank you all for your replies.
I wanted to update that I decided to go with the elegant solution, which also turns out to be more practical, meaning letting the client side do the work:
I only transfer lean JSON elements to the client side; I let the client generate the relevant HTML.
True, it is sort of “repeating” myself since the server side and client side both have similar code segments handling the creation of exactly the same HTML segments.
Nonetheless, it became clear to me that loose coupling in this instance is crucial for being able to scale to other non-pc interfaces such as android, ios, windows phone etc.
Moreover – it is faster that way. No need to burden the server side with rendering countless amounts of HTML when the client side can do it.
Thank you all again.
My conclusion is – make it right, even if is seems to cost more.
- [Answered ]-Stopping ignoring migration files in git for a Django Project
- [Answered ]-Run linux command from django view script
- [Answered ]-Signal for M2M changed on a through field