My project is small but TS takes 4-5 seconds to compile it from scratch on each run.

The main speed impact is in developer productivity though. If something ain't working right, now I first gotta fix the types before I can see if I've fixed the actual logic.

I imagine if my codebase was more "OOP-y" (i.e. if I replaced every layer of my domain model with 3 layers of dependency injection, turning the whole thing into an inscrutable ball of spaghetti like the cartel wants me to) I could probably iterate without breaking the types.

But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential.

"But then why have types at all?" Exactly. They're a crutch for people who want their IDE to understand the code instead of them.

It's always fascinating how different people approach writing code. I've worked with some very talented devs who preferred dynamic languages because they liked what I call a "smash face on keyboard" style of coding. They wanted to be able to make a change, run the code, make a change, run the code, often repeating that dozens of times before they got it right. I, and I think many people who prefer statically typed languages prefer a more methodical style of programming where we spend more time reasoning about the types and how data flows through the app. I might only run the code every five or ten minutes, but often if it builds it's right the first time. If the types are wrong, the code is wrong, and I've no interest in running code that's wrong.

Is one side or the other right or better? I dunno, I'm not qualified to answer.

TypeScript doesn't entirely prevent you from doing that, even if you have to stick in a few "any" keywords here and there and ignore whatever linter warnings you might get. I'm happy for individual devs to work like that if that's what works best for them to get their code going - but I'm certainly not happy for a shared codebase for a large complex project with dozens of devs on it to operate the same way.

For me the best experience during development is to build ts to js first with something fast like esbuild and check types in parallel without preventing the output in any way from running in the browser.

A perfect scenario for me is having all errors in the project caught by vscode. At the moment vscode only checks files that are currently open. I think type checking should only be done when building to some sort of production or realtime in your editor. Templates like "create react app" can report runtime errors but it's somewhat strange that it also report typescript errors. (although understandable given that it wants to be tooling agnostic)

One potential major upside with adding optional type hints to javascript is the ability to run typescript files directly in the browser without needing to strip types in a build step. Advanced type checking could be done the same way we use linters like eslint.

>At the moment vscode only checks files that are currently open

While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality.

>I think type checking should only be done when building to some sort of production or realtime in your editor.

Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't.

>Templates like "create react app"

...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.

> But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential.

You’re free to hold that opinion, but I think you see (based on downvoting) that your definition of a “sane” developer is not as universal as you may have thought.

Personally I almost never see any value in running known broken code.

If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.

>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?"

> Where I'm from, sanity has historically been the minority opinion

You are conflating santity for your subjective opinion. I guess your post might have been received better if you showed more awereness of that.

> That's completely subjective.

Yes. Which is why i prefixed "Personally I...". I'm clear about this being my opinion, not an universal truth.

> 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

If the compiler tells me I'm passing a string to a function expecting a number, I find that error pretty easy to grasp, and I don't need to run the code to know how to proceed from that error-message.

> But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language.

Sure. But if you (and that's up to you!) decide to write your code using types and allow TypeScript to check them, at least you know that your code in isolation is unaffected by whatever dynamic runtime it will end up being run on.

> And not one that's good enough for me to sacrifice the expressivity that JavaScript allows.

So you prefer to go full iron, and rather trust the correctness of your own code, than having a compiler check it for you.

That's your choice, ofcourse, but if that's how you do things, you cannot come afterwards and claim that TypeScript is a bad language based on that. It's a bad match for you, and how you would rather manually be in control of everything.

But just tells us about how you like things, it says nothing about the language itself.

> we get all these (generations of) people with the impression that JS is a "low sanity" language...

Javascript as a language has lots of quirks. Lots of quirks which are unexpected to most developers not coming from Javascript. That is to say, Javascript behaves differently than most other programming-languages.

I'm not saying it's wrong or "not sane", but programmers coming from other languages will make assumptions and those assumptions will be wrong for "plain" Javascript, leading to buggy code.

Typescript embraces the modern parts of Javascript, and makes them easy to work with, and makes your code easier to prove correct than plain Javascript would. That's why people like it. That's why people use it.

> and that it needs, of all possible features, even more of a type system.

This is not specific to JS. I think any language used to build bigger systems benefits from having a type-system to ensure the components interacting are always interacting in a known good way.

To me it seems like you're one of those people who prefers to work with all the quirks that Javascript provides and considers those to be good things, even though they are (much) harder to formally verify.

Where Typescript tries to force you to make formal declarations for your code, you find those limiting or getting in your way. Great. Be a superstar if you like.

Me (and many others) on the other hand, are just human, and we like a compiler to tell us about obvious errors in our code without having to discover them at runtime, or even worse, in production.

>I guess your post might have been received better

You assume that I'm primarily optimizing for that.

I optimize for being able to express my opinion in sufficient detail that people actually bother to try to show me things that I don't know, just because they're mildly outraged at my audacity to say, "but some things are very not ok" :)

