First of all. Thanks for the argumented and detailed answer :)
I'm also using typescript every day at work.
For the first point about how typescript handle its target I see your point. I still prefer the way browserslist handle it. But ok.
This is a false statement. Typescript is absolutely a strict syntactic superset of javascript. If you disagree, please point to javascript that the typescript compiler can't understand.
I invite you to read the medium article I linked. It is possible to write code which will be parsed, compiled and changed by typescript even if it was valid javascript at the beggining. It's a specific case which probably nobody won't ever encounter in the real world. But it's there and that's it !
As for decorators, they are currently a stage 2 proposal, thus they aren't valid javascript. In typescript, decorators are an experimental feature, in which the documentation explicitly notes, "Decorators are an experimental feature that may change in future releases."
Ok so, you admit that in that case typescript isn't really a fully specified language :D. It is for everything but the decorators ;) In addition of what whenever you upgrade the typescript compiler you can encounter bugs and regression. Upgrading can (and will due to Murphy's law) break your code. which mean that the specification can change.
Use JSDoc instead. Why?
Because the one thing you're using typescript for types are perfectly handled by simple comments. KISS principle.
"A big advantage to use JSDoc instead of typescript is that you write javascript which remove any need for a compilation step."
I'm confused. In early sections of your post you've pointed to many javascript features that aren't supported in all browsers.
What I want is to have control over the code that is shipped to the user. Either using features which will be transpiled and knowing what the output will look like or not using them because the output doesn't meet my quality criteria (Avoid class when targeting legacy browser for example).
I don't want to use all the latest features. I want to use some good features which benefits me and the user. I want to be able to focus on recent browser while maintaining compatibility with IE (if I need).
In this case JSDoc types are just not advanced enough compared to typescript.
That is a false assumption ;) Once again some people have explained it far better than me. JSDoc is perfectly able to type javascript.
As for the tooling. Yes typescript tooling is a little better. Because typescript is more used than JSDoc. My interogation are about why is that the case when for the same result typescript introduce a lot more complexity ?
Typescript is easy to learn, so onboarding new developers is not cost prohibitive.
If javascript is a subset of typescript and typescript is easy to learn. Javascript must be easier to learn ^^.
Typescript can be safe. If an entire application is strongly typed and the types at the application boundaries are validated, then typescript can reduce the application's potential bugs to programmer errors only.
Agree TYPES ARE GREAT We should use them
Existing applications can be migrated slowly to typescript.
It's even simplier to migrate them to JSDoc, it's just writting comments.
Typescript is a popular language. Last year 80% of programmers would like to use or learn typescript.
And ?!? Again I'm asking why !
If people want only types. JSDoc can provide them. Typescript is more complexe for really small benefit.
If people want mostly compilation benefits and extra features. Babel is better.
If they want both they can combine JSDoc and babel. Instead if they want the compilation power of babel they combine it with typescript. Which is strange because both of them are compiler even if you use one only for striping types (which by the way can lead you to make typescript manipulate invalid typescript code).
First of all. Thanks for the argumented and detailed answer :)
I'm also using typescript every day at work.
For the first point about how typescript handle its target I see your point. I still prefer the way browserslist handle it. But ok.
This is a false statement. Typescript is absolutely a strict syntactic superset of javascript. If you disagree, please point to javascript that the typescript compiler can't understand.
I invite you to read the medium article I linked. It is possible to write code which will be parsed, compiled and changed by typescript even if it was valid javascript at the beggining. It's a specific case which probably nobody won't ever encounter in the real world. But it's there and that's it !
As for decorators, they are currently a stage 2 proposal, thus they aren't valid javascript. In typescript, decorators are an experimental feature, in which the documentation explicitly notes, "Decorators are an experimental feature that may change in future releases."
Ok so, you admit that in that case typescript isn't really a fully specified language :D. It is for everything but the decorators ;) In addition of what whenever you upgrade the typescript compiler you can encounter bugs and regression. Upgrading can (and will due to Murphy's law) break your code. which mean that the specification can change.
Use JSDoc instead.
Why?
Because the one thing you're using typescript for types are perfectly handled by simple comments. KISS principle.
"A big advantage to use JSDoc instead of typescript is that you write javascript which remove any need for a compilation step."
I'm confused. In early sections of your post you've pointed to many javascript features that aren't supported in all browsers.
What I want is to have control over the code that is shipped to the user. Either using features which will be transpiled and knowing what the output will look like or not using them because the output doesn't meet my quality criteria (Avoid class when targeting legacy browser for example).
I don't want to use all the latest features. I want to use some good features which benefits me and the user. I want to be able to focus on recent browser while maintaining compatibility with IE (if I need).
In this case JSDoc types are just not advanced enough compared to typescript.
That is a false assumption ;) Once again some people have explained it far better than me. JSDoc is perfectly able to type javascript.
As for the tooling. Yes typescript tooling is a little better. Because typescript is more used than JSDoc. My interogation are about why is that the case when for the same result typescript introduce a lot more complexity ?
Typescript is easy to learn, so onboarding new developers is not cost prohibitive.
If javascript is a subset of typescript and typescript is easy to learn. Javascript must be easier to learn ^^.
Typescript can be safe. If an entire application is strongly typed and the types at the application boundaries are validated, then typescript can reduce the application's potential bugs to programmer errors only.
Agree TYPES ARE GREAT We should use them
Existing applications can be migrated slowly to typescript.
It's even simplier to migrate them to JSDoc, it's just writting comments.
Typescript is a popular language. Last year 80% of programmers would like to use or learn typescript.
And ?!? Again I'm asking why !
If people want only types. JSDoc can provide them. Typescript is more complexe for really small benefit.
If people want mostly compilation benefits and extra features. Babel is better.
If they want both they can combine JSDoc and babel. Instead if they want the compilation power of babel they combine it with typescript. Which is strange because both of them are compiler even if you use one only for striping types (which by the way can lead you to make typescript manipulate invalid typescript code).
I don't like the fact that typescript is an hybrid thing between a type system and a bundler. It's not KISS.
That's it simple word for a simple thing :D