Product1 publisher2 min readPublished
Devframe moves devtool plumbing behind a single Web Standard request handler
Anthony Fu's new framework asks devtool authors to define a tool once and mount the result almost anywhere, on the argument that his own six inspectors each rebuilt the same RPC, state sync, serialization and asset hosting.
The Product Desk · Product desk
What happened
- Anthony Fu introduced Devframe on September 16, 2026, a framework-neutral foundation for defining a devtool once and then bringing it to different host frameworks, standalone adapters and coding agents.
- He names six devtools he has worked on, including Nuxt DevTools, Vitest UI, the UnoCSS Inspector and the ESLint Config Inspector, all of them built to make implicit state visible.
- Each of those tools carries its own RPC, state synchronization, serialization, static asset hosting and web interface, and decides separately how it is packaged and mounted into a host framework.
- A Devframe definition becomes a live instance whose request handler serves the SPA, connection metadata, live RPC, authentication and an optional MCP endpoint under one namespace.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- constraint While a devtool's transport is written against one development server's request and connection handling, the host it was built for decides who can ever run it.
- exposure Authentication and an optional MCP endpoint answer on the same base path as the user interface, so whoever can reach that port reaches the agent-callable surface too.
- capability One definition can feed both a browser SPA and a coding agent, so an agent can read a tool's state without anyone building a second interface for it.
- precedent If the boundary holds the way unplugin's did for bundler plugins, maintainers of overlapping inspectors get one target to contribute to instead of a version per host.
Five pieces of shared infrastructure across six tools is thirty implementations of the same five problems [1]. That count is the case for a shared foundation, though the same history is what makes one hard to build: three hand-written serializers mean three sets of edge cases the shared layer has to absorb.
The coupling costs more than the duplication. Fu writes that most devtools in the ecosystem are tied to a specific framework and to the details of its development server, down to how it serves assets, handles requests and upgrades connections [5]. Capabilities with nothing host-specific about them get rebuilt anyway: data inspectors, asset viewers, build analyzers, terminals, editor tooling [6].
Devframe puts one function between the tool and the host. `initDevframe()` returns an instance carrying `.handler`, typed as a Web Standard `(request: Request) => Promise<Response>`, plus `.nodeMiddleware` for connect-style servers [9]. Fu credits the handler-first model to Comark Content [11]. For the adapter layer he offers unplugin as the parallel, since unplugin gives bundler plugins a common interface across bundlers [12].
The idea has been public for three years. It was first shared in 2023 as a diagram of a Universal DevTools Ecosystem [13]. "The diagram was aspirational. The direction felt right, but finding the boundary that could make it work was much harder," Fu wrote [14]. Vite DevTools, which he worked on at Vercel, gave the idea a concrete home, and he says the goal was always to open it to other build toolchains [15]. He also credited the tooling he used to explore it: "Each iteration taught us something new, while LLMs made it much faster to explore and validate the design" [16].
For anyone maintaining a devtool and wondering whether to move onto a definition layer, the useful test runs piece by piece. Take the five shared pieces one at a time and ask whether a user would notice if you swapped in someone else's implementation [3]. For most tools the answer is none, because users came for the view that makes implicit state visible [18]. If the answer is one of them, say state synchronization because your tool streams a large build graph, then the shared layer is where the arguments will happen, and a neutral definition will cost more than it saves.
Fu's worked example defines one tool, creates one instance and mounts it at `/__my-tool/` [17].
What to watch
- Whether a devtool outside Fu's own set adopts defineDevframe(), and which host framework ships the first adapter.
- Whether Vite DevTools gets rebuilt on Devframe, the first real test of the boundary outside its home toolchain.
- How Devframe specifies the authentication sitting in front of the RPC and MCP endpoints that share one base path.