whyframe: rendering any UI framework's markup inside an iframe

One attribute, and the framework stops mattering

whyframe enables rendering any UI framework markup within an iframe, including Svelte, Vue, Solid, Preact and React, and the whole usage is one HTML attribute:

<iframe data-why>
  Hello world!
</iframe>

That is the whole conceit. Instead of each framework needing its own way of embedding a live example into a page, the markup goes in an iframe and the framework specific packages handle the rest. The audience is therefore the people who write documentation and component libraries, where the same page frequently needs to show a Svelte component and a Vue component and a React component, and where spinning up a dev server per example is not a viable workflow.

The feature list names the reasons it is built this way. Develop components in isolation, flexible HTML customization, tight bundler integration, a fast runtime, and compatibility with major bundlers and frameworks.

The bundler integration is the piece that is doing the real work. A static iframe cannot run a Svelte component on its own, so something has to compile that component and inject the result into the document. Doing that at build time, through the bundler the documentation site already uses, is what makes the approach fast, and it is why there is a separate package per framework rather than one clever runtime.

The documentation lives at whyframe.bjornlu.com, the licence is MIT, and the sponsor link points to the author's site at bjornlu.com.

One detail deserves to be repeated from the top of the README, because it changes how you should read everything else here. The project is in maintenance mode.

Maintenance mode is the first line of the README

The very first thing in the README is a callout marked IMPORTANT that says the project is in maintenance mode.

That is a statement about the future, not about the code. The library works, the packages are published, and the documentation is live. What it means is that new features are not the plan, and that anyone planning to build on whyframe should plan to maintain it themselves if they need more.

The dates back this up. The last push to the repository was on 2026-07-08, and the newest core release, @whyframe/[email protected], was published the same day. The framework packages are a little behind that, with @whyframe/[email protected] and @whyframe/[email protected] both dated 2026-04-02.

So the project is at the 0.2 and 0.3 stage, roughly three months since the last change, and explicitly parked.

For a team that wants exactly what it does, that is a perfectly good project. An iframe based renderer with a single attribute and per-framework build integration is a narrow, well-defined need, and a stable implementation of it can be more useful than an actively developed one whose API keeps moving. What it does mean is that a new requirement, a new framework version or a security fix has to be handled by whoever adopts it, and the MIT licence makes that a fork rather than a negotiation.

The honest way to evaluate it is as a finished tool with a finite feature set, rather than as a dependency with a roadmap.

Five packages, one per rendering target

The package table in the README is the clearest description of the design.

@whyframe/core is the shared base. @whyframe/svelte, @whyframe/vue and @whyframe/astro cover the frameworks that need a dedicated integration. And @whyframe/jsx covers the JSX family, which is how React, Preact and Solid are served with one package rather than three.

Each package carries its own changelog in the table, linked from the package directory, which is the normal arrangement for a monorepo that publishes several packages independently.

That split is the design rather than an accident. A Svelte component compiles to JavaScript with a compiler that Svelte owns, a Vue single file component compiles through the Vue plugin, and a JSX component compiles through a JSX transform. The work of turning markup into something an iframe can display is framework specific at the build step and framework agnostic at run time, which is exactly why the runtime is shared and the build integration is not.

The peer dependency configuration in the root package.json confirms the intent. The ignoreMissing list covers react, react-dom, vite, typescript, rollup, @babel/core and @types/react, and the pnpm overrides force every @whyframe package to the workspace version. In other words, the framework packages do not require a particular framework to be installed, which is what lets the same documentation site carry examples for several of them without pulling in all of them as dependencies.

The onlyBuiltDependencies list names @parcel/watcher, core-js, esbuild, sharp and vue-demi, the native or post-install packages that pnpm is allowed to run scripts for.

A pnpm monorepo with changesets and snapshot tests

The root package.json is a monorepo manifest, and the scripts tell you how the project is built and released.

