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

371–380 of 395 posts

Re: The absurd complexity of server-side rendering

#371

Post by etchalon »

hardee wrote: post #125
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

Fantastic if you ever could anticipate having multiple different consuming clients. Otherwise it's fantastically over-engineered IMO.

I don't see it as anymore over-engineered than SSR.

In traditional SSR, using a template language, you craft a query and expose your variables to your template.

In SPA, you craft a query and expose your variables through an API.

Re: The absurd complexity of server-side rendering

#372

Post by com2kid »

Nextgrid wrote: post #238
com2kid wrote: post #193

Earlier quoted context omitted.

> 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 mili seconds 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.

> I'm sorry but 2 seconds to load a page with primarily text is not something you should brag about.

Reddit's homepage is primarily video and photos.

The homepage contents are obscenely dynamic, I have no doubt they use tons of caches for everything, but the homepage is not simple at all.

Since I am logged in, there is a profile lookup, as well as looking up to see if I have an notifications.

There is the fetching of stories + metadata from my personal feed, which involves custom prioritization. I doubt any of that can be trivially cached.

Reddit is not some simple static text website. Hacker news doesn't render a different page for every visitor, Reddit does. Heck HN saves on CPU by not even telling me if there are replies to my posts!

Re: The absurd complexity of server-side rendering

#373

Post by com2kid »

ryanbrunner wrote: post #242
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…

> 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 more comments is, well, not fast, but quick. Reddit is an example that clearly shows that the user experience of "old-style" code where interactions are primarily with the server beats out SPA. old.reddit.com is clearly superior in pretty…

old.reddit.com is great when I am travelling and limited to 128kbit/s of data.

The new site solves the problem of not losing my place in the feed when leaving a story, which is a huge pain point of the original reddit design.

Re: The absurd complexity of server-side rendering

#374

Post by com2kid »

PaulDavisThe1st wrote: post #327
com2kid wrote: post #190

Earlier quoted context omitted.

Pardon me while I load up reddit on my 4 year old $1000 Costco Special laptop. Yup, that was fast. OK let me disable ad block. Under 3 seconds to first render. Comments appear in under 2 seconds. Reddit performs very well. The new UI is legit faster. There is a bit of stupid here and there with it, and if you aren't logged in the experience is horrible, but speed is, IMHO, not one of the site's problems.

16 core Ryzen Threadripper 2950X on a 40Mbps link with ublock origin: 4-5 seconds for first render.

What OS?

Fresh Firefox instance, Windows 10, hitting homepage without logging in. 2 seconds, if that, page is fully loaded.

Chrome, I am logged in, but still using the old UI somehow. Same 2 second page load.

Core I7-8550. 16GB of RAM.

Running on a laptop whose battery is pretty much useless and whose fans are rather upset at the moment!

Re: The absurd complexity of server-side rendering

#375

Post by PaulDavisThe1st »

soundnote wrote: post #352
PaulDavisThe1st wrote: post #140

Earlier quoted context omitted.

> People complain about reddit a lot, but even on mobile, the reddit website is fast. only on mobile is Reddit fast.

I sometimes wonder if my HN refreshes go through because the site reloads instantly.

Yep. HN is fast.

Re: The absurd complexity of server-side rendering

#376

Post by grey-area »

DangitBobby wrote: post #343
grey-area wrote: post #210

Earlier quoted context omitted.

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

You choose something like react for the frontend if you need heavy interactivity, something closer to a desktop application than a traditional web app. Then you choose tools like Next.js that will do SSR for you so you can take advantage of how good browsers are at rendering HTML.

The needs you describe are incredibly rare. Facebook for example doesn’t have heavy interactivity closer to a desktop app. You can also do interactivity just fine with Ajax. These frameworks bring nothing but complexity and confusion.

Also, how good browsers are at rendering html has nothing to do with next js. Browsers don’t care where the html came from.

Re: The absurd complexity of server-side rendering

#377

Post by jwr »

christophilus wrote: post #274
jwr wrote: post #269

I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could bene…

This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever. I wish there were more stacks like Clojure/Script. While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know w…

> This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever.

"I don't like fruit — they are bitter and taste bad"

"Here's a kiwi: it's sweet and tastes great!"

"I think it's safe to say it'll probably remain niche forever. I wish I could get sweet fruit!"

I don't know about others, but I don't get paid for non-nicheness of tools I use (nor, incidentally, for the small size of my "hello world"). I get paid by users who use the software that I develop, and I choose tools that allow me to effectively deliver good quality software. So I guess my decision process might be slightly different — but overall I have no reason to complain, because I'm doing great so far :-)

Re: The absurd complexity of server-side rendering

#378

Post by tored »

motogpjimbo wrote: post #353
astrange wrote: post #80

Earlier quoted context omitted.

The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…

I'm not sure why you've been downvoted. Anyone who has ever seen a Laravel stack trace will surely have been appalled at the number of stack frames that sit below their own code, and all that machinery is loaded on every single request. It's truly shocking. PHP isn't Java and shouldn't be treated as such.

There is a very strong movement for using a large framework within the PHP community, like Laravel, upside is that is has helped PHP community to revitalize the PHP stack. The downside is that large frameworks is now considered best practice.

I wonder if OOP as a technique will eventually always end up as Rube Goldberg machine.

Re: The absurd complexity of server-side rendering

#379

Post by engineeringwoke »

Front end complexity - Making applications isomorphic so you can re-use code on the client and server

Hacker News commenter: Ugh, why is this problem so over-engineered. It's completely unnecessary

Back end complexity - Two hour Google article from yesterday that goes through layers of C++ and raw assembly that results in a 2-3% speed up by basically using SIMD and turning off branch prediction

Hacker News commenter: Wow! So cool!

Re: The absurd complexity of server-side rendering

#380

Post by dbbk »

nawgz wrote: post #363
dbbk wrote: post #333

Earlier quoted context omitted.

Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.

You're right, it's a far superior pattern to waste tons of dev cycles to enable your team to give money to AWS so AWS can execute the logic their device would already do, just so your initial page load is 50% faster and your app otherwise performs identically, except the huge stutter step when you try to hydrate the state to match what your server rendered, which looks like hot garbage. HN is not full of front-ends,…

Your viewpoint is valid but it's a philosophical argument, not a pragmatic one.

I'm also not sure what you mean by 'stutter step'. I would posit that 95% of visitors never even notice hydration.

Post reply on HN