Show HN: Hacker News clone using Remix and React (github.com)
This project was a pleasure to do, Remix has very good developer experience. But further than that it's actually a really good way to develop applications, it's a mix of old meets new where the paradigm encourages you to take advantage of web standards for data fetching (forms, links, a tags).
And it turns out that it's actually an optimal way to develop simple or even complex web applications which can deploy in a number of runtime environments (including edge workers). So you can get an insanely fast website for users. Note that this project is not necessarily an optimal website implementation (since it copies Hacker News) but rather it's intended to be useful as a starting point or reference for your own projects!
You can read about some of the benefits of it on the project page linked.
By the way I'm currently available to work (if you email me at clinton.dannolfo @gmail!)
50 comments
[ 2.8 ms ] story [ 127 ms ] thread> Most apps can be built leveraging web fundamentals (form/anchor tag) requiring no state management library
Remix also provides a higher level <Form> React component and hook with support for extra states like loading etc!
When you click the browser back button as far as I remember Remix will do what the browsers do and show the previous data, but if you click a button in the UI to navigate to the previous page it will fetch the new data.
Re global state, in my experience with Remix and before it with tools like React Query, once you move the server state (data fetched from an API or queried from a DB) outside tools like Redux, then what you have left is mostly UI state (input values, open/close states, etc.) and you don't need Redux for that.
And if your app is more complex (like a canvas-like app for example) you can either use a state + context in a parent component or you can use Redux or any other state management library, Remix once JS load will not cause a full page navigation so if you initialize a global state in something like Remix it will keep working across page navigations, even if you click back it will keep the state because Remix uses RR to navigate so it's pure client-side navigation.
In this news site example the "previous data" was fetched with infinite scroll, and it was lost from memory when the user navigated to the new page. So when the user clicks back in their browser, the browser is unable to show the previous data, because it does not have the previous data in memory any more.
> Re global state, in my experience with Remix and before it with tools like React Query, once you move the server state (data fetched from an API or queried from a DB) outside tools like Redux, then what you have left is mostly UI state (input values, open/close states, etc.) and you don't need Redux for that.
> And if your app is more complex (like a canvas-like app for example) you can either use a state + context in a parent component or you can use Redux or any other state management library, Remix once JS load will not cause a full page navigation so if you initialize a global state in something like Remix it will keep working across page navigations, even if you click back it will keep the state because Remix uses RR to navigate so it's pure client-side navigation.
All this sounds like typical state management in any React app: keep local UI state in React components (no need need for a state management library) and use a state management library to maintain global state.
Your README gave the impression that Remix leverages web fundamentals in a way that removes/reduces the need for a state management library, but based on this discussion it sounds like that is not the case. Thanks for your answers and sorry about hijacking this thread for this.
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 doing and I think you're being a bit unfair. 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.
For those cases where you really do need to do client side data fetching you are free to do so.
But do these use cases require a state management library in the first place? Can you provide an example where using React Component state is not sufficient - a state management library is needed - and then Remix removes this need?
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:
`<Link to="?page=2" state={{ data }} />`
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!
This sounds great! I never thought of using history state to store arbitrary data. Thanks for the explanation!
And other videos on their youtube channel discussing their framework: https://www.youtube.com/c/Remix-Run/videos
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 which parts can be rendered later as HTML and data is streaming from the server. Before this, all of React server frameworks would render the entire page, shove "hydration data" in it which is mostly repeated data that is used to render the page and also include that HTML in the form of complied JSX in the page in the page scripts. Obviously that would make React SSR very bulky and unscalable. That's why RSC can solve so many React performance problems
[1] https://github.com/vercel/next-react-server-components
If React Server Components can improve things for Remix (they can't right now, but maybe they will get better?) and if it is ever released (it's been 5 years now... and they still are saying they've got a long way to go), then Remix will ship support for them and it will be a non-breaking change for Remix users.
For example, where are the styles for the skeleton ? Why inserting CSS with "dangerouslySetInnerHTML" in the index.js ? Maybe its easy and I am missing some obvious stuff but the code doesnt seem very readable to me. Maybe is due to the nature of Server Components in Nextjs ? Would be nice to hear someone else's opinion on the patterns used in this repo.
OPs code on the other hand is a piece of cake to understand. Really good job!
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.
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?
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.
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.
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.
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.
https://news.ycombinator.com/from?site=github.com/clintonwoo
Might be fun to compare
It's not necessarily an apples to apples comparison of web servers though, since the NextJS one is also using GraphQL which adds extra response time. The remix one is also running on fly.io instead of a regular VPS in middle america just to cope with extra HN traffic.
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...
Random yearly payments to keep tiny side project vanity URLs doesn't measure high on the life partner acceptance factor scale.
[0] https://hackerxp.com/
Very great work! I love destroying the notion that you have to use some esoteric hyper-optimized tech to get quality performance.
I don't know the stats, but I could imagine that HN is used by quite some mobile users, so an UX update would be appreciated.
Side note: seems like there is some sort of issue when swiping back on iOS Safari. Periodically getting flashes of the incorrect content.