May 28, 2026
Zip drama, XML tears
Ruby vs. Java vs. TypeScript: my experience on building a Cowork DOCX plugin
Java won the battle, but the comments turned it into a full-blown language war
TLDR: The developer says Java handled Word files best, but TypeScript was chosen because it could make the app dramatically smaller later. Commenters turned that into a food fight over missing explanations, overlooked tools, and which language should have won instead.
A developer built the same document-editing tool three times — first in Ruby, then Java, then TypeScript — and somehow the real chaos didn’t come from the code, but from the crowd watching it unfold. The article’s big reveal is deliciously messy: Java was the easiest and most reliable choice for handling Word files, but TypeScript got picked anyway because it may lead to a much smaller app later. Translation for normal people: the sturdy minivan won the road test, but the flashy compact car got the final rose because it might save space down the line.
The comments immediately went feral. One camp was baffled that anyone found it surprising Java already includes built-in support for zip files and XML, with one commenter basically saying, why is this even news? Another group jumped in with armchair coaching: why not use Apache POI for Office files, why not ship Java differently, and while we’re at it, why wasn’t .NET invited to this party? Ruby took some of the roughest hits, with the author’s complaints about confusing errors and weak type checking feeding a familiar internet pile-on.
And then there was the acronym drama. A commenter had to stop the whole conversation to explain that MCPB is basically a packaging format for AI tool add-ons, because apparently everyone was expected to know that already. The funniest vibe in the thread? Equal parts nerd rage, backseat driving, and “actually, my favorite language would have fixed this in one weekend.”
Key Points
- •The author implemented the same Cowork DOCX plugin in Ruby, Java, and TypeScript/Node within about a month, later switching packaging to Bun.
- •Java is described as the strongest option for this use case because its runtime handled ZIP and XML processing without issues and its libraries appeared most mature.
- •Ruby was used first but the author reports debugging difficulties related to missing typing, along with library issues involving rubyzip and Nokogiri/libxml2.
- •TypeScript was ultimately chosen because possible future MCPB support could eliminate the embedded runtime and reduce binary size by roughly 99%.
- •The article says Codex's plugin mechanism lacks capabilities available in Claude's plugin system, including an equivalent of CLAUDE_PLUGIN_ROOT and apparent support for executing a binary inside a plugin.