Minze is a small framework that makes web components feel like Vue

What the framework adds to the custom elements API

Minze is described as a dead-simple JS framework for native web components, and the framing is that it provides an intuitive abstraction layer around the web components API with its own fully typed JavaScript API. The list of what that layer adds is specific: reactivity, lifecycle hooks, scoped styles, one-shot components registration, and more. Those four are the whole proposition. A raw custom element has none of them, so a component that renders a list has to subscribe to state changes by hand and manually attach and detach listeners, and a component that needs to run code when it enters or leaves the DOM has no standard hook. Minze gives you the equivalent of a component model in about 3KB, which is the number the feature list quotes for the minified and compressed size. For a framework whose whole pitch is that you can use it with React, Vue, Svelte or no framework at all, a small runtime is not a nice-to-have, it is the premise.

The two use cases the README puts first

There are two numbered claims in the introduction and they are the decision criteria. First, you can create cross-framework component libraries or design systems and share them with your team or the world. Second, you can add Minze to any web project and create components without even using any build tools. The second is the more surprising one and it is the reason a framework this small is worth a look. Because a web component is a browser primitive, a Minze component can be written as an ES module, loaded with a script tag or an import map, and used in a page that has no bundler at all. That also means the same component works in a React application, a Vue application, a Svelte application and a static HTML page, which is what the framework agnostic feature is really claiming. The cost of that portability is that you give up the framework-idiomatic developer experience of whichever framework you were using, since the component API is Minze's own rather than the host framework's.

The feature list, taken apart

The feature list is short and each entry has a claim attached. Simple means you can dive right in by scaffolding a project, installing from npm or using a CDN link. Fast means a tiny footprint of about 3KB minified and compressed. Modern means it is based on the latest technologies around web components. Shareable means you can build component libraries or design systems, define once and use everywhere. Framework agnostic means you can use Minze with any common framework, React, Vue, Svelte and the rest. Storybook means there is a Minze and Storybook development environment integration. Extensive Docs means there is a full documentation set and an API reference. And Typed API means you can scale your component library with ease by using TypeScript. The combination that matters is the small footprint with the typed API, because a component library is judged on two things, how heavy it is for the consumer and how hard it is to keep consistent across many components, and Minze aims at both.

Four packages, and the tooling around them

The repository is a monorepo and the packages table lists what each one does. create-minze is the scaffolding CLI tool for setting up a Minze development environment, which is the entry point for a new project. minze is the framework itself. minze-vsc is VS Code language support for Minze, published to the Visual Studio Marketplace under the sergejcodes.minze-vsc identifier. And vite-plugin-minze is the Vite plugin for the Minze development environment. The story of the release history is the story of the tooling, since the recent releases are all minze-vscode at 0.6.1, 0.6.2 and 0.6.3, all published on the same day in May 2025, which suggests the editor integration was the active piece of work at that point. The root package.json is an npm workspaces setup rather than a pnpm one, with the packages/* glob, a stub and build script run across workspaces with --if-present, and a docs script that runs VitePress for the documentation site, which is where the extensive documentation lives.

The repository tooling and its commit conventions

The root manifest shows the quality gates, and they are worth a glance because they describe how the project expects contributions to arrive. The scripts are format with prettier writing through a cache, lint with eslint through a cache, test across the workspaces, and the docs scripts for VitePress. The dependency refresh script is a small thing that says something about the project's age, since it runs taze recursively and then reinstalls. The commit hooks are set up with simple-git-hooks, with a pre-commit hook running lint-staged and a commit-msg hook running a custom verification command, so commit messages are checked by the project rather than by convention. Lint-staged then runs prettier on everything and eslint on the TypeScript and JavaScript under packages/. The dev dependencies pin eslint 9.39.1 with the flat config, typescript-eslint 8.48.0, prettier 3.7.3, VitePress 1.6.4 for the docs and typescript-eslint's globals package. The engines field requires Node 16 or newer, and the type is module throughout, so the packages are ESM.

What a reader should check before choosing it

The README is a project announcement rather than a technical document, and it says so by pointing at the documentation site for anything deeper. What it does not cover is the set of questions you would want answered before committing. It does not state which browsers are supported, which matters for a framework built on custom elements and shadow DOM, and it does not say how the reactivity system tracks changes, whether it is a signal-based implementation or something else. The docs site is linked as the place to learn more, and the API reference is the linked typed API documentation. The licence is MIT, the repository is not archived, and the last push was on 2026-04-29, so the code is being worked on even where the release history focuses on the editor extension. The naming of the VS Code package also changed along the way, since the table calls it minze-vsc while the release tags call it minze-vscode, which is a small sign of a project still settling its own names.

Editorial conclusion

Adopt Minze when you want components that work in any framework, or none, and you want reactivity and scoped styles without shipping a framework runtime to the page. Do not adopt it if your team has already standardised on a component framework and is not looking for cross-framework distribution, since the value here is portability rather than capability. Verify first that the browser support you need covers custom elements and shadow DOM, that you are happy with a framework whose stated size is about 3KB minified and compressed, and that the Storybook and Vite integrations match the versions of those tools you already run.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sergejcodes/minze on GitHub