RFC: Server-Side Features

[ubugeeei]

WIP!

By the way, Evan announced VOID in the keynote at VueJS Amsterdam, and it included several server-side features.
With the stabilization of Suspense in mind, it seems worthwhile to further discuss Vue’s server-side capabilities in terms of the VOID backend, Vue’s semantics as a DSL, and runtime-level handling.

My RFC is still far from being thoroughly reviewed, and if there are any new ideas, I would love to discuss them with the team.

[posva]

I don't think this makes sense as a core feature in vue because in order for it to be useful it requires build-time optimizations that can strip off the runtime code from the client. Because of this, opinionated solutions (like Nuxt) seems to be a better fit

[ubugeeei]

This is still a work in progress, but similar to RSC, there seem to be cases where it would be useful for Vue to have non-hydrating components that run only on the server side (including at build time).
Also, meta frameworks such as Nuxt could potentially build on top of that foundation.

[ubugeeei]

Also, I’m not a fan of use server or use client.
Since Vue is a DSL, if we could provide first-class support through something like custom blocks or compiler macros, we might be able to cover these use cases.

[ubugeeei]

This feature is also related to Suspense.
Providing first-class support for async resolution like defineServerSideProps, including at the runtime level, should be quite valuable.
If the argument is that it’s sufficient for Nuxt to wrap such features, then things like Suspense shouldn’t be included in Vue’s core either.
#822

[asip]

I don't think it's smart to introduce defineServerSideProps for server-side data fetching and separate client-side and server-side concerns.

If <script server> is introduced for server functions, then instead of introducing defineServerSideProps for server components, it would be smarter to use <script server setup> for server components.

I feel that defineServerSideProps is too heavily influenced by Next.js's getServerSideProps.

[ubugeeei]

My intention is to take advantage of the semantics where Vue has compiler-informed mechanisms through defineXXX, and use that as a foundation to bring in things like Next.js-style reserved export words and React-style directives within Vue’s own semantics.

Rather than being strongly inspired by those API shapes themselves, it is closer to using Vue’s ability to introduce its own semantics as a trump card, and cleanly organizing APIs that other ecosystems are forcing onto plain JavaScript syntax.