Fair enough, preference is a valid argument all things being equal.
And property type safety in the IDE without compiling as you immediately type.
So that exists with both systems, and this is my argument... if it's just preference then that's cool... I can understand that, but then the overall question of how productive a team will be using a tool that is only picked because of preference will come up.
Preference makes sense when we are only choosing a tool on the basis of superficial qualities like the colour for instance (blue hammer vs red hammer), but if the tool is fundamentally different (and demonstrably and objectively less productive) then it becomes a whole other discussion.
Your views are skewed to your world view of Javascript only. Totally ok but not true for Typescript only people.
Typescript can be written in Javascript only, which I have to do sometimes when using Javascript libs that don't have def files. So I'm not against Javascript, I use it every day. I still prefer Typescript and my job requires it.
I get where you are coming from but it's not true I'm applying a skewed / biased view to this. To me this is a cost / benefit calculation. I'm looking purely at objective facts (happy to have any of these reasonably disputed):
1) TypeScript code takes longer to code than a JSDoc comment (because IDEs auto-generate JSDoc)
2) TypeScript adds additional compile time to projects - sometimes quite significant additional time
3) TypeScript requires additional modules / third-party toolsets and setup
4) TypeScript achieves nothing that cannot be done via JSDoc and a correctly setup linting and pre-commit system (except maybe the currently non-standard things like decorator support which if you really wanted to you could use babel to achieve)
5) TypeScript doesn't play well with the existing eco-system when def files are not present
6) TypeScript has to compile to JavaScript to run on your target environment
7) TypeScript is yet-another thing that JS developers have to learn and keep up to date with
On the other hand:
1) JSDoc code can be auto-generated from inference by IDEs making it very quick to write what is missing by filling in the blanks the IDE has left for you - therefore converting an existing codebase to typed code requires zero changes to the actual code you have written - the risk of converting is nil.
2) JSDoc does not compile, the code you write is the code you are executing and all that compile time from TS is removed - additionally JSDoc encourages documenting your code and you can generate documentation from it automatically - see isogenicengine.com/docs-reference.... for an example of documentation that was completely generated from JS code I wrote. I literally did not have to create any of that HTML, it was all autogenerated.
3) JSDoc is natively supported by almost every IDE. No additional software is required to get type checking in your IDE.
4) JSDoc does everything that TypeScript does, has been around for years before TypeScript even existed and for most developers who aren't coming to JS as new devs, JSDoc has been a defacto standard
5) JSDoc adoption among libraries in the eco-system is vastly superior to TypeScript adoption, it's far more likely you can see library code types via JSDoc than there being a def file for TS
6) If you have to compile TS to JS, why not just write JS. Since the tools to do what you want already exist, the devs that know JS vastly outnumber the devs that know TS, hiring is easier and integrating with existing teams is easier.
7) KISS principal
The cost / benefit is overly weighted in favour of JSDoc that TS seems so untenable by comparison.
I still prefer Typescript
I'm not trying to change your mind about your preference, it's personal and it's your right...
my job requires it
This is the part that I'm arguing against, and I realise this is likely out of your control, but at some point in the future if someone making that decision happens across this discussion, at a bare minimum they will ask questions and realise there are alternatives before committing to a solution.
Choosing TS means infusing it throughout your codebase. Changing later is painful and requires precision since modifying code is dangerous. Choosing JSDoc ties you in to nothing and changing your mind later requires no functional code changes.
I realise this was a hefty speech but can you see what I'm getting at here? I'm not espousing zealotry, I'm endorsing simplicity and choice over complexity and lock-in.
"Complexity and lock-in?" How can this possibly be true when Typescript can run in JavaScript only mode.
On lost time: I can't tell you how much time I've lost on poor javascript practices, e.g. the worst being declaring the same object in multiple places with keyname spelling errors, with values not expected like numeric over string. Most of all almost all javascript code I have maintained in the past (written by other people) was the most convoluted monolithic code I have ever seen. No separation of concerns, nothing DRY, no SOLID principals. The interesting thing is that I can get into the minds of what they were thinking when they created it. I can't tell you how undisciplined most are... Monolithic code is technical debt in a major way from day one.
BTW software studies all show that up to 80% of all software cost is in maintenance and often done by people who've never seen the code before. You can't possibly be factoring in the cost of maintaining monolithic Javascript code. It's the stuff Migrations to new Architecture is required, you know like the AngularJS rewrite which blew everyone out of the water. When software architecture is abandoned the cost to recoup is in the billions.
From code bases I've seen, most Javascript only people haven't a clue on good architectural practices, its code-and-go as fast as possible. Who cares about software principals, the simple most being DRY.
One other note, if Typescript is so costly why did Google adopt it saying it's a much better model for Organize Modules on large projects. This translates to easier to maintain.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well... that's a reason for either JSDoc or TypeScript. It's certainly not a differentiator!
It is to me Rob. I prefer typescript...
And property type safety in the IDE without compiling as you immediately type.
Fair enough, preference is a valid argument all things being equal.
So that exists with both systems, and this is my argument... if it's just preference then that's cool... I can understand that, but then the overall question of how productive a team will be using a tool that is only picked because of preference will come up.
Preference makes sense when we are only choosing a tool on the basis of superficial qualities like the colour for instance (blue hammer vs red hammer), but if the tool is fundamentally different (and demonstrably and objectively less productive) then it becomes a whole other discussion.
Your views are skewed to your world view of Javascript only. Totally ok but not true for Typescript only people.
Typescript can be written in Javascript only, which I have to do sometimes when using Javascript libs that don't have def files. So I'm not against Javascript, I use it every day. I still prefer Typescript and my job requires it.
I get where you are coming from but it's not true I'm applying a skewed / biased view to this. To me this is a cost / benefit calculation. I'm looking purely at objective facts (happy to have any of these reasonably disputed):
1) TypeScript code takes longer to code than a JSDoc comment (because IDEs auto-generate JSDoc)
2) TypeScript adds additional compile time to projects - sometimes quite significant additional time
3) TypeScript requires additional modules / third-party toolsets and setup
4) TypeScript achieves nothing that cannot be done via JSDoc and a correctly setup linting and pre-commit system (except maybe the currently non-standard things like decorator support which if you really wanted to you could use babel to achieve)
5) TypeScript doesn't play well with the existing eco-system when def files are not present
6) TypeScript has to compile to JavaScript to run on your target environment
7) TypeScript is yet-another thing that JS developers have to learn and keep up to date with
On the other hand:
1) JSDoc code can be auto-generated from inference by IDEs making it very quick to write what is missing by filling in the blanks the IDE has left for you - therefore converting an existing codebase to typed code requires zero changes to the actual code you have written - the risk of converting is nil.
2) JSDoc does not compile, the code you write is the code you are executing and all that compile time from TS is removed - additionally JSDoc encourages documenting your code and you can generate documentation from it automatically - see isogenicengine.com/docs-reference.... for an example of documentation that was completely generated from JS code I wrote. I literally did not have to create any of that HTML, it was all autogenerated.
3) JSDoc is natively supported by almost every IDE. No additional software is required to get type checking in your IDE.
4) JSDoc does everything that TypeScript does, has been around for years before TypeScript even existed and for most developers who aren't coming to JS as new devs, JSDoc has been a defacto standard
5) JSDoc adoption among libraries in the eco-system is vastly superior to TypeScript adoption, it's far more likely you can see library code types via JSDoc than there being a def file for TS
6) If you have to compile TS to JS, why not just write JS. Since the tools to do what you want already exist, the devs that know JS vastly outnumber the devs that know TS, hiring is easier and integrating with existing teams is easier.
7) KISS principal
The cost / benefit is overly weighted in favour of JSDoc that TS seems so untenable by comparison.
I'm not trying to change your mind about your preference, it's personal and it's your right...
This is the part that I'm arguing against, and I realise this is likely out of your control, but at some point in the future if someone making that decision happens across this discussion, at a bare minimum they will ask questions and realise there are alternatives before committing to a solution.
Choosing TS means infusing it throughout your codebase. Changing later is painful and requires precision since modifying code is dangerous. Choosing JSDoc ties you in to nothing and changing your mind later requires no functional code changes.
I realise this was a hefty speech but can you see what I'm getting at here? I'm not espousing zealotry, I'm endorsing simplicity and choice over complexity and lock-in.
"Complexity and lock-in?" How can this possibly be true when Typescript can run in JavaScript only mode.
On lost time: I can't tell you how much time I've lost on poor javascript practices, e.g. the worst being declaring the same object in multiple places with keyname spelling errors, with values not expected like numeric over string. Most of all almost all javascript code I have maintained in the past (written by other people) was the most convoluted monolithic code I have ever seen. No separation of concerns, nothing DRY, no SOLID principals. The interesting thing is that I can get into the minds of what they were thinking when they created it. I can't tell you how undisciplined most are... Monolithic code is technical debt in a major way from day one.
BTW software studies all show that up to 80% of all software cost is in maintenance and often done by people who've never seen the code before. You can't possibly be factoring in the cost of maintaining monolithic Javascript code. It's the stuff Migrations to new Architecture is required, you know like the AngularJS rewrite which blew everyone out of the water. When software architecture is abandoned the cost to recoup is in the billions.
From code bases I've seen, most Javascript only people haven't a clue on good architectural practices, its code-and-go as fast as possible. Who cares about software principals, the simple most being DRY.
One other note, if Typescript is so costly why did Google adopt it saying it's a much better model for Organize Modules on large projects. This translates to easier to maintain.