Sending Ajax to the site and returning a JSON, thus manipulating the array to use in the application.
In that case, the required Javascript code will be much larger, since it contains the logic to display the data.
That means you’re gonna have to load more Javascript before displaying the data.
But this can be paid over time if the data is loaded several times without reloading the page, since the amount of data transmitted is less per request.
This approach tends to present best performance, but also greater complexity and soon your code base can become chaos unless you and the rest of the team are disciplined developers and write modular Javascript (AMD, ES 6).
Sending Ajax to and on the site by assembling a string with HTML code and returning it to the application to use this HTML in its interface.
The Javascript tends to be much simpler and concise, however the amount of data transmitted per request is much higher.
Switching in kids, the site loads faster, but with each new asynchronous update it will consume a little more bandwidth and server processing.
Another problem with this approach is that it can be complex to keep sections of the page separate from the main page that are sometimes rendered within the context of the page, either independently. Without a good organization and a good rendering engine this tends to generate spaghetti or duplicate code.
Usually pollutes the backend code with endless HTML tags being concatenated
Not necessarily. In PHP you can have snippets of templates that can be rendered independently or in conjunction with the page. Some frameworks allow you to create components or widgets that work that way.
You prevent that ajax url from being used elsewhere in your project, because not everyone who needs that data needs that HTML.
Rendering HTML definitely docks the service with your page, but nothing prevents you from maintaining public services in JSON and private in HTML separately.
In my experience, third-party data consumers usually have a different view of the data. Not always the case, but trying to maintain a single API for internal and external use can be a much bigger headache, as you get stuck by the API contract that can’t break for external systems.
Anyway, I would choose to return only the data to your frontend and treat all the HTML you need there anyway.
From an architectural point of view this is more sophisticated form, the current trend and preference of the vast majority of front end developers, for enabling:
- Better separation of concepts: does not divide the rendering logic between client and server, but focuses on client
- Flexibility: allows the evolution of the independent front end of Apis or back end services.
Finally, if you’re really concerned about performance, consider using a more compact protocol than JSON, such as Protobuf from Google. See some advantages here and a PHP implementation here.
For the little I know the advantage of [JSON] is its human reading and its ease of writing without as many tags as in [XML] for example. In terms of benchmarking remember that the [JSON] you will have to build all the elements, use something like the [Mustache] and probably the user request will be more dynamic, It may take a little longer while in HTML the delay would only be to treat the elements one by one, the consumption will be higher. I didn’t have much time to research and study about it so I don’t know much about it, but I hope I helped a little bit.
– Valter Salvador
JSON facilitates the front and back side, because it carries a list of objects, which can be interpreted by the assigned tags, making it easy to read for javascript and to control.
– HudsonPH
Gives an example of the HTML you have in mind to use.
– Anderson B. Magalhães