Hacker News Reader

Comment by kelchm | Hacker News Reader

Are you really suggesting that the choice to use Typescript wasn't a deliberate one?

IMO -- it makes total sense within the existing Cloudflare tooling ecosystem.

Whether it was deliberate or not, I do not think it's a good choice. When agents can write in any language, there's no reason to pick the wrong tool for the job. At this point Javascript/Typescript belongs only in the browser. It's the suboptimal choice for every other environment. Especially for a command line tool. Even if the back-end is written in Typescript (also not the best choice imho), the clients need not be in the same language.

Typescript and the npm/JS ecosystem may be complex, but you don’t need AGI to figure out how to install a CLI built with TS. My agent can figure out how to install this.

It's not just the complexity. You're also vulnerable to supply chain attacks via NPM. It's also performance as you don't need the entire javascript runtime just for a CLI.

Pretty much every modern language with a package repository is vulnerable to supply chain attacks.

Are there any languages doing something unique or are especially resilient in this respect?

You can get a binary compiled by the author or a trusted source and none of the dependencies can change out from under you. This isn't possible with an interpreted language where the dependencies are resolved (often from dubious places like npm) at install and update time.

You can write a CLI in typescript and bundle it into a a single JS file. In fact (without looking) I’m sure that’s what Cloudflare is doing here because it’s standard practice.

> It's not just the complexity. You're also vulnerable to supply chain attacks via NPM.

Oh you mean like the attacks that occur in Rust's cargo?

https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...

Installation is not the problem.

Javascript is plenty fast, but only if it has enough time to JIT the code and can keep it JITed in memory. For long-running backed services, it's plenty fast, for browser things, it's the only option, but for the command line, it adds needless startup time.

Agents make this even worse because they don't have a "sense of time", so if they accidentally do something which causes startup time to increase dramatically, they won't feel it like a human dev would, and won't immediately start optimizing. Unless you have some specific benchmarks in CI that fail any PR which makes the code too slow, agents will just make things slower and slower.

Various agent tools (including current versions of codex-rs, which is otherwise a normal Rust program) make effective use of JavaScript/TypeScript for “code mode”. I actually think it’s an excellent choice for this use case. (I think that a less weird language with otherwise similar optimizers and tooling would be even better, but JS/TypeScript is what we have.)

What would even be a good alternative? The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.

> The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.

JS as a tech stack breaks your "fully safe" constraint (unless you are talking about running a CLI JS application without using npm...)

In this particular instance, I mean JS-the-language, not JS-the-ecosystem with browser and/or npm-style APIs.

codex-rs's code-mode-runtime uses plain V8 and gives it limited capabilities. (It gives it a very strange set of capabilities, but the point is that a program can grant specified capabilities to a JS script that it hosts, and the JS script can use those capabilities and nothing else.)

I suppose I should have added Lisp-like langauges to my list, although those don't have the kind of static type checking that TypeScript can offer.

Code should be written for the user.

> Code should be written for the user.

Yes, and the user wants to use a command line app, regardless of what's running underneath.

Counterpoint: many cloud CLIs are thinnish wrappers around APIs, so looking under the covers can actually be useful in figuring out how to do something in the API when documentation is unclear.

Reply on news.ycombinator.com