>your definition of a “sane” developer is not as universal as you may have thought Where I'm from, sanity has historically been the minority opinion, so we don

>your definition of a “sane” developer is not as universal as you may have thought Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.) What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it. No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity. Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress. But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system. >Personally I almost never see any value in running known broken code. That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...) So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style. Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows. Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus. > If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose. Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades, TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working... Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"