4 ms·

> that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). You only need one (or none). I personally recommend Next.js for jus

> that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). You only need one (or none). I personally recommend Next.js for just about anything.

onion2k 4y ago
Next is lovely to work with but it has a flaw. It loses client state between pages if you use getServerSideProps. For any app that needs to load some up to date data on every page if the user is hitting it for the first time, but doesn't need to load it if the client already has it, Next doesn't have a solution. You end up using a persist gateway pattern which is a massive amount of work that you shouldn't really need the client to do. The problem is that that's pretty much every web app. Every time I've used Next I've end up abandoning SSR and building a plain clientside rendered app.
- srigi 4y ago
  Can you elaborate a little more, or navigate to some GH issue, where this is discussed, please?
- cercatrova 4y ago
  Also, next/image only works with a CDN, ie Vercel, it doesn't work with static site generation. It's been an open issue for years and I honestly now feel like Vercel doesn't fix the problem on purpose, to push more people to using their service rather than simply exporting to a static host which are plentiful.
  - solardev 4y ago
    You can set next/image to work with Cloudinary or Imgix or a custom provider. It gets the job done that way, but yeah, the experience isn't as smooth as with Vercel. Same with incremental static regeneration and some other features... Next is obviously built not just by, but also for, Vercel. Vendor lock-in already is a small issue and may become a bigger one if they keep going down that route.
  - deckard1 4y ago
    been saying it for awhile... Next.js is an ad for their services. Take a look at their middleware. It's designed to be used solely with their serverless cloud BS. It uses a janky JS sandbox which means you can't use node APIs. It's just horrible for no good reason at all. I've never seen middleware so intentionally crippled anywhere before. And the whole reason you need middleware is to maneuver around the flaws that the prior person mentioned with getServerSideProps. Next.js probably seems great if you're writing greenfield code in a dead simple web app. Routing/URL handling on Next.js is just broken. This is all glaringly obvious if you've been around the SPA/SSR world for more than a day.
    - moneywoes 4y ago
      What is the alternative for SSR?
    - zwily 4y ago
      AFAIK, Vercel middlewares use Cloudflare Workers, which are V8 isolates. Describing that as a “janky JS sandbox” is pretty funny.
- chrisco255 4y ago
  They're working on that with Server Components: https://nextjs.org/blog/layouts-rfc?utm_source=next-site&utm_medium=banner&utm_campaign=next-website https://nextjs.org/blog/layouts-rfc?utm_source=next-site&utm...
Hedepig 4y ago
Choosing the tool that fits best with the requirements saves a bunch of time during a project lifecycle.

> that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). You only need one (or none). I personally recommend Next.js for just about anything.

onion2k 4y ago

Next is lovely to work with but it has a flaw. It loses client state between pages if you use getServerSideProps. For any app that needs to load some up to date data on every page if the user is hitting it for the first time, but doesn't need to load it if the client already has it, Next doesn't have a solution. You end up using a persist gateway pattern which is a massive amount of work that you shouldn't really need the client to do. The problem is that that's pretty much every web app. Every time I've used Next I've end up abandoning SSR and building a plain clientside rendered app.

srigi 4y ago
Can you elaborate a little more, or navigate to some GH issue, where this is discussed, please?
cercatrova 4y ago
Also, next/image only works with a CDN, ie Vercel, it doesn't work with static site generation. It's been an open issue for years and I honestly now feel like Vercel doesn't fix the problem on purpose, to push more people to using their service rather than simply exporting to a static host which are plentiful.
- solardev 4y ago
  You can set next/image to work with Cloudinary or Imgix or a custom provider. It gets the job done that way, but yeah, the experience isn't as smooth as with Vercel. Same with incremental static regeneration and some other features... Next is obviously built not just by, but also for, Vercel. Vendor lock-in already is a small issue and may become a bigger one if they keep going down that route.
- deckard1 4y ago
  been saying it for awhile... Next.js is an ad for their services. Take a look at their middleware. It's designed to be used solely with their serverless cloud BS. It uses a janky JS sandbox which means you can't use node APIs. It's just horrible for no good reason at all. I've never seen middleware so intentionally crippled anywhere before. And the whole reason you need middleware is to maneuver around the flaws that the prior person mentioned with getServerSideProps. Next.js probably seems great if you're writing greenfield code in a dead simple web app. Routing/URL handling on Next.js is just broken. This is all glaringly obvious if you've been around the SPA/SSR world for more than a day.
  - moneywoes 4y ago
    What is the alternative for SSR?
  - zwily 4y ago
    AFAIK, Vercel middlewares use Cloudflare Workers, which are V8 isolates. Describing that as a “janky JS sandbox” is pretty funny.
chrisco255 4y ago
They're working on that with Server Components: https://nextjs.org/blog/layouts-rfc?utm_source=next-site&utm_medium=banner&utm_campaign=next-website https://nextjs.org/blog/layouts-rfc?utm_source=next-site&utm...

Hedepig 4y ago

Choosing the tool that fits best with the requirements saves a bunch of time during a project lifecycle.