4 ms·

I feel like the odd man out in discussions like these. I don't like Typescript and I regret pushing to integrate it into a project at work. I've found it vast

I feel like the odd man out in discussions like these. I don't like Typescript and I regret pushing to integrate it into a project at work. I've found it vastly increases incidental complexity and affords little to no benefit to me. The IDE completions are nice, but ultimately not worth the price, in my humble and honest opinion.

ipnon 6y ago
How large is your TypeScript project? What were your type issues before you integrated? My work has benefited from TypeScript because we can now propagate changes to our unstable API throughout our medium sized application using the compiler. We are fairly certain that all of our components are integrated if the compiler is silent. Before this certainty, we would frequently push broken API integrations to production. The complexity of TypeScript doesn't seem to benefit projects that are already clean and tested. TypeScript gave us some confidence of correctness when we had disorganized code and inadequate test coverage.
- wry_discontent 6y ago
  It's about 20kloc. I encounter seemingly nonstop opaque type errors that come usually when I upgrade TS versions. I'll stipulate this was mostly written when we decided to add TS, and I was new to TS when I added it, but I tried really hard. As an example, it took me a full week to properly add type definitions to a HOC, and I had to rope in a couple other engineers across that time who had more TS experience. Eventually I got it working, but decided to deprecate the HOC cause the file exploded from being about 50loc to well over 250.
  - treve 6y ago
    The last large project I added Typescript, it took several weeks to add types. It took another year to learn how to write code in a way that is more likely to be successful in Typescript. If you have a ton of state, classes, high coupling and a lot of variance in your data structures (which Javascript really easily allows), Typescript is not an instant game-changer. This is not that different from having good test coverage is easier during development than adding it later, as you will end up writing your code in a way that makes things more decoupled and testable. It was way easier to get to that sweet spot with our Node.js code vs. our React code. React code is still more of a battle than non-React code, although functional components has made this better. Class based components suck the most and we just opt for using "any" instead of fighting it. Don't get me started about HoC.
deleted 6y ago
[deleted]
cageface 6y ago
After working in Typescript for 18 months I've moved onto a new Rails project and I miss type checking so much every single day. There are so many dumb bugs that have slipped their way into production that would have been caught by type checks and null checks. It's professionally embarrassing for the client to see this stuff that would have been stopped by better tools.
- genuine_smiles 6y ago
  Have you looked at Sorbet? https://sorbet.org/ https://sorbet.org/
  - cageface 6y ago
    Yeah I tried using this on our current project but it couldn't really handle Rails + all the gems we're using. I think it's very difficult to retrofit types onto a codebase with deep roots in dynamic code.
    - mekster 6y ago
      Just hope ruby 3 would integrate static typing.
keb_ 6y ago
I also disliked my time with TypeScript, but perhaps its value hasn't made itself entirely apparent to me. Most of my programming experience has also been with dynamically typed languages. I think if you had already spent enough time with a language like JavaScript or Lua and familiarized yourself with its quirks/footguns, you learn how to avoid the common pitfalls of not having a strict type system. Although I've found that TypeScript is a great way to attract devs who hate JavaScript to try working on front-end.
- cageface 6y ago
  When working with devs that have grown up on dynamically typed languages I often find that they have not really thought carefully about the structure of their data and there are essentially many ad hoc data types strewn throughout the code. Thinking in types from the beginning leads to much better structured code and stronger abstractions IMO.
  - DabbyDabberson 6y ago
    I couldn't agree more. I think the introduction of types in JS (either TS or flow) has been the single biggest leap in front end development in a decade.
  - wry_discontent 6y ago
    I see the same thing, but in people who primarily work in statically typed languages. I don't think there's much of a pattern in wrt types, but people who don't think about data.
    - cageface 6y ago
      Specifying all those complex ad hoc data types in a statically typed language is so tedious I think it pushes you to start looking for unifying abstractions.
- mekster 6y ago
  What editor are you using? If you don't use an editor that supports TS, then it's all moot. Editors are meant to auto complete any parameters that you have typed as well as provide errors that don't fit to your typing. Using editors like vim wouldn't work.
johnghanks 6y ago
ok
camgunz 6y ago
Yeah by the numbers I like it (sum types!), but what put me off is in practice, TS is built for autocomplete. If you aren’t using that, it’s a real pain to guess what type you need to say, and you’re basically digging through code or bad/old docs to find out. I also found the typing to not really help. Non-null stuff is nice, but without range types, I don’t think the trade off is worth it. It helps about as much as Go’s type system but asks you to do 3x the work, restrict yourself to typed libraries, and setup some pretty tricky tooling.
qudat 6y ago
The real benefit is with refactoring. It is built-in testing. If I change an interface because a business requirement changed, I immediately follow a trail of errors that I need to fix. If types are setup properly, making major changes is dramatically simpler to accomplish.
orange8 6y ago
TS was designed to solve a problem. If you cannot see the problem, then you do not need it. Unless when working in teams with devs more used to thinking and structuring their code around types.
- mekster 6y ago
  Actually TS shows you the problem when you hadn't realized. Use it with a proper editor that supports TS like VS code or IntelliJ and figure it out.
  - orange8 6y ago
    I have used TS before, and VS Code is the best editor. I simply do not have a problem with JS, or dynamic languages for that matter.
