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

231–240 of 395 posts

Re: The absurd complexity of server-side rendering

#231

Post by adrianh »

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…

Sorry, I’m not seeing how this overengineered solution adds any benefit…?

If it’s a mostly static site, just use Django or Rails and be done with it. SEO becomes a non-issue and your code stays in a single (server-side) language.

Re: The absurd complexity of server-side rendering

#232

Post by Nextgrid »

giantrobot wrote: post #220
jsemrau wrote: post #195

Earlier quoted context omitted.

Very aptly put. But its our fault as we don't want to pay for content online.

Most online content is too small/short to be worth paying an amount of money that would be worth the transaction.

A lot of content such as clickbait/etc actually has negative value and only works because ad impressions pay before the content has been seen and can't be clawed back even if the content ends up being garbage.

Re: The absurd complexity of server-side rendering

#233

Post by zorr »

Honest question: it's clear to me that the term SSR has been repurposed to mean this complex "generate html reusing ~same code on backend/frontend and then hydrate it" thing. What do we call the classic style where the server just renders html using a template language?

Re: The absurd complexity of server-side rendering

#234

Post by [deleted] »

zorr wrote: post #233

Honest question: it's clear to me that the term SSR has been repurposed to mean this complex "generate html reusing ~same code on backend/frontend and then hydrate it" thing. What do we call the classic style where the server just renders html using a template language?

[deleted]

Re: The absurd complexity of server-side rendering

#235

Post by the_gipsy »

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…

Do you realize that neither points justify SSR? You only need those because you introduced SSR.

Anyway, there are webapps that fall between the highly interactive webapp examples of the GP, and static sites. With just enough interactivity that static + sprinkled JS becomes unmanageable. In that area I would really like to see a comparison between SSR (which everybody seems to jump on) and alternatives like... knockout.js? I don't know what's a modern alternative.

Re: The absurd complexity of server-side rendering

#236

Post by tored »

nawgz wrote: post #44
Rauchg wrote: post #41

Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR: 1. A filesystem convention (`*.server.ts`) for more cleanly separating client and server component trees 2. The introduction of a Web standards runtime[1] for SSR. If anything, we're entering the best generation of SSR ever. We'll see new generations of apps shipping less JS to the client, rendering…

Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it'…

If you look at it from a societal perspective SSR is better, it is easier to place servers closer to a clean energy source rather than every client.

Re: The absurd complexity of server-side rendering

#237

Post by epolanski »

boloust wrote: post #29
epolanski wrote: post #25

Earlier quoted context omitted.

What does any of the gist has to do with monads.

Principled, explicit handling of various function colours. If implemented like Fantasyland, probably a terrible idea.

Which, again, has very little to do with any of the gist.

Re: The absurd complexity of server-side rendering

#238

Post by Nextgrid »

com2kid wrote: post #193
briHass wrote: post #130

Earlier quoted context omitted.

It's pretty hard to compare some random free PHPBB running on a underspec'd host to companies with billions in revenue to support their platform. Honestly, reddit and HN are so simplistic, there's not much added by JavaScript doing any rendering. Reddit in particular is horrific. Their API is slow, and their JS bogs down on anything that isn't a super-fast desktop. Server pages would be able to handle most of what th…

> Their API is slow, and their JS bogs down on anything that isn't a super-fast desktop. I'm on a $1000 4 year old laptop. Initial render on home page is under 3 seconds. Comments load in under 2 seconds, Hacker News is faster, but Reddit is the next best thing. This is all w/o ad block, new reddit UI enabled. With uBlock Origin enabled, it is marginally faster. > It's pretty hard to compare some random free PHPBB ru…

I'm sorry but 2 seconds to load a page with primarily text is not something you should brag about. This kind of stuff should take miliseconds to load, with the bulk of it spent waiting for the server's reply. In fact, the "old" Reddit (which is entirely SSR with minimal JS on the front-end) would load in under less than a second.

Re: The absurd complexity of server-side rendering

#239

Post by Nextgrid »

com2kid wrote: post #189
ConsoleTVs wrote: post #93

Earlier quoted context omitted.

> I remember when forums were multi-seconds to load each page. It sucked. You mean when you had the same internet speed 10 years ago, right...?

I could pull 2 megabytes per second down back in 2000. I was at 5x that by 2010. My internet speed didn't really improve from 2010 to 2021, (Comcastic!) then I got fiber. File downloads are faster (800mbit gets binary fast), web pages are about the same. Servers have gotten faster, but ad tech had made crap slower. SSR won't help solve ad tech garbage making pages janky.

You could exclude adtech from the equation using an ad blocker and theoretically make everything lightning-fast, but in reality adtech is not the only problem and non-ad JS also grew to consume all the available resources.

Re: The absurd complexity of server-side rendering

#240

Post by ryanbrunner »

devmunchies wrote: post #171
geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

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?

I'm not familiar with htmx, but the approach I use in Rails with turbo is to return a full page, and then use a subset of that page for what I replace client side. This has a nice property that you can get it working as progressive enhancement, where the site still functions perfectly well without Javascript.
Post reply on HN