[novagameco]

Well python allows for type annotations as part of the language; javascript does not, so the compilation stage in typescript is just about erasing types for the most part (typescript tries to have minimal impact on the runtime). It just seems like a worse option than typescript's syntax. Bun runs typescript natively without doing any of the type checking

[wilsonnb3]

Even though type annotations are part of the language now in Python, they aren’t used by the runtime so it is still essentially the same as jsdoc or sorbet style type checking. More like a really powerful linter than a transpiler like typescript.

Before type annotations were officially added in python 3.5, you could still use mypy for type checking. The only difference being that the type hint format wasn’t standardized across tools.

[satvikpendem]

But...TypeScript is the same, types are not used by the runtime.

[botten]

With types as jsdoc annotations there is no compilation step at all, no matter where the script runs. Have your cake and eat it.

[satvikpendem]

JSDoc is strictly less powerful than TypeScript though. For example, more complex types as well as template literal types are impossible to have in JSDoc. It is simply more ergonomic to use TypeScript instead of JSDoc.

[novagameco]

Are you saying there isn't any tool which checks whether you're using your types correctly? If not, then the two aren't comparable at all

[wilsonnb3]

There are tools that check whether you are using your types correctly. They work like linters, where you get hints in your IDE and you can run it across the whole project looking for problems when you want to.

The difference between this approach and the typescript approach is that typescript isn’t valid JavaScript, you need a build step that converts it. JavaScript with JSDoc type annotations is valid JavaScript, just with special comments in it, so it doesn’t need to be converted before it is run.

[shortrounddev2]

How would you implement an interface in jsdoc, since interfaces aren't valid javascript

[alldaysintoone]

You wouldn't implement an interface per say. You would implement a JSDoc type annotation which you can then attach to a doc string for a function input or return.

Next time you try to use that function the tooling (VS Code) will highlight the Type required by it as both documentation and a dynamic check - this fn input is missing X property.

Imagine it as a TS light version, where tooling and docs helps you write well-documented typed code that isn't checked for validity at compilation.

All the logic that is important is typed: all inputs, outputs. Each function is documented in terms of the program IO and what it should do and why (description).

There's no typed guard rails in place. You could pass an object that doesnt follow a type, but with team agreements, reviews, testing, and diligence you wouldn't. In TS you bypass process because the compiler does those checks for you.

To actually force runtime compliance to types and further get to a statically typed vision I used object validation schema. Each complex fn input would have a schema and we would validate against that.

In such a way you have some typing, documentation, and some static typing.

Since JS was never build with types or static typing as a first class citizen (like other languages are) there's less friction in scenarios where JS is too multifaceted or loose. This is the "have your cake and ear it" reply: you have types, documentation, runtime type checks for what matters, but you stay native to JS and avoid full static typing, remove the need for TS compiler.