> JSDoc and TypeScript are standards/formats for typing. Like any tools, they both have advantages and disadvantages. Neither is objectively better than the other.

Agreed. Just to clarify, my intentions with this post weren't to advocate for one over the other. Just to point out that they are the same thing. They are both TypeScript.

▲

mattmanser a day ago | parent | next [-]

I don't know how anyone can agree with this, because it pivots on this outrageous claim:

"Like any tools, they both have advantages and disadvantages"

You cannot make any argument based on such a position. Putting aside anyone's views on TS or JSDoc, tooling is of extremely variable quality, and lots of tools ARE objectively much worse than other tools.

It we can't point at tools and say this one is better than that one, we might as well give up.

I always remember a scene in Will & Grace where Will is trying to get his boss to say one thing is better than the other. He's brought a lovingly hand-crafted sandwich made with amazing, bread, fillings, etc. and a store bought sandwich made with cheap bread/fillings. He asks his boss to try both and say which one he likes more.

His boss says something like the store bought one reminds him of his grandma's sandwiches, so invokes nostalgia, and still can't make a decision.

Don't be that boss.

	▲	rpsw a day ago \| parent [-]
		I don't understand how this an outrageous claim. You might say a luxury sports car is objectively better than a cheap minivan, but that is no good to someone who needs to transport around a family. Or is you problem with the word any instead of many?

▲

KPGv2 a day ago | parent | prev [-]

> They are both TypeScript.

I take issue with this position because this seems to imply "PureScript and JavaScript are both JavaScript" is a true statement merely because one of them turns into the other with tooling.

▲

nosianu a day ago | parent | next [-]

TypeScript is indeed Javascript, all you have to do is remove the type annotations. They are not code.

TS does have some minor things like enums that need to be transformed and are actual code, but those are very few, and leftovers from early days of TS, and the TS authors regret having implemented them. For many years now the TS philosophy has been that the CODE part of TS is 100% ECMAscript, and only annotations, which are not code, are added.

The initial Babel transpiler for TS => JS, and still the most part of the current one, simply removes annotations.

It is recommended not to use the few parts that are actual code and not standard JS. They are certainly not needed any more since ES6.

People may get confused because the type syntax itself is almost like a programming language, with conditions and all. But none of that ends up as code, it's not used at runtime.

One of the IMHO worst design decisions of TS was to bundle type checking and transpiling into one tool. That caused sooo many misunderstandings and confusion.

▲

egeozcan a day ago | parent | prev [-]

I think the point here is that all the TS tooling works with JSDoc without any friction. As long as you don't look into the file, from the tooling perspective, a .ts file and a .js file with proper JSDoc annotations are practically the same.

	▲	aatd86 a day ago \| parent [-]
		Except the js files can work in the browser as is.. not the ts one (fortunately I might add, I find ts syntax very loaded at times) Either one is superseding the other one, or they are simply distant cousins, but this is not interchangeable. TS from JSDoc requires a generative pass to. This is a (expected) level of indirection. (unless some tooling does it automatically)