But I don't think your problems with FE Dev/TypeScript are "TypeScript" problems so much as they're problems around the tooling you're using with `node`. And I

But I don't think your problems with FE Dev/TypeScript are "TypeScript" problems so much as they're problems around the tooling you're using with `node`. 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?