10 ms·

Why? Typescript just compiles down to JS, and type definitions are used IDEs so they still help when writing JS. How does removing typescript help you?

baybal2 7y ago
> How does removing typescript help you? https://github.com/microsoft/TypeScript/issues https://github.com/microsoft/TypeScript/issues Please count the number of open bugs JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness. Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day. Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs. Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it. No, it does not pay off at all
- manigandham 7y ago
  Yea bugs exist, yet there are still thousands of teams using it to build very complex projects with less bugs because of Typescript safety and features. TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference? Can you give a concrete example where TS is a blocking issue for your development?
  - baybal2 7y ago
    If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough. People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously. How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS. > Can you give a concrete example where typescript is a blocking issue for your development? Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit. Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.
    - sbergot 7y ago
      Do you still put your seat belt in your car after 5+ years of driving experience? If yes, would you say that you do that because your driving skills are "plainly not good enough"? Typescript allow you to spend less energy on minor issues like typos and more energy on design. It also provides you with the ability to reason locally about some code. When you inspect a function in js, you cannot know what are the contracts that it has to deal with. To be sure you have to unravel all the calling and called functions. Typescript also enables better intellisense. About your issues: - I never had tsc dying on my hand in 5 years. - About the transpilation noise: it can be as noisy as you want. Have you checked the default result for the es6 target? It litteraly look like your source code with only your type signatures stripped. The noise comes from the transpilation to lower versions and bundling and those are independent of typescript.
    - thawaway1837 7y ago
      Considering typescript compiles down to JS, and incredibly readable JS at that, the fact that your developers are unable to debug the JS directly may indicate that they are not as amazing at JS as you may believe they are.
    - rpastuszak 7y ago
      > If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough. What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge? Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.
      - baybal2 7y ago
        Of course we do that, and I looked at Flow a few times. But typing errors are such a minor thing in comparison to everything else, than "everything else" is of much higher on the priority list
    - deleted 7y ago
      [deleted]
- scrollaway 7y ago
  You're removing typescript because you think it's creating bugs... You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS? This is some prime dailywtf material.
  - afiori 7y ago
    Well not exactly, the parent said something quite different, in the comment they were comparing tooling not languages and they say that the tooling makes for a significant part of the bugs they have to solve so they want a build process as slim as possible. Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.
- inertiatic 7y ago
  >Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. Who are these mythical people? Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
  - orange8 7y ago
    I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter. I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way. >> Do they just magically decipher what interface an argument conforms to? This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply. >> What methods are accessible on a returned result from any random library they're using? Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
    - manigandham 7y ago
      Typescript is as strongly typed as you want it to be. You can easily work with dynamic types and it will fill in where it can.
      - danShumway 7y ago
        Eh... people say this, and in theory it should be true. If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful. For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch. You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down. The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.
- cageface 7y ago
  I would never hire a JS dev with this attitude towards typescript nor work for one. I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.
  - smichel17 7y ago
    I like going type-less for prototyping (pun intended), then converting to or rewriting in typescript for anything I'm going to need to maintain or refactor.
- blackoil 7y ago
  Ratio of open/closed issue is a very strong indicator of how active a project is. My perspective, with 21k closed and 4k open issues, shows a very active project where I should not be finding major blockers if I adopt it. If it has an issue 1000s of people are actively looking at it and it will be caught at beta stage or will be solved quickly.
- williamdclt 7y ago
  This is the weirdest and least convincing thing I've read about Typescript. I won't comment on such experienced devs spending so much time struggling with tooling that shouldn't change all that often, but I have to react that "fixing Typescript" means "fixing your code". If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems. > most of devs we hire are long past the stage when typing errors are a thing for them This is just not a thing.
- miffy900 7y ago
  > https://github.com/microsoft/TypeScript/issues https://github.com/microsoft/TypeScript/issues > Please count the number of open bugs You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with. Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively. > Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs. Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.
- MaxBarraclough 7y ago
  > long past the stage when typing errors are a thing for them Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on. No-one is too smart for type systems to be helpful. > it does not pay off at all You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.
- matthewmacleod 7y ago
  Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.
  - karatestomp 7y ago
    Seriously. “We manage OK without static types” is one thing but “LOL we’re not n00bs so we don’t need your productivity-killing static types” is... wow. WTF. Keep anything that team writes far away from important data and processes, please.
- SaxonRobber 7y ago
  Sounds like you need to raise the bar on hiring if learning static typing is an impediment. I recommend less JS monkeys and looking for actual engineers.
  - cvlasdkv 7y ago
    Their 6+ year engineers are getting paid less than many interns do in America according to said poster. The big tech monopoly means that hiring good senior engineers is nearly impossible. :)