The test script runs the unit tests and then the end to end tests. The unit run filters the workspace to every package except the test package and the monorepo root, and the end to end tests run from the tests/ directory. There is also a test:unit-update script with an update flag, which is the snapshot update path, and the fact that it exists as a first class script is a hint that there are snapshot assertions to regenerate when output changes.

The end to end tests are the interesting part for a project whose product is a rendered iframe. The unit tests can check that the generated markup is right, but whether a component actually renders inside a frame is a browser question, and the tests/ directory is where that is settled.

Formatting and linting run through Prettier across the file types the monorepo contains, with dedicated plugins for Astro and Svelte, and a cache. The documentation has its own dev and build scripts pointing at the docs/ directory, which is a VitePress site, and the playground/ directory is the development surface for the packages themselves.

Releases are handled with changesets. The ci-release-version script runs changeset version and then a small node script, scripts/fix-versions.js, which suggests the monorepo needs a post-version fixup step, most likely to keep the internal package references consistent after a version bump. Publishing is a separate script that runs changeset publish.

The root also pins pnpm at 10.33.0 as the package manager, and the repository carries a pnpm-workspace.yaml and a pnpm-lock.yaml.

What an iframe buys, and what it costs

The architectural choice of whyframe is to show rendered component output in a document of its own, and that has consequences in both directions.

What it buys is containment. A component with its own CSS cannot leak styles into the surrounding documentation page, and the page cannot leak styles into the component, which is the classic problem with embedding a live component in a documentation site. It also buys shareability, because an iframe of static markup is something you can put in a static site, an email or a chat message, and it is fast, because the rendering happens at build time rather than in the reader's browser.

What it costs is that the iframe is a separate document. A component that depends on the surrounding page, on a shared theme provider, on global state or on keyboard focus moving between the frame and the page, behaves differently inside a frame. And because the output is a build artifact, an example cannot be interactive with the surrounding page.

The library does not attempt to solve those problems, and the README does not claim to. It presents itself as a way to render framework markup inside an iframe, with flexible HTML customization and bundler integration, and the examples in the README are as simple as Hello world, which is an honest signal about the scope.

The alternative approach is to run the framework's own development server and embed a live component, which gives full fidelity and real interactivity at the cost of running an application for each example. The choice between the two is a trade of speed and simplicity against fidelity, and whyframe deliberately takes the first.

The people behind it, and where the documentation lives

The README closes with three credits that tell you something about the project's shape.

dominikg is thanked for casual chat and feedback, Jutanium for documentation feedback, and kiaking for the VitePress documentation design. The last of those is the significant one, since it means the documentation site is a designed artefact rather than a set of markdown files.

Funding is handled through a sponsor page on the author's own site, and the project is MIT licensed.

For a project in maintenance mode, the documentation matters more than usual, because that is where the knowledge lives now that the code is not changing. The docs directory in the repository is where that site is built, and the packages directory holds each package with its own changelog, so the per-package history is the best record of what each integration does and when it last changed.

The repository root is otherwise conventional: a .changeset/ directory for the changesets workflow, a .github/ directory, an .npmrc, Prettier configuration, a jsconfig.json for the JavaScript tooling, a scripts/ directory, and the LICENSE file.

If you are evaluating this for a team, the questions worth asking are narrow. Does the framework you use have a package, and is its version recent enough for your build? Does the iframe approach match how your components are consumed, particularly around styling and interactivity? And are you comfortable owning the project if the next thing you need is not there?

Editorial conclusion

whyframe suits a component library or documentation team that wants to show rendered output from several UI frameworks in one place, cheaply, without running each framework's dev server. It does not suit a team looking for a project that will gain features, because the README declares maintenance mode and the last push to the repository was on 2026-07-08. Check three things before you adopt it: that the framework you use has a package, that the version you install is one you can live with, since the core is at 0.2.1 and the framework packages are at 0.2.x and 0.3.x, and that an iframe is the right isolation mechanism for your use, since it buys style containment at the cost of a separate document. The MIT licence means you can fork it and carry on.

Frequently asked questions

Official sources

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