schwartzworld 6y ago
HN has a high proportion of experienced programmers coming from typed languages. If you are a C# dev who has to write JS, I'm sure typescript is a breath of fresh air, but from where I stand it's awful. The whole point of TS is to reduce the friction in writing JS for those people. However, from where I stand, Typescript sucks. Sucks sucks sucks. It takes everything I love about JS programming and turns it into suck.

ipnon 6y ago

How large is your TypeScript project? What were your type issues before you integrated? My work has benefited from TypeScript because we can now propagate changes to our unstable API throughout our medium sized application using the compiler. We are fairly certain that all of our components are integrated if the compiler is silent. Before this certainty, we would frequently push broken API integrations to production. The complexity of TypeScript doesn't seem to benefit projects that are already clean and tested. TypeScript gave us some confidence of correctness when we had disorganized code and inadequate test coverage.

wry_discontent 6y ago
It's about 20kloc. I encounter seemingly nonstop opaque type errors that come usually when I upgrade TS versions. I'll stipulate this was mostly written when we decided to add TS, and I was new to TS when I added it, but I tried really hard. As an example, it took me a full week to properly add type definitions to a HOC, and I had to rope in a couple other engineers across that time who had more TS experience. Eventually I got it working, but decided to deprecate the HOC cause the file exploded from being about 50loc to well over 250.
- treve 6y ago
  The last large project I added Typescript, it took several weeks to add types. It took another year to learn how to write code in a way that is more likely to be successful in Typescript. If you have a ton of state, classes, high coupling and a lot of variance in your data structures (which Javascript really easily allows), Typescript is not an instant game-changer. This is not that different from having good test coverage is easier during development than adding it later, as you will end up writing your code in a way that makes things more decoupled and testable. It was way easier to get to that sweet spot with our Node.js code vs. our React code. React code is still more of a battle than non-React code, although functional components has made this better. Class based components suck the most and we just opt for using "any" instead of fighting it. Don't get me started about HoC.

deleted 6y ago

[deleted]

cageface 6y ago

After working in Typescript for 18 months I've moved onto a new Rails project and I miss type checking so much every single day. There are so many dumb bugs that have slipped their way into production that would have been caught by type checks and null checks. It's professionally embarrassing for the client to see this stuff that would have been stopped by better tools.

genuine_smiles 6y ago
Have you looked at Sorbet? https://sorbet.org/ https://sorbet.org/
- cageface 6y ago
  Yeah I tried using this on our current project but it couldn't really handle Rails + all the gems we're using. I think it's very difficult to retrofit types onto a codebase with deep roots in dynamic code.
  - mekster 6y ago
    Just hope ruby 3 would integrate static typing.

keb_ 6y ago

I also disliked my time with TypeScript, but perhaps its value hasn't made itself entirely apparent to me. Most of my programming experience has also been with dynamically typed languages. I think if you had already spent enough time with a language like JavaScript or Lua and familiarized yourself with its quirks/footguns, you learn how to avoid the common pitfalls of not having a strict type system. Although I've found that TypeScript is a great way to attract devs who hate JavaScript to try working on front-end.

cageface 6y ago
When working with devs that have grown up on dynamically typed languages I often find that they have not really thought carefully about the structure of their data and there are essentially many ad hoc data types strewn throughout the code. Thinking in types from the beginning leads to much better structured code and stronger abstractions IMO.
- DabbyDabberson 6y ago
  I couldn't agree more. I think the introduction of types in JS (either TS or flow) has been the single biggest leap in front end development in a decade.
- wry_discontent 6y ago
  I see the same thing, but in people who primarily work in statically typed languages. I don't think there's much of a pattern in wrt types, but people who don't think about data.
  - cageface 6y ago
    Specifying all those complex ad hoc data types in a statically typed language is so tedious I think it pushes you to start looking for unifying abstractions.
mekster 6y ago
What editor are you using? If you don't use an editor that supports TS, then it's all moot. Editors are meant to auto complete any parameters that you have typed as well as provide errors that don't fit to your typing. Using editors like vim wouldn't work.

johnghanks 6y ago

camgunz 6y ago

Yeah by the numbers I like it (sum types!), but what put me off is in practice, TS is built for autocomplete. If you aren’t using that, it’s a real pain to guess what type you need to say, and you’re basically digging through code or bad/old docs to find out. I also found the typing to not really help. Non-null stuff is nice, but without range types, I don’t think the trade off is worth it. It helps about as much as Go’s type system but asks you to do 3x the work, restrict yourself to typed libraries, and setup some pretty tricky tooling.

qudat 6y ago

The real benefit is with refactoring. It is built-in testing. If I change an interface because a business requirement changed, I immediately follow a trail of errors that I need to fix. If types are setup properly, making major changes is dramatically simpler to accomplish.

orange8 6y ago

TS was designed to solve a problem. If you cannot see the problem, then you do not need it. Unless when working in teams with devs more used to thinking and structuring their code around types.

mekster 6y ago
Actually TS shows you the problem when you hadn't realized. Use it with a proper editor that supports TS like VS code or IntelliJ and figure it out.
- orange8 6y ago
  I have used TS before, and VS Code is the best editor. I simply do not have a problem with JS, or dynamic languages for that matter.

schwartzworld 6y ago

HN has a high proportion of experienced programmers coming from typed languages. If you are a C# dev who has to write JS, I'm sure typescript is a breath of fresh air, but from where I stand it's awful. The whole point of TS is to reduce the friction in writing JS for those people. However, from where I stand, Typescript sucks. Sucks sucks sucks. It takes everything I love about JS programming and turns it into suck.