ZX – Uma ferramenta para escrever scripts melhores

Uma ferramenta apoiada pelo Google chamada ZX pretende permitir que desenvolvedores escrevam scripts em estilo shell usando JavaScript/TypeScript moderno em vez de Bash, prometendo melhor ergonomia, logging e reaproveitamento das ferramentas do ecossistema Node.js. Os comentaristas estão divididos: algumas equipes com forte uso de JavaScript consideram isso uma dádiva para CI e automação de projetos, enquanto outras se opõem à exigência de Node para scripts de sistema, à verbosidade de async/await e à perda da ubiquidade e simplicidade do Bash. O debate mais amplo gira em torno de se o scripting complexo deve permanecer em shells tradicionais e Python, ou migrar para a linguagem principal da aplicação e seu ecossistema.

Recepção geral

  • Muitos desenvolvedores com forte uso de JavaScript/TypeScript gostam do zx: ele permite escrever automação no estilo “shell” em uma linguagem familiar, com bons logs e facilidade de depuração.
  • Outros são fortemente contrários a JavaScript como linguagem de script, citando confiança, complexidade e problemas de ecossistema.
  • Vários comentadores enfatizam que o zx não é um “shell melhor” universal, mas sim uma ferramenta de conveniência para projetos JS.

Casos de uso e benefícios percebidos

  • Usos comuns: ferramentas de projeto, scripts de CI, código de integração em torno de apps Node, verificações de API e devtools que mostram cada comando e sua saída.
  • await no nível superior e o tratamento de subprocessos baseado em promises são vistos como um ajuste natural para usuários de JS assíncrono.
  • Ter linguagem e ferramentas consistentes (TS, suporte da IDE, autocompletar) entre a aplicação e os scripts é um grande atrativo.

Críticas ao JS/Node para scripting

  • Objeções a exigir instalação do Node apenas para executar um script; preocupação de que isso possa virar “o Electron dos shell scripts”.
  • Alguns argumentam que scripts devem ser pequenos, síncronos e simples; JS focado em async é exagerado e barulhento (await await await).
  • Reclamações persistentes sobre os “footguns” do JS e peculiaridades históricas, mesmo que o estilo moderno evite muitas delas (por exemplo, === vs ==).

Comparações com outras linguagens e ferramentas

  • Muitos preferem Python, Ruby, Perl ou POSIX shell para scripts maiores; outros observam os problemas de empacotamento/ambiente do Python e as fraquezas de type-checking em comparação com TypeScript.
  • Alguns usam Groovy, scripting em C# ou Ruby/Python com gerenciamento de dependências embutido.
  • Alternativas mencionadas: Dax (baseado em JS), Bun Shell (estilo bash com builtins rápidos), xonsh, x-cmd (orquestrador baseado em POSIX shell), Nushell.

Portabilidade, desempenho e questões de design

  • O zx depende do shell do sistema para comandos, então o comportamento não é totalmente multiplataforma. O Bun Shell tenta ser multiplataforma com comandos embutidos.
  • O tempo de inicialização do Node e o tamanho do runtime são preocupações para alguns, especialmente em servidores/containers.
  • Exigir .mjs para await no nível superior, e vincular semântica a extensões de arquivo, é criticado como um mau design para scripts estilo shebang.

Filosofia de scripting

  • Um lado vê bash como bom apenas para one-liners; qualquer coisa maior deveria migrar para uma linguagem “de verdade”.
  • Outro lado valoriza scripts ultra simples e enxutos, e vê “scripts complexos” como um cheiro de código, em vez de algo a ser otimizado.