>Where I'm from...

...they stopped putting people in cages not even for believing outrageous things, but for holding outrageous disbeliefs, about a generation ago. So it's also about maintaining the capability to express dissent.

>I'm clear about this being my opinion, not an universal truth.

God forbid I claim to know any universal truth! Therein lies the way to True Madness. Anything anyone says can at most be their subjective truth - if they can reproduce from memory the things that make them believe what they're saying. Snippet battle was fun

>If the compiler tells me I'm passing a string to a function expecting a number, I find that error pretty easy to grasp, and I don't need to run the code to know how to proceed from that error-message.

And if the compiler happens not to? Back to runtime validation, considering priorities it remains ad-hoc, so the mess gets even unholier.

(where's my authomatic runtime validation layer based on parsing the type definition? holla at me)

>Javascript as a language has lots of quirks. Lots of quirks which are unexpected to most developers not coming from Javascript. That is to say, Javascript behaves differently than most other programming-languages. >I'm not saying it's wrong or "not sane", but programmers coming from other languages will make assumptions and those assumptions will be wrong for "plain" Javascript, leading to buggy code.

I'm not saying it's wrong for JS to be like that either (I put forward a couple good reasons for the contrary and know a couple more), but I am saying that it is already "not sane" enough - in the sense that the hidden assumptions and unexpected behavior impair one's immediate ability to reason about the codebase.

The transpiler ecosystem doesn't help with that, either - TS, Babel, CLJS or whatever else, if I have to run scripts through a compiler it smells like someone isn't managing complexity right and it sure as hell it ain't every downstream developer who just uses whatever has the most mindshare (so that the quirks are at least googlable). Though I guess you could approach it from that angle too

>rather trust the correctness of your own code, than having a compiler check it for you

Rather verify the correctness of my code by running it, than trust the half-assed third-party static analyzer that's manipulated itself between my editor and runtime, yes

>Where Typescript tries to force you to make formal declarations for your code, you find those limiting or getting in your way.

That's a deficiency of TypeScript. The only option is not to use TypeScript, which is in many cases not an option.

>Me (and many others) on the other hand, are just human, and we like a compiler to tell us about obvious errors in our code without having to discover them at runtime, or even worse, in production.

I'm all in for this! I just wish it worked well enough to justify the drawbacks.

>To me it seems like you're one of those people who prefers to work with all the quirks that Javascript provides and considers those to be good things,

Prefer to know things that will not become invalidated by progress? Who doesn't. I already have to reason about a whole stack of "quirks" from the user's brain to the CPU and back. I would've preferred for Microsoft not to add 2322 more of those out of sheer community goodwill but there you have it.

>But if you (and that's up to you!)

It's up to me on my down time. Rest of my life it's up to the economy lol

>decide to write your code using types and allow TypeScript to check them

"decide to buy into the TypeScript language and ecosystem" because "writing your code using types and allowing TypeScript to check them" by manually writing a .JS + .D.TS is also not a practical option.

>That's why people use it.

My guess is most devs adopted it on their down time to stay relevant, "join us or fade away" hahahaah

>at least you know that your code in isolation is unaffected by whatever dynamic runtime it will end up being run on.

Where did that even come from. You mean like how it's now 4x harder to publish an isomorphic library because the CJS->ESM migrations and TypeScript doing its own things with modules have mangled the packaging surface in further sanity-reducing ways

>Be a superstar if you like.

One does not reach a position of power simply by doing what one wants. You also gotta tell others what not to do :)