[kingdomcome50]

Found the guy who hasn't used Typescript beyond tinkering!

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!).

[claytongulick]

<raises hand>

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.

[kingdomcome50]

> 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.

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!).

[claytongulick]

What I'm referring to is non-trivial function definitions.

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.

[kingdomcome50]

Functions like the ones you are describing probably shouldn't exist!

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!

[jestar_jokin]

Sounds like a problem with some API trying to make everyone happy.

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

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

[forrest2]

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

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...

[claytongulick]

I'm specifically referring to an extra 30% of LOC that does nothing other than type abstraction and provides no functional value.

30% is a conservative number.

[forrest2]

Ah sorry, I misread your claim.

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