Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

111–120 of 395 posts

Re: The absurd complexity of server-side rendering

#111
post #106
post #99

In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.

Confusion is by whoever wrote the headline. Server side render is easy. Isomorphic is hard.

Yeah I was planning on changing the title, and then woke up on HN. Oh well.

Re: The absurd complexity of server-side rendering

#112
post #36

Laravel livewire / Phoenix liveview and a lot of new frameworks are now focusing on bridging this gap between ssr and clientside - almost trying to make it seamless. Though only time will tell, what can of worms that will open later.

to be fair, .net had stuff like that for ages. i've never used any of it though.

Re: The absurd complexity of server-side rendering

#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 client/browser still has to "render" that HTML into visual output.

True server-side rendering I would think should mean the server renders HTML into a gif or jpg which then gets shown in the browser.

Re: The absurd complexity of server-side rendering

#114

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

It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence.

The answer is "yes."

Re: The absurd complexity of server-side rendering

#115
post #77
post #73

Earlier quoted context omitted.

> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.

Heavily cached server-side rendering and statically generated sites kinda converge at some point to the same thing

Yes, but the latter can do the same thing without the complexity of the former.

Re: The absurd complexity of server-side rendering

#116
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…

The correct answer to this is that state lives in the url, which is shared between client/server. This is a simplistic solution for many applications, but still achievable on some level.

Re: The absurd complexity of server-side rendering

#117
whats the reason behind all this endless JS race that s been going on for years. I only had to use it once and it felt like everything was prematurely overabstracted ending in more code doing less. It made me run back to php+jquery, which is more like a car engine rather than an modern abstract art statue.

is it the overabundance of programmers? the fact that it makes them look busy? people liking wasting time recompiling most of the day? overengineering making people feel superior? it certainly doesnt feel healthy and makes one question whether the whole SV startup ecosystem is a cargo cult built on shaky grounds by people who are just apeing each other on everything, from design to backend.

Re: The absurd complexity of server-side rendering

#118

See https://remix.run for a modern, sane, progressive approach to server-based rendering w/ as-needed hydration.

Remix has the exact same issue unfortunately: https://remix.run/docs/en/v1/guides/constraints

Yep. But it does a pretty good job of communicating where the boundaries are and telling you when you've crossed them. It's not even close to a deal breaker.

Re: The absurd complexity of server-side rendering

#119

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'.

> 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'.

OTOH, making a reply button that drops-down a textarea with "save"/"cancel" buttons requires about 30 lines of Javascript.

And yet, almost all "modern" sites that have only this functionality has megabytes of dependencies.

Maybe both extremes are bad, and Javascript is like adding salt to food - too little and you'll be able to eat it, but won't enjoy it. Too much and you won't even be able to eat it.

Re: The absurd complexity of server-side rendering

#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.

Post reply on HN