2 ms·

I grew up on JavaScript and usually enjoy it, and also adopted TypeScript and usually get along with it. I'd find it difficult to contribute to an enterprise A

I grew up on JavaScript and usually enjoy it, and also adopted TypeScript and usually get along with it. I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.

EMM_386 3y ago
> But, I don't know that it's ever truly helped me move faster It's incredibly helpful to move fast on large projects. It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is. I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean. Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out. That's just one simple example.
- brailsafe 3y ago
  Ya that's sort of what I meant by the rest of the comment, and I agree, in theory, but haven't personally encountered this because I've never come onto a project that's already had a well-established TS implementation. I'm always doing the implementation, and then lose my job before getting to the point where the benefits were realized, and it's quite a slow path to getting to a place where the full codebase of sufficient size is typed, simply because most huge cosebases have evolved over time and aren't completely JS or TS. Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.

EMM_386 3y ago

> But, I don't know that it's ever truly helped me move faster It's incredibly helpful to move fast on large projects. It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is. I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean. Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out. That's just one simple example.

brailsafe 3y ago
Ya that's sort of what I meant by the rest of the comment, and I agree, in theory, but haven't personally encountered this because I've never come onto a project that's already had a well-established TS implementation. I'm always doing the implementation, and then lose my job before getting to the point where the benefits were realized, and it's quite a slow path to getting to a place where the full codebase of sufficient size is typed, simply because most huge cosebases have evolved over time and aren't completely JS or TS. Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.