ZX – Una herramienta para escribir mejores scripts

Artículo original ↗ Discusión en Hacker News ↗

Una herramienta respaldada por Google llamada ZX busca permitir a los desarrolladores escribir scripts estilo shell en JavaScript/TypeScript moderno en lugar de Bash, prometiendo mejor ergonomía, registros y reutilización de las herramientas existentes de Node.js. Los comentaristas están divididos: algunos equipos muy centrados en JavaScript la ven como una “bendición” para CI y la automatización de proyectos, mientras que otros objetan tener que usar Node para scripts del sistema, la verbosidad de async/await y la pérdida de la ubicuidad y simplicidad de Bash. El debate más amplio gira en torno a si el scripting complejo debería seguir en shells tradicionales y Python, o pasar al lenguaje principal de la aplicación y su ecosistema.

Recepción general

  • A muchos desarrolladores con fuerte carga de JavaScript/TypeScript les gusta zx: les permite escribir automatización “al estilo shell” en un lenguaje familiar, con buenos registros y facilidad de depuración.
  • Otros se oponen firmemente a JavaScript como lenguaje de scripting, citando confianza, complejidad y problemas del ecosistema.
  • Varios comentaristas subrayan que zx no es un “mejor shell” universal, sino una herramienta de conveniencia para proyectos JS.

Casos de uso y beneficios percibidos

  • Usos comunes: herramientas de proyecto, scripts de CI, código de pegamento alrededor de apps Node, comprobaciones de API y devtools que muestran cada comando y su salida.
  • El await de nivel superior y la gestión de subprocesos basada en promesas se ven como una adaptación natural para usuarios de JS asíncrono.
  • Tener un lenguaje y unas herramientas coherentes (TS, soporte de IDE, autocompletado) entre la app y los scripts es un gran atractivo.

Críticas a JS/Node para scripting

  • Objeciones a tener que instalar Node solo para ejecutar un script; preocupación de que se convierta en “el Electron de los scripts de shell”.
  • Algunos argumentan que los scripts deberían ser pequeños, síncronos y simples; JS centrado en lo asíncrono es excesivo y ruidoso (await await await).
  • Quejas persistentes sobre los “footguns” de JS y sus rarezas históricas, incluso si el estilo moderno evita muchas (por ejemplo, === frente a ==).

Comparaciones con otros lenguajes y herramientas

  • Muchos prefieren Python, Ruby, Perl o POSIX shell para scripts más grandes; otros señalan el dolor del empaquetado/entornos de Python y sus debilidades para la comprobación de tipos frente a TypeScript.
  • Algunos usan Groovy, scripting de C#, o Ruby/Python con gestión de dependencias en línea.
  • Alternativas mencionadas: Dax (basado en JS), Bun Shell (tipo bash con comandos integrados rápidos), xonsh, x-cmd (orquestador basado en POSIX shell), Nushell.

Portabilidad, rendimiento y cuestiones de diseño

  • zx depende del shell del sistema para los comandos, así que el comportamiento no es totalmente multiplataforma. Bun Shell intenta ser multiplataforma con comandos integrados.
  • El tiempo de arranque de Node y el tamaño del runtime preocupan a algunos, especialmente en servidores/contenedores.
  • Se critica que requiera .mjs para await de nivel superior, y que una semántica ligada a extensiones de archivo sea un mal diseño para scripts estilo shebang.

Filosofía del scripting

  • Un bando considera que bash está bien solo para one-liners; cualquier cosa más grande debería pasar a un lenguaje “real”.
  • Otro bando valora scripts ultrasimples y livianos, y ve los “scripts complejos” como un olor de código más que como algo a optimizar.