web-app-template: a Vite and React starter kit built around tool speed

A template where the tooling choices are the point

The nkzw-tech web app template is a starter kit for Vite, React, TypeScript and Tailwind, and the tagline is minimal, sensible defaults, fast.

That word fast is doing more work than in a typical template. There is a blog post about this template linked from the top of the guide, titled as being about the fastest frontend tooling in 2022, and that post is the real explanation of the repository. The template is the argument in code form: here is what a front end stack looks like if the primary constraint is how fast the tools run while you are writing code.

The manifest makes the point concretely. The runtime dependencies are seven packages: @nkzw/define-env for environment variables, @nkzw/stack, better-auth, fbtee, react, react-dom and react-router. That is a short list for a template that includes authentication, internationalisation, routing and styling.

Two entries are worth pausing on. @nkzw/stack is a shared package that appears in the author's other templates as well, and it is the kind of internal library that makes a family of templates consistent. @nkzw/define-env handles environment variables, and having that as a dependency rather than a convention is the difference between a rule people follow and a rule that is enforced by the type checker.

The package is version 0.0.1, which is right for a template: it is not published as a product, it is a starting point that you take and rename, and a version number of 0.0.1 says so without anyone having to say it.

The author is Christoph Nakazawa, and the licence is MIT, so there is nothing stopping you from stripping it down to nothing.

The technology list, and what each entry is actually for

The technologies are listed with links and a one-line purpose for each, which is a compact way to see the shape of the stack.

Vite is the build tool, and React comes with the React Compiler enabled. That combination is the most interesting choice in the list, because the compiler is not a build plugin you add, it changes what React itself does: components are compiled so that they no longer need manual memoisation to be efficient. Enabling it in a template means you start with the fast path and never write the useMemo and useCallback noise in the first place.

Tailwind handles styling, and the version in the manifest is 4.3.3 with the @tailwindcss/vite plugin rather than a separate PostCSS setup, which is how Tailwind 4 is meant to be wired.

fbtee does internationalisation, and it comes with its own compiler package and Vite plugin, both from the same author at the @nkzw scope. A first-party tool for translation with a build step is a meaningfully different approach from runtime lookup dictionaries, and the fact that there is a compiler rather than just a runtime library suggests the translations are extracted at build time rather than shipped as a map.

Better Auth handles authentication, and React Router handles routing. Relay is listed as optional, for data fetching, and it is on a branch rather than in the main line.

The optionality of Relay is the design decision to notice. The main branch does not include a data fetching layer, which means you are not forced into one. If you want Relay, there is a with-relay branch, and the guide explains that in the setup steps you can check out the branch and run pnpm install to get it.

Setup, and the one command that does the setup work

The setup is a short list and the second item is the one that matters.

Press the Use this template button on the top of the repository's GitHub page. Run pnpm install, or npm install if you do not use pnpm. Run pnpm dev:setup. Then pnpm dev for development, pnpm test to run tests, and pnpm build for production builds. The note adds that you can install pnpm via homebrew on macOS with brew install pnpm.

So the whole flow is: get your own copy of the repository, install the dependencies, run one setup command, and you have a working application.

What dev:setup does is visible in the manifest. The script is vp run fbtee:all, which in turn is vpx fbtee collect && vpx fbtee translate. So the setup step is running the fbtee toolchain over the project: a collect pass and a translate pass. Whatever fbtee needs to do to wire up the internationalisation, such as discovering translatable strings and processing the translation files, it does it as part of getting started rather than leaving you to work it out.

The translations/ directory at the repository root is where that work lands, and the .env file at the root is where the environment configuration goes, which connects back to the @nkzw/define-env dependency. The prepare script is vp config, so the vite-plus configuration is also generated on install.

The overall point is that the template ships in a state where a new contributor can run the app and see something working, and where the fiddly parts of i18n setup are already done.

The toolchain choices that are unusual: Rust linting, and a workspace with no root dependencies

Two things in the manifest are worth pulling out, because they are the actual differentiators of this template.

The first is the linting and formatting tools. The protips section says to use oxlint for linting and oxfmt for formatting. Both are from the Oxc project, which is a set of Rust-based JavaScript tooling, and the template goes all the way in: the dev dependencies include @nkzw/oxlint-config, a shared config package from the same author, and oxc-transform-react, which is the React Compiler transform as an Oxc package rather than the Babel-based one. The config files at the root are oxlint.config.ts and oxfmt.config.ts.

