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

Nice to see Ruby vs Java. Must say that in this context Kotlin deserves a mention: my Kotlin code basically looks+feels like Ruby-with-types. Both Ruby and Kotlin are essentially OO, but with "lots of FP features where it makes sense".

On the side of the jpackage: I'm currently using GraalVM compile to native for a Kotlin CLI tool. I do the build in a build container so I use an older glib to ensure compatibility on a wide variety of Linuxes, AND because this way no-one needs to install all the GraalVM requirements by hand. The result is a 57MB binary, that start in a blink of the eye. The downside is long compile times (2 minutes for a simple CLI tool that uses AWS SDK). I think I prefer this of jpackage; but I'm not building a GUI tool.

Reality has types and identity. Static types just make sense.

That all being said, the JVM has never broken into local apps, even with JavaFx. I think the thought of installing a JVM, plus then installing an app is no longer a workflow most users will tolerate. Electron has proved though people don't mind downloading a multi-gig app anymore however, so maybe this is no longer an issue.

How is it surprising to people that zip and XML are in stdlibs for a programming language?

Btw, you should have looked at dotnet for this as well. There is a very good library ( DocumentFormat.OpenXml) that can handle all docx/xlsx/pptx files. And dotnet can ship standalone binaries (though AOT probably won't work).

Maybe it's because I don't know anything about how claude plugins work, but I find it odd that there's no actual TS code in the mentioned repo: https://github.com/LegalRabbit-AI/legalrabbit-docx-claude-pl...

There is a zip file of code in the releases though. I wonder if the LPGL 3.0 license covers that?

UPDATE: the zip file is just the repo itself. So everything interesting is in the legalrabbit-docx-mcp.exe, contained in the GitHub releases.

What a tease.

> MCPB

It's annoying when acronyms are used without explanation. It's https://github.com/modelcontextprotocol/mcpb , which looks a kind of installation bundle for MCP servers.

There's Apache POI which is intended for working with Office documents, so directly using XML parsers might not be necessary.

The MCPB format seems to be able to run external processes, even if there's a Node in the middle. So you could also compile the Java version to a native binary with GraalVM and ship that as an MCPB.

Sometimes I see things that make me reevaluate assumptions I make. I am all in on flexibility using LLMs and agentic coding harnesses: I hate feeling locked down to one platform.

Then I saw this in the article:

>> 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.

I don't know why this is so appealing to me but it is. I currently use Claude Code with a DeepSeek v4 Pro API backend. I will check out if Claude Code itself has MCPB support.

> I wrote a lot of Ruby back in 2010s. I felt Ruby was a beautiful language. Unfortunately, I don't feel that anymore.

Perhaps because he sucks.

It's easy to write ugly code in any language. You need to think, in order to write good code, in any language. Even then some languages are uglier than others. All my PHP code looks awful in comparison to my ruby code. Even with the same expertise level, the issue remains that PHP is just an uglier language. Similar comparisons can be made for many other languages.

> The biggest issue is no typing.

Well ... it's not. But it is pointless to try to explain this people whose brain is too addicted to "mama told me types must go into everything I touch".

> I worked at Stripe for 4.5 years, so I looked into integrating Sorbet

There you go! This already tainted his ability to THINK.

> Forgot .each in node.children.each do |x|. The error showed up as "unexpected nil" at a random place.

Erm ... how can you forget this while claiming you write a lot of code in ruby?

By the way, I almost never use the do/end synax. It helps me visually to use {}.

A side effect is that:

    def foobar(
        i = node.children
      )
      i.each {|element|
        check_for_cats_in_this_container(element)
      }
    end

will also be easier to visually notice missing things such as ".each" or ".map" or anything. Keep the structure simple at all times. And no, forgetting .each a lot - that is a bogus complaint. People using ruby for a little while don't really do such an error. But let's assume it is that way:

    def foobar(
        i = node.children
      )
      i {|element|
        check_for_cats_in_this_container(element)
      }
    end

Well, that visually already looks wrong. What method did you want to run on the variable i here?

> Forgot .children in node.children[i]. The error showed up as > "unexpected nil" at a random place.

Mate - use methods. The guy seems to have written only spaghetti code in ruby. Definitely not "4.5 years of writing ruby". Nah.

Also, "unexpected nil" - first, such an error does not exist, he probably means a nil. Second, why do you not check for nils properly? You don't need types for that. So the issue is you were lazy when writing the code. Understandable, but not a reason to "I need types" as compensation for your own laziness here.

> Using assert_raises in the test obscured a compilation error.

What compilation actually? Then again someone who forgets .each, already disqualified here.

>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.

Sounds like a project with awful documentation. This is a problem with many ruby projects. For some reason ruby projects hate documentation, with a few exceptions. I never understood this. To me it seems writing ruby is fun, then nobody wants to write documentation. That's really stupid of those people who do. Please look at rack. This thing has no real documentation that is useful. Same with opal and ruby-wasm. Ruby hates documentation. It's my number #1 complaint too.

I am fine with those admitting to this problem. Who I can not stand are the "the code is self-explanatory". This always leads me to assume the code is utter garbage. And this indeed is almost always the case so.

> 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.

Or it is a fake story. Is this AI generated text? The guy makes up things on the fly.

People, please - stop using AI. It will slop zombify your brain.