zx VS deno

I mean, at some point you're going to end up with a bunch of shell scripts in your repo that will dodge the usual type checks & lint rules, and I've wasted quite some time on bugs that would be caught by such safety nets. I think working with bash is too error-prone, even for smaller scripts, and there's a reason why tools like zx exist.

The automatic flattening of Promise> is a minor inconvenience that I faced recently when working with zx scripts (see the Real-life example section in my other article in this series). The root of the problem was that I wanted to get access to the Promise returned from an async function as zx adds methods on that Promise (and calls it a ProcessPromise) and I was unable to, since it was automatically flattened. This led me to evaluate the Promise API and see how different it is from a traditional Future monad.

Python also has a rich ecosystem of ebook parsing libraries, and fairly easily handles things like file renaming, extensions, environment variables on Linux machines, which is what my NAS box runs. And while my first language is typescript/javascript, so I could’ve utilized something like BASH + Google’s ZX, it felt like a good case to try to get some experience with Python, which I’ve never really used. Luckily VS Code’s intellisense (with some Python plugins), and Python’s relatively simple syntax made it quite easy to get from A→ B in terms of getting the pieces all put together.

I stopped writing bash too. I'm writing a lot of TypeScript these days, and for that zx is really cool. I think its Clojure equivalent would be nbb.

I've also done that, as it is the better solution for applications that are meant to be purely single-threaded. It's also easier than dealing with the async version (either promise-based or callback). Or at least it was, before I discovered https://github.com/google/zx.

Personally I seldom write bash scripts so when I do usually have to google how to do everything, and I usually have shellcheck in my editor to catch obvious bad practices. I write js much more often so I’ve used Shelljs to avoid such headaches, though it has its own set of conventions to wrap your head around. Zx looks neat too https://github.com/google/zx . If the scripts are going to be maintained by devs without node experience I’d stick with bash.

There are many alternative shells out there. The popular ones seem to maintain a degree of compatibility with bourne shell and bash, namely dash and zsh. Some deviate even more, like fish. But then I've learned that it is possible to use shells based on regular programming languages. I've seen people using python instead of bash, which initially I thought was weird, but then wondered "why not?". I've also heard about scheme's scsh, and potentially JavaScript's zx. Never tried them, so maybe they're bad examples.

You might be delighted to learn of https://github.com/google/zx :-)

Finally, you could use a runtime like Deno which natively supports Typescript.

Why not just use https://deno.land/

Fast iterating thanks to Deno, for built in Typescript debugging and bundling

I usually look at https://github.com/denoland/deno for the releases.

Or you can see the latest release on GitHub Releases page. https://github.com/denoland/deno/releases

I'd run an API using Deno (https://deno.land), and consume that API with an SSR/SSG site built using Astro (https://astro.build). SCSS for styling, and probably just Vanilla JS (written in Typescript and compiled via Deno) — I increasingly find that unless my site is massively interactive, plain old Vanilla JS is totally sufficient.

First, you would need to obtain the source code for the Deno runtime and its dependencies, which you can find on the Deno GitHub repository (https://github.com/denoland/deno).

Reading Deno source code dependcies to build appear to be Rust and V8. listenTls: https://github.com/denoland/deno/blob/f0c79a676cc36a5e8f6f5af86d93186d41974518/ext/net/01_net.js, https://github.com/denoland/deno/blob/f0c79a676cc36a5e8f6f5af86d93186d41974518/ext/net/02_tls.js.

When you look at the current web ecosystem, you'll see players like Deno, Bun, Qwik all pushing the frontier on performance in their own domain.