Is it ever a better idea to render html on the server than the client?

[Maximilian]

This is just a curiosity of mine. I know the trend for a few years has been to send raw data probably in JSON format from the server and just let the client deal with it. Is it ever a better solution to render html on the server?

I have dealt with two applications recently. One of which (I posted on here about it, the Java memory leak one) sent a 38MB JSON file to the client. And it pretty much crashed the browser trying to deal with this thing using jquery datatables. The other application was written using webforms and runs on .NET 4.x. I brought back what ended up being ~300,000 pages worth of data from the database using this application and it loaded it into a paginated table. It was a bit slow but far from crashing the client. I know 38MB and 300,000 pages are not directly comparable But I was pretty impressed by how well the webforms application handled a large amount of data.

It made me wonder if there are ever any niche situations where html is better rendered on the server and sent to the client, like maybe dealing with huge amounts of data or something.

tl;dr as in the title really, are there any niche situations where it is better to render html on the server rather than sending a JSON to the client and letting the client deal with it?

 

[DaveSimmons]

It's often better to summarize, filter or paginate data on the server before deciding what to send to the client. Then the client renders that subset of data into HTML.

That is, if the user is only going to look at 3 of those 300,000 pages, then design the client app so it can tell the server which 3 pages to send. The server load to extract them will often also be less than to send all 300,000 and it certainly uses much less bandwidth.

Even if the server has to run an extraction job 3 times to send pages 1-10, 11-20, 21-30 that will almost always be a better experience than having to wait for the other 299,970 pages to arrive.

 

[Merad]

TBH for most sites it doesn't matter. You can write stupidly slow sites with client side rendering and screamingly fast sites that primarily use server side rendering. The idea of server side rendering being "niche" cracks me up a bit though. I'd be willing to bet money that the majority of websites in the world run on server side rendering and will for the forseeable future.

 

[DaveSimmons]

TBH for most sites it doesn't matter. You can write stupidly slow sites with client side rendering and screamingly fast sites that primarily use server side rendering. The idea of server side rendering being "niche" cracks me up a bit though. I'd be willing to bet money that the majority of websites in the world run on server side rendering and will for the forseeable future.

I guess we should narrow down the term then. Of course 99.99% of web content is dynamically generated from code running server side. But much of that generated content has the client side run scripting to render a "responsive" page and to do fewer page reloads by using AJAX.

 

[mxnerd]

Don't think that 300,000 pages were pushed to the client at once. As OP said, it's paginated.

Only the page that user was viewing was pushed to the client.

 

[Red Squirrel]

I prefer to generate as much html as possible and use as little javascript as possible. Not only is that easier from a programming perspective because it means overall less code, but it also means that it makes for a web page that won't be as bloated for the client and is also less likely to cause issues in functionality between platforms.

There seems to be an awful trend to use javascript for the most ridiculous things now days , there is no need for that.

Where fancy javascript stuff is nice is if the nature of the web page actually needs to be real time or have real time like functionality. Then you use ajax or what not and deal more with raw data and rendering it on the client. But for simple stuff like just displaying text and images there is absolutely no reason to use tons of javascript to do those things. Look at how ridiculously bloated news websites are. No reason at all for that. News websites should actually be relatively simple. It's literally just text, images and maybe video.

 

[DaveSimmons]

A lot of the client scripting is so that the browser can render the page properly for any device from lo-res phones to tablets to 4K desktops. The server doesn't know the screen resolution or any settings like scaling up for legibility, at least not until after a page has loaded and some "here's my stats" AJAX message can be sent.

The scripting doesn't just re-arrange the page, it can drop or collapse menu items that don't "need" to be displayed so that less scrolling is needed and the awful olden days finger zoom to make sense of a page isn't required.

 

[Mr Evil]

I'm with Red Squirrel. Very few of the sites I visit actually need JavaScript. A lot of sites might work better with it, but could and should be made to work without it (like this very forum). Most sites are just text and images, so it's disappointing to come across one that can't even display anything without JS when they would actually be a better experience without. Just spend a while browsing with JavaScript disabled and marvel at how much faster everything is.

A lot of the client scripting is so that the browser can render the page properly for any device from lo-res phones to tablets to 4K desktops. The server doesn't know the screen resolution or any settings like scaling up for legibility, at least not until after a page has loaded and some "here's my stats" AJAX message can be sent.

The scripting doesn't just re-arrange the page, it can drop or collapse menu items that don't "need" to be displayed so that less scrolling is needed and the awful olden days finger zoom to make sense of a page isn't required.

