4 ms·

I'm a senior developer and I've never touched TypeScript and don't have any desire to unless I have no choice. I haven't worked on any projects that were large

I'm a senior developer and I've never touched TypeScript and don't have any desire to unless I have no choice. I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Also I find it a bit verbose and ugly and I'm just not a fan of pseduo Javascript languages that need to be compiled down into JavaScript.

MentallyRetired 6y ago
Same. Lead dev here. Part of my problem stems from the lack of typed libraries across the JS ecosystem. Party supported typing leads to more issues, I've found. Then there's the IDE. I don't use code hinting. In fact, I find it irritating. So, I draw no benefit from TS in this regard. Then there's the cryptic error messages. They've gotten better over the years but I always seem to spend more time debugging TS than writing code. And finally, I just don't run into the kinds of errors people talk about solving with TS. That said, I did enjoy the strong typing that AS4 provided back in the day. But TS is intolerable to me and I've worked with it for years.
- antihero 6y ago
  As another lead/senior dev, I've found that onboarding hires that know some TS into a TS codebase is a hugely slicker process than onboarding people into a pure JS codebase, simply because the typechecker can do the overhead of having to check each call etcetera. The issues you are having sound like teething issues but as someone who's worked with TS for years I've found they aren't hugely difficult to overcome, either with @types packages, or writing declarations, or declaring module (and having an "unsafe" library that people use with care). > I don't use code hinting. In fact, I find it irritating. I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind.
  - meheleventyone 6y ago
    > I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind. Very much this. I pushed to move the scripting language for our game engine project dot big bang from JS to TS primarily because the typing makes the entire codebase much more discoverable and beginner friendly. Using Monaco embedded in the browser programmers get great auto-complete and inline code documentation as well as the compilation step making some simple and common runtime errors much harder or impossible to run into. Qualitatively the mixed experience bunch we have using it now all much prefer the TS experience to the JS one we had before.
    - pcthrowaway 6y ago
      I'm learning typescript on-the-fly as I migrate an existing React+express codebase to it; Curious if you'd recommend Monaco over VS Code, and if so, why?
      - meheleventyone 6y ago
        Monaco is the engine that powers VS Code. It’s super neat you can just embed it. https://github.com/microsoft/monaco-editor https://github.com/microsoft/monaco-editor
antihero 6y ago
> I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Can I esk exactly how you're considered senior if you've not worked on any projects large enough to warrant type checking?
Aldipower 6y ago
Same here. I still do not get it. I see the benefits of typed languages for use cases controlling binary data, like hardware controlling, drivers or binary file formats. And actually you can write very type safe code in pure JavaScript. 1. (arg) => if (typeof arg !== "string) throw new Error() Of course, this is executed during runtime (which could have benefits too sometimes) and not at transpile time. Yes, you can laugh at me. But.. You should be always aware of the types you are using, which data is coming in and if the function is type critical, which is only the case for some functions, it is even more fault safe doing it this way, because your app is spitting an error during runtime, which will definitely be fixed very quickly. :) To validate data, use typed structs. 2. You need to write good tests anyway. Tests should test with malformed and faulty data always. I and the teams I had, maintained and coded big JS applications. I can remember only one case, where TypeScript could have been helped with typing. But also, we had no test written for it, so..

MentallyRetired 6y ago

Same. Lead dev here. Part of my problem stems from the lack of typed libraries across the JS ecosystem. Party supported typing leads to more issues, I've found. Then there's the IDE. I don't use code hinting. In fact, I find it irritating. So, I draw no benefit from TS in this regard. Then there's the cryptic error messages. They've gotten better over the years but I always seem to spend more time debugging TS than writing code. And finally, I just don't run into the kinds of errors people talk about solving with TS. That said, I did enjoy the strong typing that AS4 provided back in the day. But TS is intolerable to me and I've worked with it for years.

antihero 6y ago
As another lead/senior dev, I've found that onboarding hires that know some TS into a TS codebase is a hugely slicker process than onboarding people into a pure JS codebase, simply because the typechecker can do the overhead of having to check each call etcetera. The issues you are having sound like teething issues but as someone who's worked with TS for years I've found they aren't hugely difficult to overcome, either with @types packages, or writing declarations, or declaring module (and having an "unsafe" library that people use with care). > I don't use code hinting. In fact, I find it irritating. I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind.
- meheleventyone 6y ago
  > I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind. Very much this. I pushed to move the scripting language for our game engine project dot big bang from JS to TS primarily because the typing makes the entire codebase much more discoverable and beginner friendly. Using Monaco embedded in the browser programmers get great auto-complete and inline code documentation as well as the compilation step making some simple and common runtime errors much harder or impossible to run into. Qualitatively the mixed experience bunch we have using it now all much prefer the TS experience to the JS one we had before.
  - pcthrowaway 6y ago
    I'm learning typescript on-the-fly as I migrate an existing React+express codebase to it; Curious if you'd recommend Monaco over VS Code, and if so, why?
    - meheleventyone 6y ago
      Monaco is the engine that powers VS Code. It’s super neat you can just embed it. https://github.com/microsoft/monaco-editor https://github.com/microsoft/monaco-editor

antihero 6y ago

> I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Can I esk exactly how you're considered senior if you've not worked on any projects large enough to warrant type checking?

Aldipower 6y ago

Same here. I still do not get it. I see the benefits of typed languages for use cases controlling binary data, like hardware controlling, drivers or binary file formats. And actually you can write very type safe code in pure JavaScript. 1. (arg) => if (typeof arg !== "string) throw new Error() Of course, this is executed during runtime (which could have benefits too sometimes) and not at transpile time. Yes, you can laugh at me. But.. You should be always aware of the types you are using, which data is coming in and if the function is type critical, which is only the case for some functions, it is even more fault safe doing it this way, because your app is spitting an error during runtime, which will definitely be fixed very quickly. :) To validate data, use typed structs. 2. You need to write good tests anyway. Tests should test with malformed and faulty data always. I and the teams I had, maintained and coded big JS applications. I can remember only one case, where TypeScript could have been helped with typing. But also, we had no test written for it, so..