Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not really on topic but

I mean I would usually go with NextJS since it just works so well with Vercel, providing a really convincing, complete solution.

But I will check out Vite nonetheless, curious how it fares against it...



> But I will check out Vite nonetheless, curious how it fares against it...

It is 100x better. :)


IMO Vite isn't better or worse, it just has a different use case. Next has more bolts included (like robust SSR + fetching/caching strategies, routing, middleware, etc.)

If you're just building a SPA, using Next is overkill (and will often get in the way, actually). But for some other websites, having all of that included and supported by a single source/vendor is very valuable and beats trying to Frankenstein a project out of 30 other libs like the bad old initial days of React.

For simpler or client-only sites, Vite is actually wonderful. But it's not automatically the best choice for every project.


It's best to compare it to Webpack - both are pretty good. Vite is intuitive with fast build times and has HMR that's easy to configure. Webpack takes effort to configure but will likely have a well supported plugin for any edge case.


Wait upon quick glance Vite doesn't come with SSR support ... ?

Yea guess I'll stick with NextJS


I built a React SSR app on Vite using Vike (https://vike.dev), it worked well enough for my simple needs. Best part was I was able to easily reuse a bunch of components from the primary React SPA app that lives side-by-side in the same project without needing to buy into the "Next.js way".


SSR support is only needed for public-facing websites that will undergo some kind of search engine indexation. For most apps this is not necessary since most apps are not accessible publicly.


NextJS does more than SSR, like determining routing based on directories and making React Server Components and Actions so simple it's hard to not choose NextJS

They've removed a ton of pain from full stack React/JS/TS


OK, but on the other hand I've heard from someone who worked at a startup that unnecessarily chose NextJS despite no requirement, and it really held back the organization for the rest of its existence, limiting velocity. Simple things like fetching queries become harder due to the split lifecycle. Relevant HN thread: https://news.ycombinator.com/item?id=36472166


Yeah, you definitely buy into a paradigm and ecosystem that has its own flaws. It's all tradeoffs and right for for sure.

My new project requirements for well with NextJS. I was mainly pointing out that there are a number of benefits for the drawbacks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: