For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base.

It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.

At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.

So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)

https://github.com/typescript-eslint/typescript-eslint/blob/...

Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.

Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.

So guess what's going to happen? I'm using fucking `any` and I don't care.

Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.

It is massively easier to make change to large TS codebase. Just because you never bothered to learn TS and you rush feature at cost to maintenance, do not mean it is TS fault.

> Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.

Because native types would create even more fragmentation while being less powerful than TS. JS was never intended for application development, we either embrace compilers or move away from language that have pathetic standard library, dynamic and complex type coercion rules, no stable module system, lack of strong leadership and legacy of supporting IE.

I feel like I was crippling myself for years, being an inferior developer wasting so much time with the things that TS guards against, documents, and autocompletes for.

I support any formalization of TypeScript that further tidies up the "add-on" nature of it. But to be honest, it's really quite fine already.

Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat.

For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics).

If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.

IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.

It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".

  - what about tests, how do they run
  - source maps support in node being 3rd party and unbearably slow for any medium sized project 
    - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 
    - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541
    - also applicable when not bundling, albiet fewer reprcutions to turning off source maps
  - poor native (C++) modules support in bundlers 
  - modules with really dynamic `require` statements being supported at varying levels by varying bundlers

I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability.

But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler".

A better test suite can have exponential more value on maintainability than types.

> Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1]

So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved.

[1] https://github.com/giltayar/proposal-types-as-comments/#comm...

A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types.

The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase.

Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.

Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.

Machine-verifiable documentation about the intended I/O of functions and shapes of structs and objects is hugely fucking valuable to everyone. Your documentation isn't good enough if it doesn't include that, so it may as well be in a format that a machine can read, validate, and use to help out every single person who ever has to read or touch that code.

I would say exactly the opposite - beginners pick languages without [much] typing because it is or at least it seems easier to get started. When you step out of toy program territory you will start to appreciate the value of types.

It's hard to tell whether the reason beginners pick languages is because they are not typed or because they are immediately practical (such as javascript, php or python). Christopher Allen's and Julie Moronuki's Haskell Programming from First Principles is targeted at complete beginners. Harvard's CS50, which starts with C (well, Scratch, technically; then C), also targets beginners.

You don't see much lisp among beginners, despite the absence of type notation.

No, it is not hard to tell. Programming beginners positively do not choose languages by evaluating concepts that they have no clue about.

> You don't see much lisp among beginners, despite the absence of type notation.

Lisps are simply not widely promoted to beginners; there aren't enough people to do that.

Beginners end up learning whatever is thrust at them most frequently and loudly. Basically, the non-beginners more or less decide that for the beginners.

Types catch a lot of stupid errors that anyone can make, regardless of skill level.

They also localize guarantees. If your data has a type, you don't need to understand the full path it took to arrive in your function to be able to work with it. With dynamic types, you can only hope that a value has the type you need unless you explicitly check every time.

> But unfortunately it does not bring that much value.

If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place.

People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it.

In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.

I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act.

It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.

In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.

You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time.

These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer.

(For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)

Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.

But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.

I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.)

The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing).

I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.

Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.

    const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBar

When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.

Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-7...

The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.

Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.

Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening.

Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.

Or just to the developer that likes to offload that cognitive load to their tools.

Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.

Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.

If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.

Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.

"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.

My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.

Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"

Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.

2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"

The real lightbulb moment for me was using JSDoc annotations with TypeScript types in JS files. It definitely isn’t as graceful as JS itself but it’s not that big of a deal, plus it encourages you to add comments. And any TypeScript editor will parse the code as if it’s TS, provide autocomplete, type checking etc etc as required.

I kid... mostly. But in all honesty I have found very few instances of developers who have worked significantly with both languages and have come to the conclusion that TS has a marginal upside (though maybe they will come out in defense here!).

I've worked extensively with both.

I find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff.

It makes maintaining the code base excruciating.

Small changes between versions of ts or .d.ts files have caused hundreds of errors. A concrete example of this is the change in mongo driver that forced "new ObjectId()" instead of "ObjectId()" though functionally there was no difference.

