Brisa: an experimental web framework that ships almost no client JavaScript

The warning at the top of the README is the most important line

Brisa describes itself as an experimental web framework inspired by the others, taking the best of each one, and the very first thing a visitor sees is a warning.

The 0.x versions of Brisa are considered experimental, use it for experimentation, we do not recommend using it in production until 1.x. The project asks for help to improve it by testing and giving feedback, and says it is open to suggestions and contributions.

That framing is unusual and worth respecting. Most frameworks in this position either quietly imply they are production ready or leave the warning in a contributing guide. Here it is a callout above the feature list, and it changes what you should do with the project: it is a place to try an architecture and give feedback, not a dependency to build a business on.

The concrete numbers give the project its shape. The version is 0.2.15, the licence is MIT, the default branch is canary, and the homepage is brisa.build. The last push to the repository was on 2026-05-01, and the most recent release is 0.2.15 from 2025-10-18, preceded by canary builds of the same version. There is a link to a roadmap issue for 1.0.

So the project is being worked on more recently than its last release, which is the normal shape of a pre-1.0 framework with a canary branch, and the README does not oversell any of it.

The bundle size claim, broken down by what actually costs bytes

The Tiny feature is the one that distinguishes Brisa from most of the frameworks it draws on, and the numbers are given with unusual precision.

The claim is 0B by default, 2kB when you use server actions, which is the RPC size, and 3kb when you need web components.

That breakdown is a design statement rather than a benchmark. Zero bytes by default means the client receives no framework runtime at all for a page that does not need interactivity, because the work happens on the server. Two kilobytes when you use server actions is the cost of the remote procedure call channel that lets the client invoke a function that runs on the server, and the README is explicit that the 2kB figure is the RPC size, which is the honest thing to name since it is the only client-side code involved in that path. Three kilobytes for web components is the price of shipping a custom element to the browser.

The Everything you need feature lists what that model covers: JSX, TS, server and web components, server actions, optimistic updates, SSR, streaming, suspense, signals, websockets, middleware and layouts. That is a wide surface, and the size claim is only credible because most of those features have no client cost at all, since they run on the server.

The Speed feature says Brisa is designed to start, build, test, deploy and run fast, which is a design goal rather than a measurement, and the i18n feature is described more specifically: text translation and routing carrying only the translations you consume.

One configuration command changes the output target

The feature that is easiest to get excited about, and the hardest to believe, is the Change the output line. You can change your web from server to static, to desktop, android, or ios app with just one configuration command.

This is a consequence of the architecture rather than a separate feature. If your components execute on the server and the client only receives output, then the same component tree can be rendered ahead of time for a static build, or driven at runtime on a server, or packaged for a desktop or mobile shell, because the output boundary is the same in each case. The framework does not need a different rendering model per target, only a different host.

Whether that holds up in practice is exactly the kind of question a 0.x framework leaves open, and the examples directory is a reasonable way to find out. There are examples for API routes, Elysia, an external web component, i18n, middleware, Panda CSS, SQLite with a server action, an SSR modal, a streaming list, suspense, Tailwind CSS, view transitions and websockets. Thirteen examples, each isolating one capability, is a good map of the feature set and a good way to test whether a given feature actually behaves as the headline claims.

The presence of an Elysia example is also worth noting, since it suggests the framework is designed to sit alongside a specific server runtime rather than to replace the whole stack.

Getting started is one command, and the monorepo is Bun driven

The Getting Started section is a single command:

bun create brisa@latest

It scaffolds a project, and the quick start documentation lives at brisa.build/getting-started/quick-start. The use of Bun rather than npm is not an incidental detail, because the whole repository is built around it.

The root package.json is named brisa-monorepo at version 0.2.15, with the description The next-gen web framework, and it declares pnpm style workspaces over packages/*. The scripts confirm the tooling. The build runs bun run --cwd packages/brisa build, the format and lint commands call bun run biome, and the prepare hook runs husky plus a TypeScript script that generates JSON dependencies for the Tailwind CSS package.

The release scripts show the shape of the publishing process. There is a release-all script that chains the individual package releases, and a matching release-all:canary variant that publishes under the next tag instead. The adapter for Vercel has its own release script and its own canary script, and the adapter is published with npm publish --workspace=packages/adapter-vercel --access public, using a tag of next for canary.

So the monorepo publishes several packages independently, and it has a canary channel for every one of them. The repository top level also carries a bun.lock, a bunfig.toml, a deno.json, a biome.json, a tsconfig.json and a .husky/ directory, and the default branch is canary, which is where the framework is developed.

An i18n model that ships only the translations you use

The internationalisation feature is described in one line, and it is a specific claim: text translation and routing carrying only the translations you consume.

Most internationalisation approaches bundle a locale file per language and let the client fetch what it needs, which means either shipping all strings to every visitor or making a runtime request per page. The Brisa claim is that because the rendering happens on the server, the server can decide which translated strings the response actually contains and send only those.

That is a genuine advantage of a server-first design, and it is also the kind of claim that needs a careful reading. The wording is about carrying only the translations you consume, which is about the payload for the strings used on that page. It does not describe how the translation files themselves are organised or split, and the docs site is where that would be spelled out.

The routing part of the same line is worth separating, because translated routing is a different problem from translated strings. A locale usually affects the URL shape, not just the labels, and a framework that renders on the server can resolve the route and produce the right links server-side, which is where most of the benefit lands in practice.

There is a dedicated example directory, examples/with-i18n/, and one for middleware and one for websockets, so the three features that need the most machinery each have a runnable reference.

Maintenance, community and what the project is asking for

The community side of the project is organised and small in a good way. The main repository links a Discord community channel, an issues page, and a roadmap issue, and the contributing guide and code of conduct are both in the repository.

The contributors table is populated with named people and roles, and one of them, Aral Roca Gomez, is marked as the maintainer. The author field in package.json is the Brisa Team with a contact address, and the sponsorship page names Kitmul and Viatsy as sponsors. The project also lists a Hacktoberfest topic, which is a reasonable way for a pre-1.0 framework to attract people willing to test edge cases.

On the technical side of maintenance, the release history is thin. Version 0.2.15 came on 2025-10-18, with canary builds of the same version in June and October 2025, and the last push to the repository on 2026-05-01. The package version in the monorepo root still reads 0.2.15, so the published version and the source version have not diverged.

The MIT licence is the permissive one, and for a project that asks people to experiment with it and give feedback, that is the right choice: nothing in the licence stops you from building on top of it even while the API is still moving.

What the project wants from you is stated in the warning itself. Test it, report what breaks, and help it get to 1.0. That is a reasonable exchange for a framework you are not being asked to depend on in production.

Editorial conclusion

Adopt Brisa if you are evaluating server component architectures in TypeScript and want a framework where the interesting behaviour happens on the server, since the streaming, signals and server action model is the thing to study here. Do not adopt it for a production project yet, because the README states that the 0.x versions are experimental and that the project does not recommend production use until 1.x, and the release history is thin for a framework at this stage. Before you commit, read the 1.0 roadmap issue, check the last push date of 2026-05-01 against your own timeline, and try the examples directory to see whether the model fits your team before the API moves.

Frequently asked questions

Official sources

1. brisa-build/brisa on GitHub
2. License: MIT
3. Project website
4. README
5. Releases