What is a good alternative, if I want to stick to React. Does any other framework support server/client hybrid rendering.
I really like ReactRouter v7 (it was previously Remix).
You should know this before choosing Next.js
61–70 of 147 posts
Re: You should know this before choosing Next.js
#62The 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.
>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.
Re: You should know this before choosing Next.js
#63I was under the impression that Next.js was the successor to React? Is that not the case?
Don’t know why you are gray as when I was researching my front end platform choice “the universe” certainly seemed to frame it that way. It was framed as you were seemingly either using next.js or writing some kind of “legacy app” in boring old react. Which turns out isn’t true.
I didn’t need SSR and my research suggested that next.js might be overkill so I landed on react + vite. So far so good.
Re: You should know this before choosing Next.js
#64Well shoot. I just started a new Next.js project least week. What's everybody's go to alternative?
Nuxt
Re: You should know this before choosing Next.js
#65I warn everyone away from next.js. Unsurprisingly V0 has a real shot at massively increasing its adoption because people don’t know any better. What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cos…
As mentioned on another reply, it is favoured by many SaaS vendors as the only extension framework for their products.
Using something else, means not having support, and spending time yak shaving instead of coding the real solution.
From Java/.NET ecosystem point of view, Next.js is the framework where I feel at home.
I work with agencies that have partner agreements with Vercel/Netlify, which makes it a good option for SaaS products that are in the MACH architecture space.
Re: You should know this before choosing Next.js
#66I’m mixed about Next.js. On one hand, it’s a company building a framework with investors, of course there are incentives for them to corner the market. Like the author mentions, Redis labs has a similar model. The license is MIT, so Netfify or anyone can fork and offer a better alternative, if they’re capable and willing to take on the risk of it flopping. Also, if I’m an investor in Vercel — why would I encourage them to put my investment at risk by aiding competition?
On the other hand, there does seem to be a sleight of hand with Vercel. They want it both ways — to be a company that champions and fosters open source while also keeping the necessary friction in place to make their hosting platform the best choice.
For better or worse, I think we’ll only see more of this model in the future.
Re: You should know this before choosing Next.js
#67I warn everyone away from next.js. Unsurprisingly V0 has a real shot at massively increasing its adoption because people don’t know any better. What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cos…
>What are some salient counter points for choosing next.js? ... If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one.
For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple.
And for any developer I'd really recommend implementing SSR yourself with an express server or whatever. It really increases your understanding of how frameworks work.
Re: You should know this before choosing Next.js
#68The 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.
>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.
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.
Re: You should know this before choosing Next.js
#69To add to this, in the last couple of releases Next.js got worse for static build exports (everything is compiled and exported to static html+js+assets and put into out/) - it seems it is not a priority anymore.
Their built-in image exporter (next/image) never had support for static export whatsoever (in contrast to gatsby). When I brought that up on HackerNews some time back, an employee of Vercel tried to argue against that and dial that down without disclosing he is actually an employee of Vercel [0].
Overall, sketchy company with sketchy business practices.
Re: You should know this before choosing Next.js
#70Well shoot. I just started a new Next.js project least week. What's everybody's go to alternative?
Just use React and any backend?
If you have time for the project, you have time to learn a proper setup that every company for the past 15+ years has used.
SSR is quite frankly a performance myth if you distribute your frontend on a CDN. Ultimately your cloud functions reach out to your database, that is centrally located... SEO work well without SSR for the most part.