Live data from Hacker News

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

timr.co

231–240 of 286 posts

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

#231
post #111

Earlier quoted context omitted.

The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary. If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.

Frontend-backend separation isn't arbitrary at all. A few things that are often different between FE and BE: 1. Written in different languages. 2. Completely different deployment paths. 3. Causing completely different ways of scaling. 4. Focus on UI and UX is a very different mindset, with often some people preferring it to be a focus of their work, or not.

You can (and probably will) have multiple different frontends with website vs app. If you have a clean API for the backend, then you have one set of calls which can be made from multiple different user interfaces

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

#232

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.

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...

If you're talking about static sites, wordpress definitely isn't it, it renders server side every request. (Google's Blogger.com used to be static, not sure about now). HN is likely not static either.

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

#233

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…

Don't know who built this site or how old it is, but the UX is definitely sub-par compared to many other server-rendered sites. Submitting a form and losing the scroll position doesn't happen in every site, even if the page gets reloaded. And the font thing is more of a CSS problem than a SSR/client-rendering problem.

A lot of it could be improved with some CSS changes (scaling etc) as a sprinking of javascript which could handle commenting without reloads. My opinion is that it's perfect for what it is, a discussion board and nothing more. It's not a social media site.

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

#234
post #148

Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.

Have to disagree with you. Plenty of web applications are using WebGL and have been for years (Cesium\GoogleEarth). I also like my applications to function when they're offline, especially if I'm flying or working without a network. I also might want to use WASM tools and use my local device as something more than just a dumb terminal. All of those use cases would make me prefer to use a more client centric approach…

Literally most applications aren't Google Earth.

But even google earth would be better as a desktop application.

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

#235

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

> it creates a clear separation between frontend and backend devs

Yes, and if a single team is doing both it adds another stack to master. This can be a pro or con depending on the size/organization of the team.

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

#236
post #222

Earlier quoted context omitted.

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.

This reply comes off as needlessly rude, but I'll give you the benefit of the doubt that it's just intent not coming across well via text.

In the context of the comment to which you're replying[0] I'm not sure how else to take your comment. OK, you don't like HN's UX, that's either a comment on SSR and on topic for the thread, or completely unrelated.

> HN as a site is a perfect example of how bad a SSR experience can be.

This is a great ending line if the things you list before it would automatically be better under CSR, or are only capable of being fixed by moving HN to CSR. So, it seems pretty natural to me to assume that you're saying those things (reply notifications, typography, losing position on a reply) would be better under CSR, which is not necessarily the case.

[0] https://news.ycombinator.com/item?id=37237320

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

#237

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary. If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.

> If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems.

It also gets you vastly more choice in language/tooling/etc, even allowing a mixture of different ones, which is what attracts me to SSR. Of course this may change in the future once WebAssembly has had most of the DOM interop overhead optimized away, bringing this freedom to CSR.

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

#238
post #160

Earlier quoted context omitted.

"Frontend builds are basically a requirement for any application with a UI" I disagree with this premise. Dynamic languages don't have builds either.

Since JS people target multiple browser versions and vendors, building is basically a requirement.

Builds are absolutely not a requirement for targeting multiple browser versions and vendors.

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

#239
post #225

Earlier quoted context omitted.

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 i…

> SSR that needs to run JavaScript hydration

This is not SSR.

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

#240

Earlier quoted context omitted.

Don't know who built this site or how old it is, but the UX is definitely sub-par compared to many other server-rendered sites. Submitting a form and losing the scroll position doesn't happen in every site, even if the page gets reloaded. And the font thing is more of a CSS problem than a SSR/client-rendering problem.

A lot of it could be improved with some CSS changes (scaling etc) as a sprinking of javascript which could handle commenting without reloads. My opinion is that it's perfect for what it is, a discussion board and nothing more. It's not a social media site.

Not that this should be the answer, but there are a lot of HN browser plugins. Most have at least some level of theming and inline commenting. I'm currently a fan of Refined Hacker News (no affiliation) - https://github.com/plibither8/refined-hacker-news - but I'm sure there are others just as good out there.
Post reply on HN