Meh. I'll still know the only actual typing that matters after TypeScript's disappears in the transpiler, and my production code will be smaller because it's not the mangled garbage that "classes" turn into.
And given the likes that comment is getting, it seems I'm not the only old man yelling at it.
Unless it's performance sensitive code, what's the difference? If the developer time saved and bugs prevented is more than the bandwidth costs and time difference, it's worth it.
Anything that helps prevents bugs is not a "crutch", it's a developer productivity tool. Or correcting the analogy, it is a crutch, so that you don't trip and fall. It's not a bad thing. People make mistakes. Period. Admitting that and trying to prevent those mistakes is not a bad thing. Do you have all the unit tests for bugs that would be caught by the compiler? No? Then I don't trust your code. I don't care if you're Brendan Eich or someone junior.
Except that, in practice, this leads to convoluted codebases which are more difficult to organize, read, and maintain, much like the "object oriented JavaScript" (🙃) craze of the early-mid last decade and the silly MVC-for-the-sake-of-MVC projects it led to (which often, somehow, managed to be less readable than the spaghetti codebases they were refactored from).
This isn't jQuery or Underscore/Lodash which, as completely unnecessary as they are now, were handy convenience wrappers that ended up informing the development of JavaScript's own methods because of their utility.
This is "Can't handle JavaScript qua JavaScript? We got you fam. Feel free to hack at JS to make it behave like the language you wish it were." It's basically everything Kyle Simpson warned about in YDKJS.
Oh... And it's also (being generous, if you believe the survey results that half of all JS devs are using TypeScript) a way to immediately slash your available talent pool in half by requiring it.
Depends all on how you use it. Functions with typed parameters and indicating something as nullable or not is going to get you a good chunk of the benefit without straying too far from javascript. If you're doing objects for the sake of objects? Yeah, that can get convoluted if you're not disciplined. Stick with POJO and functional programming if you don't like classes.
Are you saying you never typoed a field? Or do you use jsdoc to make sure you get field names right? If not, what is your testing strategy to make sure you didn't get things wrong. How do you deal with maintenance?
If someone can't handle simple type definitions on function parameters and return types, they're not a dev I want to consider anyway. They don't have the required discipline or flexibility. If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.
If someone can't handle simple type definitions on function parameters and return types
These should be documented anyway. I'd rather enforce the (much simpler, and more necessary) standard comment syntax of JSDOC than that plus a bunch of extra crap which isn't actually part of the language.
Stick with POJO and functional programming if you don't like classes.
Pssst... They're still functions.
They don't have the required discipline or flexibility.
Sounds a lot like someone who not only expects, but insists on one language behaving like another, rather than using the language as designed (if it makes you feel any better, I've long said the same about Python devs and CoffeeScript - just, fortunately, it didn't take off nearly as much... Now, YirgaCheffeScript or SidamoScript? Count me in).
If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.
2.5 if it's JS. You should be using JSDoc (and linting) anyway.
But again, to give TS (utilities) some credit: ts-check (which recognizes JSDoc, and can be set for JavaScript) is a fantastic tool while coding in VS Code. I mean that sincerely.
And tsc is great for turning TS codebases into (at least semi-)usable(/fixable) JS/ES.
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.
Meh. I'll still know the only actual typing that matters after TypeScript's disappears in the transpiler, and my production code will be smaller because it's not the mangled garbage that "classes" turn into.
And given the likes that comment is getting, it seems I'm not the only old man yelling at it.
Unless it's performance sensitive code, what's the difference? If the developer time saved and bugs prevented is more than the bandwidth costs and time difference, it's worth it.
Anything that helps prevents bugs is not a "crutch", it's a developer productivity tool. Or correcting the analogy, it is a crutch, so that you don't trip and fall. It's not a bad thing. People make mistakes. Period. Admitting that and trying to prevent those mistakes is not a bad thing. Do you have all the unit tests for bugs that would be caught by the compiler? No? Then I don't trust your code. I don't care if you're Brendan Eich or someone junior.
Except that, in practice, this leads to convoluted codebases which are more difficult to organize, read, and maintain, much like the "object oriented JavaScript" (🙃) craze of the early-mid last decade and the silly MVC-for-the-sake-of-MVC projects it led to (which often, somehow, managed to be less readable than the spaghetti codebases they were refactored from).
This isn't jQuery or Underscore/Lodash which, as completely unnecessary as they are now, were handy convenience wrappers that ended up informing the development of JavaScript's own methods because of their utility.
This is "Can't handle JavaScript qua JavaScript? We got you fam. Feel free to hack at JS to make it behave like the language you wish it were." It's basically everything Kyle Simpson warned about in YDKJS.
Oh... And it's also (being generous, if you believe the survey results that half of all JS devs are using TypeScript) a way to immediately slash your available talent pool in half by requiring it.
Depends all on how you use it. Functions with typed parameters and indicating something as nullable or not is going to get you a good chunk of the benefit without straying too far from javascript. If you're doing objects for the sake of objects? Yeah, that can get convoluted if you're not disciplined. Stick with POJO and functional programming if you don't like classes.
Are you saying you never typoed a field? Or do you use jsdoc to make sure you get field names right? If not, what is your testing strategy to make sure you didn't get things wrong. How do you deal with maintenance?
If someone can't handle simple type definitions on function parameters and return types, they're not a dev I want to consider anyway. They don't have the required discipline or flexibility. If you've jsdoc'ed your code, you can understand enough of the syntax in like 5 minutes.
These should be documented anyway. I'd rather enforce the (much simpler, and more necessary) standard comment syntax of JSDOC than that plus a bunch of extra crap which isn't actually part of the language.
Pssst... They're still functions.
Sounds a lot like someone who not only expects, but insists on one language behaving like another, rather than using the language as designed (if it makes you feel any better, I've long said the same about Python devs and CoffeeScript - just, fortunately, it didn't take off nearly as much... Now, YirgaCheffeScript or SidamoScript? Count me in).
2.5 if it's JS. You should be using JSDoc (and linting) anyway.
But again, to give TS (utilities) some credit: ts-check (which recognizes JSDoc, and can be set for JavaScript) is a fantastic tool while coding in VS Code. I mean that sincerely.
And tsc is great for turning TS codebases into (at least semi-)usable(/fixable) JS/ES.