Support SSR and JavaScript frameworks (Next.js, Nuxt, Vite, Hono, …) for web hosting

[dywongcloud]

---

name: Feature request
about: Suggest an idea for this project
title: "Support SSR and JavaScript frameworks (Next.js, Nuxt, Vite, Hono, …) for web hosting"
labels: enhancement
assignees: 'Dylan Wong'

---

Is your feature request related to a problem? Please describe.

Tau web hosting currently serves static sites only — a build is just a zip of
files served as-is (with SPA fallback). There's no way to host apps that render
on the server or expose /api endpoints, so the modern JavaScript ecosystem —
Next.js, Nuxt, SvelteKit, Remix, Astro, server-rendered React/Vue, and JS API
servers like Hono/Express — can't be deployed to Tau the way they can to
Vercel/Netlify/Cloudflare. You're forced to pre-render to static or host
elsewhere.

Describe the solution you'd like

**DISCLAIMER I am aware that container based deployments solve this issue too. **

First-class SSR + JavaScript framework hosting that reuses Tau's existing
WASM runtime, so dynamic routes and /api are served by a WebAssembly server
bundle while immutable assets keep being served directly from the build asset:

• A website becomes self-describing via an SSR manifest
  (__taubyte__/ssr.json) embedded in its build zip. Presence of the manifest
  switches it from static to SSR — fully backward compatible (no manifest = today's
  behavior).
• Two handler ABIs: function (an exported handler using the go-sdk HTTP
  event — for hand-written/TinyGo handlers) and wasi-stdio (request on
  stdin / response on stdout — for JS engines compiled to wasm via Javy/QuickJS).
• Framework detection from package.json + zero-config build generation,
  plus an adapter that turns a JS handler into a wasi-stdio bundle.
• SSR bundles inherit Tau's function machinery: cold-start pooling, memory/timeout
  limits, SmartOps, and metrics.

Describe alternatives you've considered

• Static export only (e.g. Next output: 'export') — already works via static
  hosting, but rules out SSR, server components, and dynamic /api.
• A separate Node.js/V8 runtime in the platform — heavyweight, breaks the
  WASM/edge model, and duplicates the existing function runtime.
• Browser-side "Node in the browser" shims (e.g. almostnode) — client-side
  only; doesn't provide server rendering.
• Per-framework bespoke adapters — instead, generalize to one manifest + two
  ABIs so any WASI stdin/stdout JS bundle works.

Additional context

A working reference implementation exists and is proven end-to-end with dreaming
tests, including a real Javy-compiled JavaScript module rendering through Tau
(static + dynamic + /api). Both handler ABIs are green live. Remaining follow-up:
bundling a Web-API polyfill (Request/Response/URL) so Web-standard
frameworks like Hono/Next.js run on bare Javy — the platform hosts the result
unchanged.