vike
vike copied to clipboard
vikejs
Comparison with NextJS
From reddit @redbar0n:
it's a bit hard to imagine and reason around the cost/benefit vs. NextJS. Could you elaborate a little bit on: How NextJS "plugin system become painfully limiting"? What "Custom SSR integrations" would one typically need when scaling? How vite-plugin-ssr would allow "perfecting UX" more than NextJS?
I've a lot on my plate already, so I'd be up for someone explaining why vite-plugin-ssr is a fundamentally more robust tool than Next.js.
This could be in the form of a blog post we'd share on the landing page of https://vite-plugin-ssr.com/. Or just a comment in this ticket.
Wrote first things that came to mind, will revisit and add more
- development speed is better because is Vite based plugin (no bundling, native ESM)
- nextjs has to have many examples in repo and whole plethora of libraries are existing just to integrate some lib with nextjs because is not trivial (for example https://github.com/isaachinman/next-i18next). With this plugin you just read lib docs you want to integrate and you are good to go.
- when new React or Vue feature arrives you can start to use it right away and don't have to wait next team to integrate it (streaming API, Server components, Suspense on server, partial hydration...) because you have control over render functions, both on client and on server
- you can use every possible routing library
- you can use other rendering frameworks, not only React
- nextjs can't read files in /public directory after it was built. i.e. user upload images
- with getServerSideProps next blocks client-side rendering https://github.com/vercel/next.js/discussions/23921 while with vite-plugin-ssr you are flexible and can choose what you want
- nextjs is really pushing vercel platform and is starting to show in recent feature updates. Features that align with this are getting priority while important fixes are delayed.
- nextjs is leaning on serverless and complicates usage when you don't want it
(SOON) you can use every possible routing library
That's actually already the case 😊 @gryphonmyers has been busy but he'll have more time soon and we'll finish up the deep Vue Router integration. The new hook onBeforeRoute() is quite powerful and allows you to almost entirely replace/customize the routing logic in a simple & straightful manner.
(SOON) getServerSideProps next blocks client-side rendering while with vite-plugin-ssr you are flexible and can choose what you want
Tracking ticket: https://github.com/brillout/vite-plugin-ssr/issues/95 and I'll start the implementation today. The conceptual/design part is done. EDIT: done.
Could this issue be renamed to "Comparison with NextJS"? To be easier for people to find.
This comment https://github.com/brillout/vite-plugin-ssr/issues/209#issuecomment-1041573876:
I wrote a small comparison table based on my experience with both vite-plugin-ssr and Next.js. It's definitely not complete but should be a good starting point
by @patryk-smc belongs here. Since that issue is for providing a migration guide. (Update: I imported the comparison table here, further down in this issue).
Could this issue be renamed to "Comparison with NextJS"? To be easier for people to find.
Done 👍.
I took the aforementioned comment by @patryk-smc, imported his comparison CSV to Excel, and then converted it to markdown, so it could be shared here, for people to enjoy:
(I added some info/links in brackets, and I'll try to keep the table updated as you add comments here with new info)
Update: This table has now been upstreamed and added to the webpage, so the latest version can be seen here: https://vite-plugin-ssr.com/nextjs-comparison#detailed-comparison-table
Original (no longer updated) table below, archived for posterity:
| Vite + vite-plugin-ssr | Next.js | |
|---|---|---|
| View frameworks | React & other supported by Vite (Vue, Preact, Svelte, Lit) | React only |
| TypeScript support | Yes | Yes |
| Code-splitting and Bundling | Yes | Yes |
| Fast Refresh | Yes | Yes |
SSR: |
||
| Control | Full control | Limited / Black box |
| Renderers | Yes, create as many you need | Just one (_app.ts file) |
Routing: |
||
| File system routing | Yes | Yes |
| Client routing | Supported | Supported |
| Client router | Use bulit-in or bring your own (eg. React Router) | Built-in [or hack it] |
| Server routing | Supported | Not supported (?) |
Integrations: |
||
| HTTP server | Not included | Baked-in, but custom server partially supported, with caveats |
| Apollo Client with SSR | Fully supported | Partially supported |
Extras: * |
||
| Head component | No, use react-helmet | Yes, next/head |
| Image component | No | Yes, next/image |
| API routes | No, use your server | Yes |
| Internationalization (i18n) | Yes | Yes |
Deployment options: |
||
| Vercel | Yes, minimal config | Yes, zero config |
| Cloudflare Workers | Yes, minimal config | No, [work in progress] |
| Node server (Docker, Heroku, Digital Ocean etc.) | Yes, minimal config | Yes, but limited |
| RSC (React Server Components) | Work in progress | Yes, experimental |
* - Vite/vite-plugin-ssr do not ship those extras by design.
Maybe @patryk-smc could explain this row a little bit?
| Vite + vite-plugin-ssr | Next.js | |
|---|---|---|
| Server integration | Required | Optional, partially supported |
@redbar0n To run Vite+VPS you need some sort of http server that invokes VPS, e.g. Express. Next.js comes with a built-in server, yet it supports http servers like Express too.
ah ok, makes sense, I got a bit confused due to Serverless deployments there for a while. Since vite-plugin-ssr does support serverless deployments (CloudFlare Workers, Vercel, Netlify, etc.).
Next.js comes with a built-in server
I thought NextJS used Express under the hood, but apparently it uses a vanilla HTTP server. In any case, using a custom server in NextJS has some disadvantages like "initial time investment learning custom nextJS server patterns", and since "you can't deploy custom servers to Vercel" it means that "you don't get serverless functions" support out of the box with NextJS then.
On the other hand, vite-plugin-ssr allows you to use the HTTP & GraphQL server combo you like. Which paves the way for some performance optimizations... (if you should at all care about it...).
But if you care about it, I found that Hyper-Express + Benzene is the fastest (bench1, bench2) Node HTTP server & GraphQL server combo, that also has JIT enabled, as of 2022-09-04. Another fast setup would be Fastify Mercurius + graphql-JIT.
In any case, for clarity / accuracy, I will rename:
| Vite + vite-plugin-ssr | Next.js | |
|---|---|---|
| Server integration | Required | Optional, partially supported |
To:
| Vite + vite-plugin-ssr | Next.js | |
|---|---|---|
| HTTP server | Not included | Baked-in, but custom server partially supported, with caveats |
@redbar0n That makes sense. It's a complicated topic with numerous options. Tricky to fit in into comparison table. I, personally, deploy to Vercel.
Internationalization | Yes (?)
It's a yes: https://vite-plugin-ssr.com/i18n and many users do this. It's slightly more boilerplate than Next.js but, as usual, you get much more control.
But in the industry framework right now, like Qwik, NuxtJs, NextJs, Svelte Kit, or Astro. Can you point out what precisely the main focus of this plugin?
I mean I'm from the point of view of the user, and I need to know the points of each tool - To match our purpose's products. @brillout
And I think you should put this conversation's result on the readme of repo 😆.
The way I see it is this: if you read the landing page http://vite-plugin-ssr.com and it doesn't make "click" then VPS isn't the right tool for you.
Next.js comparison table updated and live at https://vite-plugin-ssr.com/nextjs-comparison.
Awesome!
Image component → Currently just says "No". What is the recommended solution if using VPS? A link would be helpful. Especially since NextJS image component is so praised and could be perceived as a unique benefit there.
Internationalization (i18n) → I have the impression there's more support for this with VPS than with NextJS? Especially when it comes to custom URL's and subdomains? In any case, the NextJS could be changed to "Yes, with next-i18next, see user feedback 2. above."
For example, you can use Relay and Apollo in ways that aren't possible with Next.js.
This could use some backing, like:
- a link to the issues with NextJS, as evidence of the claim.
- an explanation of the ways and their benefits, explained then and there, or potentially though a link to a blog post.
- a blog post (or any resource known) on how to integrate Apollo/Relay with VPS in to achieve the benefits in point 2.
Image component → Currently just says "No". What is the recommended solution if using VPS? A link would be helpful. Especially since NextJS image component is so praised and could be perceived as a unique benefit there.
Done.
Internationalization (i18n) → I have the impression there's more support for this with VPS than with NextJS? Especially when it comes to custom URL's and subdomains? In any case, the NextJS could be changed to "Yes, with next-i18next, see user feedback 2. above."
Done. Changed Next.js's support to "Limited".
This could use some backing, like:
The plan is to implement Stem Relay. That should be enough evidence 😁.
Under "Server/deployment agnostic" it's possible to mention that NextJS uses their own internal web server. If you want to use another server like Fastify you'd have to use fastify-nextjs. But if you want to use the fastest HTTP server which is currently hyper-express then you're out of luck, because no one has made a NextJS integration yet. But with vite-plugin-ssr you could easily use it as is. That's a good argument for those concerned with scaling Update: That is, the server load is important mostly if you care about scaling in terms of HTTP servers. You could argue scaling is largely solved by going Serverless (like Next.js leans on, since it's tailored for deployment on their serverless platform, Vercel), but it often comes at a cost of some form of vendor-lock in.
Done https://github.com/brillout/vite-plugin-ssr/commit/aed7eaecf5b824ace8d63aea57bf9e65c41049d3.