Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remix vs. Next.js

remix.run

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Remix vs. Next.js

#11

Post by cockatiel_day »

Remix's approach to fetching is unique and compelling for Rest APIs.

However, if you're working with a GraphQL API, you can eliminate all these much-mentioned fetch waterfall issues by using Relay as a client... Relay inspects the data needs of all your page's components and compiles them to a single page query. Relay also has a number of nice developer interfaces for common/annoying problems like pagination that I don't think are possible w/ Remix's approach.

This article is informative, but I think it misleadingly implies that you can't avoid waterfall fetches in Next (or that it only might be possible someday w/ React Server Components)... you can.

Re: Remix vs. Next.js

#12

Post by dbbk »

jokethrowaway wrote: post #7

Glad to see someone not focused on frontend. Frontends are incredibly bloated already and next.js embedding react in any page is a killer for static websites.

This is a frontend framework? It still uses React on the frontend?

Re: Remix vs. Next.js

#13

Post by danhab99 »

littlecranky67 wrote: post #8

Haven't heard of Remix, will give it a try. One thing that bugs me with Next.js is the missing data mutations part that Remix claims to address. When I setup my next.js project and was fetching data via getServerSideProps I was impressed. Until I realised there is zero support for mutating data. As soon as I need a single POST/PUT request, next.js support ends and you are back to writing your own fetch() code. It som…

I submitted a feature request for a "transporter" function that would do exactly this. Didn't get much traction.

https://github.com/vercel/next.js/discussions/31136

Re: Remix vs. Next.js

#14

Post by steve_adams_86 »

jokethrowaway wrote: post #7

Glad to see someone not focused on frontend. Frontends are incredibly bloated already and next.js embedding react in any page is a killer for static websites.

Next is alpha-testing something which will allow for JS-free static sites, though they're generated using React on the server.

https://nextjs.org/blog/next-12#react-server-components

Note that this is an effort largely driven by the React team, and Vercel is integrating support for the feature into Next. You're able to do this without Next:

https://reactjs.org/blog/2020/12/21/data-fetching-with-react...

It's early still, but I imagine this will be an established and well-supported feature by the end of the year.

Re: Remix vs. Next.js

#15

Post by steve_adams_86 »

DangitBobby wrote: post #6
steve_adams_86 wrote: post #5

Earlier quoted context omitted.

I agree. Part of what my team likes about next is that although it doesn’t get everything perfect, it’s generally close enough and otherwise often within the realm of customization when it counts. The only exception might be the router. I’ve found it a little limited at times and there’s no way around it. This is one of remix’s apparent strengths, but it’s insanely comprehensive. I wonder if it might be too much in t…

I spent a weekend playing around with Remix, and it didn't fail to deliver. I don't think you have anything to worry about.

Thanks for this comment. It pushed me to take a closer look, and so far I'm really impressed. I'll definitely give this more of a chance. The Remix team has a solid grasp on the request waterfall and how to reliably optimize page loads. I have no doubt that Vercel will optimize this in Next as well, but as long as their router is so limited I don't see how they can compete on optimizing dynamic content. It'll be interested to see how it shakes out!

Re: Remix vs. Next.js

#16

Post by omgsean »

cockatiel_day wrote: post #11

Remix's approach to fetching is unique and compelling for Rest APIs. However, if you're working with a GraphQL API, you can eliminate all these much-mentioned fetch waterfall issues by using Relay as a client... Relay inspects the data needs of all your page's components and compiles them to a single page query. Relay also has a number of nice developer interfaces for common/annoying problems like pagination that I d…

GraphQL comes with its own set of headaches though, especially if you're the person responsible for implementing the server.

Re: Remix vs. Next.js

#17

Post by pier25 »

omgsean wrote: post #16
cockatiel_day wrote: post #11

Remix's approach to fetching is unique and compelling for Rest APIs. However, if you're working with a GraphQL API, you can eliminate all these much-mentioned fetch waterfall issues by using Relay as a client... Relay inspects the data needs of all your page's components and compiles them to a single page query. Relay also has a number of nice developer interfaces for common/annoying problems like pagination that I d…

GraphQL comes with its own set of headaches though, especially if you're the person responsible for implementing the server.

Exactly.

Plus, if you're using something like Remix, you don't need an API layer anymore. The data goes from the query straight into the view.

Post reply on HN