re: TypeScript is a waste of time. Change my mind. VIEW POST

TOP OF THREAD FULL DISCUSSION
re: We previously used JSDoc comments with type info, which worked fine and is still a decent solution when working in plain JS because most IDEs under...

As Jeff Atwood said, the best code is the one that is self-documenting. I follow that rule, and I believe that static typing and JSDoc comments just cement in bad code even further (cause then refactoring it takes even more work).

There are certain patterns that become difficult if not impossible to enforce across a codebase. Not using shotgun surgery, for example. I think regardless of how much CI pipelining you do, ensuring the quality of the codebase still comes down to the skill level of the developers, proactiveness of developers with regard to regular refactoring, and the proactiveness of managers in maintaining code review processes and hence enforcing code quality.

I agree that JSDocs can get stale, but TS types don’t have that same affliction. Do you realize that you don’t have to explicitly create interfaces? That’s why I’m so confused by this point:

As Jeff Atwood said, the best code is the one that is self-documenting. I follow that rule, and I believe that static typing and JSDoc comments just cement in bad code even further (cause then refactoring it takes even more work).

TypeScript can infer the return type of a function. So it that manner... TypeScript is the most effective language at creating “code as documentation.”

For instance everything in this example is standard JS but when it’s run through the TS compiler it catches the error implicitly:

function createMockUser(){
    return {
         firstName: Bob,
         lastName: Smith
    }
}

const myUser = createMockUser();

console.log(myUser.name.toLowerCase()); // this will cause a compiler error

Update: Based on Edward’s feedback below I’d like to clarify that you have the option of explicitly defining the return type too (more info here). I personally find it amazing that you can have implicit or explicit return types. Is there another language that allows that?

No. That does NOT make TypeScript is the most effective language at creating “code as documentation.” simply because it can infer returned types from the function, because you can always implicitly return the wrong thing.

And put aside whether liking typescript or not, this is the attitude that leads me to dislike the typescript community. The title says "change my mind", and you are definitely not changing anyone's mind.

Edward, my goal is to help people to get happier at work. For me, part of that happiness equation is TypeScript. If I’m not being convincing, then please let me know how I can better be of service to the larger community. I want people to understand more. If through that understanding people discover that TypeScript isn’t right for them, then I’m happy. If they discover that TypeScript is right for them, then I’m happy too. So please let me know what I can do. Is there a type of problem or example situation that I can illustrate with a code example?

This tone is better, and I appreciate that.

I work across multiple programming languages over years, and I think that every language has its own philosophy and its own way to achieve certain objectives (either it being the best is subjective).

Typescript is one language that I have to work with closely recently. While I appreciate some of the good things TS can bring to developers, I wouldn't say it is one-size-fit-all language for all the practical use cases.

In this particular discussion, I think a elaboration of how you can achieve "code as documentation" with inferred types in TS with some code example would be helpful. (Though I personally thing proper unit tests and JDoc would server better in this particular aspect, and it is not a TS specific thing).

I updated the original comment with examples. I don’t understand the “tone” comment though. If you’re reading my comments and assuming that I have some kind emotion behind them, then that’s a tone that you’re projecting onto it. My goal has always been to spread knowledge and enthusiasm.

As for the testing comment, every professional project I’ve developed recently has over 75% test coverage and it uses TypeScript. Why does everyone bring up testing vs types like they’re mutually exclusive? I like both. A lot.

I do not think testing and typing are "mutually exclusive". But one of the "pros" people keep pitching about Typescript is the "code as documentation" and "less error" talking point, which I think is already achieved by having proper unit tests whether the language is typed or not.

I could be biased here, but just talking about this specific "merit" Typescript can give is not convincing to me. It could be also due to working style, because I tend to write very thorough unit test coverage (~98% across the projects I developed in the past few years).

code of conduct - report abuse