The absurd complexity of server-side rendering • Hacker News Board

Re: The absurd complexity of server-side rendering

#261

Post by christophilus » Wed, Apr 20, 2022, 8:08 AM UTC

dinkleberg wrote: post #165

diego_sandoval wrote: post #151

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based U…

100%. Also, every web app I’ve worked on has accreted UI interactivity with time, and I often end up crossing the threshold where I wish I had started with a decent client-side framework.

Re: The absurd complexity of server-side rendering

#262

Post by ehnto » Wed, Apr 20, 2022, 8:12 AM UTC

vecinu wrote: post #202

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…

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

> SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

This is the only realistic reason I have seen to be honest. Isomorphism is a tool that you use to achieve a statically rendered site that you can give to Google, that will then become highly dynamic in the hands of the user.

But if you've got a mostly static site, what's the point of all the complexity? Why not just make a static site a more simple way, rather than using SPA tooling. Either you have highly interactive site or you don't, and if you do have an SPA style site, and need to appease Google, you might need SSR. Otherwise, use the right tool for the job and cut out the complexity is my opinion on the matter.

Re: The absurd complexity of server-side rendering

#263

Post by tored » Wed, Apr 20, 2022, 8:13 AM UTC

Except for the confusion about terminology the article has some good points.

We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time.

It think this is bad assumption to begin with.

If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is only one thing that makes sense to share, input validation code.

Like what is the definition of a first name, last name, age, price, email address etc. That is the one thing that need to be in agreement between the frontend and the backend to be able to exchange data.

But to share frontend and backend technology for only the gain of input validation seems like a heavy price to pay for little gain.

Re: The absurd complexity of server-side rendering

#264

Post by rawoke083600 » Wed, Apr 20, 2022, 8:15 AM UTC

ehnto wrote: post #262

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…

> SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized. This is the only realistic reason I have seen to be honest. Isomorphism is a tool that you use to achieve a statically rendered site that you can give to Google, that will then become highl…

>SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

SEO aside(that is another discussion), but Google "requiring" your site to be fast is a net positive for consumers/us !

Re: The absurd complexity of server-side rendering

#265

Post by jefftk » Wed, Apr 20, 2022, 8:16 AM UTC

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

SSR (2012ish, debatable) long predates Lighthouse (2018). If you mean that SSR is only a thing because people want pages to load quickly, however, then I'll completely agree with you.

Re: The absurd complexity of server-side rendering

#266

Post by fredrikholm » Wed, Apr 20, 2022, 8:18 AM UTC

lmc wrote: post #150

geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

How well does it work for complex projects/component libraries? React is a pain in the ass but there's at least some established patterns for large projects.

You will most likely be using a templating language to re-render the view with new state.

If you're lucky your chosen language enables you to do that inlined in your function along with your normal workflow. Otherwise you now have template files, templating logic and domain logic across several files and you're right back where you started (accidental complexity), minus the JS.

Re: The absurd complexity of server-side rendering

#267

Post by locallost » Wed, Apr 20, 2022, 8:18 AM UTC

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.

Re: The absurd complexity of server-side rendering

#268

Post by Widdershin » Wed, Apr 20, 2022, 8:18 AM UTC

IceDane wrote: post #224

What an incredibly boring, prosaic post which is almost completely devoid of anything useful. In fact, over half of the post is just the author waxing poetic about some tangentially related things. His arguments boil down to "To me, this seems like a bad idea." Well, OK buddy. Then don't do it. Meanwhile thousands of web developers have been doing it for years and it has never been easier.

This is a nice idea, but unfortunately my work involves helping customers with all sorts of stacks integrate our technologies.

Rather than quit my job, it’s a bit easier to document and raise awareness about these issues.

Unfortunate that you didn’t enjoy the prose, can’t please everyone.

Re: The absurd complexity of server-side rendering

#269

Post by jwr » Wed, Apr 20, 2022, 8:20 AM UTC

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 benefit from adding "using Node", because much of the complexity described is something I do not encounter at all. I'm using Clojure and ClojureScript with Rum as a React interface. Much (if not most) of my code is in cljc files, which get compiled with Clojure (for JVM on the backend) or ClojureScript (for JavaScript on the frontend). And the ClojureScript advanced compilation takes care of only including what is strictly necessary in the frontend compiled JavaScript.

I mean, sure, you need to be careful not to do stupid things like trying to read from files, but otherwise I just don't encounter much friction. And I reap the benefits of using a single language for both backend and frontend, with most of my data model (e.g. business logic) code written only once, with SSR being a nice cherry on top.

Re: The absurd complexity of server-side rendering

#270

Post by Widdershin » Wed, Apr 20, 2022, 8:23 AM UTC

epolanski wrote: post #237

boloust wrote: post #29

Earlier quoted context omitted.

Principled, explicit handling of various function colours. If implemented like Fantasyland, probably a terrible idea.

Which, again, has very little to do with any of the gist.

Hiya, I wrote this gist. I do actually think Monads or similarly expressive type constructs would allow us to eliminate this class of issue for good.

Hopefully the rise of Wasm makes this problem irrelevant for functional programmers, but that’s a whole other can of worms.

That said, it’s probably impractical to try and achieve that sort of type safety in JS via the Monad route, but maybe a clever TypeScript extension could be devised.