Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin
Sign in
Subscribe
Summary
I've built a Claude Cowork DOCX plugin in Ruby, Java, and TypeScript.<br>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.<br>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.<br>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, I've implemented the same Cowork DOCX plugin 3 times. The first prototype was in Ruby. I reimplemented it in Java in order to make it a desktop app. Then, I reimplemented it in Typescripts (Node) in order to make it compatible with MCPB. Eventually, I've switched to Bun because Cowork plugin apparently doesn't support MCPB.<br>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.<br>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.<br>💡<br>If anyone is interested in using our DOCX plugin with Claude Cowork, you can try it out here: https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-plugin
The plugin is still in its nascent stage. I'd love for you to drop us an email at tanin@legalrabbit.ai, so we can help you and notify you when there's an update.
Ruby<br>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.<br>The biggest issue is no typing.<br>I worked at Stripe for 4.5 years, so 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.<br>Here were some common errors that I encountered:<br>Forgot .each in node.children.each do |x|. The error showed up as "unexpected nil" at a random place.<br>Forgot .children in node.children[i]. The error showed up as "unexpected nil" at a random place.<br>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.<br>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.<br>In terms of processing a zip file and XMLs, I used:<br>rubyzip: it has an obbscure 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.<br>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.<br>Java<br>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.<br>I have my fair share of building a Java desktop application and know jpackage and alike very well (See: my Java electron framework).<br>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.<br>The final single-executable binary is about 88MB. It is 88MB because a JDK is embedded inside.<br>I used AI to port the code. It took only 3 days to port thousands of lines of code.<br>TypeScript<br>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.<br>With TypeScript, I have to use the following libraries for processing zip files and XML:<br>fflate for processing zip files. It works as expected.<br>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.<br>I used AI to port the code from Java to TypeScript. It only took 1.5 days to do.<br>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<br>Claude plugin only supports a single-executable binary. Node doesn't have...