undefined | Better HN

0 pointsbob10292y ago0 comments

> It's number of requests.

Absolutely. This is the prime hallmark of shitty, slow web. If you fight your battles here everything else will fall into place.

I've started building our B2B web apps where the server returns 1 final, static HTML document in response to every resource. There are no separate js/css resource URLs at all in our products anymore. Anything we need is interpolated into the final HTML document script or style tag by the server.

If you back up for a few minutes and really think about what kind of power you get with server-side rendering relative to # of requests... It's a gigantic deal. Composing complex client views shouldn't happen on the client. It should happen on the server where all of the answers already live. Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage?

In terms of latency, the game theory for me is simple: Either do it in exactly one request, or it doesn't matter how many requests it takes. That said... caching effects are really important for many applications, and separating sources out can save you a lot of $$$ at scale. So, you will need to balance the UX and economic effects of some of these choices.

0 comments

ethbr02y ago

> Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage?

Correct me if I'm wrong, but originally it was because "servers" had order-of client compute power. Ergo, it was necessary to offload as much compute to the client as possible.

And then in early js era it was because network latency and bandwidth limitations precluded server-client round-trips for anything user-interactive.

Now, we've got surplus compute and bandwidth on both sides (order-of text payloads), so caching architecture and tooling become the limiting factors.

bob1029OP2y ago

> "servers" had order-of client compute power

Still do. Biggest difference: If you intend to serve the same complexity of web experience today that you were trying to serve 20 years ago, you will find a single MacBook would likely be enough to handle the traffic. The challenge is that we've taken advantage of the exponential compute growth over the years and now it feels like we still have the exact same scaling issues on the server relative to the client.

If you constrain your product & design just a tiny bit, you can escape this horrible trap and enjoy those 4-5 orders of magnitude. If you design your website like Berkshire Hathaway or HN, you are on the right power curve. Seriously - go open Berkshire's website right now just to remind yourself how fast the web can be if you can lock that resume-driven ego crap in a box for a little bit.

NikolaNovak2y ago

It's very fast. It's almost unusable on a phone. That's not necessary though - I don't think you need much fanciness to make those tables not look teeny on the phone, just a little less pixel and size hard coding I think?

bob1029OP2y ago

I am 99% sure you could solve this with a media query and some CSS totaling no more than 1KB.

XiS2y ago

Ever watched how many requests are fired off when opening the Telegram Web emoji window in any browser cache? Open it for yourself with developer tools open and cry.

4111111111111112y ago

For the record: a PWA can also be served by a single request, it's called hydration.

My issue with these kinds of discussions is that they're inevitably using outright false arguments.

You can make a well performing website through SSR and a backend templating language, yes.

However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.

You can make a pwa with any of the usual frameworks and it's going to perform wonderfully... The bad performance begins when people start to write terrible code or just keep adding dependencies to cyberstalk their users.

But doing the same in the backend puts you into the same position wrt poor performance, so it's just not an argument for or against SPAs.

It's totally fine if you decide to write your website with a SSR stack however, and it could very well be the better choice for you, depending on how your skillset is aligned with the technology.

treis2y ago

>You can make a well performing website through SSR and a backend templating language, yes.

>However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.

I'm not sure this follows. It's harder to do client side rendering because your data is across a slow HTTP barrier. And the client is maintaining state which is harder than stateless.

The problem with SSR is that it's usually tied with single applications which are usually monoliths. But neither of these are requirements for SSR. If you break up your monolith into modules and/or SOA you get the best of both worlds.

But for reasons I don't understand nobody does it this way. It's either monolith + SSR or microservices + client rendering

bob1029OP2y ago

> If you break up your monolith into modules

This is what we are doing. The server-side web monstrosity is effectively 30+ independent modules that are nested inside a common template. All of these could be worked individually without anyone stepping on each other. Anything that needs to be truly common lives in the wrapper and is rarely changed.

The only part of our business that everyone absolutely has to agree upon is the SQL schema. As long as we are talking to the data in some common language, no one will get too far off track.

azurelake2y ago

They do, look up the “Backend for Frontend” pattern.

j / k navigate · click thread line to collapse

0 comments

ethbr02y ago

> Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage?

Correct me if I'm wrong, but originally it was because "servers" had order-of client compute power. Ergo, it was necessary to offload as much compute to the client as possible.

And then in early js era it was because network latency and bandwidth limitations precluded server-client round-trips for anything user-interactive.

Now, we've got surplus compute and bandwidth on both sides (order-of text payloads), so caching architecture and tooling become the limiting factors.

bob1029OP2y ago

> "servers" had order-of client compute power

NikolaNovak2y ago

bob1029OP2y ago

I am 99% sure you could solve this with a media query and some CSS totaling no more than 1KB.

XiS2y ago

Ever watched how many requests are fired off when opening the Telegram Web emoji window in any browser cache? Open it for yourself with developer tools open and cry.

4111111111111112y ago

For the record: a PWA can also be served by a single request, it's called hydration.

My issue with these kinds of discussions is that they're inevitably using outright false arguments.

You can make a well performing website through SSR and a backend templating language, yes.

However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.

But doing the same in the backend puts you into the same position wrt poor performance, so it's just not an argument for or against SPAs.

It's totally fine if you decide to write your website with a SSR stack however, and it could very well be the better choice for you, depending on how your skillset is aligned with the technology.

treis2y ago

>You can make a well performing website through SSR and a backend templating language, yes.

>However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.

I'm not sure this follows. It's harder to do client side rendering because your data is across a slow HTTP barrier. And the client is maintaining state which is harder than stateless.

But for reasons I don't understand nobody does it this way. It's either monolith + SSR or microservices + client rendering

bob1029OP2y ago

> If you break up your monolith into modules

The only part of our business that everyone absolutely has to agree upon is the SQL schema. As long as we are talking to the data in some common language, no one will get too far off track.

azurelake2y ago

They do, look up the “Backend for Frontend” pattern.

j / k navigate · click thread line to collapse