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

61–70 of 395 posts

Re: The absurd complexity of server-side rendering

#61

Post by qbasic_forever »

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…

VS Code is effectively a SSR IDE. Electron and node are the 'server' side of it and are necessary for interacting with the filesystem and all the native things browsers can't access (running processes, terminals, etc.). It has a somewhat complex RPC model (inherent to all Electron apps in general) where JS code on the browser frontend side has to make requests with JS code on the node side and vice-versa, just like most Next.js style SSR apps. It's a very similar ball of complexity for better or worse as mentioned in this gist/blog post, and in general very necessary as browsers are only taking baby steps to give full access to file systems, processes, hardware, etc.

Re: The absurd complexity of server-side rendering

#62

Post by acchow »

trinovantes wrote: post #28
stickfigure wrote: post #20

SSR feels like an echo of JSF (that's JavaServer Faces for you youngins) - an exceptionally complicated way of doing simple things. IMO, SSR will follow the same arc in history - a brief period of popularity, followed by a lot of "what on earth were we thinking". Client side rendering is much simpler and cleaner.

SSR is generally for SEO and performance

Googlebot can render with javascript now, so why do we still need SSR for SEO?

Re: The absurd complexity of server-side rendering

#65

Post by pphysch »

giantrobot wrote: post #37
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.

Adtech wants that JavaScript. It doesn't necessarily need it. Most of the metrics generated are ultimately worthless. They exist to slap together bullshit graphs to overwhelm clients with "data".

Sure, analytics doesn't necessarily require JS, but the host client software absolutely does need it to create a gameified experience to attract and retain users over their competitors.

Re: The absurd complexity of server-side rendering

#66

Post by presentation »

nawgz wrote: post #54
chrisco255 wrote: post #52

Earlier quoted context omitted.

Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the…

> Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my question was unclear. I did not mean compute/bandwidth "in totality", I meant "in costs that would be invoked by the application owner". > Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server sid…

Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.

Re: The absurd complexity of server-side rendering

#67

Post by Gigachad »

kodah wrote: post #30

I already know I'm off my rocker (and my lawn with that phrasing) but I really wish the browser supported Python as a language instead of Javascript. I can pickle Python, send it to a client, and run it. Combine that with everything else Python 3 has brought to the table and I'd have a language that runs client side that I can depend on and that I love.

Maybe some day WASM will become the default and you will just compile whatever you feel like to send out.

Re: The absurd complexity of server-side rendering

#69

Post by giobox »

kodah wrote: post #30

I already know I'm off my rocker (and my lawn with that phrasing) but I really wish the browser supported Python as a language instead of Javascript. I can pickle Python, send it to a client, and run it. Combine that with everything else Python 3 has brought to the table and I'd have a language that runs client side that I can depend on and that I love.

Isn't this supposedly one of the magical things WebAssembly gets us?

While I can sympathise with wanting in the browser, I'm not sure its so great in reality and I'm really scared of things like Pyodide/Blazor/ from a debug perspective.

Today the fact its JS everywhere client side for most part has made our lives hugely easier in a lot of regards. A world in which many languages can compile down to some web assembly and run will make debugging and developing web apps even more complicated than it already is...

Re: The absurd complexity of server-side rendering

#70

Post by bcrosby95 »

bob1029 wrote: 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…

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 client and server: instead of living in Javascript, it lives in the html, oftentimes as values in form elements. Even though the html is generated on the server, it still lives in the client, ready for the client to do things with it - such as submit a form with information that is 8 hours out of date.

There are obviously ways around this, but it's still something one should keep in mind.

Live update via websockets can kinda get around this. As long as there are no bugs and all state is properly transmitted and processed in a deterministic order. But it's still effectively a synchronization process and stuff can go wrong.

Post reply on HN