Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin
Recorded: May 28, 2026, 12:01 p.m.
| Original | Summarized |
Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin tanin About Sign in Subscribe By tanin Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin Summary 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.💡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-pluginIt works well with legal documents, and you can use it together with the Claude for Legal 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.RubyAt 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 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.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.JavaAfter 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.I used AI to port the code. It took only 3 days to port thousands of lines of code.TypeScriptLater, 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. I used AI to port the code from Java to TypeScript. It only took 1.5 days to do.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 :SClaude 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 CodexI 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.ConclusionJava 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. Previous issue Subscribe to tanin jamie@example.com tanin © 2026 Powered by Ghost |
The author describes an experience building a Claude Cowork DOCX plugin using Ruby, Java, and TypeScript, emphasizing the technical trade-offs involved in choosing a development language for a task that requires processing zip files and XML data inherent in a DOCX file structure. Java emerged as the initial winner because its standard runtime effectively supported the processing of zip files and XML without encountering issues, and the associated libraries were perceived as more mature than those in Ruby or JavaScript, further enhanced by the benefits of static typing for error reduction. In contrast, TypeScript was ultimately selected due to future compatibility considerations surrounding the hypothetical MCPB support. The rationale was that TypeScript allows the application to potentially eliminate the embedded runtime, which could reduce the binary size by 99 percent. Although TypeScript required the use of external libraries such as fflate for zip processing and xmldom for XML manipulation, the author successfully ported code from Java to TypeScript, a process taking only about one and a half days. Although the Claude plugin itself did not support MCPB, the author opted for TypeScript because the potential for future MCPB support was deemed advantageous. Ruby was explored first, primarily due to familiarity with the language, but the author found that the lack of typing introduced significant challenges. The development process in Ruby involved encountering numerous errors related to null pointers and difficulties in utilizing assertion methods, and the underlying libraries for handling zip and XML, such as rubyzip and nokogiri, presented specific bugs or limitations concerning file corruption and XML formatting. Bun was considered for its ability to build a single-executable binary; however, the author noted a remaining difficulty in integrating source maps with PostHog, which is a requirement for certain debugging tools. While Java proved technically robust for handling zip and XML natively, the author favored TypeScript because of the strategic advantage offered by potential future architectural changes related to MCPB support, viewing the strict typing of Java as a secondary benefit over this long-term compatibility goal. The experience highlights a balancing act between immediate technical stability (Java) and long-term architectural flexibility (TypeScript). |