All those things can be done with CSS, and you'll end up with something that is more maintainable, faster, and more likely to be compatible with not only current browsers, but future ones too (CSS is less of a moving target than JS).

 

[sao123]

My take on this has always been that if you are designing a data driven system (enterprise application) as opposed to a content driven, then it absolutely should be done using server side rendering. Asp.net does this better and faster in development than client side technologies.

 

[KB]

I prefer sending html to the client (server side rendering). It makes debugging rendering issues a hundred times easier and is more client agnostic.
Many programmers think, "oh I am sending just a little json, its so small, surely its better than sending all those html tags over the wire", then they also have the client download jquery, jquery-ui, bootstrap, knockout, date formatters et al. and suddenly that page running pure json is tens times larger than the html version.

 

[mxnerd]

The way I see is that the more complex Javascript code is, the job is more secure for the programmer.

 

[purbeast0]

A lot of the client scripting is so that the browser can render the page properly for any device from lo-res phones to tablets to 4K desktops. The server doesn't know the screen resolution or any settings like scaling up for legibility, at least not until after a page has loaded and some "here's my stats" AJAX message can be sent.

The scripting doesn't just re-arrange the page, it can drop or collapse menu items that don't "need" to be displayed so that less scrolling is needed and the awful olden days finger zoom to make sense of a page isn't required.

Most responsive pages are not done like that. They are the same HTML and use CSS with media queries to handle how it's laid out.

 

[sourceninja]

Well, ideally you need to be doing both if you are going to render client side with fancy JavaScript. You don't know if someone with disabilities might need to use a web browser with poor JavaScript support. Web Accessibility should be important. Sadly it is not. Lots of modern JavaScript libraries are lacking in web accessibility, which leads to an entire class of people who can not use the sites made with them.

 

[you2]

The client knows the display the server might or might not (http headers). However, the client scales much better than the server (if you process a 1000 request per unit time; the you have a 1000 clients rendering (perhaps in parallel); vs (potentially) a single server. The only reason to have the server render is if the rendering has security implications (the data required for rendering is too sensitive to provide the client).

 

[Cogman]

Generally, the trend I've seen is a mixed approach. You prerender some stuff on the server (everything that doesn't need dynamic data) cache and send that down and then handle the rest through AJAX/json.

Rendering on the client only ends up with a couple of problems, for one, your client needs javascript which may cause them to see only a white screen when they hit your page. Further, some search engines have a hard time depending on how you choose to render things. And finally, clients can be slow, so you have to be fast with your javascript.

Rendering server side only runs into scaling problems. For one, you might end up sending more data then necessary (because a large portion of your site could be generated from small data packets vs large ones). Next, your servers have to do a bunch of extra processing simply laying things out on a page can be a long and tedious process that you may be better served shipping off to the client. However, server side rendering is highly consumable by search engines and clients.

The mixed approach is appealing because you get a lot of the best of both worlds. A nice landing page with added functionality provided by javascript. For example, if you are serving up blogs, it makes sense to only render the blog page once and server that up a million times.

Even for something like a forum, it might make more sense to render server side only on changes since these sites don't change as much as they are read.

The exact right answer depends on what you are doing.

 

[Cogman]

*edit* double post

 

[mikegg]

Pros of server-side rendering:

• Better for SEO (most crawlers can't execute javascript)
• Faster initial load time for most cases. You're just sending down HTML & CSS. Client doesn't have to download a giant JS file and then call for data.

Pros of client-side rendering:

• Faster page loads after the initial load. You're just calling for data and re-rendering what's already on the page.
• Lighter load on the server since you don't need to pre-render anything.

Both have pros and cons. Figure out what's important for you.

To me, I use isomorphic Javascript rendering. The server and client runs the same JS code. This allows me to pre-render on the server side on the initial load then run client-side rendering after. Best of both worlds.

Like many of said, 99% of websites out there are server-side rendered which means calling it "niche" is incorrect. But the most popular sites are often client-side rendered such as Facebook/LinkedIn.

 

[TempAcc99]

It's often better to summarize, filter or paginate data on the server before deciding what to send to the client. Then the client renders that subset of data into HTML.

Exactly. Sending 36mb json file obviously is utterly stupid for many reason including network bandwidth and cost server-side.

Generally, the trend I've seen is a mixed approach. You prerender some stuff on the server (everything that doesn't need dynamic data) cache and send that down and then handle the rest through AJAX/json.

Agree as well. Send static stuff as html, load data dynamically via AJAX, This prevents page reloads when you page the data. This also nicely separates presentation layer from data layer in the source code plus for the ajax you will now have an API that can be consumed by other clients.

 

[Maximilian]

Thanks for the replies guys. Interesting read