I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions.

I see painful compilation times, a beefy laptop's CPU getting pegged and the fan whining while trying to do even minor updates.

Try to do a build while on a video conference? I see two to three minute build times.

I see a series of nonsense stories in sprints that are nothing more than activity over achievement. They don't drive product functionality, they are a bunch of make-work to satisfy the developer asthetic and the compiler.

The nightmare of "compiled" NodeJS production support is a dystopian hellscape that I'm forced to endure every day because of NestJS and typescript. And nothing in that has done anything to increase code quality or reduce bugs from the crappy offshore team that wrote it.

Clearly, I'm not a fan.

That being said, I think type comments in jsdoc are a honking good idea.

I use inline /* @type */ declarations and .d.ts files liberally.

If we could add to jsdoc the ability to document types and purpose of arbitrary js objects inline, at definition time, instead of an external .d.ts file, I'd be a happy guy.

An example of this would be sequelize schema defs, or mongoose schema defs, where I can have all my jsdoc code comments and type definitions in the same place as the code.

All that being said, I like the idea of this proposal. Especially if it could solve the schema definition issue above.

I think optional typing is a good idea to bake directly into the language. I thought AS3 did a great job of this.

I even think it would be great to have an equivalent of "strict" that would enforce typing at the module level to enable straightforward AOT / wasm interop (I know it doesn't solve the GC issue).

My beef is mostly with the extra compilation step and needless complexity of ts.

If we had simple (no generics) opt-in typing that was natively supported by the engine, I think it would enhance the language overall, like type hints have done for python.

Is this better or worse than no type definition? Whether or not a type is defined it is still consumed. I can totally understand that sometimes types can get a bit unwieldy, but those are the exact scenarios that save future-you from introducing a bug because you didn't know what a variable is (and is not). At the very least it may be an indicator of poor design/code smell when the above occurs.

I hear you on compilation/build process woes. That's the fairest criticism against TypeScript IMO (though it's a fairly weak argument as well).

Most of your other critiques aren't really levied against TypeScript, rather, your work environment (not that it makes working with TS any less painful!).

Things with optional parameters that can accept a wide variety of types, async callbacks and async variadic return types.

The hoops you need to jump through to make the compiler happy are absurd.

I have no doubt that a sizable portion of these functions' bodies is dedicated to figuring out which type each of our input variables represent (from our wide variety). So now instead of having our editor/compiler help us out, we are now actually writing code to figure it out ourselves... this is more absurd (and less efficient).

And FWIW, using union types makes it trivial to denote that a function can accept a wide variety of types in a type-safe way. But guess what you will be doing first thing in the function body? Discriminating that union!

Could be avoided by having more functions, one for each case.

(Only if you control the code, of course.)

That 30% number is almost certainly why. The experience with codebases with 100% type coverage / tight types have been glorious, and the ones with partial coverage / plain js files / lots of "as any" / lack of strict compiler flags https://www.typescriptlang.org/docs/handbook/compiler-option... have been miserable and a waste of time. Can't stress the strict flags enough.

One of the "pros" of typescript is its gradual typing, but I think it's a trap and forces poor impressions on people.

One of those reasons is how `any` works. In gradual adoption, lots of stuff turns into `any`. `any` is a contagious/viral construct where anything it touches could become `any`. And then you spiral out of control and the whole codebase gets nothing from typescript but gets all the operational overhead.

If your browser doesn't support text fragments, can cmd/ctrl+f for "contagious" and/or "gradual" https://www.typescriptlang.org/docs/handbook/typescript-in-5...

30% is a conservative number.

Sounds high but if it's true it's true.

I do agree it would be nice to simplify some of the tooling though.

stuff.anAccountTypeField = obj.aNumberValue;

Would cause an error in a typed language , something like incompatible type Number and type Account.

Maybe you were confused by my commnet about the network requests and different order of running code, this caused the error not to happen most of the time so it never crashed on developer machine.