baybal2 7y ago

> How does removing typescript help you? https://github.com/microsoft/TypeScript/issues https://github.com/microsoft/TypeScript/issues Please count the number of open bugs JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness. Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day. Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs. Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it. No, it does not pay off at all

manigandham 7y ago
Yea bugs exist, yet there are still thousands of teams using it to build very complex projects with less bugs because of Typescript safety and features. TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference? Can you give a concrete example where TS is a blocking issue for your development?
- baybal2 7y ago
  If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough. People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously. How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS. > Can you give a concrete example where typescript is a blocking issue for your development? Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit. Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.
  - sbergot 7y ago
    Do you still put your seat belt in your car after 5+ years of driving experience? If yes, would you say that you do that because your driving skills are "plainly not good enough"? Typescript allow you to spend less energy on minor issues like typos and more energy on design. It also provides you with the ability to reason locally about some code. When you inspect a function in js, you cannot know what are the contracts that it has to deal with. To be sure you have to unravel all the calling and called functions. Typescript also enables better intellisense. About your issues: - I never had tsc dying on my hand in 5 years. - About the transpilation noise: it can be as noisy as you want. Have you checked the default result for the es6 target? It litteraly look like your source code with only your type signatures stripped. The noise comes from the transpilation to lower versions and bundling and those are independent of typescript.
  - thawaway1837 7y ago
    Considering typescript compiles down to JS, and incredibly readable JS at that, the fact that your developers are unable to debug the JS directly may indicate that they are not as amazing at JS as you may believe they are.
  - rpastuszak 7y ago
    > If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough. What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge? Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.
    - baybal2 7y ago
      Of course we do that, and I looked at Flow a few times. But typing errors are such a minor thing in comparison to everything else, than "everything else" is of much higher on the priority list
  - deleted 7y ago
    [deleted]
scrollaway 7y ago
You're removing typescript because you think it's creating bugs... You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS? This is some prime dailywtf material.
- afiori 7y ago
  Well not exactly, the parent said something quite different, in the comment they were comparing tooling not languages and they say that the tooling makes for a significant part of the bugs they have to solve so they want a build process as slim as possible. Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.
inertiatic 7y ago
>Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. Who are these mythical people? Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
- orange8 7y ago
  I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter. I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way. >> Do they just magically decipher what interface an argument conforms to? This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply. >> What methods are accessible on a returned result from any random library they're using? Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
  - manigandham 7y ago
    Typescript is as strongly typed as you want it to be. You can easily work with dynamic types and it will fill in where it can.
    - danShumway 7y ago
      Eh... people say this, and in theory it should be true. If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful. For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch. You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down. The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.
cageface 7y ago
I would never hire a JS dev with this attitude towards typescript nor work for one. I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.
- smichel17 7y ago
  I like going type-less for prototyping (pun intended), then converting to or rewriting in typescript for anything I'm going to need to maintain or refactor.
blackoil 7y ago
Ratio of open/closed issue is a very strong indicator of how active a project is. My perspective, with 21k closed and 4k open issues, shows a very active project where I should not be finding major blockers if I adopt it. If it has an issue 1000s of people are actively looking at it and it will be caught at beta stage or will be solved quickly.
williamdclt 7y ago
This is the weirdest and least convincing thing I've read about Typescript. I won't comment on such experienced devs spending so much time struggling with tooling that shouldn't change all that often, but I have to react that "fixing Typescript" means "fixing your code". If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems. > most of devs we hire are long past the stage when typing errors are a thing for them This is just not a thing.
miffy900 7y ago
> https://github.com/microsoft/TypeScript/issues https://github.com/microsoft/TypeScript/issues > Please count the number of open bugs You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with. Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively. > Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs. Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.
MaxBarraclough 7y ago
> long past the stage when typing errors are a thing for them Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on. No-one is too smart for type systems to be helpful. > it does not pay off at all You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.
matthewmacleod 7y ago
Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them. It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.
- karatestomp 7y ago
  Seriously. “We manage OK without static types” is one thing but “LOL we’re not n00bs so we don’t need your productivity-killing static types” is... wow. WTF. Keep anything that team writes far away from important data and processes, please.
SaxonRobber 7y ago
Sounds like you need to raise the bar on hiring if learning static typing is an impediment. I recommend less JS monkeys and looking for actual engineers.
- cvlasdkv 7y ago
  Their 6+ year engineers are getting paid less than many interns do in America according to said poster. The big tech monopoly means that hiring good senior engineers is nearly impossible. :)