Hacker News Reader

Comment by t0astbread | Hacker News Reader

Aren't you back to the scaling problem when you generate the HTML on your server? As in, you now have frontend code to run on your server, which is more or less the same as SSR.

Addendum: That is, if your loads are large enough of course. Small projects will not have scaling problems either way.

View on HN

One of the bigger problems these days is that people don't bother assessing whether their use case is actually complicated enough to actually need any of this stuff, they just want to use it for the sake of using it.

People are allergic to actually profiling anything. I think, some days, that it is intentional, because if they had real data, the stories they tell themselves to justify what they are doing would fall apart.

The issue here is nodejs, react ssr is costly, taking all you cpu time, blocking the event loop and slowing down your app. On a multi-threaded (async or sync) web server this wouldn't be a issue most of the time.

Some add additional nodejs servers specifically and only for SSR, increasing complexity.

airbnb created https://github.com/airbnb/hypernova to solve exactly this problem.

That's exactly the point he's making. If you use a frontend js framework and you have to do SSR, then there's no longer any reason to use a JS frontend framework, because the reason they were made was to offload to clients the rendering, at the price of more complexity.

Back then, the cloud was not a thing yet, there was no Docker, no Kubernetes, no nice APIs to start instances, so it made sense to offload some computation to clients. Today, no longer.

What... the reason for JS frontend frameworks is to be able to dynamically update data visible without a full page refresh/refetch

JS does add some capabilities around avoiding full page refresh/refetches. See e.g. Turbolinks or PJAX for libraries that help with that.

Frontend frameworks do a hell of a lot more than that, though. Much of the time, they're doing things that are either the result of shortcomings in browser standards and implementations or things that are just stupid.

The reason React was made is because it's an easier way to reason about apps at scale, with many components and people working on them. As a result, there will be less errors and your team can move faster. It has nothing to do with offloading rendering to the client.

How is "reasoning" about apps at scale easier with React vs static or classic server-side HTML rendering where everything is addressed by a URL?

It isn't, but requirements rarely allow for static websites.

Amazon could be a server rendered web site and it is. AWS's and Google Cloud's consoles are borderline. Google Docs must be a client side app.

I worked on 3 projects this year, using Rails, Django and Phoenix. Only one of them has a front end that requires a client side app. The other two are within the bounds of server side rendering. That saves time and money to the customer.

Reply on news.ycombinator.com