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.
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 ;-).
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.
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.
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.
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)
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.
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
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.
[0] https://tamagui.dev
[1] https://github.com/tamagui/tamagui/tree/master/apps/site-vit...
[2] https://tamagui.dev/docs/intro/compiler