I built a live React playground inside VS Code — no dev server required

Debabrata — Mon, 20 Jul 2026 03:31:49 +0000

How many times have you wanted to see just one component render — and ended up starting a dev server, or pasting code into CodeSandbox? I did that once too often, so I built ReactCanvas, a VS Code extension that turns any .jsx/.tsx file into a live playground. No terminal, no localhost, no leaving the editor.

The problem: component preview friction

The gap between "I wrote a component" and "I can see it" is embarrassingly wide for how routine that task is.
Say you're building a <PriceTag /> in isolation. Your options today:

Spin up the dev server. Now you're waiting on a cold Vite/webpack start, routing to the right page, and mounting the component inside your whole app just to look at one thing.
Reach for CodeSandbox / StackBlitz. Great tools, but you've left your editor, lost your project's context, and you're copy-pasting code back and forth.
Write a throwaway story or scratch route and delete it later. Everyone's done it. Nobody enjoys it.

Each of these is a context switch, and context switches are where flow goes to die. What I wanted was dumb and obvious: put my cursor in a component file, hit a shortcut, and see the thing — rendered, interactive, hot-reloading — right next to the code.
That's the whole pitch. ReactCanvas opens a preview panel beside your file and renders whatever component it exports, live as you type.

How it works

The core loop is: read the file → transpile it in memory → render it in a sandboxed iframe → repeat on change. No files hit disk, and nothing runs a Node build.

Transpile with esbuild-wasm. The heavy lifter is esbuild-wasm, running entirely in the browser context of the webview. When your file changes, ReactCanvas hands the source straight to esbuild's transform API — JSX and TypeScript in, plain JS out — in single-digit milliseconds. Because it's WASM, there's no separate Node process to spawn or keep warm, which keeps the extension light and the first render fast.

Babel as a fallback. esbuild-wasm is fast but deliberately narrow — it transforms, it doesn't do everything Babel does, and occasionally a file leans on syntax or a transform esbuild won't take. Rather than fail the preview, ReactCanvas falls back to @babel/standalone for those cases. You get a slower but more forgiving path instead of a red screen. Most files never touch it; the ones that do still render.

Imports via esm.sh and an import map. The transpiled code still says import React from "react" — so where does React come from with no bundler and no node_modules in the loop? An import map. ReactCanvas injects a map that points bare specifiers at esm.sh:

<script type="importmap">
{
  "imports": {
    "react": "https://esm.sh/react@18",
    "react-dom/client": "https://esm.sh/react-dom@18/client"
  }
}
</script>

Security: this runs arbitrary code in your editor

This is the part I'd want to read about if someone else had built it, so I'll be direct: a live playground means executing whatever code is in the file, inside VS Code, on your machine. That deserves real isolation, not a shrug.
Two layers do the work.
A sandboxed iframe. The rendered component never runs in the webview's own context. It runs in a nested <iframe sandbox="allow-scripts"> — enough to execute React, nothing more. No same-origin access back to the webview, no top-level navigation, no popping windows. If your (or a dependency's) code does something nasty, it's boxed in.
A strict CSP with per-load nonces. VS Code webviews are already locked down, but the preview generates HTML on every reload, so the Content-Security-Policy is generated with a fresh nonce each time and only scripts carrying that nonce are allowed to run:

<meta http-equiv="Content-Security-Policy"
      content="default-src 'none';
               script-src 'nonce-{NONCE}';
               style-src {webview.cspSource} 'unsafe-inline';
               connect-src https://esm.sh;">

default-src 'none' means everything is denied unless explicitly re-allowed, connect-src is narrowed to the CDN the import map actually needs, and the nonce makes injected <script> tags inert. For an extension that lives inside your editor, "assume the rendered code is hostile and contain it" felt like the only responsible default.

Interesting problems I hit

1. Debouncing reloads without feeling laggy. Transpiling on every keystroke means transpiling mid-token — you type <div, esbuild sees invalid JSX, the preview flashes an error, and by the time you finish the tag it's gone. It looks broken even though nothing is. The fix was a trailing-edge debounce on file changes (300ms) so a burst of typing collapses into one rebuild after you pause. The subtlety: when a rebuild does fail, keep the last good render on screen instead of blanking it, so a transient syntax error while typing never wipes what you were looking at.
2. Error overlays with the right line numbers. When a runtime error throws, the stack trace points at the transpiled output, not your source — and JSX/TS transforms shift line numbers around, so "error on line 12" in the compiled code might be line 8 of what you wrote. Useless. The answer was to keep esbuild's sourcemap from the transform step and map the thrown error's position back through it before rendering the overlay. Now the error points at the line you'd actually go fix, which is the entire point of an error overlay.
3. Theme-aware chrome.A preview panel that's blinding white while your editor is dark is jarring. Rather than ship my own theme, the playground's UI is styled entirely with VS Code's own CSS variables — var(--vscode-editor-background), var(--vscode-editor-foreground), and friends. That means it inherits your theme automatically, including light, dark, and high-contrast, and it follows along the instant you switch themes without ReactCanvas knowing or caring which one you picked.

Limitations & roadmap

Being upfront: today ReactCanvas previews a single file. If your component imports a sibling ./Button or a local helper, v1 can't resolve it — bare npm specifiers go through the import map, but relative project imports don't yet.
Multi-file imports are the headline feature for v2. The plan is to walk the local import graph, transpile the dependencies alongside the entry file, and stitch them into the same in-memory module system so ./Button just works. That unlocks previewing real components instead of only self-contained ones, and it's the thing I most want for my own use.

Try it

ReactCanvas is on the VS Code Marketplace (publisher debabrata100) — search "ReactCanvas" in the Extensions panel, or grab it here:

Marketplace: https://marketplace.visualstudio.com/items?itemName=debabrata100.reactcanvas
Repo: https://github.com/debabrata100/reactcanvas

If you try it, I'd love feedback — especially on the transpile fallback and where multi-file resolution would help you most. What's the first component you'd point it at? Drop a comment, and a ⭐ on the repo helps me prioritize v2.