Hacker News Reader

Comment by catshirt | Hacker News Reader

why suffer the performance implications of client side rendering for something like partials?

Sounds to me like there would be a trade-off between network latency (delivering HTML ⇒ possibly more network traffic) and a number of string operations & DOM manipulations. Given how fast browsers are at the latter lately, I would imagine client side rendering could be the faster option — but let’s look at the real numbers before deciding, I suppose.

Wouldn't the right question be "why suffer the performance implications of server side rendering for something like partials?"

Agreed. Client side rendering for most things is instant. Client side rendering scales better than server side, in my opinion. 1 user or 1,000 users using your website, will not affect the rendering time on the client's machine (just the data transfer times), but will affect the rendering time on the server.

actually i believe the right question would be "in which scenarios does it make sense to deliver them rendered, and in which scenarios does it make sense to render on the client"; which was the intention of my original question.

based on the responses it's clear that my question sounded like a leading one. it was not and i employ both methods actively.

Accessibility, for one.

I see this one come up time and time again, Accessibility is not implicit to server side rendering and is easily managed via client side rendering. It is one of my companies specilizations we do client side web app accessibility and to be honest building an accessibility layer with client side logic is far easier than dealing with it via the degree of separation that the server creates. There are many tricks that we use to fool JAWS into doing what we want that are just not available via server side rendering. Accessibility is not hindered by client side rendering if anything it can be enhanced.

Definitely. I wasn't posing the question, just pointing out that the performance hit is actually doing it server side.

There are definitely drawbacks, but I'll tell you the best two reasons I know why you should render partials in JS:

- It means you can render partials to the user before you receive data from the server. So things seem to happen instantaneously to the user.

- It also means you can have your partials rendering in a single place and rendered by a single template engine.

surely. the first reason is clear to me. i use client side transformations for this purpose.

performance was admittedly awfully misdirected in a general context. i suppose my situation is unique; several templates on my app require complex logic or additional requests based on properties of the initial request. this is where you start to see it get hairy.

again though, admittedly not the normal scenario. i appreciate you taking my question literally, as it was meant.

It's a good point. When you have complicated templates, usually these JS template libraries fall a bit short.

can you be more specific or cite examples on performance.

We use pure.js to render our entire app. There is no server rendering at all and I find it fast. Here's a link to a demo https://beebole-apps.com/?demo&lang=en_US&x=2

Reply on news.ycombinator.com