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

221–230 of 395 posts

Re: The absurd complexity of server-side rendering

#221

Post by vecinu »

danjac wrote: post #218
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…

"We built a very complex SSR framework so we can share code between client/server". Um, how many development hours did you save here?

Honestly that's difficult to quantify, if not impossible.

The beauty of what we've done is that other microservices internal to our corp are also leveraging said SSR code and can bootstrap their own backend very quickly. We've been following the BFF pattern (Backend for frontend).

Re: The absurd complexity of server-side rendering

#222

Post by ngrilly »

alkonaut wrote: post #207
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…

Does SSR need to be so complex for SEO? Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version, as soon as a browser isn't detected properly, or determined to be known a bot/crawler? E.g. you skip all interactivity, layout etc. I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampa…

This is what Discourse does.

Re: The absurd complexity of server-side rendering

#223

Post by iforgotpassword »

matt_kantor wrote: post #176
iforgotpassword wrote: post #169

Earlier quoted context omitted.

I've tried this twice and it didn't work out for me. If you want even just some features like categories and tags you end up with a tool that has some weird metadata language you put over the actual text, the markup obviously is yet another slightly different kind of markdown, and then learn the umpteenth way of linking to internal sites. Then you run the generator, triple check everything is not messed up because of…

I don't think I understand your point. Weird markup vs WYSIWYG authoring is orthogonal to static vs dynamic serving.

Static serving usually means you don't have anything running on the server but an actual web server, and you upload the static files to its webroot. So it's not technically possible to have any fancy editor in your browser. You have all the brains in some tool you run on your machine that processes your markup files and spits out html files.

Sure, you could throw PHP or whatnot on your server, have a nice editor and whenever you edit or add content it statically generates all the html files, which would probably technically still be called a static site generator but then I don't see why you'd want to do that instead of just going all the way and use normal blogging software and putting a cache in front.

Re: The absurd complexity of server-side rendering

#224

Post by IceDane »

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.

Re: The absurd complexity of server-side rendering

#225

Post by tored »

trinovantes wrote: post #81
hnov wrote: post #59

Earlier quoted context omitted.

If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker I've come up with, Server Only Rendering).

Except that many applications have public content that you want to be indexed and interactive for the user e.g. forums and ecommerce

For e-commerce probably checkout and perhaps the buy button needs to be interactive. Rest of it can be normal pages.

You can use different approaches depending on what you serve.

Re: The absurd complexity of server-side rendering

#226

Post by flak48 »

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…

Uber? :)

Re: The absurd complexity of server-side rendering

#227

Post by slim »

astrange wrote: post #108
gmfawcett wrote: post #92

Earlier quoted context omitted.

You sound like me, but ten years ago. :) I used to have a similarly negative and narrow-minded perspective about PHP, but my colleagues and their outstanding work have enlightened me.

PHP itself is perfectly designed to run CGI scripts and the correct architecture for web performance (shared-nothing). It's the third party developers that have second-system effect enterprise dreams. Though maybe some of them have found simplicity again.

you're right. it was obvious when we started seeing templating engines for php while php is itself a templating engine

Re: The absurd complexity of server-side rendering

#229

Post by uuyi »

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…

Worth pointing out that SSR scales better for huge surface area applications on very low resource endpoints like Citrix etc. Consider LOB enterprise applications. I’ve worked on ones with 700+ logical endpoints. A few chrome or edge tabs open on a few meg of JS and the client will bite the dust hard.

Re: The absurd complexity of server-side rendering

#230

Post by tonto »

my personal worry, could be unjustified, but SSR seems to be much less secure compared to plain old client side stuff. sure, static client side is less seo friendly but...not going to compromise your servers! considering the fast moving and relatively patchy security of npm ecosystem...things like prototype pollution vulns are alerted almost weekly if not daily and you are lucky if a fix exists that you can upgrade to!
Post reply on HN