I got tired of the fact that every time a developer wants to launch a tooling product, they have to write it three separate times: once in TypeScript for VS Code, once in Java/Kotlin for JetBrains, and again in Rust for Zed.
It feels like an absolute waste of engineering hours. The IDE landscape has evolved, but the way we build extensions is stuck in a fragmented past.
To try and solve this for myself, I've spent the last few months building OXP (Open Extension Protocol). It’s an open source infrastructure layer designed to let you build an extension once and run it across any host editor.
How the Architecture Works Under the Hood: Instead of trying to map complex, bloated editor's specific APIs directly, OXP decouples the extension from the host entirely:
The Component Model: Extensions are compiled into WebAssembly (WASM) components using WebAssembly Interface Type (WIT) files to define strict boundaries.
The Communication Layer: A JSON RPC protocol handles the asynchronous communication bridge between the isolated WASM guest runtime and the native IDE host adapters.
Sandboxed Execution: Because the plugins run in a lightweight WASM sandbox, a buggy or malicious extension can't crash the entire editor thread, leak memory, or steal local environment variables.
The Current State & The VSX Wedge: Right now, I have host adapters running for VS Code and JetBrains.
To bridge the "chicken and egg" ecosystem problem, I’ve also been hacking on an internal translation layer. Using a jco backend to execute JavaScript from WASM components inside a background Node process, I’m building a compatibility shim that intercepts require(vscode) calls from standard Open VSX .vsix packages.
By mapping basic namespaces (window.showInformationMessage, workspace.fs, commands), I can get about 20% of existing, lightweight VS Code utilities running natively inside JetBrains right now. The other 80% the heavy language servers and complex WebViews is the long term mountain to climb.
Where I Need Your Brutal Feedback: This is a massive undertaking for a solo developer, and the WIT boundary definitions are incredibly tricky to get right. I would love to hear from other tool authors or engine developers:
Is the performance and UI rendering overhead of a universal JSON RPC/WASM layer too high a price to pay for cross platform portability?
What core editor APIs should be prioritized next in the WIT definition to make this genuinely useful for your workflow?
The codebase is completely open, and I’d appreciate your realistic, brutal architectural critiques.
Top comments (0)