vite-plugin-ssr

🔧 Control

Use any UI framework (React, Vue, Svelte, Solid, ...) and any tool you want (Vuex/Redux/Storeon, RPC/GraphQL/REST, React/Vue Query, PWA, Service Workers, other Vite plugins, ...).

With vite-plugin-ssr, you integrate tools manually and keep architectural control.

With vite-plugin-ssr you keep control over how your pages are rendered.

// /pages/about.page.js
// Environment: Node.js, Browser

export { Page }

// `Page` can be anything you want such as a React/Vue/Svelte/... component
function Page() {
  return <>
    <h1>About</h1>
    <p>This is our first vite-plugin-ssr app.</p>
  </>
}

// _default.page.server.js
// Environment: Node.js

import { escapeInject, dangerouslySkipEscape } from 'vite-plugin-ssr'

// This can be any UI framework (React, Vue, Svelte, ...)
import { renderToHtml } from 'my-favorite-view-framework'

// You control how `Page` is rendered to HTML
export async function render({ Page }) {
  const pageHtml = await renderToHtml(Page)
  const title = 'My first vite-plugin-ssr app'
  return escapeInject`<!DOCTYPE html>
    <html>
      <head>
        <title>{title}</title>
      </head>
      <body>
        <div id="page-root">${dangerouslySkipEscape(pageHtml)}</div>
      </body>
    </html>`
}

// _default.page.client.js
// Environment: Browser

import { getPage } from 'vite-plugin-ssr/client'
import { hydrateToDom } from 'my-favorite-view-framework'

// This file defines the *entire* browser-side code.
// If you leave this file empty then there is zero browser-side JavaScript.

hydrate()

// You control how `Page` is hydrated
async function hydrate() {
  const { Page } = await getPage() // In production, `await getPage()` is preloaded
  await hydrateToDom(Page)
}

This means you can use and integrate any tool you want simply by following the tool's official installation guide.

📦 Zero-config

vite-plugin-ssr gives you control only where it matters.

Everything else just works without the need to configure/decide anything.

💫 Simple

With vite-plugin-ssr, you integrate tools manually instead of using a plugin system. While it means more work, it gives you a fundamentally simpler & more stable foundation to build upon.

The clean cut between vite-plugin-ssr and your UI framework (React/Vue/...) makes reasoning about your app easier.

Less easy, but simpler

With vite-plugin-ssr you integrate tools yourself. This usually means more work and it's less easy than just adding a Next.js/Nuxt plugin; getting started is often slower.

But plugin systems are inherently complex and limiting; they quickly become counterproductive. You end up fighting the plugin system and needing brittle workarounds to circumvent Next.js/Nuxt's black-box limiting nature. The net result is a substantial loss in development time and massive frustration.

In contrast, vite-plugin-ssr gets out of your way and integrating a tool is simply a matter of following the tool's official installation guide.

In a nutshell: vite-plugin-ssr is less easy but simpler.

Stable foundation

Plugin systems / frameworks need to constantly keep up with the ecosystem, whereas do-one-thing-do-it-well tools can quickly stabilize. Actually, vite-plugin-ssr is already stable: the v1 release will most likley have no breaking change with the current v0.3.x releases, and the goal is to stay on v1 for the foreseeable future.

Clean Cut

vite-plugin-ssr is agnostic; there is no conflation between vite-plugin-ssr and your UI framework (React/Vue/...). This makes reasoning about your app easier.

Fun

Last but not least, manual integration is fun & insightful, whereas fighting some arbitrary framework and idiosyncratic abstraction is an annoying waste of time.

Full-fledged

Filesystem Routing, Data fetching, Pre-rendering (SSG), HMR, i18n, Link Prefetching, HTML Streaming.

Client Routing (fast page navigation) or Server Routing (simple architecture).

All render modes: SSR, SPA, SSG, HTML-only. Each page can use a different mode.

Fast HMR

