I don't understand why this is written in Typescript. This is a great example of how agents can write code (I'm sure they wrote `cf`), yet having fundamental computer science knowledge is still critical. Do not force your users to manage the dependencies of your cli. Do write your cli in a compiled language. Understand the reason for those decisions and tell your agents to use the correct architecture.
No it is exactly right mode for modern tech companies:
1) If it runs on my dime and my infrastructure I will optimize the hell out using most cleverly written Rust and what not and gloat about engineering prowess.
2) If it runs on users computers well then, we have carefully evaluated our strategic direction and come to conclusion that JS/TS/Electron option is the best way to go.
There's also a (maybe more minor but still interesting) explanation. On a server, you know quite precisely your load and you want to be able to causally trace bottlenecks, which is simpler with AOT compiled programs. On users' machines, they may not give you full telemetry and may use your system in quite variable ways. So V8 comes in quite nicely and optimises hot paths on workload it observes on each users system.
Is this sarcasm? We’re talking about a CLI. The fancy JIT system will collect data from one single operation and then promptly forget everything it learned and discard all those shiny optimized instruction sequences before the next operation.
For example are workloads for which Java performs very, very well. CLI tools that do one operation and return are not examples of these workloads. v8 is plausibly less bad because v8 is also optimized for short-running scripts, but that just means less outrageously slow, not that it will be remotely competitive with native code.
This is precisely why this blend of comments is insane.
All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
Pretty much any choice of tech stack will work well. This is not rocket science. It's pointless to talk about optimized solutions. It's a complete waste of time.
> Pretty much any choice of tech stack will work well.
Choice of tech stack is not merely a question of performance, but also portability and packaging. Self-contained, compiled static binaries are much, much more portable than shipping full script runtimes (JS/Python), dealing with the inevitable spread of runtime versions installed on everyone's machines, and dealing with the version spread of the dependencies installed separately.
> All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
This is an argument in favor of a language like Go, arguing that the garbage collector in the runtime is inconsequential, over a language like Rust. It is not an argument for shipping a script runtime.
> Choice of tech stack is not merely a question of performance, but also portability and packaging.
Yes, and clearly typescript is an established tech.
Just look at Cloudflare's wrangler cli.
Everything else is nonsense.
> This is an argument in favor of a language like Go (...)
Not really, in the sense that a myriad of alternatives would also meet the same bar,thus its stupid to frame it as "language X can do this, so language X should do it".
The bar is higher than that.
Typescript works well. Cloudflare already has a lot of experience using typescript to develop cli apps that hit their APIs.
Everyone just call down with the bike shedding. You're wasting everyone's time.
Is actually a really good example of why TS was a bad choice for Cloudflare. It made sense for their initial version, because the only programs that you could run on Cloudflare Workers were themselves JavaScript scripts, so it was a reasonable expectation that developers were already using npm/yarn/pnpm to install tools and manage dependencies.
But now, Cloudflare Workers supports containerized workloads and Python workloads. So even if your project doesn't use TS, you are still expected to set up some kind of JS toolchain for your project, just for wrangler.
slowin · · focus · HN ↗
geodel · · focus · HN ↗
1) If it runs on my dime and my infrastructure I will optimize the hell out using most cleverly written Rust and what not and gloat about engineering prowess.
2) If it runs on users computers well then, we have carefully evaluated our strategic direction and come to conclusion that JS/TS/Electron option is the best way to go.
gobdovan · · focus · HN ↗
amluto · · focus · HN ↗
For example are workloads for which Java performs very, very well. CLI tools that do one operation and return are not examples of these workloads. v8 is plausibly less bad because v8 is also optimized for short-running scripts, but that just means less outrageously slow, not that it will be remotely competitive with native code.
locknitpicker · · focus · HN ↗
This is precisely why this blend of comments is insane.
All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
Pretty much any choice of tech stack will work well. This is not rocket science. It's pointless to talk about optimized solutions. It's a complete waste of time.
solatic · · focus · HN ↗
Choice of tech stack is not merely a question of performance, but also portability and packaging. Self-contained, compiled static binaries are much, much more portable than shipping full script runtimes (JS/Python), dealing with the inevitable spread of runtime versions installed on everyone's machines, and dealing with the version spread of the dependencies installed separately.
> All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
This is an argument in favor of a language like Go, arguing that the garbage collector in the runtime is inconsequential, over a language like Rust. It is not an argument for shipping a script runtime.
locknitpicker · · focus · HN ↗
Yes, and clearly typescript is an established tech.
Just look at Cloudflare's wrangler cli.
Everything else is nonsense.
> This is an argument in favor of a language like Go (...)
Not really, in the sense that a myriad of alternatives would also meet the same bar,thus its stupid to frame it as "language X can do this, so language X should do it".
The bar is higher than that.
Typescript works well. Cloudflare already has a lot of experience using typescript to develop cli apps that hit their APIs.
Everyone just call down with the bike shedding. You're wasting everyone's time.
solatic · · focus · HN ↗
Is actually a really good example of why TS was a bad choice for Cloudflare. It made sense for their initial version, because the only programs that you could run on Cloudflare Workers were themselves JavaScript scripts, so it was a reasonable expectation that developers were already using npm/yarn/pnpm to install tools and manage dependencies.
But now, Cloudflare Workers supports containerized workloads and Python workloads. So even if your project doesn't use TS, you are still expected to set up some kind of JS toolchain for your project, just for wrangler.