The second is the vite-plus dependency and the vp and vpx commands. The dev dependencies list vite and vite-plus both as catalog:, which is a pnpm feature that pulls a version from a shared catalog, and the scripts call vp rather than vite directly. vite-plus appears to be a wrapper that bundles several tasks behind one command, since the same vp invocation handles both the config generation and the fbtee task runner. The test script is npm-run-all2, and the protips recommend using npm-run-all2 to parallelize local test runs.

The pnpm workspace file and the pnpm-lock.yaml at the root confirm the workspace setup, and the packageManager field pins [email protected] with engines requiring node ^24.11.0 or 26.0.0 or newer and pnpm 11.0.0 or newer.

So the template bets on Rust-based tooling for lint and format, on a task runner wrapper rather than raw scripts, and on pnpm workspaces with a version catalog. None of that is in the visible technology list, which is why the manifest is worth reading rather than skimming.

Maintenance, versioning and what a template does not promise you

The maintenance facts are thin in the way you would expect from a template, and they are worth reading carefully before you treat the repository as something you can pull updates from.

There are no GitHub releases, and the package version in the manifest is 0.0.1. The last push to the repository was on 2026-10-14 and the repository is not archived, so the template is still being worked on.

That combination tells you the model. A template is not a dependency you upgrade; it is a starting point you take a copy of. The Use this template button creates your own repository, and from that moment the upstream project is a reference rather than something in your dependency graph. There is no upgrade path, because you have diverged from it deliberately.

So the real question with a template is not how often it is updated but how much of it you keep. If you keep the fbtee setup, the @nkzw/define-env pattern and the vite-plus scripts, then a bug fixed upstream is a copy and paste away, and you have a reason to watch the repository. If you rip all of that out on day one, the template becomes a starting point for the src/ directory and nothing else, and the tooling choices described in the manifest stop mattering to you.

The licence is MIT, and the repository has a LICENSE file, so the code is yours to do what you want with. The technologies are all permissively licensed as well, and the browser support target in the manifest is set with a browserslist of greater than 0.2 percent, not dead, and not op_mini all, which is a sensible default for a modern React application and a reminder that the template targets evergreen browsers rather than legacy ones.

The engines field is the one constraint you will hit first. It requires node ^24.11.0 or 26.0.0 or newer, pnpm 11.0.0 or newer, and the packageManager field pins [email protected]. A team on an older Node, or on npm rather than pnpm, will need to adjust that before anything else works.

The family of templates, and how to get rid of the parts you do not want

Two things in the guide make this more than a one-off repository.

The first is the sibling set. Check out the nkzw-tech/server-template for a GraphQL based server with Pothos and Prisma, or the nkzw-tech/expo-app-template for building mobile apps. So the same author maintains a front end, a back end and a mobile template, and the naming convention makes it obvious that they are meant to be used together. The front end template also has an optional Relay branch for data fetching, which is the piece that would connect to the GraphQL server.

That coherence is worth something even if you use only one of them, because the choices in the front end template are consistent with the choices in the others rather than being a grab bag.

The second is the escape hatch, and it is refreshingly blunt. There is a section headed I'm not using Better Auth, and the answer is that you can simply remove everything related to Better Auth in the src/user directory.

That is a real property of a good template, and it is worth testing for before you adopt one. A template that makes a choice hard to undo is a template you will fight. If the authentication code lives in one directory, if the i18n setup is one command, and if the data fetching layer is on a branch rather than woven through, then you can use the parts you want and delete the parts you do not, and the rest of the template still works.

The repository layout is small and consistent with that: an index.html at the root, a vite.config.ts, a tsconfig.json, an .env, a src/ directory, a translations/ directory, a .vite-hooks/ directory, and a .vscode/ directory.

Editorial conclusion

Adopt this template if you are starting a new web application with React and TypeScript and would rather inherit a working set of choices for authentication, internationalisation and routing than make each one from scratch. Do not adopt it if you have strong existing opinions on those choices, since the point of a template is that its defaults win. Before you start, read the blog post that accompanies it, because the reasoning behind the tool choices is the actual content of this repository, and note that the Relay integration lives on a separate branch and the server and mobile equivalents live in their own repositories.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nkzw-tech/web-app-template on GitHub
4. README