[feat] Language-Independent Extension API

[asqarslanov]

Describe the problem

Currently, KunKun’s plugin system only supports JavaScript. Which is actually a great choice since:

1. JS is one of the most well-known programming languages, with a large ecosystem and great tooling support.
2. It is the most mature language when it comes to building web-based GUIs, which are essential for Custom UI Commands.

However, limiting the platform to a single language also has its cons. For example:

1. Different programming languages have different libraries and capabilities, some of which may not be available in other ecosystems.
2. Some developers may just not be familiar with JavaScript (or they may simply not like it).

This makes developing extensions for KunKun less joyful, and some people may just give up on the idea of building their plugin.

Describe the solution you'd like

It would be really great to support other programming languages for building extensions.

One way to achieve this is to use Extism—a tool specifically designed to build WASM/WASI-based plugin systems. It should align well with KunKun’s current design because of its focus on security: porting the existing permissions and commands to Extism shouldn’t be very difficult.

To achieve type-safety and IDE support, language-specific wrapper libraries may be created. Initially, a JS/TS library would suffice. Then, (possibly, with the help of the community), other languages may also get type-safe bindings. But even without them, Extism would allow building plugins in any language supported by Extism itself.

Alternatives considered

No response

Additional context

1. I’m not sure about that, but Custom UI Commands might already support any front-end frameworks that can compile to the web, not limited to the major JS ones (e.g. Leptos, Blazor). If that’s the case, it would be really nice DX to be able to access KunKun’s API in almost any programming language when building a UI extension.

2. Adding support for many programming languages will make it difficult to review extensions before adding them to the extension store. One way to deal with this (not the best one, though) is to only publish extensions written in certain languages and simply leaving plugins in other languages available to be installed manually. TBH, I don’t really like this point, since even with a single language it’s perfectly possible to write big/complex/cryptic code for an extension so that no one else can review it.

3. Similar to the previous point, allowing multiple languages will inevitably fragment the ecosystem and people will have difficulties contributing to other’s extensions. I don’t really think this is that big of a problem, though: very few people are willing to contribute to small extensions anyways, it’s often just easier to start a new plugin from scratch.

Contributes

• I am willing to submit a PR to implement this feature

[HuakunShen]

Thank you for your interest in this project and your thoughtful suggestions!

The idea of using Extism to build a WebAssembly (WASM)-based extension system is indeed intriguing. I actually considered WASM early on but decided against it at the time due to my limited familiarity with it and concerns about its practical integration. Including a WASM runtime like Wasmer or Wasmtime would increase the bundle size by approximately 40 MB, but it might be acceptable if everything runs within a WebView without an extra runtime.

Although I’ve heard of Extism, I haven’t had the chance to explore it in-depth yet. It looks very promising, and I’ll definitely keep it in mind for future development. However, since I’ve already invested significant time in this project and am currently focused on preparing for a formal release—including creating YouTube videos for an introduction and user guide—I don’t have the bandwidth to explore it thoroughly right now.

With almost no users so far 😂, I feel that adding support for additional languages may not be worth the immediate effort. However, if the app gains traction, I’m very interested in revisiting the idea. I also have plans to implement a graphical extension composer similar to Alfred’s workflows—though that will depend on user adoption.

I’m happy to continue discussing the feasibility and technical details with you! Are you experienced with WASM and Extism? Your insights would be valuable.

[asqarslanov]

Thank you for your reply! I’m glad you’re open to this idea. Of course, this isn’t a high priority for now. May be a plan for a potential v2.0 🙃.

As to my experience, I’ve only tried to build a really simple hello-world-ish app with Extism, which was actually pretty easy. The whole idea of plugins in Extism revolves around “host functions” (functions defined by the application with a plugin system) that can be called from plugins (e.g. to access system APIs, not available in WASM by themselves).

[asqarslanov]

By the way, until it’s not too late. If KunKun wants to eventually support a new extension format, it needs to decide whether the current JS-only extensions are still going to be supported. For example, extensions may be required to have an API version field in the manifest, so that KunKun may distinguish between different types of plugins.

[HuakunShen]

By the way, until it’s not too late. If KunKun wants to eventually support a new extension format, it needs to decide whether the current JS-only extensions are still going to be supported. For example, extensions may be required to have an API version field in the manifest, so that KunKun may distinguish between different types of plugins.

The current JS version will be supported for sure.
For now it uses @kksh/api in dependencies field to find the API version.
Later I could add a field like mode, or language to distinguish between different types of plugins.

[HuakunShen]

It seems like extism cannot run in browser. Many Kunkun APIs like fs, dialog are re-exports from tauri's official API, implementing all APIs again with Extism host function in Rust will be a lot of work.

I tried adding extism to the app. On Mac, it increased .app from 50 to 64MB, and .dmg from 20 to 24MB.
This increase in size is lower than I expected.