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

211–220 of 395 posts

Re: The absurd complexity of server-side rendering

#211

Post by nickcox »

noduerme wrote: post #197
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…

Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React that would automate the Dom update and bind the Dom more closely to the data state on the server. After many years, front end programmers forgot how to build…

> Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React

I think you skipped a few years there! AJAX, Mootools, prototype, JQuery, etc.

Re: The absurd complexity of server-side rendering

#212

Post by lawn »

tiberriver256 wrote: post #133
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…

Blazor Server and other HTML over the wire frameworks (Livewire, Hotwire, HTMX, etc.) are the new sweet spot for a lot of LoB web applications I think.

The productivity boost I've gotten with Phoenix LiveView vs a typical front/backend split is simply unreal.

Seriously, if you haven't tried it, you're missing out.

Re: The absurd complexity of server-side rendering

#213

Post by fatbird »

dimgl wrote: post #183
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.

I think you're confused as well. Most frameworks that provide any kind of HTML rendering method can do server-side rendering. The trickiness is making them isomorphic. > the other is the definition of leaky and crappy abstraction Well that's just like, your opinion man.

You're not wrong, dimgl, you're just an asshole.

Re: The absurd complexity of server-side rendering

#214

Post by blenderdt »

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…

Recently I started to toy with a PHP framework that works like Blazor and has all the state on the server. It also has the virtual DOM on the server. This works great even without sockets or polling. All requests from the client to the server will have a virtual DOM diff as result.

Having the state only on the server is great.

Re: The absurd complexity of server-side rendering

#215

Post by KorematsuFredt »

throwanem wrote: post #154
KorematsuFredt wrote: post #142

Earlier quoted context omitted.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

Millions of pages? What was the site?

It was basically a clone of https://www.gutenberg.org/.

Re: The absurd complexity of server-side rendering

#216

Post by fatbird »

jdrc wrote: post #117

whats the reason behind all this endless JS race that s been going on for years. I only had to use it once and it felt like everything was prematurely overabstracted ending in more code doing less. It made me run back to php+jquery, which is more like a car engine rather than an modern abstract art statue. is it the overabundance of programmers? the fact that it makes them look busy? people liking wasting time recomp…

JavaScript based webdev continually makes the next thing you have to do seem easy if you just use this framework, that approach, the latest library for it, and the build tool that finally handles this case. It's a textbook example of the combination of the sunk cost fallacy and short-termism: you continually make amazing web stuff happen quickly by going into just a bit more technical debt. It's a technical debt pyramid scheme. The further you get, the more you're trapped by your previous decisions of convenience. It's an ecosystem addicted to quick fixes, no matter the cost.

Re: The absurd complexity of server-side rendering

#217

Post by robin_reala »

throwanem wrote: post #154
KorematsuFredt wrote: post #142

Earlier quoted context omitted.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

Millions of pages? What was the site?

It’s not so unusual. My employer has a product line of ~40k products, in ~45 markets, with ~2 languages per market, which gets you to 3.6m product pages immediately, and that’s leaving aside any other pages.

Re: The absurd complexity of server-side rendering

#218

Post by danjac »

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…

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

Re: The absurd complexity of server-side rendering

#219

Post by vecinu »

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…

> I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?

That's correct. They call that "cloaking" when you render different content for a crawler than for a normal user. Google is rewarding sites for making the UX better for the end user.

> Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version

We're actually experimenting with this approach in a couple of different ways. One approach we're testing now is using AWS Lambda to render a fairly static version of the page using puppeteer. So far the results are promising as the page is true to what the end user would see (except for client-side logic / AJAX requests) and it renders much quicker than the standard experience with all the analytics/JS libraries we use.

Re: The absurd complexity of server-side rendering

#220

Post by giantrobot »

jsemrau wrote: post #195
kibwen wrote: post #127

Earlier quoted context omitted.

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

Very aptly put. But its our fault as we don't want to pay for content online.

Most online content is too small/short to be worth paying an amount of money that would be worth the transaction.
Post reply on HN