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

151–160 of 395 posts

Re: The absurd complexity of server-side rendering

#151

Post by diego_sandoval »

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

I didn't get the memo when this was decided, and I'm still unconvinced.

Let me see if I get this straight:

The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). When the inherent complexity of the application means that there are state changes pretty often, doing a page reload so often would just kill the user experience, and using jQuery or similar libraries would lead to a spaghetti.

Is that the reason for client-side rendering being the "default" in the realm of modern javascript?

If that's the actual reason, then that seems reasonable, but I think that Javascript culture (frameworks, tutorials, articles) usually erroneously assumes that every application is a complex one with tons of state changes, thus assuming that client-side rendering is the only right way to develop an application (without counting "isomorphic" SSR which is just another way to create a spaghetti).

Sure, if I don't like it I can just move over to Django, Laravel, etc. but it feels like I never get an actual explanation of why client-side rendering is the default in these js frameworks, it's just accepted as a fact of life.

Re: The absurd complexity of server-side rendering

#152

Post by PaulDavisThe1st »

ConsoleTVs wrote: post #93
com2kid wrote: post #55

Earlier quoted context omitted.

> Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading mor…

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

10 years ago in suburban Phila, I had 50/50.

Today in rural NM, I have 40/5. Many of my neighbors have 25/2.

Time is not the only thing that controls internet bandwidth.

Re: The absurd complexity of server-side rendering

#153

Post by donavanm »

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…

Your axis here seems to be something like "unique content/personalization per client." From every client sees the same documentation content to every page view/action of an IDE is unique.

Re: The absurd complexity of server-side rendering

#154

Post by throwanem »

KorematsuFredt wrote: post #142
JJMcJ wrote: 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.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

Millions of pages? What was the site?

Re: The absurd complexity of server-side rendering

#155

Post by DangitBobby »

sph wrote: post #123
DangitBobby wrote: post #109

Earlier quoted context omitted.

Its a bit leaky, but I wouldn't call it crappy. What's crappy about it? Be specific.

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.

Re: The absurd complexity of server-side rendering

#156

Post by capn_duck »

nsonha wrote: post #143

article crticizes "the absurd complexity of server-side rendering" by starting with "In the olden days, HTML was prepared by the server..."

There's a huge difference between traditional server side web applications and the modern meaning of SSR. If you don't know the difference then this article probably isn't for you.

Re: The absurd complexity of server-side rendering

#157

Post by DangitBobby »

Widdershin wrote: post #126
DangitBobby wrote: post #118

Earlier quoted context omitted.

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.

Unfortunately that hasn’t been my experience. I learned about this problem after helping a very confused Remix user overcome this issue. I will give kudos to Remix for having a good docs page about this, something Next.js could do better (unless I just couldn’t find the docs). Also just wanted to say that I love your username.

I agree that the lines are a bit more unclear in practice and in the documentation. It genuinely takes some experimentation. That said, I think Next.js has a good reputation for good reason.

And thank you!

Re: The absurd complexity of server-side rendering

#158

Post by jshen »

cyber_kinetist wrote: post #115
eli wrote: post #77

Earlier quoted context omitted.

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.

A purely static site is more complicated outside of the simplest use cases.

Re: The absurd complexity of server-side rendering

#160

Post by toastercat »

KorematsuFredt wrote: post #142
JJMcJ wrote: 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.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

Yeah, I don't think a site with "millions of pages" is the right fit for SSGs.
Post reply on HN