Sunday, October 29, 2023

Why I Wont Use Next#epicweb.dev

When Kent Dodds has something spicy to say about the web people usually listen.

This was an especially spicy topic (why Next.js is not for him) but he has an unsurprising opinion given his course content.

Some quotes:

Where Next.js has utilities to allow you to interact with the request, headers, cookies, etc, Remix exposes those APIs directly to you through its loaders and actions. In Remix, these functions accept a Request and return a Response. If you need to understand how to return JSON with some set headers, you go to MDN (the de facto standard web platform documentation) rather than the Remix docs. There are many such examples. As you get better at Remix, you get better at the web and vice versa.

Hard agree with this. Next.js has great docs but standard web APIs / MDN will always be better. This was a great feature of building a basic web app with deno. When it's standard request and response objects there's always good info on how these things work.

From the beginning, Remix was built to deploy anywhere you can run JavaScript. This is helped in large part by the emphasis on standards. I definitely appreciate this aspect of Remix.

Hard yes to this too. If I can easily deploy it to a container and on something like AWS Lightsail then I'm sold.

I would feel more comfortable if React belonged to an open foundation. But short of that, it would be nice at least if they were more collaborative than they’ve been since joining Vercel.

React should be an open standard. It's that big now that this is what it deserves. Of course Vercel don't want this for commercial reasons.

Most of us learned from the MooTools days that overriding built-in features of the platform leads to problems (it’s the reason we have String.prototype.includes instead of String.prototype.contains). Doing this has negative impacts on the future of the web platform, and it also means that when you go to debug why something isn’t working you have to sift through the resources available to find the "Next.js version of fetch” vs “the web platform version of fetch."

The Next.js version of fetch has very confusing rules with caching. I don't like it.

That kind of stability has a major impact on me and the apps I build. There are some libraries that I’m always terrified to upgrade because I’ve had a history of hours of confusion as I try to update all of my code to adapt to the new version. For something as impactful as a web framework, I would prefer to not have that feeling. Remix has been a gift in this regard.

Upgrading to Next 13 at Mr Yum feels like it would be hard to do. It shouldn't be hard.

I also wouldn't use Next for my own projects.