[Framework]: Vike

[brillout]

Name

Vike

Homepage

https://vike.dev

Install instructions

• Bati (for using Vike with vike-react), or
• npm create vike@latest (for using Vike with a manual React integration)

Is your framework open source?

Yes

Well maintained

Bugs are systematically fixed (see GitHub issues).

Feature requests are systematically handled (either put on the roadmap or swiftly implemented).

CHANGELOG.md

Vike is maintained by a team.

Active community

• Discord, to get help from the community.
• GitHub Discussions, to get help from the Vike team.

Clear onboarding

• Scaffold new Vike app
• Add SSR/SSG to existing Vite app

Ecosystem compatibility

Vike offers unprecedented flexibility in that regard. (See DX section below.)

Self-hosting option

Full-fledged support for static host deployement with pre-rendering, classic server deployment, edge deployment, and ISR support with vite-plugin-vercel.

With SSR, Vike's server-side is merely a server middleware that can de deployed anywhere (it doesn't depend on Node.js).

Developer Experience

Full-fledged: Filesystem Routing, Data fetching, SSR, Pre-rendering (aka SSG), Layouts, HMR, i18n, Link Prefetching, Client Routing, HTML Streaming, ...

Vike's architecture is designed to enable two types of usage:

• With vike-react, the official Vike extension that integrates React in a full-fledged manner, providing a DX similar to regular frontend frameworks such as Next.js and React Router.
• Without vike-react, enabling users to implement a fully custom React integration. (While providing helpers such as react-streaming.)

Vike caters to the extra flexibility large companies often need — see, for example, the use case of Vike sponsors.

Note

Vike enables companies to choose between:

• Stability, by using a conservative Vike extensions (e.g. old-fashioned React without Server Components).
• Bleeding-edge, by using bleeding-edge Vike extensions (e.g. experiments around Server Components).

Vike extensions are small, easy to develop, and can be maintained for a (very) long time. It fosters both stability and experimentation.

We believe Vike represents the next generation of framework architecture.

Vite-based, thus blazing fast development DX.

Polished details:

• Automatic frontend deployment synchronization.
• Low-level i18n API, for full control over i18n.
• Route Functions and Route Guards.
• Error messages/warnings meticulously crafted to be helpful.
• Advanced Base URL support. (Base URL for static assets + Base URL for the SSR server.)
• URL rewriting
• User can seemlessly use hitory.pushState().
• Opt-in support for legacy browsers.
• Great care about interop, e.g. Tauri support.
• ...

User Experience

• Built-in data() hook for page-level data fetching (thus no waterfalls).
• With RPC (using Telefunc which we are also the author of): when waterfalls are detected we warn users and tell them to group and move up their data fetching logic (either in a common ancestor component or using Vike's buit-in data() hook).
• HTML Streaming with progressive enhancement.
• Client-side Routing
• SSR
• (Partial) Pre-rendering (aka SSG)
• Link prefetching
• Code-splitting, powered by Rollup.
• ...

Compatible with our future vision for React

We participated in the RFC of React Server Components and we are the author of RFC #219: injectToStream.

The main blocker for Server Components is Vite's lack of support, but this is going to change with Vite's upcoming Vite Environment API.

All other aspects of React's new architecture are already implemented, such as component-level data fetching with progressive enhancement. (For example Vike > HTML Streaming > Progressive Rendering.)

We were among the first to believe in the "RPC renaissance" (e.g. with a POC back in 2018). We're thrilled about RSC also from an RPC perspective, although we're researching a design that doesn't involve code extraction, as we believe code extraction (mixing client and server code inside the same file) adds non-negligible complexity.