[Framework]: Vike

[brillout]

Name

Vike

Homepage

https://vike.dev

Install instructions

• vike.dev/new (for using Vike with vike-react)
• npm create vike-core@latest (for using Vike with a manual React integration)

Is your framework open source?

Yes

Well maintained

Bugs are handled quickly (see GitHub issues).

Feature requests are triaged quickly (either put on the roadmap with prioritization, declined, or quickly implemented).

CHANGELOG.md

Vike's team

Active community

• Discord (to get help from the community)
• GitHub Discussions (to get official 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

Vike supports all deployment strategies:

• Static host (using pre-rendering)
• Classic VPS server deployment
• Serverless/edge deployment
• ISR (supported by vite-plugin-vercel)

Vike users can choose between:

• Zero-config integration (with vike-server for a quick start)
• Manual integration (with Vike's agnostic server middleware renderPage() for full control)

We're working on sharing our server infrastructure with other Vite-based frameworks (ideally also non Vite-based frameworks).

Developer Experience

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

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 companies that need extra flexibility, 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 — fostering stability as well as experimentation.

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
• 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
• Interop e.g. with Tauri
• Errors & warnings meticulously crafted to be helpful
• ...

User Experience

• Built-in data() hook for page-level data fetching (no waterfalls)
• With RPC (using Telefunc which we are also the author of): when waterfalls are detected we warn users and tell them to move up their data fetching logic in a common ancestor component
• 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. We're researching a design that doesn't involve mixing client and server code within the same file (no code extraction).