5 ms·

It seems that I fundamentally misunderstand the benefits of TypeScript. I found myself spending hours and hours on reading the type errors stacktraces and addi

It seems that I fundamentally misunderstand the benefits of TypeScript. I found myself spending hours and hours on reading the type errors stacktraces and adding types for libraries. Writing TS code takes 2x time than simple JS... and it is extremely painful experience. In comparison to many old plain JS projects I did - it simply doesn’t make any sense, the TS solves problems which I haven’t experienced at all.

jameshush 6y ago
It's helped me immensely, however the projects I work on get millions of hits a day (I’m in publishing/adtech). More eyeballs means more chances for an edge case to pop up. It's been worth it alone to catch undefined errors at compile time. I'm also on a team of 5+ front end engineers, though and use other team’s internal libraries often, which is probably why it's made a difference. If it seems more hassle then it's worth for what you're working on, the rest of your team isn't bothered, and your clients are happy you don't have to worry too much. I still throw in vanilla JS on other smaller projects every once in a while for those reasons.
Humphrey 6y ago
Yes - there are some pain points - but my experience is that the 2x is worst case. It gets MUCH closer to 1x with experience, and I'd dare to say it will be closer to 0.75x over the long term.
- karatestomp 6y ago
  As soon as a significant portion of the time spent tackling a new feature or addressing a bug becomes reading code (which you may not have written) the types pay off to at least[1] a 0.75x time-multiplier, and I'd say that's very conservative. It also makes it a hell of a lot easier and faster to collaborate on different parts of a feature that interact without exactly overlapping—"here's the interface I expect to implement, code to that, if anything changes TypeScript will tell you without our even having to talk (about that)" [1 EDIT] at most? hahaha.
mattlondon 6y ago
Where I've found that TypeScript is a hindrance is where I want to code fast/lazily. E.g. if I need to add a Bar property to a Foo object, in plain JS you just do it as and when you need to without any extra hassle. This makes hacking something together really fast and low-friction which is nice. Typescript wont let you do that though - you need to go off and define the Bar property on Foo which you might argue slows you down, or seems inappropriate if you only need Bar in certain circumstances and not every time or whatever. Personally I find that the extra rigor that Typescript forces is way worth the extra hassle - it prevents so many subtle bugs, makes refactoring a lot easier, helps multiple people work together on the same code in a sensible way, and IDEs work so much better (in my experience at least). Most popular libraries by the way all have the types defined already - check out https://definitelytyped.org/ https://definitelytyped.org/
- Humphrey 6y ago
  I'd disagree with that - and say this scenario is where TypeScript saves me time. I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.
  - mattlondon 6y ago
    > TS will show me every location I have forgotten to set the Bar property Yeah this is what I was getting at - e.g. say I have 5 functions that all return Foo object, and for just one of them I need to add in an extra Bar property then I need to make sure that all 5 functions also do the Bar property, even if only 1 needs it (or make it optional, but that might screw with the semantics of the one function that does need it). So now I have a Bar on all Foos, even though only 1 function needs it - things start to get messy. The alternative to changing all 5 functions is just to create a separate type for just that one function that needs Bar Either way it is "extra work" if you are used to the fast and lose javascript way of just adding it there and then and not caring about the others. I agree though that TypeScript is way superior as you point out it would just tell you where you screwed up and I would always start with a new TS project rather than JS today, but I still think there is a place for the raw & dangerous world of untyped JS for rapid and unsafe prototyping and hacking where TS can slow you down.
