7 ms·

I can't imagine maintaining a large JS codebase without types now. For places where you really need dynamic typing the any type is there for you. I certainly w

I can't imagine maintaining a large JS codebase without types now. For places where you really need dynamic typing the any type is there for you. I certainly would never take a job in a pure JS shop.

capableweb 4y ago
I certainly wouldn't take a job in a place where they default to using TypeScript without thinking about the tradeoffs first. Cargo-culting never ends well, and there are no silver-bullets. I'm more afraid of those two "concepts" being a part of "company culture" than having to use JavaScript without TypeScript.
- nsonha 4y ago
  I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a form of documentation). Programming is too hard?
  - camgunz 4y ago
    Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.
    - nsonha 4y ago
      no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
      - camgunz 4y ago
        Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
        nsonha 4y ago
        The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
        camgunz 4y ago
        > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
- EduardoBautista 4y ago
  I can't think of a single trade-off where choosing JavaScript would be better than having absolutely zero run-time errors in production, almost making error monitoring tools useless. Could you please provide a list of these tradeoffs?
  - capableweb 4y ago
    Would of course depend on the situation, and also I'm not employed to evaluate your use of TypeScript vs JavaScript, you usually do this at the start of each project depending on the needs of what you're building. But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer. As a second tradeoff, choosing JavaScript over TypeScript tend to make codebases less complect and more modular, at least in the teams I've been in who maintained codebases with both languages.
    - aew4ytasghe5 4y ago
      Both are your personal experiences, neither of those are a valid tradeoff. My experience with js-land is that choosing a typescript and make use of the @types packages is _the_ modern way of doing js dev. What you describe is basically do the same people did 15 years ago. That is not a trade-off, but a refusal to re-evaluate the situation under changing conditions.
      - capableweb 4y ago
        I'm sorry but if you don't understand what tradeoffs are nor understand what tradeoffs are involved with choosing between JavaScript and TypeScript, I don't think there is much left for us to discuss.
        selfmodruntime 4y ago
        >I'm sorry but if you don't understand what tradeoffs are nor understand what tradeoffs are involved with choosing between JavaScript and TypeScript, I don't think there is much left for us to discuss. You've yet to provide even a single example.
- matthewmacleod 4y ago
  I do understand where you are coming from, and I normally wouldn't say this about any technology – but Typescript is probably the closest thing to an actual silver bullet that has ever existed in front-end tech. In almost all cases it massively improves code quality at a low cost, and if I encountered an organisation that wasn't using it I would expect them to have evaluated it and have extremely clear justifications for that decision front-and-center.
- schwartzworld 4y ago
  At my job, we evaluated TypeScript and thought about the tradeoffs and decided to adopt it for all new front-end code, migrating older code when possible. The decision was considered and made. Do we really need to rehash the discussion every time a new front-end gets set up? How is that cargo culting?
  - capableweb 4y ago
    If the requirements and purposes are the same for every frontend project you do, it obviously makes sense to reuse previous planning and apply it without rehashing the discussions.
    - schwartzworld 4y ago
      Of course they aren't the same, but the benefits of using TypeScript don't go away from one UI to the next.
- cdelsolar 4y ago
  there are no tradeoffs with TypeScript.
  - capableweb 4y ago
    One day you'll want to be able to call yourself "senior" and then you'll realise, everything about software engineering is about balancing tradeoffs and every choice you make comes with tradeoffs.
    - cdelsolar 4y ago
      ... i've been a senior engineer for over 10 years. TS is one of the only technologies i have found where it is only positive, in relation to Javascript.
- itsmeste 4y ago
  "How did you decide for TypeScript, and how do you benefit from it" is among my first questions in interviews for TS positions. It's ironic how rarely I get a good answer, but it offers a good insight into their tech philosophy, and mostly I'd pass on the position. (working in backend)
  - Aeolun 4y ago
    If anyone asked me this I’d be kind of confused. If they really don’t know how choosing Typescript over Javascript benefits them I don’t want to hire them.
    - sangnoir 4y ago
      Interviews are a two way street. What you've said is the equivalent of an interviewee saying "If a company has to ask me how to implement a zero-allocation sorting algorithm in an interview, they are clearly incompetent and I wouldn't work for them". In both cases, the person doing the asking knows the right answer(s) more or less - they are checking if the person across the table does too.
blauditore 4y ago
It's crazy how just a few years ago, many web (turned Node) devs insisted that static types are overrated and one can totally maintain large code bases without. Now with the TS hype, the same people preach hoe useful static types are. I think it was just a mix of stockholm syndrome and lack of experience what working with static types is like.
- Macha 4y ago
  I mean, if you're in 2012, comparing Java 6 or C# 2.0 or C++98 to Ruby or Python, you can see how people come to that conclusion. Local type inference has done wonders for the ergonomics of static typing, and while research-y languages have had it forever (and some like Haskell even allow the scope of inference to go further), it's a relatively recent addition to the mainstream.

I can't imagine maintaining a large JS codebase without types now. For places where you really need dynamic typing the any type is there for you. I certainly would never take a job in a pure JS shop.

capableweb 4y ago