Blazing fast Hot Module Replacement powered by Vite ⚡. It stays fast as you scale (thanks to Vite's novel lazy-transpiling approach).

Routing

Pages are automatically routed:

FILESYSTEM                  URL
pages/index.page.js         /
pages/about.page.js         /about
pages/faq/index.page.js     /faq

You can also use so-called Route Strings and Route Functions.

// Route String — for parameterized routes
export default '/movie/:movieId'

// Route Function — for full flexibility
export default ({ url, ...pageContext }) => url==='/admin' && pageContext.isAdmin

You can choose between:

Client Routing for a faster page navigation. (DOM mutation upon page navigation.)
Server Routing for a simpler app architecture. (Full HTML reload upon page navigation.)

Render Modes (SSR, SPA, SSG, HTML-only)

For each page, you can choose between:

SSR: the page's HTML is rendered at request-time.
SSG: the page's HTML is pre-rendered at build-time.
SPA: the page is not rendered to HTML; it's only loaded & rendered in the browser.
HTML-only: the page is rendered only to HTML with zero/minimal browser-side JavaScript.

For example, you can render an admin panel as an SPA, while rendering marketing pages only to HTML with zero browser-side JavaScript.

https://vite-plugin-ssr.com is HTML-only and loads only few KBs of JavaScript (implementing the few bits of interactivity such as the collapsibility of this LEARN MORE section).

🌍 Deploy anywhere

Works with any server environment (Vercel, Cloudflare Workers, AWS EC2, AWS Lambda, Firebase, Google Cloud, ...).

Pre-render your app and deploy it to any static host (Netlify, GitHub Pages, Cloudflare Pages, ...).

Fits Cloudflare Workers's small worker size requirement like a glove.

It's just a middleware

From an architectural point of view, vite-plugin-ssr is just a server middleware.

const { createPageRenderer } = require('vite-plugin-ssr')
const renderPage = createPageRenderer(/* ... */)

// `app` can be any server framework such as Express.js/Fastify/Koa/Hapi/...
app.get('*', async (req, res) => {
  // `renderPage()` can also be used in serverless environments such as
  // Cloudflare Workers and Vercel
  const pageContext = await renderPage({ url: req.url })
  res.send(pageContext.httpResponse.body)
})

Pre-rendering (aka SSG)

You can also pre-render your app to remove the need for a production Node.js server and deploy to any static host (Cloudflare Pages, GitHub Pages, Netlify, ...).

$ npx vite-plugin-ssr prerender
vite-plugin-ssr 0.1.2 pre-rendering HTML...
✓ 3 HTML documents pre-rendered.
dist/client/index.html
dist/client/about/index.html
dist/client/404.html

Cloudflare Workers + `vite-plugin-ssr` = ❤

Thanks to vite-plugin-ssr's lean architecture, your app is much less limited by Cloudflare Workers's 1MB bundle size limit.

Also, vite-plugin-ssr has been designed with first-class Cloudflare Workers support in mind, for example:

For development you can use Vite with an Express.js dev server for lightning fast HMR & dev start, and for production you can bundle your worker code with Cloudflare Workers's webpack bundler.
vite-plugin-ssr is the first SSR tool to work with Cloudflare Workers's support for HTML Streaming

💎 Rock-solid

The source code of vite-plugin-ssr has no known bug, every release is assailed against a heavy suite of automated tests, it's used in production by many companies, and it's stable: the v1 release will most likely have no breaking change with the current v0.3.x releases.

🚀 Scalable

DX that scales to hundreds of kLOCs — HMR & dev start stays fast.

Architectural flexibility that scales from small hobby projects to large-scale enterprise projects.

Lazy-transpiling

One of Vite's foundational novelty is lazy-transpiling: only executed code is transpiled. If you define ten pages but load only one page in the browser, then only the code for that page is transpiled.

Thanks to lazy-transpiling, you can scale to (very) large source code while keeping fast HMR & dev start.

No black box, no plugin system

At scale, Next.js/Nuxt's black-box nature and its plugin system become painfully limiting.

In contrast, vite-plugin-ssr is transparent: you keep control over both the server- and browser-side.

As you scale, you usually need increasingly custom SSR integrations; vite-plugin-ssr's flexibility accommodates such needs.

Vite + SSR + Scale = ❤

At (very) large scale, you can progressively replace vite-plugin-ssr with Vite's native SSR API which is low-level and highly flexible. If you're Netflix and perfecting UX leads to a substantial revenue increase, then vite-plugin-ssr and Vite's native SSR API are what you are looking for.

Large production apps are using Vite for its speed.

Tweet 1398240747661533184

Tweet 1392901819135795202

Tweet 1409983946201370626

Tweet 1423324336845426691

⚡ Fast

Browser-side: Code Splitting (each page loads only the code it needs), Client Routing (pages loaded & rendered only on the browser-side upon page navigation), Link Prefetching (preload preponderant links for instantaneous page navigation), Lighthouse Score: 100%.

Fast Node.js cold start: pages are lazy-loaded so that adding pages doesn't increase the cold start of your serverless functions.

💖 Fun

vite-plugin-ssr is simple, clear, and robust: no magic, no unexpected behavior, no conflation, no bugs (known in vite-plugin-ssr's source code), no breaking changes (as far as we can see).

With vite-plugin-ssr, you are under control; it's addictively fun.

Framework Engine

Use vite-plugin-ssr to build frameworks.

You want to build an internal framework for your company? Or you want to build a Next.js alternative? Use vite-plugin-ssr to jump-start with a rock-solid foundation.

❤ Craftsmanship

Crafted with attention to details and care for simplicity.

Upsteam contributions to Vite and others.

GitHub and Discord conversations are welcome.

⚗ Cutting Edge

We regularly participate in RFCs and we are usually among the first to support the latest techniques.

Have a question? Want a feature? A tool integration is not working? Join our Discord or open a GitHub ticket.

Explore how it's like to use vite-plugin-ssr