I have a best practices/performance question. I am creating an ASP.NET MVC 2 project, and I have several parts of the page that are accessed dynamically either at load time or on user interaction.

My question is this: is it better to have the sections rendered in HTML on the server and then just replace the sections of HTML or is it better to just retrieve the information as JSON objects and then use JS to create and insert the HTML?

It should be noted that the objects of concerns are very simple in nature. An example would be a 'message' object that has an ID field, a to field, a from field, a subject field and a body field that are all strings.

Are there some serious advantages or disadvantages to either approach? Or is this a case of preference to how to construct your application?

I have a best practices/performance question. I am creating an ASP.NET MVC 2 project, and I have several parts of the page that are accessed dynamically either at load time or on user interaction.

My question is this: is it better to have the sections rendered in HTML on the server and then just replace the sections of HTML or is it better to just retrieve the information as JSON objects and then use JS to create and insert the HTML?

It should be noted that the objects of concerns are very simple in nature. An example would be a 'message' object that has an ID field, a to field, a from field, a subject field and a body field that are all strings.

Are there some serious advantages or disadvantages to either approach? Or is this a case of preference to how to construct your application?

• javascript
• html
• asp-mvc
• performance

4 Answers 4

Consider the following questions:

1. Will there be any advantage of having the raw data on the client? In some cases other parts of the page use the data. In these cases it may make more sense to send data over the wire.

2. Are there potential performance differences? Consider the total pipeline. Sending HTML can be verbose, but is rendering faster on the server? Can the rendered HTML be cached on the server?

If neither of these push you in one direction or another, then I choose the more maintainable code base. This will depend not only on the specific problem, but also on the skillset of the team.

Bob

I don't think either are better; it's going to depend on your requirements. The question is borderline unanswerable. Are you using the data on the client for further putation or manipulation or are you just plopping something out to be displayed?

In both cases you're outputting textual data, though it happens to be easier to represent data structures as JSON more directly than it is to convert data structures to HTML and it's easier to directly display HTML than JSON.

Many frameworks have relatively slow render libraries (the View portion of Model-View-Controller architecture.) The reason is that the render library needs to parse/execute a View domain-specific-language to substitute variables, etc.

Depending on your app's scale, it can be much faster to have the client's browser execute the render. But moving the View putation to the client can be tricky to do in a consistent way.

Google's Closure piler includes a template library. Another option is liquid. It has a Javascript, .Net and Ruby implementation.

As Jonathon has said already, I don't think there is a simple yes/no answer to your question.

The only factor that hasn't been mentioned already is that server side execution is more predictable, whereas client side execution is out of your control and may vary depending on the browser. This may practically not be a factor on an intranet site, but can bee important if the audience is diverse. Modern Javascript libraries usually (not always) shield us from browser quirks, but older browsers could have specific performance issues as well (performance really shouldn't be your primary criteria though, unless you try it out and it's horrendous).

Picking the solution you feel the most fortable implementing might very well be the way to go.