Hacker News Reader

Comment by badfrog | Hacker News Reader

> a 2mb page right now, than a 200kb page that slowly grows to a 2mb page over the course of 20 components individually loading themselves.

Isn't the point that the 200kb is static code that can be served immediately, while the rest can't? Regardless of whether the remaining 1.8mb is built on the server or client, it still isn't available "right now"

View on HN

I think what he is saying is since there is a network delay of 300ms for every request, it's better for him to make a single request for a large file than to have to make 10 requests for 200k files and wait 300ms * 10.

If every requests adds this fixed latency, it would be much better to try and parallelize the requests vs bundling everything.

True, but these requests cannot be made simultaneously. The code is loaded only when the UI needs it.

If the files can be combined, the requests can be made simultaneously

You're right, and HTTP/2 was supposed to be a major boon here, but the problem is actually that the UI itself only loads these things once they've been rendered by the framework which is often after another component has loaded them, and even if they can be ran in parallel the response times can still vary, causing the UI jiggle you often see.

This isn't really a problem unique to high latency either, if you have a patchy connection in transit or for some other reason, the UI will suffer.

> but the problem is actually that the UI itself only loads these things once they've been rendered by the framework which is often after another component has loaded them

That just sounds like bad front end coding. A good framework used properly would not have that issue.

In webpack you can define which components are in which chunk, so you could organize them that way. I don't, but I know it exists.

If you have high bandwidth and low latency, bigger packages can lead to better user experience.

If you have high bandwidth and low latency, you generally get a good user experience anyway.

I meant high latency, sorry.

Most of the time it is though. I can understand if you have interacted with a component and now it needs to load new data. But on first page load, all the data you intend to show them you should be able to fetch and send with the initial request.

> all the data you intend to show them you should be able to fetch and send with the initial request.

Sure, but if it requires data from five different services and significant compute time, the initial request is going to be very slow. Users are more likely to bail out if they see nothing for a few seconds than if they immediately see a loading screen that lasts for a few seconds.

It's true, there are definitely use cases for lazy-loading UI. I would wager the majority of the time lazy-loaded UI is only present because the engineering team wanted to use new tools and not because there was a requirement to ease long compute calls though, but I'm speculating.

Reply on news.ycombinator.com