Generating html with data on the server side or getting data using ajax?

Question

JavaScript

There was a problem of filling the page with data, I determined two approaches for myself:
1) Generating the entire page on the server side (using Razor);
2) The server creates only a frame page, and the data fills it through ajax requests;

With the first approach, as I understand it, we get the fastest page loading, but at the same time, the load on the server increases, and the bandwidth may fall accordingly. There may be caching issues.

In the second case, we get an almost complete separation of the data and the page skeleton, in fact, you can completely separate the markup, cache it, and use something like a CDN to distribute it along with css and js files. All data will come through a client-side javascript request. Accordingly, the server will be a set of data delivery services.

Technologies used ASP.NET MVC 4, AngularJs

Which approach did you choose? Perhaps you already have experience with this issue, please share.

Answer 1

The second way is more correct. Especially since you are using AngulaJS. When you enter a page (or template) in the controller, you request data. It is better that they come in json string. If the response is successful (when the data arrived without errors), we pass the response to some $scope that is parsed by the template. Angular has all the means for this.
It looks like this:
Controller:

$http({method: 'GET', url: url+'/api/?action=get_res'}).success(function(res) {
  $scope.data=res;
}).error(function(res) {
  alert("error");
});

Sample:

<ul class="records_list">
  <li ng-repeat="item in data" ng-class="{important:item.important==1}">
    <span>{{item.name}}</span>
      <input type="checkbox" data-id="{{$index}}" data-uid="{{item.id}}">
  </li>
</ul>

Answer 2

My opinion so far is as follows.
Markup generation in the browser is appropriate when it is necessary to display information from the same system entities, but in different views (for example, depending on the user's role in the system or in different contexts: both on site pages and platforms in general).
In other cases, it seems to me that there is no point in wasting energy on this.