FAQ

Is this production ready?

It's production ready for web and as an API server, Native still needs more love but has been in development for over a year and now works with a majority of React Native dependencies.

The Tamagui website and theme builder SPA run One in production, and we've tested porting a variety of apps to Native successfully, including the entire Uniswap UI package, which involved fixing a large number of dependencies.

What's breaking?

There's a few things that we need to improve:

• We've been adding tests, but need quite a few more and a couple rounds of code cleanup.
• Hot reloading on native has cases where it can break, and we need to develop this area a bit more.
• We've spent a lot of time making Vite compatible out of the box with the much less ESM-friendly React Native ecosystem, but there can still be sharp edges. Server side rendering can require a bit of configuration to get right. The deps options in the One Vite plugin can help alleviate this.

See the Status documentation for more on the general stability of the high level API surfaces.

How does it compare to Expo Router / Metro?

One started as vxrn, a library we made that let Vite serve React Native. We then forked Expo Router as an experiment to see if vxrn could power it. Today, One has changed quite a bit, but retains quite a bit of similarity in the file-system router. We appreciate the work the Expo team has done to pioneer universal file system routes.

A big part of One's upsides is in its leverage of Vite, as explained in the next section. One has already diverged quite a bit from Expo Router, with render modes, loaders, a production build and serve pipeline, middlewares, and other quality-of-life features. One currently lacks DOM components, a feature we'd like to implement.

How does Vite compare with Metro?

Pros:

• On a high level, Vite has a much larger ecosystem and community around it with many more answers online to common issues and an active Discord.
• Vite docs are world-class, and much more comprehensive in general than Metro.
• Vite is written in TypeScript, with rich JSDoc comments on most API surfaces.
• Vite is invested in by a wide variety of projects, and has a strong RFC process with a history of long discussions around upcoming features.
• Vite supports ESM first-class and generally just works with exports field and other modern module features.
• vxrn uses SWC under the hood rather than babel, leading to much faster build and hot reload times.
• The Vite plugin system allows many more hooks, and is much better documented.
• Vite supports many more features on the web, with a variety of features that Metro doesn't support or has limited support for. Some of these include dynamic imports, importing more types of assets, and importantly, proper code-splitting.
• Vite can tree shake require calls that are unused, whereas Metro always attempts to import require calls, even if the are behind falsy process.env checks.
• Metro has historically been very slow to nearly unresponsive to implement features not used by Meta.

Cons:

• Metro is supported by Meta and is far more mature.
• vxrn is in beta. It simply hasn't been tested on nearly a many use cases.
• Vite is less forgiving on the module-system level and expects things to be closer to spec. vxrn adds a variety of things to smooth this out, including an extensive system for patching bad modules, but in general this is an area that needs improvement.
• We've implemented a custom HMR in vxrn that will also need time to be as reliably good as Metro.

How'd you get that npm package?

A big thanks to Dan Maier, who donated it after being unused for 7 years with under 20 downloads a week

Will you support RSC?

We plan to support a limited subset, but not in the immediate future.

We think Zero makes for such a dramatic simplification of data - loading, mutating, and realtime sync - that we want to avoid much of the complexity of Server Components while retaining some of the upsides.

What we do like about RSC is that ability to avoid sending some parts of your React tree to the client to save bundle size, and potentially Server Functions. We're exploring bringing these to One carefully.

What we don't like is that by allowing mixing client and server trees so dynamically, they tend to have a "function coloring" like effect, where once you use them in one place, your whole apps routing at a fundamental level becomes "server-first." This is not good for UX - avoiding server round trips, and having to split mental models between server and client, are a big part of the reason we love Zero. We think there's ways to avoid this contaminating effect with a subset of RSC.

Edit this page on GitHub.