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