Vinxi describes itself as:
"a full stack JavaScript SDK to build apps and frameworks of all kinds with your own opinions."
Which doesn't really say much, since there are so many different SDK's, toolkits and tooling for JS..
Vinxi is really a kind of Meta-Router / Router Manager (built on the dev-server and bundler-toolkit Vite and the http-server Nitro). Vinxi uses various routers of your choosing as a core primitive, and allows you to compose them in a centralized config so that they work together. Be it server or client routers.
See also: Nikhil Saraf | vinxi: I needed a server | ViteConf 2023 which reads
"Compose full stack applications (and frameworks) using Vite, the versatile bundler and dev server, and Nitro, the universal production server. The core primitive in vinxi is a router."
The following is an excerpt of the relevant portions of the on-stream conversation 'Introducing Vinxi w/ Nikhil Saraf' (Sept 2023) between Ryan Carniato (author of SolidJS) and Nikhil Saraf (author of SolidStart, Vinxi):
In a lot of ways someone might look at something like Vinxi and think about stuff like Vike (aka. vite-plugin-ssr).
What is Vinxi? How is it different from Vike?
Ryan and Nikhil:
I think Vike (aka. vite-plugin-ssr) is exactly in this space that kind of Vinxi is in.
It's probably that the abstractions that we've chosen are different. The problem space is kind of similar where you're trying to build server side apps with Vite as your main bundling layer, and your module loading layer.
I think the difference in opinions is [vite-plugin-ssr] is more oriented around server-side rendering (SSR) and doing a client server and interaction, where I'm [with Vinxi is] trying to build a full like server like framework layer, where you build your API. So you can build your API server, static file servers, your SSR servers, your hybrid servers, that you can do.
That's the composable unit kind of in my space. Because I already have situations where I'm using Vinxi I think in 5 different projects, all in like different bases. One is just an API server, one is an API with a SPA, one is an SSR setup, one is 2 different APIs.. [4 server modes, and MPA feels like a derived version of SPA] Just for some reason I have them at different endpoints, and I have file system routing, and some of them don't have file systems routing.
What about Vinxi's setup or abstraction do you think makes it different than something like vite-plugin-ssr [aka. Vike]? If you could say that in a fewer words? You're saying you can do all this, but why is that?
The thing is that the abstraction we've chosen is that our [Vinxi's] server is not like 1 Vite server. So, you know, 1 Vite server is very good at serving one kind of plug-in pipeline. That means that you can have something for your API servers, and something... but what you can do in Vinxi is you can have a specific pipeline for your API, a specific pipeline for SSR, a specific pipeline... maybe you have like a... so for example React server right.. so in your typical SSR setup will have: a client router, a server router, and maybe a public directory, right? For React Server Components you need a 4th router where you need your React server route. Because you actually have 2 different servers. So for me it's very easy to compose that because now it's just another 4th router, at a specific base, and I don't need to change anything in Vinxi's code.
[Note: Vinxi supports using different Vite plugins per router]
All of my React server kind of setups were done on top of Vinxi without having to build even a framework. When I show you examples I show you like it's 1 project where it's just 2 files that are like frameworky. You know, just some setup, but it's all in user land, and that's because I realized that the core abstraction for the server, or for the web, is the router, right?
It's like, at the end of it all, message passing happens through routing, and so what your server needs to be able to give you is a very powerful way to build whatever router you want. Handle URLs however you want in a very hybrid manner. You want your static, you want dynamic, you want pre-rendering, you want incremental rendering, you want your your API servers, you want compression, you don't want compression, like all of it just has to be very composable at the server layer.
Ryan:
Vike / vite-plugin-ssr is very opinionated about the client-side router, they're trying to build an isomorphic router that would do everything, that would do the same thing you would have for your client framework, the back-end, which is what we see in most of these routers, and they have opinions about data fetching and they have everything is wrapped into the the router in this single kind of piece.
So if you go use vite-plugin-ssr with Solid you're probably going to use Vike's [aka. vite-plugin-ssr] router with a solid adapter [aka. vike-solid].
Remix did the same thing. They were like: "We can have Remix / Svelte-mix / Vue-mix / whatever, we can make a version for all the different frameworks. You just take our baseline of React Router and wrap it, and then come up with Vue Router for Remix, and then you're good."
The truth of the matter is that these meta Frameworks are largely just an extension of the router. This is part of the realization that I had over time. I was trying to make Solid Start disappear at one point. Make nothing import from Solid Start. Most of the stuff got pulled into Solid's Router package. The problem is that if it goes there, then it doesn't go into Solid Remix Router. It's duplication. So I think for me, the coolest, biggest innovation of something like Vinxi, was understanding that there is a router aspect of the server, and it's very important for figuring out how to do all the fancy stuff, file system routing is you know a big piece to make the stuff wire up easier. But it's that you let the client router and that server router be separate, almost like pluggable, and in so you didn't have to have a prescriptive take on what routing should look like. Which every meta framework: that's how they define themselves. So like you were like "no no, you you can handle that piece of the routing", we just want to have the cues, so that we can tie into the bundling. That separation makes Vinxi different than any other solution I've seen in this space.
Nikhil:
Right. Because I leave everything to the runtime, I just want to know enough to know what to bundle, but everything else is on the runtime, and that means that all of it is up for innovation. So I'll talk about vite-plugin-ssr / Vike, I think I've looked at the solution very long, and my disagreement with Brillout, the person who's built vite-plugin-ssr / Vike was that he believes that there's no more innovation in routing. In the sense that it's kind of a solved problem, and that we can just move on, and I'm like 'literally all the innovation right now is happening in routing': islands is a routing innovation, server components is a routing innovation, the Next.js App Directory is a routing innovation. So I wanted my tool to allow any routing innovation to happen on top of it, without the router needing to build the framework again, just to bring its runtime into the game.
So I'll talk about this later, but I have examples with TanStack Router...
Vinxi + TanStack Router
For a full-stack SSR solution, using Vinxi on the server and TanStack Router as the router on the client side.
The aforementioned examples, from TanStack Router docs (without and with SSR):
https://tanstack.com/router/latest/docs/framework/react/examples/vinxi-basic
https://tanstack.com/router/latest/docs/framework/react/examples/vinxi-basic-ssr
https://tanstack.com/router/latest/docs/framework/react/examples/vinxi-basic-ssr-streaming
Top comments (0)