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

The absurd complexity of server-side rendering

gist.github.com

Post reply on HN
Print view View original

201–210 of 395 posts

Re: The absurd complexity of server-side rendering

#201

Post by rodamaral »

galaxyLogic wrote: post #113

What is meant by "server-side rendering"? Is it the same as server-side on-demand html generation? If so then I think the term "server-side rendering" is somewhat confusing. Your server is "generating HTML", not 'rendering" it. Rendering in my view means turning code (like HTML) into visual output.. So whether the server serves always the same HTML, or regenerates it for every request, or something in between, the cl…

SSR always means outputting the first html as seen from the user when the app is fully loaded and ready to be interacted with. A SPA usually starts with a minimal, blank html file and a huge JS file that mounts the DOM structure and then the user can see something. SSR does the exact same thing, but on the server. From the user perspective, SSR seems faster. From a SEO perspective, SSR is better because there's some initial content on the page.

Re: The absurd complexity of server-side rendering

#202

Post by vecinu »

codedokode wrote: post #38

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…

> So I think that SSR (running JS on server) is rarely useful.

I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons:

- Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend

- SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

Re: The absurd complexity of server-side rendering

#203

Post by quickthrower2 »

etchalon wrote: post #64

I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things

SSR would make HN better under load when logged in, for example. When logged in you would get the cached versions like a logged out person, and then wait for user-specific content (and if it never renders, you can always just read).

Re: The absurd complexity of server-side rendering

#204

Post by Beltalowda »

tetraca wrote: post #182
devmunchies wrote: post #171

Earlier quoted context omitted.

When fetching from the backend, the docs recommend returning snippets of html instead of JSON. Is it technically valid to return a snippet of HTML with a content type of “text/html”? There’s no standards saying you need !DOCTYPE or a head or body?

Regardless of whether it is standard or not I've definitely worked on sites that worked this way back in the day. Smarty+PHP would generate the beef of the page, then certain components of the page would be pulled in using Ajax requests as the user did things. The browser would not care.

I still write sites like this. I realize this is not "the way" to do things today by many, but I find it works quite well and it avoids a lot of complexity. I think the "classic" web-apps were given a bit of an undeserved bad rep because a lot were written in bad PHP and bad JavaScript, and people conflated that with "this entire approach is wrong".

Re: The absurd complexity of server-side rendering

#205

Post by quickthrower2 »

chrisco255 wrote: post #60
paxys wrote: post #39

The common mistake teams make getting started with server-side rendering for React is thinking that your entire backend has to be contained in a single JavaScript bundle. Instead, use any language you want to set up your APIs and business logic. Then set up a fully independent pool of servers running Node.js whose only job is SSR. This setup skips over every problem the author mentions.

The newest versions of Next.js have API routes that are independently deployed as serverless functions, so they do not interfere with the SSR instance.

Yeah, I have recently learned Next.js WITH that and so I haven't experienced the pain points. Also using Next.js with something like Firestore (etc.) is also helpful. Next.js seem to recommend delegating in their documentation (e.g. need a scheduler? Use Github actions).

Re: The absurd complexity of server-side rendering

#206

Post by grey-area »

The original server side rendering (HTML rendered on the server by your choice of language) is simple, efficient and most sites on the internet still use it, including this one.

The article is talking about ‘modern’ js style server side rendering combined with client side rendering, which is of course a huge dumpster fire and encourages absurd complexity on both sides of the equation, starting with the fact the app is split in two.

Re: The absurd complexity of server-side rendering

#207

Post by alkonaut »

vecinu wrote: post #202
codedokode wrote: post #38

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…

> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and m…

Does SSR need to be so complex for SEO? Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version, as soon as a browser isn't detected properly, or determined to be known a bot/crawler? E.g. you skip all interactivity, layout etc. I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?

Re: The absurd complexity of server-side rendering

#208

Post by atoav »

kingcharles wrote: post #31
atoav wrote: post #3

Earlier quoted context omitted.

I handwrite all my CSS directly in the browser and the only "dependency" I use is a reset.css. The zooming issues some of those old themes have can all be solved with a modern css grid template (one for smartphone, one for desktop). Needless to say sites like these can be blazing fast. I only use js for small things like maybe hiding some header when scrolling down (no jquery, handwritten vanilla js with maybe 20 lin…

And even CSS resets are getting close to zero these days.

That is true and very fortunate, I noticed how this is getting less and less of an issue over the passt years.

Re: The absurd complexity of server-side rendering

#209

Post by andai »

jamal-kumar wrote: post #16
bob1029 wrote: post #11

I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so…

Even in smaller applications this is incredibly relevant. I've recently written something that's meant to interface on a local area network, just controlling something on another computer, literally just one or two users at a time -- thing is the precision of floating points are a big thing here, and we have to consider that. So all of the bignum stuff had to stay server-side in C++ after much messing around doing ma…

Recently I've been dabbling in developing online multiplayer games.

After some agony trying to make the chaos go away (rewinding time, merging conflicting physics states...), I realized I could actually harness it by re-framing the product from something serious into something lighthearted (eg. making goofy physics the whole point of the game).

At worst, it lowers the expectations (eg. relative to something serious/competitive where jankiness is unacceptable), and at best may actually produce laughter. I hope.

Re: The absurd complexity of server-side rendering

#210

Post by grey-area »

DangitBobby wrote: post #155
sph wrote: post #123

Earlier quoted context omitted.

This article is a good start.

I've read the article. The pain points exist, but they are not insurmountable. I'd go as far as to say they are being a bit dramatic.

Compared to traditional server side rendering, the article describes a hellscape of self-imposed complexity. Why would anyone choose this?
Post reply on HN