SSRx vs. Vinxi vs. Vike – for SSR with Vite

When you want to Server-Side Render (SSR) with Vite, you now have several options.

The official list of SSR solutions for Vite is maintained at the awesome-vite repo.

Remix with Vite is now a possibility. But let’s compare 3 other promising but less known options: SSRx, Vinxi and Vike.

Vinxi is maybe the most odd/indirect choice of the three:

While Vite is amazing as a devkit for client-side web applications, it requires some setup to use the server in the same application. The funny part is that there is a server running both in dev and prod, its just that you don’t get access to it.

Vinxi gives you the ability to add server-side functionality (SSR) to an existing Vite app.
https://vinxi.vercel.app/guide/add-to-existing-vite-app.html

Here are some collected notes of the distinctions between SSRx, Vinxi and Vike, to share with anyone else searching the web. Since my Google search came up empty, and I had to ask around on Twitter/X and GitHub to find out.

Why SSRx?

“Do you mind sharing why you started SSRx and what it solves that Vinxi or Vike don’t?”, asked Hunt Ethan.

Marc MacLeod (author of SSRx) answered:

Both of those projects are awesome. Vinxi is coupled to H3 [http framework] and Nitro [web server], and Vike does MUCH more than SSRx (which is great if you want to bet on the Vike ecosystem).

ssrx/vite plugin is simpler than both of those projects – it focuses on smoothing out a few DX issues with Vite SSR.

ssrx/renderer provides a means to hook into the lifecycle of an SSR app in a way that I haven’t seen elsewhere.

Ultimately my goal was to smooth over the DX issues I found with Vite SSR, and to formalize a means of hooking 3rd party libraries into the SSR lifecycle, while remaining as flexible as possible.

Why Vinxi?

To understand the rationale behind Vinxi (why it exists), I recommend skimming my article What is Vinxi, and how does it compare to Vike?.

To compare Vinxi with SSRx and Vike, the following discussion on some of Vinxi’s choices could be particularly useful.

My conversation with Nikhil (Vinxi author):

Personally, I got a bit more excited about SSRx than Vinxi because it is server agnostic, so I could use Hono or HatTip or any other super fast Node/Bun server or serverless HTTP framework with SSRx, if I want. With Vinxi, you can’t choose, but have to use H3 (which is not necessarily a bad alternative in it’s own right).

(Hono uses a faster RegExpRouter instead of a Radix Tree based router such as Radix3 which H3 uses, but it’s questionable whether or not it really matters.)

Nikhil’s response:

While I can understand the urge to go with different server runtimes. I really think a stable standard server runtime is important for Vinxi’s plan to be versatile across platforms and frameworks. H3 is very optimised on its own and powers Nuxt, one of the faster servers. It uses a very very thin layer on the bare platform server (be it Node or Bun). So in a lot of cases it’s faster than other Node servers that adapt to the Web Fetch API.

https://github.com/nksaraf/vinxi/issues/111#issuecomment-1886946316

My follow up question:

In what way is a standard server runtime necessary to be versatile across platforms and frameworks? Both SSRx and Vike are just as versatile wrt. platforms/deploy-targets, no? And in the worst case then frameworks already integrate with their own server runtime (like Nitro does with H3..).

Nikhil’s response:

It [a standard server runtime] allows us to build a shared library of trusted tools that can do the common operations across all the platforms, so sessions, CORS, cookies, auth, etc. It prevents us from having to open too many doors everywhere and make a lot of assumptions about the server code you are writing. This allows us to keep Vinxi much simpler (yet really powerful) than it would need to be to support any arbitrary server runtime.

From Vinxi’s perspective, it’s way better to bet on H3 which is backed by the Nitro and UnJS teams and is used by Analog and Nuxt. So lot of people working on keep it stable, fast, bug free and working everywhere. (and its still quite a difficult task).

SSRx vs. Vinxi

XiNiHa responding to tweet about the existence of SSRx:

The concept of being Vite-native definitely looks interesting, although I’m very not sure that would work well. I’d like to stick with Vinxi for now.

My reply:

Why wouldn’t it work well?
Vinxi is basically the same thing but with an integrated server (H3)…
Vike is also just a Vite plugin.

XiNiHa answered:

1. AFAIK, Vite is not a must for Vinxi. It would someday support Vite-less mode.*

2. Nitro has some rich features like pre-rendering, and Vinxi integrates with them very well.

3. Vinxi supports using different Vite plugins per router, and it is sometimes definitely needed.

* Perplexity.ai answers: Vinxi does not directly depend on Vite. However, there is a plugin called @vinxi/vite-plugin-inspect that is designed to work with Vite. This plugin is used to inspect the Vite server and provides additional functionality for development purposes. It is important to note that this plugin is an extension for Vite and not a dependency of Vinxi itself.

Why Vike?

In general, Vike is a more full-featured solution than Vinxi or SSRx. It brands itself as:

“Like Next.js / Nuxt but as do-one-thing-do-it-well Vite plugin.”

The Vike vs. Next.js comparison is a good place to start, to see why you might want to use Vike with Vite instead of Next.js that uses Webpack.

Compared to Vinxi and SSRx the biggest difference is that Vike has an integrated Client Router. Whereas you might want to go with Vinxi or SSRx if you want a specific router on the client side, like TanStack Router or React Router. It’s probably recommended to use Vinxi with TanStack Router, since Tanner uses Vinxi in his own framework TanStack Start. But if you’d rather use SSRx with TanStack Router, then see my comparison of it with Vike: Vike vs. SSRx + TanStack Router combo – a feature comparison

Most of the points in the SSRx + TanStack Router combo there should also be relevant if you switch our SSRx with Vinxi. TanStack Router even has some CodeSandbox examples of integration between Vinxi + TanStack Router (with SSR).

In general, you could say Tanner Linsley (author of TanStack) is leaning more towards Vinxi, due to his collaboration with Ryan Carniato and Nikhil Saraf (on SolidJS integrations, SolidStart which uses Vinxi, and Bling which was the predecessor of Vinxi). So current and future compatibility between TanStack Router and Vinxi might be in a better position than with SSRx. Certainly, if you plan on using the TanStack Start framework on web, then Vinxi would be a good bet.

To understand Vike vs. Vinxi better conceptually, I recommend my article: What is Vinxi, and how does it compare to Vike?.