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

31–40 of 51 posts

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

#31

Post by tracker1 »

I'm a bit surprised that Go and Rust weren't at least considered. I'd probably have looked into Deno in addition to Bun for the combined TS/JS assembly.

On the JS/TS side, you also have a few interesting tools to make interacting with XML a bit easier in practice (cheerio, for example). I'm not sure if the purpose in interacting with DOCX and to what extent manipulation is wanted/needed... it's a complex format to say the least, especially with references/embedding.

I've never been a Java fan, having preferred C# along the way, but I don't think I'd use either for something like this just because of the runtime size, if nothing else.

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

#32

Post by winrid »

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.

jpackage/jlink lets you distribute an exe, dmg, etc, with the JVM packaged inside. I have java desktop apps which are like 50mb.

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

#33

Post by diegof79 »

This part:

> What surprised me was that Java supported processing ZIP files and XML from its standard runtime.

Makes me feel old.

Java was developed at a time when most people connected to the Internet via dial-up. That meant two things: the runtime is something you download once and has to work offline, and it has to support compressed packages. JAR files are essentially ZIP files with additional metadata stored as files. So yes, that’s why Java has built-in libraries for ZIP files.

The XML came with the “XML fever” of the 2000s. Java was one of the first languages to include XML support, and many of the XML DOM APIs are very Java-oriented. And, of course, it was included in the standard lib because nobody wanted extra module downloads over a slow connection. (and because XML was evolving at that time, it also meant that you had some issues between the SDK libs and user-provided libs)

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

#34

Post by pier25 »

wky wrote: post #22
pier25 wrote: post #11

Earlier quoted context omitted.

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.

Golang has the golang.org/x packages, which avoids too much stdlib bloat while still providing the niceties of “pre-vetted” packages that don’t pull in a massive dependency tree.

yeah I wish Node had something like that

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

#36

Post by hedgehog »

diegof79 wrote: post #33

This part: > What surprised me was that Java supported processing ZIP files and XML from its standard runtime. Makes me feel old. Java was developed at a time when most people connected to the Internet via dial-up. That meant two things: the runtime is something you download once and has to work offline, and it has to support compressed packages. JAR files are essentially ZIP files with additional metadata stored as…

You know that, and I know that, but for someone who started working more recently the difference between CORBA and punch cards might be a little blurry because they're both so far back they've never seen either. It's like kids asking how the dinosaurs in LEGO Jurassic world were animated, because they don't move like real toys, and noting how much easier the 1993 live action Jurassic Park filming was because back then they could just film real dinosaurs. Feels weird, but makes sense from their perspective.

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

#37

Post by NuclearPM »

diegof79 wrote: post #33

This part: > What surprised me was that Java supported processing ZIP files and XML from its standard runtime. Makes me feel old. Java was developed at a time when most people connected to the Internet via dial-up. That meant two things: the runtime is something you download once and has to work offline, and it has to support compressed packages. JAR files are essentially ZIP files with additional metadata stored as…

I just had to look through XML at work. What an ugly format!

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

#38

Post by leapingdog »

flossly wrote: post #12
pjmlp wrote: post #10

Earlier quoted context omitted.

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

> Sadly Java did not take Smalltalk's FP inspiration (I guess they were strayed by C++'s lead in that regard)

You guess correctly. Java was easy for C++ developers to learn which was beneficial for adoption at the time.

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

#39

Post by auvi »

hedgehog wrote: post #36
diegof79 wrote: post #33

This part: > What surprised me was that Java supported processing ZIP files and XML from its standard runtime. Makes me feel old. Java was developed at a time when most people connected to the Internet via dial-up. That meant two things: the runtime is something you download once and has to work offline, and it has to support compressed packages. JAR files are essentially ZIP files with additional metadata stored as…

You know that, and I know that, but for someone who started working more recently the difference between CORBA and punch cards might be a little blurry because they're both so far back they've never seen either. It's like kids asking how the dinosaurs in LEGO Jurassic world were animated, because they don't move like real toys, and noting how much easier the 1993 live action Jurassic Park filming was because back the…

Jurassic Park 1993 introduced UNIX to the mainstream world. Movies of that era showed SGI Sun, Cray or CM computers. All gone. I miss those days.

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

#40

Post by leapingdog »

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.

I have unknowingly bought commercial desktop software that turned out to be Java + SQLite under the hood. Don't know what they were using for UI.
Post reply on HN