I love the idea of frontend dev. But the tooling takes all of the fun out of it.
And I agree. Unless it works out of the box, it's a half-day of profanity at least.
But writing a command-line tool in TypeScript doesn't require any of that. The comment focused on FE development with Next.js -- I have no experience with that, but a simple React-based solution using `create-react-app` works out-of-the-box for a lot of things[0]. I will say, it does sometimes feel like everything TypeScript gets right is made up for by everything "all of the bundlers/tooling around it" screws up, but it's gotten monumentally better. You're always going to be weighing pain points against eachother, and folks that do front-end web development all day long are going to find the problems they routinely encounter to be "simple", possibly even "intuitive" based on how the rest of the ecosystem works.
From my perspective -- partly on the inside, partly on the outside -- I seem to have to muck around with the equivalent of "build scripts" about as often as I used to (not) enjoy in the C/C++-land. But dammit-all if "time to completely working" in TypeScript isn't always twice as quick. TypeScript, configured correctly, catches so many run-time issues at compile-time[1]. For me, the distance between "it runs" and "it runs correctly" is often shorter in TypeScript despite it not being my primary language.
[0] To be sure, it's hard for me to say `create-react-app` without the obligatory `fscking` inserted... it's got many problems, but at least half the time it's an implementation detail.
[1] Static-type-checking time?
You should practice your April fools jokes to be less obvious, that post is not gonna make it.
The reason I don't write everything in TypeScript has nothing to do with TypeScript. Language-wise, it is my favorite experience, hands down. I can express things in a type-safe, strict manner, and do things generically that simply cannot be done outside of dynamic languages, while still gaining the benefits of a statically typed language.
Not taking node into account[0], TypeScript on its own is my favorite language and it's not the one I write software in every day. While I agree with your arguments around pinning and such, node is a bit of a victim of its own success and suffers from dependency-hell in a way that is truly unique and interesting all on its own. The only way to be certain that code is good is if you write it, barring that ... a trusted, supported third-party for the important things, and inspect the rest. The problem on the node side is the impossibility of the last task, and if you aren't doing it, neither is your trusted third-party. I'm not saying it's hopeless -- I'd even wager a guess there's a comment in my past that is far more harsh on `npm` than it deserved/deserves[1].
I don't think "node-based" solutions for shell are bad. The biggest problem I tend to run into with shell scripts in constrained environments are related to dependencies. With node, `install`, done (usually). I target "what's probably there" like most people. Sometimes it's not. In the past, when this was a bigger problem than it is now for me, I would throw my hands up and build it in whatever I wanted because "if I had to get a waiver to add `jq` or some other thing to this box, I might as well have them put `python` on there" -- same amount of work arguing over BS but less work writing it. I'd probably apply that to `node` these days but those problems aren't mine any longer. :)
[0] Which some will point to `npm` as the whole reason they use node while others will point out why it's the entirety of its problems.
[1] And I hate the attitude of some that implies `npm`s problems have easy solutions, "if they just ...". No. It's almost everyone's first language. It's really easy to publish packages. There's a gajillion of them out there. (Yet, it works ... every? ... time I need to solve something using it.)
The developer experience out of the box with TypeScript + VSCode + Next.js is 1000x better than any stack I’ve ever worked with in Python, for example. So what if you need to pull in some dependencies? At least I don’t need to figure out what the best way to setup a Python environment is this month.
(In fact, the current Python package manager du juor, Poetry, took most of its ideas from what Yarn implemented five years ago.)
And what’s this about being irresponsible? You can easily pin your dependencies, use a lockfile, and even bake the cache into your Docker images. There’s no reason you can’t have a program that will run the same in two years as it does now. And setting that up is a lot easier than it is with other languages.