GoKawiilWe've built a Claude Cowork DOCX plugin in Ruby, Java, and TypeScript. Java is the winner for supporting zip files and XML in its runtime with no issues. However, TypeScript is chosen due to the possibility of MCPB support.
We've built a Claude Cowork DOCX plugin in Ruby, Java, and TypeScript.
Java is the winner for supporting zip files and XML in its runtime with no issues. Java's libraries seem most mature compared to Ruby's and JS's. The static typing really makes it easier to write.
However, TypeScript is eventually chosen due to the possibility of future MCPB support, which will eliminate the embedded runtime and reduce the binary size by 99%.
Codex's plugin mechanism is lagging behind Claude's. It doesn't support an equivalent of CLAUDE_PLUGIN_ROOT and seems impossible to execute a binary inside the plugin.
Bun has been chosen for building a single-executable binary. One gap is that I cannot figure out how to make its source maps work with PostHog.
Recently, we've implemented the same Cowork DOCX plugin 3 times. The first prototype was in Ruby. We reimplemented it in Java in order to make it a desktop app. Then, We reimplemented it in Typescripts (Node) in order to make it compatible with MCPB. Eventually, We've switched to Bun because Cowork plugin apparently doesn't support MCPB.
Since now I have direct experience in implementing the same app in 3 different languages within a span of a month, I've decided to write about it.
For context, a DOCX file is actually a zip file with a bunch of XMLs and other files in it. Therefore, our code must process zip files and XMLs.
💡
... continue reading