brust — a Bun + Rust web framework: hyper serves the HTTP, Bun only wakes for your code

[Aitthi]

Hi 👋 — I've been building brust, a web framework with an unusual split: one Bun host process loads a napi .node that contains the entire HTTP layer — a hyper 1.x server (HTTP/1.1 + HTTP/2, optional in-process TLS), routing, caches, and a template renderer, all pure Rust. Bun owns everything that's actually your code: routes, loaders, React SSR, and the client bundles.

The trick: JSX compiles to templates

A route marked native: true compiles ahead of time — the JSX lowers into a MiniJinja template that Rust renders directly. At request time the loader runs in a Bun worker to produce the context, and the HTML comes out of Rust. No React executes on the server for that page, and no JavaScript ships to the browser by default.

// stores/likes.ts — one instance across every bundle that imports it
import { defineStore, signal } from 'brustjs/store'
export const likes = defineStore('app.likes', () => {
  const count = signal(0)
  return { count, inc: () => count.set(count() + 1) }
})

// components/LikeButton.tsx — client logic is a react-free directive chunk
import type { BehaviorCtx } from 'brustjs/native'
import { computed } from 'brustjs/store'
import { likes } from '../stores/likes'

export const behavior = ({ effect }: BehaviorCtx) => {
  const label = computed(() => `${likes.count()} likes`)
  effect(() => {
    document.title = `Post (${likes.count()})`
  })
  return { label, inc: likes.inc }
}

export default function LikeButton() {
  return <button x-on-click="inc" x-text="label">0 likes</button>
}

// components/CommentBox.tsx — React island, subscribes to the SAME store
import { useStore } from 'brustjs/client'
import { likes } from '../stores/likes'

export default function CommentBox({ postId }) {
  const { count } = useStore(likes)
  return <>…</>
}

// pages/Post.tsx
import { BrustPage, Island } from 'brustjs'
export default function Post({ post }) {
  return (
    <BrustPage title={post.title}>
      <article>
        <h1>{post.title}</h1>
        {post.subtitle && <p className="sub">{post.subtitle}</p>}
        <LikeButton native />
        <ul>{post.tags.map(t => <li>{t.name}</li>)}</ul>
        <Island component={CommentBox} props={{ postId: post.id }} hydrate="visible" />
      </article>
    </BrustPage>
  )
}

// routes.tsx
{ path: '/posts/{slug}', Component: Post, native: true,
  loader: async ({ params }) => ({ post: await getPost(params.slug) }) }

LikeButton renders in Rust and its behavior ships as a small react-free chunk; CommentBox is a real React island that hydrates when scrolled into view — and both write the same defineStore instance, so they stay in sync with no event bus.

Where Bun does the work

• Loaders and React SSR run in a Bun Worker pool. Renders return to Rust over a per-worker SharedArrayBuffer, and a worker holds several renders in flight (renderSlots) to overlap Suspense-bound requests instead of serializing them.
• Bun.build produces every client artifact — React island chunks and the react-free directive chunks — content-addressed, one chunk per component, loaded on demand.
• Routes that don't need JS never touch it. A native: true page is a Rust-side template render; the worker only wakes for the loader.
• brustjs dev reloads by respawning the worker pool; brustjs build --ssg prerenders static routes to plain HTML.

The payoff of the split: the hot path stays inside Rust, and Bun only wakes for application code — benchmarks and methodology live in bench/RESULTS.md if you're curious.

Links

• Repo: https://github.com/AssetsArt/brust
• Docs: Rendering Modes · Native Interactivity

Fair warning, it's 0.1.x-alpha and APIs still move. Happy to answer anything about the napi crossing or the JSX→template compiler.