Related story from today:

Google ZX – A tool for writing better scripts

https://news.ycombinator.com/item?id=39323986 (8 comments)

Bun also has a shell: https://bun.sh/blog/the-bun-shell

It's mentioned in the article, and apparently Bun Shell was partly inspired by Dax. And zx, which inspired both.

I've been using zx for a couple years now, it's a handy all-in-one library. It's gradually replacing my Bash scripts, and I tend to reach for it for any new shell scripting needs. With Bun's fast startup time, it's also gradually replacing Node.js and zx.

I'm loving the explosion of scripting tools for Node (and similar). There was basically nothing for ages. Then ZX come along and made scripting so much easier, and quickly has become indispensable for me.

Now we have more choices and more innovation? Really exciting.

TIL about zx! https://github.com/google/zx

This suite of tools feels indispensable. Anything to keep me from having to write/maintain bash scripts that are more than a series of commands.

My position is I will never willingly write another Bash script. Zx is always a better choice.

I get that there are contexts where portability etc are important, but my work is very far from such places.

I truly despise Bash and its brethren.

big +1. I see the appeal of writing things directly in the shell, but as soon as you have conditional logic it's time for Python/JS/anything else.

In most of my cases, the scripts live within NodeJS projects, and have no particular attachment to Bash or Linux, so there's not really even any good reason to have Both involved at all.

Wow this looks pretty awesome, how come I never heard of it!? Thanks for sharing it!

There was a time I was writing scripts using Node about once a week, and I settled on ShellJS. I don't remember loving the experience.

Haven't had this need in at least a year though. From looking on npmtrends[0], ShellJS still seems the incumbent and quite alive.

Are these new zx/dax/bun-shell tools, each inspired in the previous one, way better?

[0]: https://npmtrends.com/dax-vs-shelljs-vs-zx

I've used ShellJS as well with node. These days I'm more inclined to use Deno just for better ergonomics. That said, now that I know about dax, I'll probably use that with Deno.

I haven't used bun shell at all.

Nice I like this. I think I want to use this in my AGPL-3.0 project BrowserBox for some scripting of the complex install and command breakouts.

Would this be possible license-wise? Also do you have any focus on cross-platform install commands (like apt/dnf/brew/winget ~~ complex and most likely out of scope I know!)

The biggest reason this needs to be integrated is that most people simplify won’t know about this tool. Only HackerNews reader in this thread and then some enthusiasts :)

So it would result in magnitudes of more usage if it was integrated, which seems to be the path Bun is taking.

Confusing name considering Microsoft's DAX scripting language for PowerBI.

https://learn.microsoft.com/en-us/dax/dax-overview

Shells are first and foremost the core of the CLI for interactive use of the computer. Secondarily for scripting... but I don't see anything about using any of these shells as your standard computer interface. Am I missing something?

I think they’re using shell as the loose term for “shell script”, as in scripts you run in a shell.

You could use an interactive shell in Deno and import the module... You can do it interactively that way. Not sure that I would.

I still wish all of these would default to a synchronous mode of operation, maybe with something like an „unawait“ keyword for those cases where you really benefit from async behavior?

I'm curious, when do you need this?

I still use `writeFileSync` and such out of habit, but I don't think I really need them since we got first-level await (out of async functions).

curious about this jsr.io thing linked in the article. as a package author, the promise of a package registry that makes things “just work” really excites me, but the website provides no real details.

What happens if you pick Dax and a year later it's Bun-shell that emerges as "the winner"?

If you stick to Python until a winner emerges, how does that help you? You'd have some old scripts in python, and some new ones in WinnerJS, which I think it's worse than having some in WinnerJS and some in LoserJS.

Your LoserJS scripts won't stop working. At least Bun-shell and Dax scripts in the same language. Since Bun's got some inspiration from Dax, I'm sure the API won't be that different.

I'm usually not one to jump on new JS stuff, but writing scripts on any of these feels relatively low risk.

Also, I'm still maintaining code that uses the ORM-that-lost, and the Dates-library-we-don't-use-anymore, and it's OK.

They are all winners, competition is good.

What is the difference between picking "wrong" and sticking with Python?

Well, dependencies are far easier to deal with using Deno than in Python for starters.