5 ms·

On my machines (desktop and smartphone), this implementation is noticeably faster than the real thing; or at least that's how I perceive it. I never worked wit

On my machines (desktop and smartphone), this implementation is noticeably faster than the real thing; or at least that's how I perceive it. I never worked with, or even tried, React and such libraries but a bit surprised. The code in this version here must be much more complexe, and the server much smaller, yet (feels as if) it is faster. Am I the only one experiencing this and surprised by it?

sergiodxa 5y ago
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.
- mattwad 5y ago
  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?q=prefetch https://github.com/clintonwoo/hackernews-remix-react/search?...
woah 5y ago
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.
alana99 5y ago
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.
- bern4444 5y ago
  Remix (which uses React as the UI library) is server side rendered
  - tshaddox 5y ago
    True, but it still needs to download a big chunk of JS to have client-side routing.
    - bern4444 5y ago
      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).
      - tshaddox 5y ago
        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.
        bern4444 5y ago
        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.
        tshaddox 5y ago
        > 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.
cyral 5y ago
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.
- tropshop 5y ago
  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.
  - cyral 5y ago
    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.
deleted 5y ago
[deleted]
password4321 5y ago
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 {}.

sergiodxa 5y ago

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.

mattwad 5y ago
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?q=prefetch https://github.com/clintonwoo/hackernews-remix-react/search?...

woah 5y ago

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.

alana99 5y ago

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.

bern4444 5y ago
Remix (which uses React as the UI library) is server side rendered
- tshaddox 5y ago
  True, but it still needs to download a big chunk of JS to have client-side routing.
  - bern4444 5y ago
    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).
    - tshaddox 5y ago
      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.
      - bern4444 5y ago
        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.
        tshaddox 5y ago
        > 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.

cyral 5y ago

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.

tropshop 5y ago
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.
- cyral 5y ago
  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.

deleted 5y ago

[deleted]

password4321 5y ago

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 {}.