5 ms·

I have ranted countless times in Next.js issues, and most of them have not been resolved even after 2 to 3 years. Here, I'll just list some of them in case anyo

I have ranted countless times in Next.js issues, and most of them have not been resolved even after 2 to 3 years. Here, I'll just list some of them in case anyone is interested. - layout cannot access pathname of the current URL: https://github.com/vercel/next.js/issues/43704#issuecomment-1920413060 https://github.com/vercel/next.js/issues/43704#issuecomment-... - App Router cannot pass data to layout: https://github.com/vercel/next.js/discussions/44506 https://github.com/vercel/next.js/discussions/44506 - router.push does not revalidate server cache: https://github.com/vercel/next.js/discussions/54075#discussioncomment-8337419 https://github.com/vercel/next.js/discussions/54075#discussi... - stylesheet order is not guaranteed and persist accross environments: https://github.com/vercel/next.js/issues/16630 https://github.com/vercel/next.js/issues/16630 - script tag with strategy=beforeInteractive does not work in root layout: https://github.com/vercel/next.js/issues/51242 https://github.com/vercel/next.js/issues/51242 Some other thoughts: One thing Next.js likes to do is provide a lengthy and well-formatted post explaining their philosophy and reasons why a particular issue cannot be resolved. It appears convincing at first glance, but if you take a closer look, you'll find that they are just elaborations using their own terms and logic. In other words, they explain the efforts they make to justify their decisions, which stem from poor design choices they made. They like doing things look correct but not necessarily useful, similar to the feelings I have when dealing with accountants.

leerob 2y ago
- Layouts answer: https://github.com/vercel/next.js/issues/43704#issuecomment-2090798307 https://github.com/vercel/next.js/issues/43704#issuecomment-... - Pass data to layout answer: https://github.com/vercel/next.js/discussions/44506#discussioncomment-10910613 https://github.com/vercel/next.js/discussions/44506#discussi... - For router.push one, I believe you're looking for this: https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes https://nextjs.org/docs/app/api-reference/next-config-js/sta... - Stylesheet ordering: https://github.com/vercel/next.js/pull/63157 https://github.com/vercel/next.js/pull/63157 - Script tag: https://github.com/vercel/next.js/issues/51242#issuecomment-2003550390 https://github.com/vercel/next.js/issues/51242#issuecomment-...
- eddd-ddde 2y ago
  Regarding layout, there is NO REASON you need to use a request response model. That's just bad design. Other frameworks manage completely fine to expose location data without implying dynamic rendering.
- hijodelsol 2y ago
  I truly feel like the focus on PPR, streaming, etc. is forcing most developers to jump through unnecessary hoops and relearn the basics of Next.js every couple of months. Imo, the interceptors idea is just more evidence for that. On the surface, Next.js may try to keep all parts independent and allow PPR, streaming, static and dynamic living right next to each other, etc. but at what cost? Losing the request and the response object makes life unnecessarily harder. Artificially limiting certain pages to run in an "edge environment" is non-sensical when hosting Next.js on Node.js in the same data center as your database. And personally, I do not trust Next.js anymore with new "special" files and features. head.tsx was deprecated before our migration was even complete. Route interception with parallel routes is deeply broken to this day with hundreds of non-obvious caveats of how they can be used. Server actions are an anti-pattern, since they tie all manipulations to Next.js and make it impossible to use your data manipulation endpoints across multiple applications. Meanwhile, using REST-APIs with Next.js is incredibly challenging thanks to the client side cache and is not fully solved by router.refresh, tag invalidation or stale time. I believe that there are many like me who would just want to use a simple server-side rendering solution with the route-based layout structure of the app directory, which was a great improvement. Please just allow users to render everything at once and synchroneously in Next.js, expose the request and response at every point and allow database access from any point. I would be very happy to trade 2ms of time and lose PPR, etc. if that meant that I could build features for my customers faster. The introduction of the app directory had me exited and I moved the first project on the day it was announced, but recently I find myself fighting the framework rather than it supporting what I need to do. Another example of Next.js completely breaking existing code seemingly for no reason was suddenly disallowing exporting functions from page.tsx files. It worked before, so there should not be any inherent reason that it could not work anymore. Now, if I want to reuse a getData method in two pages or a page and a layout, I have to create an additional getData.ts file. Is this was the Next.js team wants users to do? Perhaps. Should they force them to do this? Absolutely not, we are all adults and requiring millions of devs to refactor their code because something could not be figured out internally or they suddenly deemed some usage unacceptable is ridiculous and user hostile.

leerob 2y ago

- Layouts answer: https://github.com/vercel/next.js/issues/43704#issuecomment-2090798307 https://github.com/vercel/next.js/issues/43704#issuecomment-... - Pass data to layout answer: https://github.com/vercel/next.js/discussions/44506#discussioncomment-10910613 https://github.com/vercel/next.js/discussions/44506#discussi... - For router.push one, I believe you're looking for this: https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes https://nextjs.org/docs/app/api-reference/next-config-js/sta... - Stylesheet ordering: https://github.com/vercel/next.js/pull/63157 https://github.com/vercel/next.js/pull/63157 - Script tag: https://github.com/vercel/next.js/issues/51242#issuecomment-2003550390 https://github.com/vercel/next.js/issues/51242#issuecomment-...

eddd-ddde 2y ago
Regarding layout, there is NO REASON you need to use a request response model. That's just bad design. Other frameworks manage completely fine to expose location data without implying dynamic rendering.
hijodelsol 2y ago
I truly feel like the focus on PPR, streaming, etc. is forcing most developers to jump through unnecessary hoops and relearn the basics of Next.js every couple of months. Imo, the interceptors idea is just more evidence for that. On the surface, Next.js may try to keep all parts independent and allow PPR, streaming, static and dynamic living right next to each other, etc. but at what cost? Losing the request and the response object makes life unnecessarily harder. Artificially limiting certain pages to run in an "edge environment" is non-sensical when hosting Next.js on Node.js in the same data center as your database. And personally, I do not trust Next.js anymore with new "special" files and features. head.tsx was deprecated before our migration was even complete. Route interception with parallel routes is deeply broken to this day with hundreds of non-obvious caveats of how they can be used. Server actions are an anti-pattern, since they tie all manipulations to Next.js and make it impossible to use your data manipulation endpoints across multiple applications. Meanwhile, using REST-APIs with Next.js is incredibly challenging thanks to the client side cache and is not fully solved by router.refresh, tag invalidation or stale time. I believe that there are many like me who would just want to use a simple server-side rendering solution with the route-based layout structure of the app directory, which was a great improvement. Please just allow users to render everything at once and synchroneously in Next.js, expose the request and response at every point and allow database access from any point. I would be very happy to trade 2ms of time and lose PPR, etc. if that meant that I could build features for my customers faster. The introduction of the app directory had me exited and I moved the first project on the day it was announced, but recently I find myself fighting the framework rather than it supporting what I need to do. Another example of Next.js completely breaking existing code seemingly for no reason was suddenly disallowing exporting functions from page.tsx files. It worked before, so there should not be any inherent reason that it could not work anymore. Now, if I want to reuse a getData method in two pages or a page and a layout, I have to create an additional getData.ts file. Is this was the Next.js team wants users to do? Perhaps. Should they force them to do this? Absolutely not, we are all adults and requiring millions of devs to refactor their code because something could not be figured out internally or they suddenly deemed some usage unacceptable is ridiculous and user hostile.