Yeah, it's due to client side routing. The tradeoff is slightly higher JS size on the first load (but it gets cached) then when performing navigations it's only needing to fetch the data required to render the page.

The alterative is an old school style web server that returns a new HTML file and page reload on every navigation which is higher download and runtime cost (which is how the real HN does it!). No criticism here as the site definitely works well regardless.

Remix (which uses React as the UI library) is server side rendered

True, but it still needs to download a big chunk of JS to have client-side routing.

Yes, though I wouldn't call it a 'big chunk'. The whole page was 500KB and it seems the Remix library code is a small piece of that (measuring in the 10s of KB).

Yeah, I didn't mean it was necessarily too big. I just meant that, due to the architecture of an app where React controls all the client-side routing and interactivity, you need a significant about of JS just to bootstrap the app even if you've only got a very small amount of client interactivity.

I see and that's accurate though this is where Remix really improves on React.

If you disable JS on the client and load a Remix app, the app will still work (though not as fully). You'll still be able to navigate links, load data etc. That's not true of most other apps built in just React that do all their data fetching client side and store all the data client side.

> That's not true of most other apps built in just React that do all their data fetching client side and store all the data client side.

I mean, it's true for any halfway competent implementation of a React app with React Router and SSR. I love Remix and I agree that it offers a great dev experience and will probably make developing React Router SSR apps much more accessible to a lot of new devs. But this particular aspect (SSR with nested routes that each have their own data loader function, and links that are actual <a href="" /> links) is, like, the bare minimum functionality you'd have in an SSR React app 5 years ago. I always feel like the Remix team is massively underselling itself when they focus so much on "we have SSR with nested routes!" instead of focusing on the real innovations that Remix brings to the table.

JS apps like this should be faster, since they are downloading the "shell" of the application once and simply rendering content from lightweight JSON data requests rather than requesting an entire HTML page and re-rendering it. (Which also requires the server to query and send back things the client already has, like your username and karma) Single page apps get a lot of hate here because they tend to end up as huge bloated applications (not that your typical website with ads and popups is any better), but it works great when done right.

Remix is a server-side rendering framework focused on pre-SPA web fundamentals like progressive enhancement and minimizing downloading and evaluating JavaScript and CSS assets for lighter, faster pages.

Edit: It does in-fact load a JSON payload along with client-side routing as well if you click to view comments. But then if you use browser refresh, it renders as a traditional server-side request. So true to its name, Remix is a blend of both approaches, playing on the strengths of each.

Yes, I should have mentioned that. Remix and Next remove the initial loading that SPAs seem to be known for, where the page is rendered but then it fetches again to actually get the content. I always hated that and was trying to find workarounds years ago for Angular because while loading JSON content is great for subsequent requests, it seemed so backwards to deliver the entire app over HTTP and then just make another HTTP request to fetch the content while the user looks at a loading screen, rather than doing it all in one step.

You're probably feeling it's faster because it's using <Link prefetch> on every link so everything is prefetched before you click the link (when you hover them) which makes the navigation almost instant once you click it.

That's not right.. it's literally only on the 'new' and 'threads' links in the top navigation: https://github.com/clintonwoo/hackernews-remix-react/search?...

Might even be a nanosecond faster if they could drop the request to ?_data=routes%2F__main that fires off on every click and returns {}.

The difference in speed is likely due to the fact that for many actions, data is sent as json and then placed into html markup on the client using code that was downloaded once at the beginning. This probably results in a smaller payload.