Honestly, I haven't done a proper performance benchmark yet. Most of my WebGPU shaders were generated via "vibe coding" (heavily AI-assisted) to prioritize rapid architectural verification over deep kernel optimization. So, jax-js or ONNX Runtime would likely outperform Kandle in raw speed at this stage.

However, it’s hard to put aside "API preference" because that is the core feature. The real value of Kandle isn't just the syntax, but the workflow compatibility.

For example, when I implemented Qwen3 or Whisper, I could practically "copy-paste" the logic from the official HuggingFace transformers Python repository into TypeScript. You don't have to re-think the model as a static graph or adapt to a different paradigm—if it works in PyTorch, you already know how to build it in Kandle.

Beyond that, Kandle is aiming for a "batteries-included" ecosystem. We already have built-in support for Safetensors and torchaudio transforms, so you can handle the entire pipeline from loading weights to audio pre-processing (like Mel Spectrograms) without leaving the framework.

So while jax-js is great for high-performance numerical apps, Kandle is for the developer who wants to bridge the gap between Python research and Web deployment with zero cognitive overhead.