I certainly wouldn't take a job in a place where they default to using TypeScript without thinking about the tradeoffs first. Cargo-culting never ends well, and there are no silver-bullets. I'm more afraid of those two "concepts" being a part of "company culture" than having to use JavaScript without TypeScript.

nsonha 4y ago
I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a form of documentation). Programming is too hard?
- camgunz 4y ago
  Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.
  - nsonha 4y ago
    no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
    - camgunz 4y ago
      Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - code formatter :: style - type system :: tests ...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated. All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
      - nsonha 4y ago
        The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. > - type system :: tests This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API. Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
        camgunz 4y ago
        > The point I was making is, there are a lot of things in software that have no empirical data, so suggesting data driven decision making such as benchmarking because you don't trust Big-O or quantifying typescript's benefits instead of actually thinking about them is a cop out. Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like: "Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system." My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?" In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc. --- > so suggesting data driven decision making such as benchmarking because you don't trust Big-O The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion. > quantifying typescript's benefits instead of actually thinking about them is a cop out This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example: int add(int a, int b) { return a - b; } A type system can tell you a lot about this function: its domain/range, overflow/underflow risks, etc. What it can't do is tell you that the function has the wrong name. Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
EduardoBautista 4y ago
I can't think of a single trade-off where choosing JavaScript would be better than having absolutely zero run-time errors in production, almost making error monitoring tools useless. Could you please provide a list of these tradeoffs?
- capableweb 4y ago
  Would of course depend on the situation, and also I'm not employed to evaluate your use of TypeScript vs JavaScript, you usually do this at the start of each project depending on the needs of what you're building. But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer. As a second tradeoff, choosing JavaScript over TypeScript tend to make codebases less complect and more modular, at least in the teams I've been in who maintained codebases with both languages.
  - aew4ytasghe5 4y ago
    Both are your personal experiences, neither of those are a valid tradeoff. My experience with js-land is that choosing a typescript and make use of the @types packages is _the_ modern way of doing js dev. What you describe is basically do the same people did 15 years ago. That is not a trade-off, but a refusal to re-evaluate the situation under changing conditions.
    - capableweb 4y ago
      I'm sorry but if you don't understand what tradeoffs are nor understand what tradeoffs are involved with choosing between JavaScript and TypeScript, I don't think there is much left for us to discuss.
      - selfmodruntime 4y ago
        >I'm sorry but if you don't understand what tradeoffs are nor understand what tradeoffs are involved with choosing between JavaScript and TypeScript, I don't think there is much left for us to discuss. You've yet to provide even a single example.
matthewmacleod 4y ago
I do understand where you are coming from, and I normally wouldn't say this about any technology – but Typescript is probably the closest thing to an actual silver bullet that has ever existed in front-end tech. In almost all cases it massively improves code quality at a low cost, and if I encountered an organisation that wasn't using it I would expect them to have evaluated it and have extremely clear justifications for that decision front-and-center.
schwartzworld 4y ago
At my job, we evaluated TypeScript and thought about the tradeoffs and decided to adopt it for all new front-end code, migrating older code when possible. The decision was considered and made. Do we really need to rehash the discussion every time a new front-end gets set up? How is that cargo culting?
- capableweb 4y ago
  If the requirements and purposes are the same for every frontend project you do, it obviously makes sense to reuse previous planning and apply it without rehashing the discussions.
  - schwartzworld 4y ago
    Of course they aren't the same, but the benefits of using TypeScript don't go away from one UI to the next.
cdelsolar 4y ago
there are no tradeoffs with TypeScript.
- capableweb 4y ago
  One day you'll want to be able to call yourself "senior" and then you'll realise, everything about software engineering is about balancing tradeoffs and every choice you make comes with tradeoffs.
  - cdelsolar 4y ago
    ... i've been a senior engineer for over 10 years. TS is one of the only technologies i have found where it is only positive, in relation to Javascript.
itsmeste 4y ago
"How did you decide for TypeScript, and how do you benefit from it" is among my first questions in interviews for TS positions. It's ironic how rarely I get a good answer, but it offers a good insight into their tech philosophy, and mostly I'd pass on the position. (working in backend)
- Aeolun 4y ago
  If anyone asked me this I’d be kind of confused. If they really don’t know how choosing Typescript over Javascript benefits them I don’t want to hire them.
  - sangnoir 4y ago
    Interviews are a two way street. What you've said is the equivalent of an interviewee saying "If a company has to ask me how to implement a zero-allocation sorting algorithm in an interview, they are clearly incompetent and I wouldn't work for them". In both cases, the person doing the asking knows the right answer(s) more or less - they are checking if the person across the table does too.

blauditore 4y ago

It's crazy how just a few years ago, many web (turned Node) devs insisted that static types are overrated and one can totally maintain large code bases without. Now with the TS hype, the same people preach hoe useful static types are. I think it was just a mix of stockholm syndrome and lack of experience what working with static types is like.

Macha 4y ago
I mean, if you're in 2012, comparing Java 6 or C# 2.0 or C++98 to Ruby or Python, you can see how people come to that conclusion. Local type inference has done wonders for the ergonomics of static typing, and while research-y languages have had it forever (and some like Haskell even allow the scope of inference to go further), it's a relatively recent addition to the mainstream.