rellekio 6y ago
No: If (typeof x === 'string') {} I personally love TypeScript, but I do have one big hang up. Janky builds in testing. Can't explain it, but sometimes the guarantees TS is supposed to provide don't compile over. Mainly while using nodemon or another auto compile. Have only ran into it a couple times, but it mainly crops up during module linking. Also keep in mind you can use as modules via require('') and skip adding types to a js lib. Be sure to add --module commonjs or the equivalent in config. Why I like TypeScript for myself is writing modules and api's. Mainly: inline documentation. And the pursuit of more of a deterministic outcome in your programs. Still the linking issue bothers me.
sunaurus 6y ago
Writing statically typed code will always be slower than writing dynamically typed code. People don't use static typing for writing code faster, they use it for code that can be READ (and understood) much faster, especially by somebody who doesn't work with that specific piece of code every day. I think it's generally agreed that in most situations, reading code is much more common than writing code, so static typing really make sense.
- winter_blue 6y ago
  > they use it for code that can be READ (and understood) much faster You nailed it. I agree, this is the biggest benefit of static types. I worked at on a several hundred thousand line JS code base at a company, and people were passing objects around, and it was extremely painful to trace code and figure what the structure of the object was. I had to set a breakpoint in the browser, and inspect the object during runtime. Moreover, some fields would randomly be missing, because the field wasn't necessary for that instance of the object. It was infuriatingly maddening. I ended up spending a lot of time adding Flow types to it, of the form: type Foobar = { someField1: string, someField2: number, someField3: Baz, fieldThatIsNotAlwaysThere: ?Qux ... } The untyped state of the code base gave me an extremely hard to resist to add Flow static types wherever I could. I also added a step to the pipeline (with my manager's support) that would break the pipeline and make it impossible to merge new code, if it didn't have Flow static types (and I used flow-coverage to make sure the "any" keyword wasn't being used excessively to side step Flow type checking). I was told by some of my teammates to stop forcing types down their throat. I eventually spent so much reworking large parts of the code base, and adding static types to it that my other work suffered (and I wasn't putting as much time as I should have into it), that I was told to stop spending so much time on adding Flow static types. But it was hard to resist the temptation. When I had to implement a new feature / change a file, I would add Flow types to it, and then be drawn to adding types to the various other files that it connects to (imports from, passes data to, etc). They fired me in the end, for that (not prioritizing the things I was supposed to do well enough) and other reasons (was going through relationship issues and eventually a bad breakup, which caused associated psychological/personal/self-care issues). I've learned my lesson. Dynamic types aren't my cup of tea, and I find dynamically typed code to be repulsive and quite nauseating.

jameshush 6y ago

It's helped me immensely, however the projects I work on get millions of hits a day (I’m in publishing/adtech). More eyeballs means more chances for an edge case to pop up. It's been worth it alone to catch undefined errors at compile time. I'm also on a team of 5+ front end engineers, though and use other team’s internal libraries often, which is probably why it's made a difference. If it seems more hassle then it's worth for what you're working on, the rest of your team isn't bothered, and your clients are happy you don't have to worry too much. I still throw in vanilla JS on other smaller projects every once in a while for those reasons.

Humphrey 6y ago

Yes - there are some pain points - but my experience is that the 2x is worst case. It gets MUCH closer to 1x with experience, and I'd dare to say it will be closer to 0.75x over the long term.

karatestomp 6y ago
As soon as a significant portion of the time spent tackling a new feature or addressing a bug becomes reading code (which you may not have written) the types pay off to at least[1] a 0.75x time-multiplier, and I'd say that's very conservative. It also makes it a hell of a lot easier and faster to collaborate on different parts of a feature that interact without exactly overlapping—"here's the interface I expect to implement, code to that, if anything changes TypeScript will tell you without our even having to talk (about that)" [1 EDIT] at most? hahaha.

mattlondon 6y ago

Where I've found that TypeScript is a hindrance is where I want to code fast/lazily. E.g. if I need to add a Bar property to a Foo object, in plain JS you just do it as and when you need to without any extra hassle. This makes hacking something together really fast and low-friction which is nice. Typescript wont let you do that though - you need to go off and define the Bar property on Foo which you might argue slows you down, or seems inappropriate if you only need Bar in certain circumstances and not every time or whatever. Personally I find that the extra rigor that Typescript forces is way worth the extra hassle - it prevents so many subtle bugs, makes refactoring a lot easier, helps multiple people work together on the same code in a sensible way, and IDEs work so much better (in my experience at least). Most popular libraries by the way all have the types defined already - check out https://definitelytyped.org/ https://definitelytyped.org/

Humphrey 6y ago
I'd disagree with that - and say this scenario is where TypeScript saves me time. I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.
- mattlondon 6y ago
  > TS will show me every location I have forgotten to set the Bar property Yeah this is what I was getting at - e.g. say I have 5 functions that all return Foo object, and for just one of them I need to add in an extra Bar property then I need to make sure that all 5 functions also do the Bar property, even if only 1 needs it (or make it optional, but that might screw with the semantics of the one function that does need it). So now I have a Bar on all Foos, even though only 1 function needs it - things start to get messy. The alternative to changing all 5 functions is just to create a separate type for just that one function that needs Bar Either way it is "extra work" if you are used to the fast and lose javascript way of just adding it there and then and not caring about the others. I agree though that TypeScript is way superior as you point out it would just tell you where you screwed up and I would always start with a new TS project rather than JS today, but I still think there is a place for the raw & dangerous world of untyped JS for rapid and unsafe prototyping and hacking where TS can slow you down.

rellekio 6y ago

No: If (typeof x === 'string') {} I personally love TypeScript, but I do have one big hang up. Janky builds in testing. Can't explain it, but sometimes the guarantees TS is supposed to provide don't compile over. Mainly while using nodemon or another auto compile. Have only ran into it a couple times, but it mainly crops up during module linking. Also keep in mind you can use as modules via require('') and skip adding types to a js lib. Be sure to add --module commonjs or the equivalent in config. Why I like TypeScript for myself is writing modules and api's. Mainly: inline documentation. And the pursuit of more of a deterministic outcome in your programs. Still the linking issue bothers me.

sunaurus 6y ago

Writing statically typed code will always be slower than writing dynamically typed code. People don't use static typing for writing code faster, they use it for code that can be READ (and understood) much faster, especially by somebody who doesn't work with that specific piece of code every day. I think it's generally agreed that in most situations, reading code is much more common than writing code, so static typing really make sense.

winter_blue 6y ago
> they use it for code that can be READ (and understood) much faster You nailed it. I agree, this is the biggest benefit of static types. I worked at on a several hundred thousand line JS code base at a company, and people were passing objects around, and it was extremely painful to trace code and figure what the structure of the object was. I had to set a breakpoint in the browser, and inspect the object during runtime. Moreover, some fields would randomly be missing, because the field wasn't necessary for that instance of the object. It was infuriatingly maddening. I ended up spending a lot of time adding Flow types to it, of the form: type Foobar = { someField1: string, someField2: number, someField3: Baz, fieldThatIsNotAlwaysThere: ?Qux ... } The untyped state of the code base gave me an extremely hard to resist to add Flow static types wherever I could. I also added a step to the pipeline (with my manager's support) that would break the pipeline and make it impossible to merge new code, if it didn't have Flow static types (and I used flow-coverage to make sure the "any" keyword wasn't being used excessively to side step Flow type checking). I was told by some of my teammates to stop forcing types down their throat. I eventually spent so much reworking large parts of the code base, and adding static types to it that my other work suffered (and I wasn't putting as much time as I should have into it), that I was told to stop spending so much time on adding Flow static types. But it was hard to resist the temptation. When I had to implement a new feature / change a file, I would add Flow types to it, and then be drawn to adding types to the various other files that it connects to (imports from, passes data to, etc). They fired me in the end, for that (not prioritizing the things I was supposed to do well enough) and other reasons (was going through relationship issues and eventually a bad breakup, which caused associated psychological/personal/self-care issues). I've learned my lesson. Dynamic types aren't my cup of tea, and I find dynamically typed code to be repulsive and quite nauseating.