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

281–290 of 395 posts

Re: The absurd complexity of server-side rendering

#281

Post by marcus_cemes »

cersa8 wrote: post #271

Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…

It's easy to server-side render Next.js apps, but usually they still have to talk to a backend. I don't think Next.js' API routes are good for this, especially if you need messages queues, cron jobs, etc. Now you have three distinct parts, client-side rendering, server-side rendering and the API, usually all communicating via JSON.

Traditionaly with PHP, C#, Ruby, Elixir, etc, your backend and frontend was tightly coupled, your code has complete access to backend resources, and the view/template would map the state to a HTML document.

Now, for the sake of interactivity, the view has effectively moved from the backend to the frontend with the introduction of SSR/SPA, JSON everywhere and code duplication so that they can all talk and understand each other. It's cool when it works, but it is easily at least 3x the amount of work.

There is of course the argument of "just write both the client and server in JS/TS and use a monorepo", that brings its own challenges. Limiting the backend stack to what browsers support is not great, especially when Node.js is single-threaded with cooperative scheduling. No, lambda functions don't solve this entirely, and they're freaking expensive for CPU time. Honsetly, other ecosystems have it so much simpler IMO, even if it isn't as flashy.

I say all this as a svelte developer, guilty.

Re: The absurd complexity of server-side rendering

#282

Post by gherkinnn »

franze wrote: post #279

I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on…

There is a lot of value in rendering the shell of an app on the server and populating the rest on the client. The outer layout of a given view is mostly static. Doing this correctly gives you stable loading with no reshuffling as the rest loads.

And some views in apps can have page-y aspects like reports that might as well be static. Though this is an optimisation, and can be deferred till later.

Re: The absurd complexity of server-side rendering

#283

Post by simongray »

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…

Rum is amazing. I also use it for my latest Clojure/ClojureScript projects since you can move quite effortlessly from HTML templates to a hydrated web app should the need arise.

Re: The absurd complexity of server-side rendering

#284

Post by 2143 »

franze wrote: post #279

I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on…

In principle I agree with what you say, but I'd like to make a more fine grained distinction.

If the website is just static content, go for static-site generation.

If it's a webapp, where you have some interactions but there's only a few of these and the site is not that complex, then go for server-side rendering.

If it's a web app with complex interactions, go for client-side rendering.

Re: The absurd complexity of server-side rendering

#285

Post by jclem »

Animats wrote: post #107
colejohnson66 wrote: post #72

Earlier quoted context omitted.

SSR in terms of webdev means what this post describes: generating HTML on the server. “Rendering” is a bit of a misnomer; a more apt title would be “server side HTML generation”, but that’s a bit long. The alternative to SSR is CSR (client side rendering). Think React SPAs.

I know, I know, the webcrap crowd uses that terminology. Nobody else does. As someone who spends most of their time right now inside of 3D game-type renderers, I have a hard time thinking of cranking out HTML as "rendering". What does that crowd call the part of the browser that does layout and display?

Layout and paint.

I don’t think using the term “rendering” for interpolating data into a template is anything new, though, nor is it bad or even confusing that it means one thing in the context of computer graphics and another in the context of programming language templates. ¯\_(ツ)_/¯

Re: The absurd complexity of server-side rendering

#286

Post by TheOtherHobbes »

dymk wrote: post #75
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.

Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.

You don't need to regenerate the entire site. You only need to regenerate the pages that have changed and maybe some indexes.

Considering that SSR has to generate the pages for each view - unless they're cached, which sort of reduces to option 1 anyway - site (i.e. page) regeneration is hugely more efficient.

Re: The absurd complexity of server-side rendering

#288

Post by cutler »

adrianh wrote: post #231
vecinu wrote: post #202

Earlier quoted context omitted.

> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and m…

Sorry, I’m not seeing how this overengineered solution adds any benefit…? If it’s a mostly static site, just use Django or Rails and be done with it. SEO becomes a non-issue and your code stays in a single (server-side) language.

But you have Turbo/Hotwire in Rails so best of both worlds, no?

Re: The absurd complexity of server-side rendering

#289

Post by langsoul-com »

marcus_cemes wrote: post #281
cersa8 wrote: post #271

Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…

It's easy to server-side render Next.js apps, but usually they still have to talk to a backend. I don't think Next.js' API routes are good for this, especially if you need messages queues, cron jobs, etc. Now you have three distinct parts, client-side rendering, server-side rendering and the API, usually all communicating via JSON. Traditionaly with PHP, C#, Ruby, Elixir, etc, your backend and frontend was tightly co…

No post body was provided.

Re: The absurd complexity of server-side rendering

#290

Post by pjmlp »

willbudd wrote: post #170
bob1029 wrote: post #135

Earlier quoted context omitted.

The amount of leverage you can get out of these paths is pretty incredible. The fundamental idea is really simple too if you boil it down to the absolute minimum essence... The following 6 lines of javascript is all it takes to connect a hot pipe from server to client and dynamically invoke whatever is required. function StartApplication() { document.ApplicationSocket = new WebSocket(...); document.ApplicationSocket.…

I can't believe it took people 12 years since the publication of the WebSocket standard to figure this stuff out. Is everyone just running in circles?

We were already doing this kind of workflows with WebForms and Java Server Faces alongside DHTML, but naturally we weren't cool, so the kiddies took 12 years to re-discover the wheel.
Post reply on HN