Just want to say well done. I’ve played with this with Tamagui[0] and I’d love to see this stack continue to develop.
Specifically, I think there’s a rare window of opportunity to replicate the new Expo router file system routes exactly in vite and build the holy grail of universal stacks.
I forked Hydrogen a month back or so just to get a feel for RSC and potentially how it’d work with native. Came away with huge positive impressions on Vite in general (and a vite stack that works nicely[1] with the Tamagui optimizing compiler fully working[2]).
Would love to collaborate towards this ideal setup with anyone competent, get in touch or I’ll ping in the discord.
There’s huge wins to be had at that level of vertical integration I think we haven’t touched yet.
Really interesting! How would you say it compares to Astro[0]? Astro is currently either all-SSG or all-SSR, but this quarter they're working on configuring that per -route.
VPS is tailored for users who like/want/need control. If you care about control, Astro isn't a good fit. E.g. you won't be able to use Astro with React Server Components. And many other subtleties that, in the end, sum up to a fundamentally different tool.
I’ve integrated vite with a rust backend[1] and so many people have asked me how I managed to achieve SSR because they equate SSR with render+hydrate but it’s really just classical SSR. I think I can finally make their dreams come true because of this.
Cool! I think with the popularity of next, SSR react frameworks are here to stay. My biggest gripe with next is how much I dislike vercel, currently looking at alternatives.
Interested to hear this too. My only gripe with them, is it's difficult to distinguish between the popularity of Next.js because it's good, or because they've hired an army of people (at Vercel) to talk about it.
1) Vercel serverless functions, or AWS lambdas, have a cold boot-up time after a period of inactivity. So basically the site goes to sleep if you're using SSR
2) I've noticed their SSLs don't work on older browsers (not that it's a huge deal, but I have some old macs which block their site, and any site hosted with them)
Sounds good, I'll check out those edge functions. I do really like that you guys have a free tier! And yes, I can send over some more info on the SSL stuff (mac model/year, browser version, etc)
I work at a web agency, and we reached the 10 user limit, and that means we have to be an enterprise customer which makes it 10-20 times the price we are paying already. We ended up removing one user and were looking for another provider. When we told the sales person from Vercel the price was high we got told we are not the kind of customer they want.
I also gave them a look, but it seems their bandwidth pricing is significantly higher than hosting it yourself, so the price accelerates much more aggressively with number of users. That much price variability is just too much of a risk (compared to a flatter/more predictable price) when you're also locking into a custom stack and can't migrate out as easily
Thanks for your work, this is what I am looking for. I have been looking for NextJS alternative since I have a tough time deploying to Cloudflare. I don't know why this never came up in my search results even though I digged beyond the 10th page of search result on many search.
The process in that doc provide the primitives on which SSR can be built. Vite-plugin-ssr is one such implementation. It provides a rather "NextJS-like" experience out of the box. Although, it allows for very easy differentiation between server vs client. (a file naming convention). It's not an attempt to clone NextJS and the documentation should make that clear. It even gives references for other projects that DO attempt that goal. If you currently have a home-grown solution, this is definitely worth a look as it could solidify some approaches to the SSR problem.
My only issue with it was (when I used it last) I couldn't get it to easily just output an HTML fragment. It kept trying to wrap my output in a full HTML doc (with a <HEAD>/<BODY> etc). That's one of my major contentions with NextJS as well. Often my webapps are used in the context of a larger document (sort of like Micro Frontends).
> I couldn't get it to easily just output an HTML fragment.
Feel free to create a GitHub ticket for that. (That's fairly easy to support as the only blocker is vite-plugin-ssr automatically injecting script tags.)
First and foremost: This looks great! I like the APIs, its a very next like experience, and I think the way you are handling fetching data is better than getInitialProps or getServerSideProps simply because it seems less limiting in approach.
Next.js is really being held back by webpack IMO and they would do well to convert to rollup / vite I think. This, Hydrogen from Shopify et. al. are proving webpack doesn't have the best future I think.
All that said, there is one thing about community solutions like this I worry about:
I know as long as I'm paying money to Vercel, I have support with Next.js and it will (in all realistic likelihood) be that way for years.
With community backed frameworks, there is no way that, say, this won't become unmaintained.
For all the possible warts Vercel / Next.js may or may not have, I think as a business building on top of these things, its important to take this into consideration. I'd rather not switch my SSR framework out from under my feet in 18 months.
I agree and that's why vite-plugin-ssr sponsorship https://github.com/sponsors/brillout plays a central role here: eventually, there will be enough sponsors to make vite-plugin-ssr a self-sustainable project a la Vue. It's a virtuous cycle and you can expect the number of sponsors to increase.
A more conservative answer is that vite-plugin-ssr is actually already fairly stable: only minor adaptations are required upon new Vite major releases. Do-one-thing-do-it-well tools stabilize quickly, that's one fundamental architectural advantage. Now the DX status quo is continuously evolving/improving and vite-plugin-ssr has to keep up (when not leading the way e.g. with Route Functions :-)). But, in the worst case scenario, you'll be stuck with non-modern DX while you'll be able to upgrade React/Vue/... independently of vite-plugin-ssr until you migrate away.
A more personal answer is that I love doing it, so expect me around ;-).
35 comments
[ 0.20 ms ] story [ 100 ms ] threadSpecifically, I think there’s a rare window of opportunity to replicate the new Expo router file system routes exactly in vite and build the holy grail of universal stacks.
I forked Hydrogen a month back or so just to get a feel for RSC and potentially how it’d work with native. Came away with huge positive impressions on Vite in general (and a vite stack that works nicely[1] with the Tamagui optimizing compiler fully working[2]).
Would love to collaborate towards this ideal setup with anyone competent, get in touch or I’ll ping in the discord.
There’s huge wins to be had at that level of vertical integration I think we haven’t touched yet.
[0] https://tamagui.dev
[1] https://github.com/tamagui/tamagui/tree/master/apps/site-vit...
[2] https://tamagui.dev/docs/intro/compiler
Yes! Please let me know about your blockers. Feel free to create a new GitHub ticket "Tamagui Integration" for this.
> RSC [...] huge positive impressions
Yes, RSC is groundbreaking, especially for mobile.
FYI the RSC Vite plugin is coming: https://github.com/Shopify/hydrogen/discussions/2225#discuss... (the author of that comment is React's tech lead).
> get in touch
I just wrote you on Discord.
[0] https://astro.build
1) Astro is either all-SSG or all-SSR, while VPS is mix-and-match
2) Astro uses `.astro` templates by default, while VPS uses `.js` by default
3) Astro comes out-of-the-box with Typescript, Sass, etc., while VPS requires more configuration (by design)
Other than that, they seem to have fairly similar project structures and use-cases... Or am I misunderstanding?
I’ve integrated vite with a rust backend[1] and so many people have asked me how I managed to achieve SSR because they equate SSR with render+hydrate but it’s really just classical SSR. I think I can finally make their dreams come true because of this.
[1] https://github.com/Wulf/create-rust-app
Love the Rust + Vite combo. These kind of combos are actually very well on my radar. (Also with Telefunc - a RPC implementation I'm working on.)
FYI, in case you missed ViteConf yesterday: Rollup (which Vite uses) is considering rewrite parts of itself in Rust.
But nicely done! I'll play around with it
Would love to hear more about the SSL issues. Would you mind sending more info to lee at vercel .com?
https://vitejs.dev/guide/ssr.html
My only issue with it was (when I used it last) I couldn't get it to easily just output an HTML fragment. It kept trying to wrap my output in a full HTML doc (with a <HEAD>/<BODY> etc). That's one of my major contentions with NextJS as well. Often my webapps are used in the context of a larger document (sort of like Micro Frontends).
Feel free to create a GitHub ticket for that. (That's fairly easy to support as the only blocker is vite-plugin-ssr automatically injecting script tags.)
Had some issues running the SSR api function on Vercel, though. Probably something to do with the the assets/ being specified in the wrong directory.
A lot of vite-plugin-ssr users are deploying to Vercel - have you seen https://vite-plugin-ssr.com/vercel and https://github.com/brillout/vite-plugin-ssr_vercel?
The recommended approach using an Vercel API Route is quite simple & straightforward.
Edit: DevClad => nice project btw.!
It's working great now. Love this project!
Things like the Enhance framework or Astro would be trivial to build with vps, especially once there single file page proposals get built.
Bold claim, but I guess it depends on the definition of "known" :)
Next.js is really being held back by webpack IMO and they would do well to convert to rollup / vite I think. This, Hydrogen from Shopify et. al. are proving webpack doesn't have the best future I think.
All that said, there is one thing about community solutions like this I worry about:
I know as long as I'm paying money to Vercel, I have support with Next.js and it will (in all realistic likelihood) be that way for years.
With community backed frameworks, there is no way that, say, this won't become unmaintained.
For all the possible warts Vercel / Next.js may or may not have, I think as a business building on top of these things, its important to take this into consideration. I'd rather not switch my SSR framework out from under my feet in 18 months.
A more conservative answer is that vite-plugin-ssr is actually already fairly stable: only minor adaptations are required upon new Vite major releases. Do-one-thing-do-it-well tools stabilize quickly, that's one fundamental architectural advantage. Now the DX status quo is continuously evolving/improving and vite-plugin-ssr has to keep up (when not leading the way e.g. with Route Functions :-)). But, in the worst case scenario, you'll be stuck with non-modern DX while you'll be able to upgrade React/Vue/... independently of vite-plugin-ssr until you migrate away.
A more personal answer is that I love doing it, so expect me around ;-).