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

41–50 of 395 posts

Re: The absurd complexity of server-side rendering

#41

Post by Rauchg »

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 and personalizing at the Edge, closer to the user, and the infrastructure to support this will be serverless and economically every efficient.

[1] https://nextjs.org/docs/api-reference/edge-runtime

Re: The absurd complexity of server-side rendering

#42

Post by phist_mcgee »

Daishiman wrote: post #2

The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fast…

I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.

Re: The absurd complexity of server-side rendering

#43

Post by richwater »

yen223 wrote: post #27
robertoandred wrote: post #12

Earlier quoted context omitted.

I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability

Frontend folks have an excuse. They cannot avoid using JavaScript, since they're limited by what browsers support. Backend developers chose to write mountains of yaml

I recall a couple of years ago when Kubernetes was all the rage and jesus christ the amount of YAML was unbelievable.

Re: The absurd complexity of server-side rendering

#44

Post by nawgz »

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's cheaper to let the public render the SPA than it is to render it for them, surely in corporate this takes better advantage of already purchased machines with already installed programs instead of developer cycles wasted to recreate it, and surely it's better to have less server load and deployment complexity in both cases

Re: The absurd complexity of server-side rendering

#45

Post by stevebmark »

epolanski wrote: post #24
stevebmark wrote: post #23

In Javascript SSR, if you need the same logic on the client and server, define an API module + interface. Make a different API bundle on the server that calls NodeJS functions, file reads, whatever, directly. Make an API bundle on the client that makes AJAX requests to your API endpoints. Now your Javascript can call the same `api.fetchWhatever()` method, and await the result, and it works on the client and server (i…

Thus, you are confirming there is a hugh level of complexity. I want to add something else on top of what's in that gist: ssr is slow, rendering an application twice (on server and client) is just slow. We only do that for cache and seo, every other page suffers.

I'm not sure what about two bundles causes a huge level of complexity. Granted, I use Next.js, it does all of this out of the box.

SSR is fast, it's provably faster than client side rendering for first load. You can optionally do client side hydration, so the time to meaningful content is fast from SSR, and subsequent page loads are done SPA style (if you want).

It's never a fair comparison, but Stackoverflow is entirely SSR (not Node.js) and it's very fast. Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. The Jamstack is a recipe for loading spinners, not speed.

Re: The absurd complexity of server-side rendering

#47

Post by eatonphil »

kodah wrote: post #30

I already know I'm off my rocker (and my lawn with that phrasing) but I really wish the browser supported Python as a language instead of Javascript. I can pickle Python, send it to a client, and run it. Combine that with everything else Python 3 has brought to the table and I'd have a language that runs client side that I can depend on and that I love.

Brython, Pyodide, Coldbrew. You do have options. ;)

Re: The absurd complexity of server-side rendering

#48

Post by Blackthorn »

phist_mcgee wrote: post #42
Daishiman wrote: post #2

The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fast…

I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.

But at the same time, if you wanted to get away from that and have replies inline, that doesn't require very much Javascript at all! It can just be incrementally added to the page you already have with little fanfare.

Re: The absurd complexity of server-side rendering

#49

Post by xboxnolifes »

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…

Javascript can get messy even if you just need integers, since even naively used integers are stored as doubles. This means that sending a random 64-bit identifier from a server to a client and just trying to read it as an int can give the wrong value if you aren't careful.
Post reply on HN