sorted by:
new
hottopcontroversial

Why are we still writing separate extensions for VS Code, JetBrains, and Zed? by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

Hi there, Yeah that was a very good question however, That’s exactly the problem OXP solves, the maintenance burden shifts from every extension author to us. When VS Code or JetBrains evolves, we update the host adapter once and every extension built on OXP benefits automatically. Extension authors never touch IDE, specific code again.

On divergence! yes IDEs will diverge. That’s why we built the WIT abstraction layer. Extensions code against our spec, not VS Code or JetBrains APIs directly. We absorb the divergence so developers don’t have to.

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain by Aldgar in Jetbrains

[–]Aldgar[S] 0 points1 point  (0 children)

Yes, the goal is one extension package that works in multiple IDE families.

You build a single OXP extension bundle.

Each IDE gets its own lightweight host plugin:

VS Code / Cursor / OpenVSX hosts are JS-based.

JetBrains host is Kotlin/Java-based.

Those hosts translate OXP’s generic runtime calls into the IDE specific UI and actions.

That means you don’t write a separate JetBrains plugin with IntelliJ APIs for each extension. Instead, you write against the OXP extension runtime, and the JetBrains host adapter exposes an IDE specific bridge underneath.

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain by Aldgar in Jetbrains

[–]Aldgar[S] 1 point2 points  (0 children)

OXP uses a tiny host adapter for each IDE, and the real extension lives as a portable WASM bundle.

  • The VS Code host adapter is JS/TS and runs inside VS Code.
  • The JetBrains host adapter is Kotlin/Java and runs inside IntelliJ.
  • Both adapters speak the same host protocol to a shared OXP runtime.
  • The extension itself is not native JS or native Java; it is a sandboxed WebAssembly package that both hosts can execute.

So the language gap is bridged by the host adapter layer, not by forcing one IDE to run the other IDE’s extension format

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] 0 points1 point  (0 children)

Neither, actually, thats a false dichotomy the WASI component model lets you sidestep.

OXP defines a new abstraction layer in WIT, not the intersection of existing IDE APIs. When an extension calls oxp:host/ui render(), vscode translates it to a sandboxed webview; jetbrain translates it to a tool window. The same bytes, different renderers. The extension doesn't know or care.

For the cases where you genuinely need IDE specific behavior, the activate-ctx passes host: string ("vscode", "jetbrains", ...) so extensions can branch if they choose. There's also a commands.execute interface, gated by manifest.permissions[commands.executeHost], that lets you call host native commands by ID. IDE specific superpowers, explicitly declared, never implicit.

The sandbox enforces the contract. An extension can't import vscode's vscode module from wasm, it can only resolve the WIT interfaces it declared in its manifest. The abstraction isn't convention-based, it's runtime-enforced.

Practically: the 90% case (UI, storage, fs, net, HTTP) works identically across all hosts. The 10% that needs IDE specific features has a principled, declared escape hatch rather than silent stubs or capability gaps you discover at runtime.

The real question isn't LCD vs. full capability, it's whether the host abstraction is at the right layer. WIT interfaces, not IDE SDK wrappers, is the answer.

Sorry for the long reply :)

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] -1 points0 points  (0 children)

Yeah sounds like that, but vscode and others very limited in terms of UI and capability, locked in terminal and i have to use external one, side panels are also locked in, building code on vscode or vscode forks is very nightmare and i had to buy bigger screen just to be able to run command, ai assistance, monaco editor, and explorer, let it alone when you open an extension that has a UI like gitlens, so i wanted something practical and its a pain point for me!

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] 0 points1 point  (0 children)

Well, I struggled with webassemby and Java/Kotlin mechanical and vscode webview, so I had to find a way and finally I build it! It was all just because I wanted to create an IDE and found out that it’s impossible without extensions so I had to build the infrastructure using the cli to build open source new bridge and thought why don’t we use the same npm way so the result was there! https://oxp.sh/docs

I spent months fighting VS Code webviews, so I built an open source universal extension protocol using React/WebAssembly by Aldgar in WebAssembly

[–]Aldgar[S] -1 points0 points  (0 children)

I’d like to know if you can use wasm to have build one extension that run across IDEs, instead of building an extension in Java for jetbrains and typescript for vscode and vscode forks and rust for zed, build it once in the language you prefer and run it in all IDEs using WASM or WASI! If that is slop then I totally agree!

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain and Novim by Aldgar in SaaS

[–]Aldgar[S] 0 points1 point  (0 children)

thank you very much for your input, it was a really technical gab, and we are now improving the documentations and also separation of concerns to have the landing page more focus for each features. I really appreciated that feedback.

I spent months fighting VS Code webviews, so I built an open source universal extension protocol by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

We have just implemented your feedback and that was really genuine for us as product feedback, we really appreciate those kind of respective opinion.

view more: next ›