Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin

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.

Ruby

At first, I built a prototype in Ruby because my colleague knew Ruby well, and we wanted it to a server-side application. I wrote a lot of Ruby back in 2010s. I felt Ruby was a beautiful language. Unfortunately, I don't feel that anymore.

The biggest issue is no typing. I looked into integrating Sorbet; it was a bit too involved, so I didn't do it. I also looked at RBS but couldn't understand how to integrate it. Admittedly, I didn't spend too much time on this.

Here were some common errors that I encountered:

• Forgot .each in node.children.each do |x|. The error showed up as "unexpected nil" at a random place.
• Forgot .children in node.children[i]. The error showed up as "unexpected nil" at a random place.
• Using assert_raises in the test obscured a compilation error. The assert_raises would just complain the error doesn't match the expected error. I had to comment out assert_raises to see the error stacktrace.
• I used ruby_llm-mcp where the doc mentioned tool.input_schema but the latest version has renamed it to tool.params_schema (issue). It took me a while to figure out since there was no typing hint to help me with it.

In terms of processing a zip file and XMLs, I used:

• rubyzip: it has an obscure bug where it produced a corrupted DOCX file. I've encountered this bug with a DOCX file from our customers. I can't share the confidential file to the rubyzip author. I tried to reproduce the file but failed to do so. Therefore, the bug cannot be solved.
• nokogiri: it also has a non-blocking bug where it doesn't format XML correctly. The bug is actually from the native library libxml2. Therefore, it's not exactly a bug for nokogiri to solve.

Java

After some time, we've decided that we want a Claude Cowork plugin instead. A Claude plugin supports executing a binary locally, so I've chosen Java for it.

I have my fair share of building a Java desktop application and know jpackage and alike very well (See: my Java electron framework).

What surprised me was that Java supported processing zip files and XML from their standard runtime. I didn't encounter any issue with the zip and XML library at all. It works as expected.

The final single-executable binary is about 88MB. It is 88MB because a JDK is embedded inside.

TypeScript

Later, I've discovered that Claude Desktop supports MCPB. The MCPB provides a Node runtime. Therefore, our application would only contain our code. This means the size of the application would be ~1MB.

With TypeScript, I have to use the following libraries for processing zip files and XML:

• fflate for processing zip files. It works as expected.
• xmldom for processing XML. Because I need DOM API. It works as expected except that it doesn't support pretty-print XML. Its rationale is that pretty-print is out of scope because XML is used for transporting/serialization. Plus, there's no standard for pretty-printing XML. See this issue.

MCPB is great. However, to operate our DOCX MCP, we need an accompanying skill. Claude Desktop supports this through Claude plugin where both skills and MCPs can be packaged together. However, Claude plugin doesn't support MCPB :S

Claude plugin only supports a single-executable binary. Node doesn't have this feature. Fortunately, Bun has, and it works as expected.

The only gap with Bun is that I cannot figure out how to upload the source map to PostHog because PostHog requires both the minimized JS file and the .js.map file.... but Bun only produces the binary and the .js.map file.

The final file size is ~70MB on Mac and ~120MB on Windows.

In the end, I've decided to stick with TypeScript because of the possibility of MCPB being supported in Claude/Codex plugin.

Thoughts on Codex

I was looking at making a Codex plugin but Codex is behind Claude Desktop in terms of the plugin mechanism.

Claude supports the environment variable: CLAUDE_PLUGIN_ROOT , and that enables me to execute the single-executable binary as the stdio MCP server.

Codex doesn't have it. Their plugin structure has a folder for binaries but their doc doesn't mention how to execute the binary in that folder. I tried a couple possible paths but couldn't make it work.

Conclusion

Java is the winner for me. However, as I mentioned earlier, I've decided to stick with TypeScript due to the possibility of future MCPB support without embedding the Node runtime.

Ignoring the possibility of the embedded Node runtime, Java's strict typing makes it easier to code. The Java's built-in libraries for zip and XMLs work as expected.

The maturity of the Java runtimes on both Windows and Mac gives me more confident compared to Bun, which is quite new. To be fair, so far I haven't encountered any issue with Bun apart from being unable to upload source maps to PostHog. Our Bun-built Claude plugin seems to work well on both Mac and Windows.