5 ms·

Zx is good if JavaScript is only language you know. If you have ability to program or learn other programming languages, Python with packages like Shell and Plu

Zx is good if JavaScript is only language you know. If you have ability to program or learn other programming languages, Python with packages like Shell and Plumbum might be better choices for shell scripting tasks that outgrow shell. - Python code with Shell is easier to read ana write - No nees to carry async/await keywords thru the code - Powerful plain text manipulation in the stdlib https://pypi.org/project/python-shell/ https://pypi.org/project/python-shell/ https://plumbum.readthedocs.io/en/latest/ https://plumbum.readthedocs.io/en/latest/

gizdan 5y ago
Wow, plumbum, despite it's unfortunate name, looks awesome. I will definitely try it next time I write a script.
- philsnow 5y ago
  how is the name unfortunate? from the site: > Plumbum (Latin for lead, which was used to create pipes back in the day)
  - marcusramberg 5y ago
    And yet it sounds like a thicc ass.
    - mst 5y ago
      I confess to being quite amazed that you saw an innuendo somewhere I didn't.
  - dogma1138 5y ago
    Yes, but the name choice was quite intentional and probably giggle inducing. This is about as toilet humor as it can get.
    - FroshKiller 5y ago
      According to the Classical Latin pronunciation I learned in school, this is "ploom-boom" rather than "plum-bum."
    - bovermyer 5y ago
      I wonder if your comment says more about how you choose to see the name rather than any inherent meaning. Personally, I only see it as the old name for lead. Interesting to see how others are wired.
    - mst 5y ago
      I guess if you've never learned about the word 'plumbing' before?
  - gizdan 5y ago
    That's fair. My Latin is non-existent, and I clearly was too eager to look at example source instead of reading the description. I'll take my criticism and walk away.
dogma1138 5y ago
Powershell is also available for Linux these days, and well Powershell is awesome. Not sure how I feel about needing Node.JS to run shell scripts…
alexghr 5y ago
Maybe, but the main advantage of `zx` (at least for me) is that I don't have to manage another language environment. I can keep everything contained within Node :)
- dogma1138 5y ago
  The problem is Node, especially all the packages that you’ll end up using under the hood, it’s seems quite risky especially if you don’t have super tight control over your Node SBOM. Would be a bit more interesting to me if it was a JS shell built from the ground up without the entire mess of the Node package dependency baggage.
  - alexghr 5y ago
    While I agree that Node's ecosystem is not the best, it's what we have in the frontend world. If you're working on a Node-based service or React app, you already have to deal with Node and its package ecosystem. Adding a couple of extra MB (or even KB, depending on package reuse) on top of your existing chain of dependencies is a tiny con to the huge benefit of not having to do logic in Bash :)
    - dogma1138 5y ago
      The problem is that you don’t always know what is actually being executed, shell scripting is risky as it is without the rabbit hole that is the Node dependencies system.
  - ptx 5y ago
    There's always WSH if you're on Windows and will settle for ECMAScript 3. No external dependencies or runtime needed.
  - arve0 5y ago
    zx has a small dependency tree, 12 packages marked as "@types" and 36 regular packages[0]. If you are fluent in Node, it should be easy to avoid further dependencies. 0: https://arve0.github.io/npm-download-size/#zx https://arve0.github.io/npm-download-size/#zx
SahAssar 5y ago
> Python code with Shell is easier to read and write That is pretty subjective
- miohtama 5y ago
  Yes. I started programming in JavaScript in 1999 and Python in 2003, so it is my subjective opinion based on mastering the both languages. There are some factual and objevtive features making Python syntax more friendly, but it is a worth of a blog post to explore. And in the end there is no point, as JavaScript maximalists would not care.
IshKebab 5y ago
Maybe but Python is sloooow and its type annotation situation is pretty poor. I would recommend using Deno. It has the following advantages: * Uses Typescript which gives you a great static typing system. * Runs via V8 so it's about a million times faster than Python. * Single statically linked binary with no project setup files required (package.json/dependencies.txt) makes it about a million times easier to deploy than either Node or Python. Especially on Windows. * You can still use third party libraries even without a project file and you get IDE integration. It's the clear winner at this point. Someone has even made a version of zx for it: https://deno.land/x/zx_deno@1.2.2 https://deno.land/x/zx_deno@1.2.2
- tcbasche 5y ago
  I’ve found Python is just fine performance-wise for CLI tools. What bad experiences have you had with it? I’ve mostly used click.
  - watermelon0 5y ago
    Python interpreter by itself is fast, it spawns in a few milliseconds, but it can slow to a crawl if you need libraries, and easily take a few seconds. However, situation is similar with nodejs.
  - IshKebab 5y ago
    Startup time is very slow. I just tested on my system and cold startup was 1 second (!) and hot 180ms. Vs 80ms and 64ms for Node. Also it obviously depends what your CLI tool is doing. Just because something is a CLI tool doesn't mean it doesn't do much stuff and therefore performance doesn't matter. For example Scons is a CLI tool. It's a build system written in Python. Everybody abandoned it because it was dog slow. Mercurial is a CLI tool. It's a VCS written in Python. Most people have abandoned it partly because it is slow (and partly because Github exists). You can read about Mercurial's troubles with Python performance here: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan > Performance is a significant pain point with Python. There are multiple facets to the performance problem: > * Startup overhead > * General performance overhead compared to native code > * GIL interfering with parallel execution > It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command's main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users.
