3 ms·

The single reason I switched from next.js was because it was taking me 6-7 seconds on a small project to see changes I made appear in the browser during develop

by vmg12 2y ago

The single reason I switched from next.js was because it was taking me 6-7 seconds on a small project to see changes I made appear in the browser during development (on an M1 Max Macbook pro with 64gb of ram). This is when using the app router, where every change requires a compilation step. I now just use a React SPA with Vite.

dirtbag__dad 2y ago
Yeah, this is shocking to me. I’m a backend developer who occasionally tinkers with frontend. I gave nextjs a spin and couldn’t believe the reload times on a new project. For folks who use this every day, how/why is this acceptable?
- wirybeige 2y ago
  It's acceptable for me because I (and others on my team) do not have to way 6-7 seconds almost ever, it is nearly instant. On odd occasion changes can take a long time to show up, ~5 seconds, but it seems restarting the server fixes it, so not sure what that is about.
  - akvadrako 2y ago
    Do you use it on vercel, maybe? I had the same experience of slow refreshes on the NextJS project I worked on (running locally) and the other seasoned NextJS developers didn't think it was unusual.
    - wirybeige 2y ago
      We do not use vercel. Unfortunate that the experience varies so much.
- 9rx 2y ago
  > For folks who use this every day, how/why is this acceptable? While I thankfully don't have to use Nextjs often, in general I am not sure I even launch my app in the browser every single day. Your tests and whatnot are already providing continuous feedback about the state of the code. 6-7 seconds every once in a while wouldn't be the end of the world. But even it were instantaneous, Nextjs has a horrible developer experience for a multitude of other reasons.
sama004 2y ago
what do you use for routing?
- vmg12 2y ago
  Tanstack router
nonethewiser 2y ago
>I now just use a React SPA with Vite. To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog. 6-7s for HMR is terrible though. Agreed.
- vmg12 2y ago
  I would have actually liked to have SSR in some cases but yes it was not critical for my app to have it. I just think Next.js (and react) jumped the shark so to speak with prioritizing SSR over client side rendering. What most web-apps need is just a very basic SSR step for the shell of the app, not everything needs to be server side rendered, in the cases where that is required we've had other SSR first frameworks that already solve that problem.
- hombre_fatal 2y ago
  Next.js' main offering is that you basically get SPA architecture but with a single browser<->server round trip on first load instead of two round trips. That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem. But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.
  - deleted 2y ago
    [deleted]
  - 9rx 2y ago
    > That's where ~all of Next.js' complexity comes from Complexity does arise there, but equally arises from limitations imposed by the Vercel service that Next.js ultimately needs to deal with. A lot of its seemingly dumb design decisions make sense once you consider the constraints Vercel (the service) forces upon it, but they are still poor decisions you have to live with that wouldn't have been necessary if it were intended to run in a "normal" computing environment.

by vmg12 2y ago

dirtbag__dad 2y ago

Yeah, this is shocking to me. I’m a backend developer who occasionally tinkers with frontend. I gave nextjs a spin and couldn’t believe the reload times on a new project. For folks who use this every day, how/why is this acceptable?

wirybeige 2y ago
It's acceptable for me because I (and others on my team) do not have to way 6-7 seconds almost ever, it is nearly instant. On odd occasion changes can take a long time to show up, ~5 seconds, but it seems restarting the server fixes it, so not sure what that is about.
- akvadrako 2y ago
  Do you use it on vercel, maybe? I had the same experience of slow refreshes on the NextJS project I worked on (running locally) and the other seasoned NextJS developers didn't think it was unusual.
  - wirybeige 2y ago
    We do not use vercel. Unfortunate that the experience varies so much.
9rx 2y ago
> For folks who use this every day, how/why is this acceptable? While I thankfully don't have to use Nextjs often, in general I am not sure I even launch my app in the browser every single day. Your tests and whatnot are already providing continuous feedback about the state of the code. 6-7 seconds every once in a while wouldn't be the end of the world. But even it were instantaneous, Nextjs has a horrible developer experience for a multitude of other reasons.

sama004 2y ago

what do you use for routing?

vmg12 2y ago
Tanstack router

nonethewiser 2y ago

>I now just use a React SPA with Vite. To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog. 6-7s for HMR is terrible though. Agreed.

vmg12 2y ago
I would have actually liked to have SSR in some cases but yes it was not critical for my app to have it. I just think Next.js (and react) jumped the shark so to speak with prioritizing SSR over client side rendering. What most web-apps need is just a very basic SSR step for the shell of the app, not everything needs to be server side rendered, in the cases where that is required we've had other SSR first frameworks that already solve that problem.
hombre_fatal 2y ago
Next.js' main offering is that you basically get SPA architecture but with a single browser<->server round trip on first load instead of two round trips. That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem. But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.
- deleted 2y ago
  [deleted]
- 9rx 2y ago
  > That's where ~all of Next.js' complexity comes from Complexity does arise there, but equally arises from limitations imposed by the Vercel service that Next.js ultimately needs to deal with. A lot of its seemingly dumb design decisions make sense once you consider the constraints Vercel (the service) forces upon it, but they are still poor decisions you have to live with that wouldn't have been necessary if it were intended to run in a "normal" computing environment.