Menu
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?
901
Client-side rendering manages the routing dynamically without refreshing the page every time a user requests a different route. But server-side rendering is able to display a fully populated page on the first load for any route of the website, whereas client-side rendering displays a blank page first.
Use Server-Side Rendering: Next.js pre-renders a page on each request. It will be slower because the page cannot be cached by a CDN, but the pre-rendered page will always be up-to-date. We'll talk about this approach below.
Yes, Self-Service (shared-memory) client connections are faster than client-server connections that use TCP/IP. Network connections are organised as a series of layers.
Running page logic and rendering on the server makes it possible to avoid sending lots of JavaScript to the client, which helps achieve a fast Time to Interactive (TTI). This makes sense, since with server rendering you're really just sending text and links to the user's browser.
Consider the following questions:
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.
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
111
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 computation 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.
44
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 computation to the client can be tricky to do in a consistent way.
Google's Closure compiler includes a template library. Another option is liquid. It has a Javascript, .Net and Ruby implementation.
1
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
