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

121–130 of 395 posts

Re: The absurd complexity of server-side rendering

#121

Post by em-bee »

singingboyo wrote: post #90
bcrosby95 wrote: post #70

Earlier quoted context omitted.

I've never worked on a project that could be "all in" on client side state. To be all in there means your application doesn't need the network at all except as a method to distribute your application. One step away from that would be something that is completely client authoritative - I've also never worked on a project like that. Note that even if your code has zero Javascript, you can still have state mixed between…

You're technically correct (the best kind!) but in practice one can largely ignore server state in some applications. I've got a side project where the data is stored server side. In practice, that server side data might as well be a saved file on the clients hard drive. Is it "all in" on client state? Not really. Do I ever need to worry much about synchronization? Also no. The synchronization is just "send it to the…

that's pretty much how i build all my websites. not with mongodb but another reusable generic CRUD backend. it's not much more network heavy than a static or serverside rendered site and the server doesn't need to keep any state other than the data itself. any custom state that the client wants to store on the server is just saved as additional server data.

Re: The absurd complexity of server-side rendering

#123

Post by sph »

DangitBobby wrote: post #109
sph wrote: 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.

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

This article is a good start.

Re: The absurd complexity of server-side rendering

#124

Post by silviogutierrez »

Shameless plug: If you want seamless SSR with Django logic, but React templates, check out my project at https://www.reactivated.io .

It's like HTMX but uses React, and the JS bits are rendered on the server. You can then hydrate on the client.

The Reactivated docs site itself uses the project: https://github.com/silviogutierrez/reactivated/tree/main/web...

Re: The absurd complexity of server-side rendering

#125

Post by hardee »

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.

Re: The absurd complexity of server-side rendering

#126

Post by Widdershin »

DangitBobby wrote: post #118
Widdershin wrote: post #94

Earlier quoted context omitted.

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.

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.

Re: The absurd complexity of server-side rendering

#127

Post by kibwen »

matheusmoreira wrote: post #57
pphysch wrote: post #17

Earlier quoted context omitted.

Adtech needs a lot of JS to work. JS to determine how long they are hovering over this and that element, how long this or that ad is in their view, and so on and so forth. The logical conclusion is that every single HTML element needs to be wrapped in a bit of JS somewhere. Nothing should happen in the users browser that can't be monitored by JS.

So adtech is ruining the web. Everything makes sense now.

Adtech represents the ruthless financialization of human attention, so it's not just ruining the web, it's ruining society.

Re: The absurd complexity of server-side rendering

#128

Post by inopinatus »

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

Now that the end-user is essentially using their browser as a thick client for that RIA/SPA, and the client-server interaction primarily supplies certification and replication services, we can congratulate ourselves on having more-or-less reinvented Lotus Notes.

Re: The absurd complexity of server-side rendering

#129

Post by [deleted] »

alserio wrote: post #86
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

As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-... https://dev.to/this-is-learning/conquering-javascript-hydrat...

[deleted]

Re: The absurd complexity of server-side rendering

#130

Post by briHass »

com2kid wrote: post #55
stevebmark wrote: post #45

Earlier quoted context omitted.

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 enti…

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

It's pretty hard to compare some random free PHPBB running on a underspec'd host to companies with billions in revenue to support their platform. Honestly, reddit and HN are so simplistic, there's not much added by JavaScript doing any rendering.

Reddit in particular is horrific. Their API is slow, and their JS bogs down on anything that isn't a super-fast desktop. Server pages would be able to handle most of what they do, faster and better, except for crap like live updates or typing/posting indicators that don't add much value.

Post reply on HN