Show HN: Vite-plugin-ssr – Do-one-thing-do-it-well alternative to Next.js / Nuxt

Show HN: Vite-plugin-ssr – Do-one-thing-do-it-well alternative to Next.js / Nuxt(vite-plugin-ssr.com)

114 points by brillout 3 years ago | 35 comments

Vite-plugin-ssr author here.

Let me know if you have questions!

nwienert 3 years ago |

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.

[0] https://tamagui.dev

[1] https://github.com/tamagui/tamagui/tree/master/apps/site-vit...

[2] https://tamagui.dev/docs/intro/compiler

brillout 3 years ago | |

> I’ve played with this with Tamagui [...] I’d love to see this stack continue to develop [...] and build the holy grail of universal stacks.

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.

redbar0n 3 years ago |

There's a fairly good and thorough comparison between vite-plugin-ssr and NextJS here: https://github.com/brillout/vite-plugin-ssr/issues/158

brillout 3 years ago | |

Comparison table: https://github.com/brillout/vite-plugin-ssr/issues/158#issue...

robertakarobin 3 years ago |

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.

[0] https://astro.build

brillout 3 years ago | |

Astro is a whole different thing really. I don't think vite-plugin-ssr users would want to use Astro and also vice-versa to some degree.

robertakarobin 3 years ago | | |

Hmm. It seems like the big differences between the two are:

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?

lionside 3 years ago |

Wowowowow thanks for your efforts behind this!

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

brillout 3 years ago | |

Neat indeed :-).

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.

johnnypangs 3 years ago |

What are the differences between this and the ssr in vite?

https://vitejs.dev/guide/ssr.html

nobleach 3 years ago | |

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).

brillout 3 years ago | | |

> 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.)

voat 3 years ago |

I am a big fan of vps. Brillout had some great ideas in this space, check out his other project Telefunc and Stem to see what I mean.

Things like the Enhance framework or Astro would be trivial to build with vps, especially once there single file page proposals get built.

tr1ll10nb1ll 3 years ago |

I'm really liking it so far and have been using this in production for the landing (and soon the blog) page at https://devclad.com/ using SSG.

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.

brillout 3 years ago | |

What exactly is the problem?

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.!

tr1ll10nb1ll 3 years ago | | |

I had a look at the updates you made in the readme. Seems like the problem was probably with the `vercel-build` command.

It's working great now. Love this project!

no_wizard 3 years ago |

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.

brillout 3 years ago | |

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 ;-).

enlyth 3 years ago |

> The source code of vite-plugin-ssr has no known bug

Bold claim, but I guess it depends on the definition of "known" :)

brillout 3 years ago | |

https://github.com/brillout/vite-plugin-ssr/issues?q=is%3Ais... (it only list recently found bugs - there are plenty of older bugs that aren't labeled)

redbar0n 3 years ago | | |

older but fixed bugs, I presume you meant to say.

srameshc 3 years ago |

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.

redbar0n 3 years ago | |

what keywords were you searching for? There are many NextJS alternatives, but not so many Vite SSR solutions.

davidjaenike 3 years ago |

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.

But nicely done! I'll play around with it

jensneuse 3 years ago | |

Can you elaborate on this? What do you dislike about Vercel?

o_m 3 years ago | | |

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.

davidjaenike 3 years ago | | |

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)

TheFragenTaken 3 years ago | | |

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.

ENGNR 3 years ago | | |

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