Hacker News Reader

Comment by aniforprez | Hacker News Reader

Remix is a wonderful, sane framework that I highly recommend for React developers. No monkey patching, no global context imports, no undocumented functionality etc etc. Had a hell of a time trying to wrangle Next and it was terrible. Next still doesn't have a way to completely disable prefetches on hovering over Next links unless you use a plain anchor tag which is the kind of insidious, undocumented behaviour that makes for weird bugs (setting prefetch to false does not disable prefetch on hovers). Remix just sends you browser and node objects like a standard request object in all the arguments and just uses the platform with the framework extensions acting as a nice layer on top

View on HN

Very interesting. Another Next victim here. One of my anecdotes is the bonkers caching / fetch deduplication. Yes, set cache: no-store. But that only works for fetch requests. If you have a 3rd party lib doing the fetching (say, Google Firestore), then you have to declare export const dynamic = 'force-dynamic' at the top of your route segment: https://nextjs.org/docs/app/api-reference/file-conventions/r...

That behaviour wasn't documented when I got started with NextJS 13...imagine the fun I had trying to work out why I can't get updated data from the server. It was nuts.

Honestly this whole RSC/app router endeavour just seems like a mistake. So many strange buggy and undebuggable behaviours. To what end? We have a basic SSR React app and it serves millions of users while cached by Cloudflare. Works perfectly.

KISS.

Yep and it split the ecosystem / documentation / dev efforts / codebase.

Should've been a different product.

It’s a pretty big fuck up actually

You can actually call `unstable_noStore()` from `next/cache` to do that without needing to set it on the segment level[1]! We're working on improving the DX around Dynamic API's to make it a seamless experience.

[1]: https://nextjs.org/docs/app/api-reference/functions/unstable...

Another insidious thing in Next: their middleware is completely sandboxed and you can't use any standard Node functionality. It doesn't matter if you're using vercel now or not, and there's no way to disable this.

This is pretty important for things like sessions with httpOnly cookies. And it forces you make an API call to yourself to resolve.

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

If only this had been brought to their attention recently with a bunch of good-faith discussion.

This is done so that you never use it (even in your own servers) because otherwise you won’t be able to move to their cloud.

This is why you don’t use VC backed dependencies that are not easy to move away from.

Remix has improved substantially since Shopify took over the project. Remix adopting Vite makes it a real choice. Prior to that acquisition, they made some, what I believe to be, bizarre API choices.

now you can simply use the full power of Vite, which means you aren't locked into Remix having to make choices for you.

This is the 3rd time they migrated the underlying tech though, first it was rollup, then esbuild, and now Vite, which is effectively rollup again. I hope they stick with Vite for the foreseeable future though

I like remix and I have big hopes for it, but the devs do have a horrible trajectory of breaking things and leaving everyone behind. But sadly this is so common in the js ecosystem. There’s no stable option.

I placed their Link component within a polymorphic wrapper which could switch between Link and plain anchor elements depending on the props given. The typing was gnarly, but it worked well. By default it would be a Link as I recall, but things like a non-relative href or use=“a” props would swap it for an anchor. And maybe other things, I’m not sure. It would reject Link props if it knew it was using an anchor element, though.

I’m ashamed to say this took way too long to get working nicely. It was worth it because our linting otherwise went crazy over misuse of Link and anchor, and people on the team weren’t respecting it. This made it so we could say “only use Link” and make it easy for that to be accomplished.

Trust me, it’s way easier to get stuff done with Next :)

Once you get past the day or three spent making it so links do what you wish they did… And you discover it handles cache headers differently than it’s supposed to… And middleware doesn’t work in several contexts with no explanation… And on and on.

This is also how I did it—also played nicely with ensuring MuiLink always get used on our MUI site.

I hate the added complexity in later releases of React and Next. There‘s always multiple ways to achieve the same thing with surprising side effects.

Interestingly, I no longer see Next Link prefetching on hover when the prefetch prop is set to false. At some point in Next 13 it was doing that, but in Next 14.1.0 I no longer see it. I’m not sure when or why it stopped.

Reply on news.ycombinator.com