Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-side rendering is a better choice for many applications (2020)

timr.co

Post reply on HN
Print view View original

221–230 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#221

Post by michaelmior »

bob1029 wrote: post #206
robertoandred wrote: post #122

Earlier quoted context omitted.

Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.

Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actual…

> Information-theoretic, there is no way you can beat SSR in this scenario.

I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything.

That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.

Re: Server-side rendering is a better choice for many applications (2020)

#222

Post by pc86 »

ninepoints wrote: post #197
ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even ac…

None of this changes simply by moving rendering to the client, and none of these changes would require a client-rendered site.

Re: Server-side rendering is a better choice for many applications (2020)

#224

Post by [deleted] »

flimsypremise wrote: post #137

This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…

[deleted]

Re: Server-side rendering is a better choice for many applications (2020)

#225

Post by nfw2 »

bob1029 wrote: post #206
robertoandred wrote: post #122

Earlier quoted context omitted.

Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.

Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actual…

Not always.

SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive.

I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.

Re: Server-side rendering is a better choice for many applications (2020)

#226

Post by ninepoints »

pc86 wrote: post #222
ninepoints wrote: post #197

Earlier quoted context omitted.

I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even ac…

None of this changes simply by moving rendering to the client, and none of these changes would require a client-rendered site.

Please indicate where I suggested as such.

Re: Server-side rendering is a better choice for many applications (2020)

#228

Post by icedchai »

MatthiasPortzel wrote: post #171
ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.

Where are you located?

It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.

Re: Server-side rendering is a better choice for many applications (2020)

#229

Post by cpursley »

granshaw wrote: post #203
lakomen wrote: post #180

Earlier quoted context omitted.

Been there, done that. I don't agree. Go's native html/template and even pongo2 or quicktemplate etc have a big problem when it comes to conditional fragments of some text. It's messy and you end up writing helper functions for pretty much everything. Need a href aware navbar? Custom function and macro time. Bleh. Performance is great, maintainability isn't. I dislike graphql because it's too mich overhead. RESTful i…

Just use Rails

These days it’s hard to justify Rails over Phoenix for fresh projects.
Post reply on HN