[rkagerer]

One thing I hate about the modern web is pages that load with lots of missing content / empty components and then download and render that content afterward.

Is this a React thing?

Waiting for the extra request(s) adds lag time, makes back/forward navigation clunky, interrupts what I was doing if I already began interacting with the page (eg. infamous relayout / unwanted scroll) and sometimes breaks snapshotting tools like archive.is.

I don't mind pages with javascripted controls, but their initial content should be included in the payload with the initial page load. Don't the frameworks have tools to help you do that?

[allset_]

It's not specifically a React thing, but JavaScript enables it. Lazy-loading content is a good idea if you're building dynamic web _applications_, as common components (buttons, modals, etc.) don't need to be reloaded over and over. However, with mostly static content like a blog, it's generally not a great idea.

[mbirth]

You can probably thank Google for that as to get a higher page ranking, a site must do the initial load fast. And showing only empty placeholders is fast.

[dzhiurgis]

Any modern browser automation tool can wait for all requests loaded. Also sounds like you need better internet or re-check your expectations.

[Fredej]

I absolutely agree with OP. I find it annoying that things load like that - even on a gigabit line with a beefy modern CPU. The solution is not to slow everything down to wait for the last thing to be loaded.

That UI/UX is getting slower as everything is getting faster is a sad reality of the times. But I guess that's the price of faster iterations, easier developer flows and a building on top of the lates greatest framework.

[deergomoo]

> their initial content should be included in the payload with the initial page load

The problem with that is that it pretty much requires you be running node on the back end too. If your back end is built with say PHP or Ruby, you’d need to call out to a node process, which is potentially a lot of additional complexity, time, and expertise.

[midrus]

Even if you are talking about SSR such as how Next.js does it, you wouldn't be spanning processes from your ruby/php application. You would deploy it as a separate application responsible of the frontend, using your ruby/php application as a backend service providing an API.

An alternative is to just serve the HTML from your ruby/php and then take over in the frontend, but this is more complex and not worth it in my opinion.

[deergomoo]

> An alternative is to just serve the HTML from your ruby/php and then take over in the frontend

This is still incredibly common for apps that are mostly server rendered but use React/Vue etc "sprinkled" through the codebase for more complex bits of UI.

[gpanders]

What, why? It’s just HTML, which PHP and Ruby can generate just fine.

[deergomoo]

If your component is generated by something like React you'd need to be running React on the back end to pre-render the component and have the front end re-hydrate it.

Otherwise you'd be trying to implement everything once in JS and once in PHP/Ruby