Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tanin.nanakorn.com

Post reply on HN
Print view View original

11–20 of 51 posts

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

#11

Post by pier25 »

martinald wrote: post #6

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

Many runtimes/languages rely on third party deps for that. Also plenty of devs think the stdlib should be as lean as possible.

Personally, I think there should be a balance. The direct consequence of a barebones stdlib is NPM and having to download hundreds of dependencies for a hello world.

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

#12

Post by flossly »

pjmlp wrote: post #10
flossly wrote: post #5

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…

Many of those "lots of FP features where it makes sense". were already present in Smalltalk. Especially anything related to lambdas, map, filter and co. Something that was lost in most OOP languages that followed suit, until like a decade later.

> Many of those "lots of FP features where it makes sense". were already present in Smalltalk.

Good point. And both Java and Ruby borrowed from Smalltalk (according to Wikipedia Kotlin does not, but that is: not directly.

Sadly Java did not take Smalltalk's FP inspiration (I guess they were strayed by C++'s lead in that regard), and we needed streams and now Kotlin to fix that :)

Smalltalk's syntax never go really popular though. One could say that was its biggest drawback.

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

#13

Post by jondwillis »

mark_l_watson wrote: post #8

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 kno…

> I will check out if Claude Code itself has MCPB support.

It doesn’t.

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

#14

Post by CharlieDigital »

martinald wrote: post #6

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

https://github.com/dotnet/Open-XML-SDK

First party from Microsoft; feels like it would be the way to go.

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

#15

Post by mring33621 »

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.

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

#16

Post by srcreigh »

vintagedave wrote: post #2

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

Some more info from the link:

> MCP Bundles (.mcpb) are zip archives containing a local MCP server and a manifest.json that describes the server and its capabilities. The format is spiritually similar to Chrome extensions (.crx) or VS Code extensions (.vsix), enabling end users to install local MCP servers with a single click.

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

#17

Post by exabrial »

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.

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

#18

Post by smrtinsert »

exabrial wrote: post #17

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.

Bitwig and Intellij stand out to me

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

#19

Post by rjrjrjrj »

martinald wrote: post #6

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

Difficult to square the author's surprise with the later comment "I have my fair share of building a Java desktop application and know jpackage and alike very well"

You can't get very far in Java development without working with .jar files (which are zip archives).

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

#20

Post by Bengalilol »

I think this project could be a perfect (I may be biased and didn't dig) candidate for Haxe to JS dev : no framework (except a small node server?), strict typing, minimal dependencies (jszip and maybe fast-xml-parser). What could go wrong?
Post reply on HN