Vscode Extension Why
Why a VS Code Extension? The Case for Meeting Developers Where They Are
_On tool distribution, friction, and the SiaS model_
The distribution problem nobody talks about
You can build a great tool. Put it on the web. Make it fast, free, offline-capable. And it still might not get used — not because it's bad, but because it requires a context switch.
A developer working in VS Code has a CSV file open. They need to visualize it as a table. The friction path: stop what you're doing, open a browser tab, navigate to the tool, paste the content, work in the browser, copy the result back. Six steps. None of them hard. All of them annoying enough that most people just... don't.
The VS Code extension removes all six steps. Right-click the CSV → "Open with Table Formatter." The table is there, in the editor, next to the code. Work done without leaving the environment.
This is the core argument for VS Code extensions: zero context switch.
Why not just build a VS Code extension from scratch?
Because the web tool is already the best version of the product.
The browser gives you things a VS Code extension can't easily replicate: a larger canvas, a more flexible layout engine, simpler CSS, no Electron sandbox constraints, no CSP headaches. My tools are visually complex — TAFNE has a node editor with a canvas renderer, the Schema Editor is a full SVG drawing tool. Building those from scratch inside VS Code's constraint set would take months and produce a worse result.
The approach I took: the VS Code extension is a thin shell around the existing web tool. The SPA loads directly as the webview document. Path rewriting happens at open time. A bridge script replaces the embedding detection. The tool code doesn't know it's in VS Code — it thinks it's in a browser. Because it basically is.
This means improvements to the web tool automatically improve the extension. One codebase. Two distribution channels.
The SiaS layer
There's a concept worth naming here: Software-in-a-Service (SiaS). It's distinct from SaaS.
SaaS sells access to software. The software lives on a server. You pay for API calls or seats.
SiaS sells structured context that AI agents consume. The software runs locally — offline, private, deterministic. The paid layer is the AI capability that sits on top: smarter extraction, schema analysis, agent orchestration. But the underlying tool works fully without it.
For Ginexys, this means:
- Table formatting, node editor, lab mode → free, offline, no account
- Schema rendering and export → free, offline, no account
- PDF geometry extraction → free, offline, no account
- AI-powered PDF extraction (Docling) → paid, cloud
- GINEX Agent schema analysis → paid, cloud
- MCP tools in Copilot/Cursor/Cline → requires account (free tier: 3 tools)
vscode.lm.registerTool) is what makes Ginexys available to AI agents inside the editor — without the user having to copy-paste or describe their data. The agent just reads the table or the schema directly.
Why Extension Pack + satellites?
The alternative is one monolithic extension. The problem with that: install friction scales with package size, and update cadence is coupled. If I update the PDF processor, TAFNE users get a forced update for code they don't use.
The Extension Pack model solves both. Install the pack (ginexys) and you get all four. Or install just ginexys.tafne if tables are all you need. Each satellite can ship on its own cadence. The core extension (ginexys.core) handles auth and shared utilities — you always have the latest version of that without caring which satellites you've installed.
It also means Marketplace SEO works better. ginexys.tafne shows up when people search "CSV editor VS Code" or "table formatter VS Code". A monolithic "Ginexys Developer Tools" doesn't surface for any specific query.
The mode command insight
One concern I had about porting: on the web, users discover modes naturally. The three-tab layout is always visible. In VS Code, the webview is tucked inside a panel — users might open TAFNE, see the table editor, and never find the Node Editor or Lab Mode.
Splitting into three separate extensions sounds like the answer. But TAFNE's source isn't modular at that level — it's jQuery globals all sharing state. Splitting would mean weeks of refactoring for marginal benefit.
The better answer: mode commands in the Command Palette. Ginexys: Open Node Editor is discoverable via Cmd+Shift+P. It opens the same webview but activates the right tab immediately. The command name IS the product description. Someone searching "node editor VS Code" finds it.
Eleven mode commands across three tools. No source refactoring. Full discoverability.
The notebook insight
The live sync feature revealed something I hadn't planned.
When you open a .md file and TAFNE watches it, fenced code blocks become interactive sheets:
<pre><code></code></pre>csv name,revenue,growth Product A,120000,0.23 Product B,85000,0.15 <pre><code></code></pre>
That block is a live table in TAFNE. Edit a value in the CSV fence in VS Code — the table updates in 300ms. Add a second \\\json` block — a second sheet appears.
This is a data notebook. Not by design, but by logical extension of the architecture: VS Code text editor as input, TAFNE as renderer, fenced blocks as sheet separators. The web tool gains a capability that wouldn't make sense in a browser context, because in a browser you don't have a side-by-side text editor.
Extensions aren't just a distribution channel. They enable product experiences that the web version can't.
_Ginexys is available at ginexys.com. The VS Code extension is coming to the Marketplace soon. Follow the build at @GINEXYS._