A few months ago I had a small job to automate: every day, take a list of URLs from my site and notify Google and Bing that they'd changed, so new pages would get indexed in hours instead of days. The obvious path was a tiny Node.js service — pull in a Google API client, an IndexNow helper, a scheduler library, drop it on a server, done.

I built the Node version first. It worked. It also pulled in forty-some transitive dependencies, needed its own runtime on the box, and broke three weeks later when a minor version bump changed an auth helper's signature. For a script that runs once a day and does little more than sign a token and POST some JSON, that was a lot of surface area to maintain.

So I deleted it and rewrote the whole thing in about thirty lines of Bash: curl, openssl, and jq. It has run every night since without a single dependency update. Here's the honest case for when that trade is worth it — and when it absolutely is not.

What Bash quietly does well

The two "hard" parts turned out not to be hard. Signing a Google service-account JWT — the thing every SDK hides behind a function call — is just base64url-encoding a header and a claims set, signing the dotted string with openssl dgst -sha256 -sign, and base64url-ing the result. That's four lines. Exchanging it for an access token is one curl. Submitting to IndexNow is one more.

Once it was written, the appeal wasn't cleverness — it was that there was almost nothing left to break. No node_modules to audit, no runtime to patch on the host, no lockfile drift. The whole program is legible top to bottom in one screen. When something goes wrong, the failure is a visible HTTP status code in a log, not an exception three layers deep in a library I didn't write.

For a narrow, stable, I/O-bound task — call an API on a schedule, parse a little JSON, log the result — Bash plus curl/jq is a genuinely good fit, and "no dependencies" is a feature, not a flex.

Where this stops being a good idea

Here's the part the "just use Bash" crowd skips. The moment my requirements grew, every advantage flipped.

• Anything stateful or branching. My quota tracker — "stop after 200 URLs a day" — is already the ugliest part of the script. The day I needed retries with backoff, I felt the language fighting me. Control flow and data structures are where Bash turns into line noise.
• Anything you need to test. There is no comfortable unit-testing story for a pile of curl calls. My "test suite" is running it and reading the log. For a daily indexer that's acceptable; for anything a business depends on, it isn't.
• Anything someone else maintains. A clever Bash one-liner is a write-only medium. The next engineer — or me in six months — will read thirty lines of tr and process substitution and quietly rewrite it in Python anyway.
• Anything with real parsing. The first time you reach for a regex to pull a field out of HTML or handle nested JSON edge cases, stop. jq has limits, and Bash string handling has more.

The actual rule

The decision isn't "Bash vs. Node." It's how much will this change, and who has to live with it. A script that does one stable thing on a timer, that you own, that fails loudly and visibly — that's where shedding a runtime and a dependency tree is a real, durable win. The minute it needs state, tests, teammates, or non-trivial parsing, the dependencies you removed were buying you something, and you should buy them back.

I keep the Bash indexer precisely because it never grew. That's the whole point: I chose it knowing it would stay small, and I'd switch back the day that stops being true. "Use the boring, dependency-free tool" is good advice exactly as far as the boring assumptions hold — and the skill is noticing when they stop.