Live data from Hacker News

Show HN: Hacker News clone using Remix and React

github.com

41–50 of 51 posts

Re: Show HN: Hacker News clone using Remix and React

#41

Earlier quoted context omitted.

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.

Re: Show HN: Hacker News clone using Remix and React

#42

Earlier quoted context omitted.

To answer this question - There is nothing stopping you from fetching on the client still while using remix or from for example wrapping your app with a provider where you can store cached client side data. Page transitions happen on the client when you have JS enabled so that data will still be in memory if done as such. But I do want to mention that the specific use case you mention is not what 80%+ of apps are doi…

> Remix ABSOLUTELY does get rid of most needs for a client side state management solution. Most apps are fetching data and displaying it primarily on page load/route transitions. Or for instance on query param change for paginated data. This is the use case Remix targets, and it does a fantastic job of simplifying the code for this and making it much faster. But do these use cases require a state management library i…

Remix co-author here. Infinite scroll/pagination is a great way to test the limits of a web framework!

Remix doesn't ship an infinite scroll/pagination set of components so it's up to apps to make sure that state is still there when the user clicks back. If the state is still there, Remix's scroll restoration will work.

You could either manage your own global state for this, but I like to use "location state" which is our API into the browser's built in `history.state`.

There are various ways to use it (declaratively, imperatively, etc.), but simplest way to explain is to imagine a "Load more" button that's really just a link like this:

``

Your Remix loader would load page 2 from the url search param and your component would concat that onto `location.state.data` (the previous entries from the initial location). This renders the old data and the new data together.

Location state, unlike typical "global state", automatically persists across both refreshes and back/forward button clicks, but dies with the session, so scroll restoration will work as expected even for a refresh! Built in browser APIs tend to be a bit more resilient than storing stuff in application memory, they also keep your bundle smaller.

I don't know where the demo is, but I helped somebody at some point implement this without needing to ship a global state container for server-supplied data. Just made a note to make an example and put it our repo :)

If we're talking "load more" a much simpler way to do it is to consider how you'd do it old school with no JS. Just return all pages according to the search param, so "?page=3" would return all three pages. More kB over the network, but far easier to implement. There's even a product reason to do it this way: when you load more you automatically update the comment counts/points of each entry, so maybe it's worth it.

Great question!

Re: Show HN: Hacker News clone using Remix and React

#43
post #28

Earlier quoted context omitted.

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…

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…

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.

Re: Show HN: Hacker News clone using Remix and React

#44

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?

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

Re: Show HN: Hacker News clone using Remix and React

#45

Earlier quoted context omitted.

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

Re: Show HN: Hacker News clone using Remix and React

#46
post #19

The author of this actually has a bunch of different HN clones with different JS tech: https://news.ycombinator.com/from?site=github.com/clintonwoo Might be fun to compare

Here's one built with Svelte: https://hn.svelte.dev/ It's not exactly an apples-to-apples comparison for a number of reasons including implementation and hosting differences, but might be interesting to people anyway. The code lives here: https://github.com/sveltejs/sites/tree/master/sites/hn.svelt...

I'm always interested to see which ones are running after a few months, or a year later when the time comes to pay to renew the domain.

Random yearly payments to keep tiny side project vanity URLs doesn't measure high on the life partner acceptance factor scale.

Re: Show HN: Hacker News clone using Remix and React

#47

Earlier quoted context omitted.

> Remix ABSOLUTELY does get rid of most needs for a client side state management solution. Most apps are fetching data and displaying it primarily on page load/route transitions. Or for instance on query param change for paginated data. This is the use case Remix targets, and it does a fantastic job of simplifying the code for this and making it much faster. But do these use cases require a state management library i…

Remix co-author here. Infinite scroll/pagination is a great way to test the limits of a web framework! Remix doesn't ship an infinite scroll/pagination set of components so it's up to apps to make sure that state is still there when the user clicks back. If the state is still there, Remix's scroll restoration will work. You could either manage your own global state for this, but I like to use "location state" which i…

> I like to use "location state" which is our API into the browser's built in `history.state` ... Location state, unlike typical "global state", automatically persists across both refreshes and back/forward button clicks, but dies with the session, so scroll restoration will work as expected even for a refresh! Built in browser APIs tend to be a bit more resilient than storing stuff in application memory, they also keep your bundle smaller.

This sounds great! I never thought of using history state to store arbitrary data. Thanks for the explanation!

Re: Show HN: Hacker News clone using Remix and React

#48
post #19

The author of this actually has a bunch of different HN clones with different JS tech: https://news.ycombinator.com/from?site=github.com/clintonwoo Might be fun to compare

I'll put in my request for https://nestjs.com/, "an application architecture out of the box".

Re: Show HN: Hacker News clone using Remix and React

#50
post #5

For comparison this[1] is Next.js implementation that uses React Server Components (RSC). I feel folks at Remix missed on React Server Components and now it will be a lot of work to make it work in Remix. Hopefully I'm wrong. If you don't know, RSC allows the HTML from server to start streaming as React is rendering the components in the backend. It allows fine grain control to what part of page renders first and whi…

Remix co-author here. We haven't "missed on RSC", they aren't even released!

We already have experimental versions of Remix running on React 18 and have experimented with RSC, Suspense, and streaming extensively. In their current state however, we're not seeing them beat Remix's current approach in production results or developer ergonomics. We've been providing the React team with our feedback. When these features from React are ready, Remix will be able to easily support them.

Post reply on HN