# Devframe: a framework-neutral base for building DevTools > Devframe is an MIT-licensed TypeScript package for developers who ship their own DevTools UI and need it to run against Vite, Next, Hono, Fastify, Deno or a plain Node process without rewriting the shell. The repository shows a monorepo with a hub and adapter split and a long list of framework examples, but the README itself is mostly a logo and a link to devfra.me. **devframes/devframe** — Framework-neutral foundation for building generic DevTools. - Repository: https://github.com/devframes/devframe - Website: https://devfra.me - Stars: 704 · Forks: 34 - Language: TypeScript - License: MIT - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/devframes-devframe ## What Devframe is for, and who ends up using it Devframe describes itself in the repository as a "Framework-neutral foundation for building DevTools." That sentence is the whole pitch, and it is narrower than it sounds. Devframe is not a DevTools product you install and open. It is the layer underneath one: the part that decides how a panel connects to the app being inspected, how messages travel between the two, and how the UI stays independent of whichever server or bundler is hosting it. The audience is therefore small and specific. You are building something like a request inspector, a state viewer, a streaming log panel or an in-app playground, and you want that thing to work when the host app is a Vite dev server, a Next app, a Hono or Fastify server, a Nitro worker, a SvelteKit app or a Deno process. The examples directory lists adapters for exactly those: hub-vite, hub-next, hub-hono, hub-fastify, hub-nitro, hub-rsbuild, hub-sveltekit and hub-deno, plus custom-hub-vite and custom-hub-next for the case where you write your own. If you are a solo developer shipping one tool for one framework, the abstraction buys you very little and costs you a dependency you have to track. The package is published on npm as devframe and the monorepo is versioned 1.0.0, matching the v1.0.0 release dated 2026-09-16. It is MIT licensed, authored by Anthony Fu, and the repository is a pnpm workspace with turbo, vitest and Playwright configured at the top level. ## The hub and adapter split visible in the repository layout The clearest architectural signal is the naming in examples/. Everything called hub-* is an integration with a host runtime, and the custom-hub-* entries are the escape hatch for runtimes that do not have one. The packages/ directory holds the published code, with the main package at packages/devframe and its own runtime smoke test at packages/devframe/test/runtime-smoke.ts. That test is run three ways, through tsx, through bun and through deno, which tells you the maintainers treat the client as something that must load in non-Node runtimes rather than assuming Node APIs. The data flow implied by that layout is: your DevTools client code lives once, a hub package knows how to attach to a particular host, and the two speak over a transport that the host can provide. The examples/sse-basic and examples/streaming-chat directories suggest server-sent events and streaming responses are first-class transports in the examples, and examples/demo-dock-client suggests a docked panel UI is one of the shipped demonstrations. What the repository does not show is a single canonical protocol document. The transport contract has to be inferred from the hub examples rather than read from a spec, and that is the main cost of adopting this over writing a bespoke bridge. You are trading duplicated glue code for the obligation to read example code carefully. ## Installing Devframe and wiring a first hub The README does not contain install steps. It shows the npm badge, the documentation link at https://devfra.me/, the sponsor block and the MIT licence line, and nothing else. So the install command below is the standard npm form for the published package name, and everything after it should be checked against the docs site rather than treated as a complete recipe. The package name on npm is devframe, and the repository pins pnpm@12.4.1 as its package manager, so a pnpm install is consistent with how the project is developed. ```bash pnpm add devframe ``` After that, the useful first move is not to write code but to run one of the shipped examples, because the examples are where the wiring actually lives. The repository exposes a play script that maps to scripts/play.ts, and the root dev script is an alias for it. ```bash pnpm install pnpm run play ``` The package.json also defines a docs script that runs the documentation site from the docs/ directory, which is the local mirror of https://devfra.me/. ```bash pnpm run docs ``` For a framework-specific starting point, the examples directory is the reference. Pick the hub that matches your host (hub-vite, hub-next, hub-hono, hub-fastify, hub-nitro, hub-rsbuild, hub-sveltekit or hub-deno) and read its entry file to see how the hub is registered. If your runtime is not in that list, custom-hub-vite and custom-hub-next are the templates for writing your own. Expect to spend the first hour reading examples rather than reading documentation. ## Where Devframe is the wrong tool The README is the first limitation, and it is a real one. A repository whose front page is a logo, a badge row, a one-line description and a licence, with "Documentation: https://devfra.me/" as the only pointer, means the repository cannot be evaluated on its own. Anyone who needs to assess a dependency without leaving the code host will not get far. There is no documented rollback path, no migration notes in the README, and no changelog content beyond the release tags themselves. Version 1.0.0 arrived on 2026-09-16, two days after v0.10.0 on 2026-09-15. A 1.0 tag that closely follows the last 0.x release usually signals a stabilisation of an existing API rather than a long hardening period, and nothing in the repository contradicts that reading. If you need a dependency with a long public track record of 1.x releases behind it, this one does not have that yet. The third limitation is scope. Devframe is framework-neutral by design, which means it cannot lean on any single framework's dev-server internals. If your tool only ever needs to run inside Vite, a Vite plugin that talks to the dev server directly will be smaller and will have fewer moving parts than a hub abstraction. The neutrality is a cost you pay up front and only recover if you genuinely ship to more than one host. Similarly, if what you need is a finished inspector rather than a foundation, Devframe is one layer below your problem. ## Devframe against writing your own bridge The obvious alternative is not another library. It is the bridge you would write yourself: a small WebSocket or SSE endpoint in your dev server plus a client that connects to it. That approach has real advantages. You control the message format, you can debug it with the browser network panel, and there is no dependency to keep in step with your framework's dev server. The difference in approach is where the abstraction sits. A hand-written bridge encodes assumptions about one host: the port, the route, how the server is started, how hot reload interacts with the connection. Devframe pushes those assumptions into a hub package and keeps the client generic, which is why the repository carries eight hub examples instead of one. The payoff appears the second time you port the tool: instead of rewriting the connection layer for Hono after doing it for Vite, you swap the hub. The cost appears the first time: you are learning someone else's transport contract from example code, and if that contract changes you follow it. A second alternative is to build on the framework's own DevTools extension mechanism. That gives you deep integration with one framework's internals at the price of being unusable anywhere else. Devframe sits between the two: less integrated than a native extension, less bespoke than your own bridge. ## Maintenance, releases and the MIT licence The repository is not archived, and the last push to main was on 2026-09-17, three days before this writing. The release history runs v0.10.0 on 2026-09-15, v0.10.1 on 2026-09-16 and v1.0.0 on 2026-09-16, so the project is moving quickly at the moment. Fast release cadence cuts both ways: fixes arrive quickly, and so do breaking changes. A tool built on a 0.x line would have had three releases in two days to absorb. The upgrade cost is shaped by the monorepo structure. If you depend on published packages from npm, you track those versions. If you fork or patch anything, the patches/ directory and the pnpm workspace layout mean you are maintaining a fork of a workspace rather than a single file, which is a heavier commitment. The repository also ships an AGENTS.md and a CLAUDE.md at the top level, which is a signal about how contributions are expected to be made but not a support guarantee. On licensing: the project is MIT, and the README carries the line "MIT License © Anthony Fu". MIT is permissive, so redistribution and commercial use are broadly allowed, but the obligations that come with it (keeping the copyright notice and the licence text with copies) still apply. This is a description of the licence identifier, not legal advice; read LICENSE.md in the repository and talk to your own counsel if the terms matter to your product. ## Conclusion Adopt Devframe if you are building a DevTools panel, inspector or playground and you want the same client to attach to several frameworks instead of one. Skip it if you only ever target a single bundler, or if you need a documented, self-contained quickstart in the repository itself: the README is a logo, a one-line description and a link to https://devfra.me/, so the real onboarding lives on the docs site. Before committing, read v1.0.0 (released 2026-09-16) in the releases list, open examples/hub-vite and examples/hub-next side by side to confirm the adapter boundary matches how your app boots, and check the packages/ tree to see which packages you would actually depend on. The last push to main was on 2026-09-17. ## FAQ ### Is Devframe a finished DevTools app or a library? It is a library. The repository describes it as a "Framework-neutral foundation for building DevTools", so you build the tool and Devframe provides the layer that connects it to a host. The examples directory shows complete integrations, but those are demonstrations rather than the product. ### Which frameworks does Devframe work with? The examples directory contains hubs for Vite, Next, Hono, Fastify, Nitro, Rsbuild, SvelteKit and Deno. There are also custom-hub-vite and custom-hub-next examples for writing your own hub when your runtime is not covered. ### How do I install Devframe? The package is published on npm as devframe, so it installs with your package manager of choice. The README itself does not list install steps; it points to https://devfra.me/ for documentation, and the repository pins pnpm@12.4.1 for its own development. ### What does the Devframe repository include besides the package? It is a pnpm workspace with turbo, vitest and Playwright configured, plus a docs site under docs/, a storybook/, a starter/ directory, and a scripts/ directory that holds the play, ecosystem-ci and typecheck-coverage scripts. The published code lives under packages/. ## Sources - [devframes/devframe on GitHub](https://github.com/devframes/devframe) - [License: MIT](https://github.com/devframes/devframe/blob/main/LICENSE) - [Project website](https://devfra.me) - [README](https://github.com/devframes/devframe/blob/main/README.md) - [Releases](https://github.com/devframes/devframe/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/devframes-devframe