3 ms·

For our new project, we decided to try Next.js for the first time and the entire experience has been hell. - Fighting hydration mismatch errors has been extrem

For our new project, we decided to try Next.js for the first time and the entire experience has been hell. - Fighting hydration mismatch errors has been extremely annoying - (related to hydration errors) react server component is a misnomer - "use client" still does a server side render - Compile time is around 10s+ for dev mode because if you happen to import from modules that have tons of exports, it will compile the entire thing even if you're not using them - next-auth has nonsensical APIs (eg the jwt and session callbacks); if you want to do federated sign out, it's also a hacked solution you have to come up with on your own - app router middleware is difficult to extend. want to have multiple pieces of middleware like express? you'll have to hack your own solution since they only support a single piece of middleware - caching problems. next 14 cached nearly everything, and 15 now disables some of it by default to help with the issues around stale data being rendered - no way to specify that next.js runs in node.js mode and not edge mode. have to use annoying comparisons to run node.js specific code developing a modern JS app shouldn't be this difficult and annoying that I totally regret using it

FleetAdmiralJa 2y ago
1. The Next.js team acknowledged that the hydration errors are hard to debug and in the Next.js 15 RC they improved on that (the only reason why Next 15 isn't out is that React 19 hasn't released yet because they want to polish things with Suspense up) 2. If you had read the docs, you would have seen that “use client” still does SSR (as it worked in the Next versions before (nothing has changed)). If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import (as it worked before in the pages router). 3. Next.js still uses Webpack because they bet on Turbopack and to be fair the release of Turbopack is a bit slow. But with it, we get a massive speed boost. Already, 100% of the tests for dev mode are passing, so you really should try it out. 4. next-auth is an entirely different thing from next. next is not responsible for the next-auth APIs 5. AFAIK, everything runs in node except the middleware if you don't specify the export runtime = "edge";
- orf 2y ago
  > If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import Of course! Duh! The concepts of “server side rendering” and “dynamic imports” are very naturally, obviously and intrinsically linked. Using “use client” is obviously totally stupid when you want to render on the client!

FleetAdmiralJa 2y ago

1. The Next.js team acknowledged that the hydration errors are hard to debug and in the Next.js 15 RC they improved on that (the only reason why Next 15 isn't out is that React 19 hasn't released yet because they want to polish things with Suspense up) 2. If you had read the docs, you would have seen that “use client” still does SSR (as it worked in the Next versions before (nothing has changed)). If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import (as it worked before in the pages router). 3. Next.js still uses Webpack because they bet on Turbopack and to be fair the release of Turbopack is a bit slow. But with it, we get a massive speed boost. Already, 100% of the tests for dev mode are passing, so you really should try it out. 4. next-auth is an entirely different thing from next. next is not responsible for the next-auth APIs 5. AFAIK, everything runs in node except the middleware if you don't specify the export runtime = "edge";

orf 2y ago
> If you want to turn off SSR, you can look at the docs and see that you can do it with the dynamic import Of course! Duh! The concepts of “server side rendering” and “dynamic imports” are very naturally, obviously and intrinsically linked. Using “use client” is obviously totally stupid when you want to render on the client!