ZX – A tool for writing better scripts

A Google-backed tool called ZX aims to let developers write shell-like scripts in modern JavaScript/TypeScript instead of Bash, promising better ergonomics, logging, and reuse of existing Node.js tooling. Commenters are split: some JavaScript-heavy teams find it a “godsend” for CI and project automation, while others object to requiring Node for system scripts, the verbosity of async/await, and the loss of Bash’s ubiquity and simplicity. The broader debate centers on whether complex scripting should stay in traditional shells and Python, or move into the primary application language and its ecosystem.

Overall reception

  • Many JavaScript/TypeScript-heavy developers like zx: it lets them write “shell-style” automation in a familiar language, with good logs and debuggability.
  • Others are strongly opposed to JavaScript as a scripting language, citing trust, complexity, and ecosystem issues.
  • Several commenters emphasize that zx is not a universal “better shell,” but a convenience tool for JS projects.

Use cases & perceived benefits

  • Common uses: project tooling, CI scripts, glue code around Node apps, API checks, and devtools that show each command and its output.
  • Top-level await and promise-based subprocess handling are seen as a natural fit by async JS users.
  • Having consistent language and tooling (TS, IDE support, autocompletion) across app and scripts is a big draw.

Critiques of JS/Node for scripting

  • Objections to requiring Node installation just to run a script; concern it could become “the Electron of shell scripts.”
  • Some argue scripts should be small, synchronous, and simple; async-focused JS is overkill and noisy (await await await).
  • Persistent complaints about JS “footguns” and historical quirks, even if modern style avoids many (e.g., === vs ==).

Comparisons with other languages & tools

  • Many prefer Python, Ruby, Perl, or POSIX shell for larger scripts; others note Python’s packaging/env pain and type-checking weaknesses versus TypeScript.
  • A few use Groovy, C# scripting, or Ruby/Python with inline dependency management.
  • Alternatives mentioned: Dax (JS-based), Bun Shell (bash-like with fast builtins), xonsh, x-cmd (POSIX-shell-based orchestrator), Nushell.

Portability, performance, and design issues

  • zx depends on the system shell for commands, so behavior isn’t fully cross-platform. Bun Shell tries to be cross-platform with built-in commands.
  • Node startup time and runtime size are concerns for some, especially on servers/containers.
  • Requiring .mjs for top-level await, and tying semantics to file extensions, is criticized as bad design for shebang-style scripts.

Scripting philosophy

  • One camp sees bash as fine for one-liners only; anything larger should move to a “real” language.
  • Another camp values ultra-simple, lean scripts and views “complex scripts” as a code smell rather than something to optimize for.