The Benefits of Server Side Rendering Over Client Side Rendering • Hacker News Board

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#31

Post by matthewmacleod » Mon, Mar 26, 2018, 5:54 AM UTC

meesterdude wrote: post #29

matthewmacleod wrote: post #20

Earlier quoted context omitted.

I'm sorry if I wasn't clear, but I don't think it's an argument without merit. I mean that if you want to build a UI in the manner described in the article—where you essentially use a JS UI framework to render the application server-side, and subsequently make it interactive on the client side—then doing so without the server being Javascript is more complex. I have direct experience of doing this – I built a complex…

> then doing so without the server being Javascript is more complex. why? What does the server being javascript do for you that no other server can do to reduce the complexity?

It allows you to use the same tools to render the user interface on both the server and the client. For example: write a UI using React components, render a static version on the server, and use those same React components running in the browser to render an SPA using the statically-rendered template as a seed.

The options if you are not using javascript on the server are less appealing - calling out to a JS interpreter to do your templating, or building duplicate templates for server and client side, or trying to sprinkle interactive client magic on the page after it’s been loaded.

They’re all possible, but they are more complex than “one set of templates rendered everywhere” - what people were calling “isomorphic” I suppose, though it’s a silly term.

Have I clarified? You seem unusually upset about what I thought was a relatively minor aspect of my initial post.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#32

Post by meesterdude » Mon, Mar 26, 2018, 4:02 PM UTC

matthewmacleod wrote: post #31

meesterdude wrote: post #29

Earlier quoted context omitted.

> then doing so without the server being Javascript is more complex. why? What does the server being javascript do for you that no other server can do to reduce the complexity?

It allows you to use the same tools to render the user interface on both the server and the client. For example: write a UI using React components, render a static version on the server, and use those same React components running in the browser to render an SPA using the statically-rendered template as a seed. The options if you are not using javascript on the server are less appealing - calling out to a JS interpre…

unusually upset? I've written like, two sentences in this thread. But apparently it was enough to get downvoted & flagged. I'm allergic to bullshit, but not to discourse.

Your initial post sounded like nonsense to me - like you were arbitrarily elevating javascript for no particular reason. But now that you've explained that you're talking in context SSR I understand. Maybe that was inferred and I just missed it - even if thats what this whole HN thread is about. I know I was thinking in terms of JSON responses and couldn't understand why one would be so much better than the other.

So, you're right. you do have to do additional work, when JS isn't your server, when your pages are rendered with JS and you want to pre-render pages.

But I wonder - is it worth it to move your entire backend into JS just to do that for SSR? Would not calling out to a JS interpreter be the more... SOA approach, or even the more pragmatic one? Or is it exponentially more difficult to do that than to move everything into node/JS?

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#33

Post by dpisk » Mon, Mar 26, 2018, 8:25 PM UTC

pjc50 wrote: post #23

migueloller wrote: post #22

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can a…

> `renderToString` is taking 500ms What baffles me is that this is a long time . In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?

This reminds me of an article I read a while back: https://hackernoon.com/server-side-rendering-shootout-with-m...

Not sure if the benchmarks still hold now that React 16 is out, but there's definitely overhead in the general approach.

> HTTP can only send strings/bytes, so it makes sense to start there and skip the overhead of building up a virtual DOM representation first. There’s a reason string based templating languages are so much faster than our modern frameworks using a virtual DOM implementation.