wdroz 5y ago
There is also xonsh[0] if you want an similar experience to zx to mix bash and python. [0] -- https://github.com/xonsh/xonsh https://github.com/xonsh/xonsh

gizdan 5y ago

Wow, plumbum, despite it's unfortunate name, looks awesome. I will definitely try it next time I write a script.

philsnow 5y ago
how is the name unfortunate? from the site: > Plumbum (Latin for lead, which was used to create pipes back in the day)
- marcusramberg 5y ago
  And yet it sounds like a thicc ass.
  - mst 5y ago
    I confess to being quite amazed that you saw an innuendo somewhere I didn't.
- dogma1138 5y ago
  Yes, but the name choice was quite intentional and probably giggle inducing. This is about as toilet humor as it can get.
  - FroshKiller 5y ago
    According to the Classical Latin pronunciation I learned in school, this is "ploom-boom" rather than "plum-bum."
  - bovermyer 5y ago
    I wonder if your comment says more about how you choose to see the name rather than any inherent meaning. Personally, I only see it as the old name for lead. Interesting to see how others are wired.
  - mst 5y ago
    I guess if you've never learned about the word 'plumbing' before?
- gizdan 5y ago
  That's fair. My Latin is non-existent, and I clearly was too eager to look at example source instead of reading the description. I'll take my criticism and walk away.

dogma1138 5y ago

Powershell is also available for Linux these days, and well Powershell is awesome. Not sure how I feel about needing Node.JS to run shell scripts…

alexghr 5y ago

Maybe, but the main advantage of `zx` (at least for me) is that I don't have to manage another language environment. I can keep everything contained within Node :)

dogma1138 5y ago
The problem is Node, especially all the packages that you’ll end up using under the hood, it’s seems quite risky especially if you don’t have super tight control over your Node SBOM. Would be a bit more interesting to me if it was a JS shell built from the ground up without the entire mess of the Node package dependency baggage.
- alexghr 5y ago
  While I agree that Node's ecosystem is not the best, it's what we have in the frontend world. If you're working on a Node-based service or React app, you already have to deal with Node and its package ecosystem. Adding a couple of extra MB (or even KB, depending on package reuse) on top of your existing chain of dependencies is a tiny con to the huge benefit of not having to do logic in Bash :)
  - dogma1138 5y ago
    The problem is that you don’t always know what is actually being executed, shell scripting is risky as it is without the rabbit hole that is the Node dependencies system.
- ptx 5y ago
  There's always WSH if you're on Windows and will settle for ECMAScript 3. No external dependencies or runtime needed.
- arve0 5y ago
  zx has a small dependency tree, 12 packages marked as "@types" and 36 regular packages[0]. If you are fluent in Node, it should be easy to avoid further dependencies. 0: https://arve0.github.io/npm-download-size/#zx https://arve0.github.io/npm-download-size/#zx

SahAssar 5y ago

> Python code with Shell is easier to read and write That is pretty subjective

miohtama 5y ago
Yes. I started programming in JavaScript in 1999 and Python in 2003, so it is my subjective opinion based on mastering the both languages. There are some factual and objevtive features making Python syntax more friendly, but it is a worth of a blog post to explore. And in the end there is no point, as JavaScript maximalists would not care.

IshKebab 5y ago

Maybe but Python is sloooow and its type annotation situation is pretty poor. I would recommend using Deno. It has the following advantages: * Uses Typescript which gives you a great static typing system. * Runs via V8 so it's about a million times faster than Python. * Single statically linked binary with no project setup files required (package.json/dependencies.txt) makes it about a million times easier to deploy than either Node or Python. Especially on Windows. * You can still use third party libraries even without a project file and you get IDE integration. It's the clear winner at this point. Someone has even made a version of zx for it: https://deno.land/x/zx_deno@1.2.2 https://deno.land/x/zx_deno@1.2.2

tcbasche 5y ago
I’ve found Python is just fine performance-wise for CLI tools. What bad experiences have you had with it? I’ve mostly used click.
- watermelon0 5y ago
  Python interpreter by itself is fast, it spawns in a few milliseconds, but it can slow to a crawl if you need libraries, and easily take a few seconds. However, situation is similar with nodejs.
- IshKebab 5y ago
  Startup time is very slow. I just tested on my system and cold startup was 1 second (!) and hot 180ms. Vs 80ms and 64ms for Node. Also it obviously depends what your CLI tool is doing. Just because something is a CLI tool doesn't mean it doesn't do much stuff and therefore performance doesn't matter. For example Scons is a CLI tool. It's a build system written in Python. Everybody abandoned it because it was dog slow. Mercurial is a CLI tool. It's a VCS written in Python. Most people have abandoned it partly because it is slow (and partly because Github exists). You can read about Mercurial's troubles with Python performance here: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan > Performance is a significant pain point with Python. There are multiple facets to the performance problem: > * Startup overhead > * General performance overhead compared to native code > * GIL interfering with parallel execution > It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command's main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users.

wdroz 5y ago

There is also xonsh[0] if you want an similar experience to zx to mix bash and python. [0] -- https://github.com/xonsh/xonsh https://github.com/xonsh/xonsh