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

351–360 of 395 posts

Re: The absurd complexity of server-side rendering

#351

Post by pygy_ »

This could probably be mitigated by a combination of algebraic effect handlers and session types for effects.

Algebraic effect handlers let you dynamically (re)define how effects are handled for a given piece of code.

and

- session types for effects, that would let one specify protocols for effects (i.e. a HTTP response handler would not be granted access to the socket, but would be allowed to use dedicated effects: `statusCode`, `header`, body` and `trailer` effects and would not be allowed to use them in a way that violates HTTP. Session types let you check that at compile time.

Re: The absurd complexity of server-side rendering

#352

Post by soundnote »

PaulDavisThe1st wrote: post #140
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. only on mobile is Reddit fast.

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

Re: The absurd complexity of server-side rendering

#353

Post by motogpjimbo »

astrange wrote: post #80
gmfawcett wrote: post #13

Earlier quoted context omitted.

I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.

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.

Re: The absurd complexity of server-side rendering

#354

Post by 5560675260 »

jdrc wrote: post #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 recomp…

Webdev shifted from making pages of content with some interactivity to web apps that live and maintain state on the client and occasionally query backend for some data. You don't need or particularly benefit from modern JS frameworks for somewhat interactive pages. But you absolutely can't do web apps with ad hoc jQuery and maintain your sanity.

Re: The absurd complexity of server-side rendering

#355

Post by 5560675260 »

dbbk wrote: post #332
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

Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max. With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen. Try it in real life and you'd quickly see your idea would be a terrible user experience.

Why would it take multiple, multiple seconds to download JS bundle (cached behind Cloudflare) and then make a request for initial data (probably also cached behind Cloudflare)? Overhead of downloading most of the app is likely less than that of loading a single hero image from said website.

Re: The absurd complexity of server-side rendering

#356

Post by dbbk »

5560675260 wrote: post #355
dbbk wrote: post #332

Earlier quoted context omitted.

Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max. With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen. Try it in real life and you'd quickly see your idea would be a terrible user experience.

Why would it take multiple, multiple seconds to download JS bundle (cached behind Cloudflare) and then make a request for initial data (probably also cached behind Cloudflare)? Overhead of downloading most of the app is likely less than that of loading a single hero image from said website.

On 3G and even low 4G it absolutely would. I've seen it. Also, a lot of mobile devices do not have as strong processing power as you think. Parsing and executing that much JavaScript also adds time.

Re: The absurd complexity of server-side rendering

#357

Post by throwanem »

robin_reala wrote: post #217
throwanem wrote: post #154

Earlier quoted context omitted.

Millions of pages? What was the site?

It’s not so unusual. My employer has a product line of ~40k products, in ~45 markets, with ~2 languages per market, which gets you to 3.6m product pages immediately, and that’s leaving aside any other pages.

That's fair, but I bet you're not using a static site generator to produce your PDPs. (Or, if so, I'd love to read an engineering blog post about it! Static PDPs would be a solid optimization in a lot of ways, and while I'm no longer in a role where that could be directly useful, it'd still be interesting to find out what challenges a team overcame and how in the course of getting there.)

Re: The absurd complexity of server-side rendering

#358

Post by locallost »

dbbk wrote: post #329
locallost wrote: post #267

The complaint in the article is technical, but my issue with the SSR + hydration approach is that it doesn't actually work for the users. Mainly because if you need a page that is indexed by Google, there is a high chance your users will browse it and open pages in new tabs. So the approach of "there is a small initial penalty, but everything is faster later" no longer applies -- you get that initial hit quite often.

What initial hit are you referring to? If it's the origin request, just chuck it behind a CDN with some Cache-Control headers and call it a day.

The initial hit to hydrate / initialize the app.

Re: The absurd complexity of server-side rendering

#359

Post by mst »

mekster wrote: post #132
mst wrote: post #105

Earlier quoted context omitted.

I am entirely unfond of PHP as a language but Laravel - and competently written apps that use it - are damn impressive nonetheless.

If you can't like the current PHP, there's probably no language that will make you feel too well. What exactly is so bad about it?

The point I wanted to make was that Laravel is objectively impressive even to somebody who dislikes PHP, so going into details as to exactly why I dislike the language would distract from what I was trying to get across.

Re: The absurd complexity of server-side rendering

#360

Post by wtetzner »

di4na wrote: post #318
wtetzner wrote: post #314

Earlier quoted context omitted.

But at that point, what exactly are you gaining?

Lower cost, better use of hardware, better scalability, easier debugging, more robustness to failure, etc etc

It's unclear that any of those are true if you need to maintain a distributed build system.
Post reply on HN