brillout

Indeed Accel is a long-term Vercel investor [0].

Not sure whether VoidZero and Vercel sharing the same investor has any sorts of implication.

[0]: https://vercel.com/blog/series-f

Doesn't seem like it — see VoidZero investors [0].

> Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS

Curious: is that speculation, or based on observation?

[0]: https://voidzero.dev/about

Vite+, Void Cloud, Void Framework... an epic battle between Vercel and Void is coming.

The PRC (aka server functions) demo [0] is particularly interesting — end-to-end type safety (from DB to UI) is a major milestone for JavaScript. We've been doing a lot of RPC design work in that space with Telefunc (tRPC alternative) [1] — it's a really hard topic, and we're looking forward to collaborating with the Void team. (Also looking forward to contributing as the creators of Vike [2].)

[0]: https://www.youtube.com/watch?v=BX0Xv73kXNk (around the end of the first talk) [1]: https://telefunc.com (see the last PR) [2]: https://vike.dev

The Void Framework demo [0] is exciting!

The PRC (aka server functions) demo is particularly interesting — end-to-end typesafety (from DB to UI) is a major milestone for JavaScript.

We've been doing a lot of RPC design work in that space with Telefunc (tRPC alternative) [1] — we're looking forward to collaborating with the Void team. (Also looking forward to contributing as the creator of Vike [2].)

[0] https://www.youtube.com/watch?v=BX0Xv73kXNk (around the end of the first talk)

[1] https://telefunc.com (see the last PR

[2] https://vike.dev

Author of Vike (unaffiliated with Vite) here. Questions welcome.

Hi, I'm brillout the creator of Vike.

Questions welcome!

I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can.

I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic.

I've wrote more about it over here[2] (SSG = static, SSR = dynamic).

[1]: https://vite-plugin-ssr.com [2]: https://vite-plugin-ssr.com/pre-rendering

Also have a look at https://vite-plugin-ssr.com/ (author here).

VPS is slightly lower level which gives you a lot more control: integrate with your existing Node.js backend (use any backend framework you want), deploy anywhere, use any React alternative (Solid, Preact, ...) and any data fetching tool (e.g. Relay can't really be used with Next.js).

The flip side is that you've to write a little bit more glue code. Although this will be alleviated by a lot with projects such as Bati[0], Stem[1], and vike-react (see Vike Rebranding[2]).

VPS also cares a ton about details, such as hooks for full control over i18n (use any i18n strategy you want), better Base URL support (VPS supports setting a different base for your server and your CDN), automatic deploy synchronisation, domain-driven file structure, polished and helpful error messages (especially the next upcoming release), ...

Detailed comparison with Next.js: [3].

If you run into any blocker then it's quickly fixed (or at least a workaround is proposed).

It supports not only SSR and pre-rendering, but also SPA in case you don't need SSR. It's going to support RSC but doesn't yet (RSC isn't ready for production).

Because it's lower level and because it's decoupled from React everything is designed in an agnostic way and with meticulous care. In other words: vite-plugin-ssr is becoming a robust foundation. There are breaking changes coming for the v1 release but beyond that chances are that there won't be any breaking changes for years in a row.

In a nutshell: vite-plugin-ssr takes care of the frontend and only the frontend. You keep control over your architecture. (Whereas frameworks tend to put themselves right in the middle of your architecture restricting you in fundamental ways.)

Last but not least: it's powered by Vite which means blazing fast HMR.

[0] https://batijs.github.io

[1] https://stemjs.com/

[2] https://github.com/brillout/vite-plugin-ssr/issues/736

[3] https://vite-plugin-ssr.com/nextjs-comparison

Very nice. Added to https://github.com/brillout/awesome-react-components.

Interestingly, Vite itself is written in a slow interpreted language (JavaScript/TypeScript) while using compilers that are written in fast native languages such as ESBuild (written in Go).

It's a nice showcase of successfully applying the strategy of focusing on hotpath performance instead of blindly making every line of code "fast".

Also, Vite being written in JavaScript is much friendlier to the ecosystem. I myself made many PRs to Vite which I would have done much less if it involved a more complex language.

Shameless plug: I'm the author of https://vite-plugin-ssr.com which is a Next.js/Nuxt alternative but with a "do-one-thing-do-it-well architecture"[1].

[1]: https://vite-plugin-ssr.com/architecture#do-one-thing-do-it-...

Seems like you may appreciate https://vite-plugin-ssr.com/ (I'm its author).

I think parent means that both Next.js and vite-plugin-ssr are open source, so "open(-source)" isn't a differentiator.

I agree although we think we can keep the word "open" and make it clear that we're takling about being a "open framework" (and not only open source).

Yea, we've plans to improve communicating that. (Although we do plan to stick to the word "open".)

Open alternative to Next.js: https://vite-plugin-ssr.com/ (I'm its author).

Open:

- Choose any UI framework you want (React/Vue/Solid/...)

- A lot more flexible than Next.js (e.g. i18n and base assets configuration are fundamentally more flexible)

- Keep architectural control (vite-plugin-ssr is more like a library and doesn't put itself in the middle of your stack)

- Use your favorite tools. And manually integrate them with vite-plugin-ssr (for full control without surprise).

- Deploy anywhere (and easily integrate to your existing server/deploy strategy)

- Open roadmap

- Ecosystem friendly

The upcoming "V1 Design" has been meticulously designed to be simple yet powerful. Once nested layouts, single route files, and typesafe links are implemented vite-plugin-ssr will be pretty much feature complete.

Note that, with vite-plugin-ssr, you implement your own renderer, which may or may not be something you want/need/like to do. Built-in renderers are coming and you’ll then get a zero-config DX like Next.js (minus extras like image processing as we believe they should be separate libraries).

Web dev isn't a zero sum game - a vibrant and healthy competing ecosystem of tools can co-exist. (I'm close to be able to make a living with sponsors.)

Vision is to make a truly open and collaborative foundation for meta frameworks.

Ask me anything.

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.

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.

Yes :sweat_smile:

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 (when not leading the way, e.g. with Routing 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 ;-).

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

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)

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

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

> 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 [...] Came away with 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.

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.

It is ironic because AFAICT Zod is actually more boilerplate than `shield()` :-). Although, the Zod familiarity is a clear argument in favor of Zod.

Speaking of boilerplate, one Telefunc feature I'm particularly excited about is its capability to automatically generate runtime type safety, so you don't even need `shield()` nor Zod then. But it's an experimental feature, let's see how it works out at scale.

The main problem with Telefunc right now is the lack of clear documentation which I'm going to work on in the next weeks/months. Hopefully, it will then become clear why Telefunc is simpler and less boilerplate. Stay tuned.

In the meantime feel free to check out the `examples/` and feel free to hit me up on Discord.