8 ms·

Question from someone who rarely uses TypeScript: why don't you use TypeScript and why do you advocate for its removal?

by keb_ 5y ago

runawaybottle 5y ago
I can tell you why I don’t like it. Everyone’s subtle OCD seems to come out with Typescript. Instead of cutting down on the number of function arguments, people don’t give a shit. They add more and more args, and maniacally define the types for every little thing. It’s like some odd version of list-making (many people get a kick out of compulsively making these detailed lists). It used to be that you think very carefully about how to keep a function simple, but Typescript is bringing out this dark side in people that allows them to just define 15 argument functions, so long as is has a nice exhaustive Type. Sometimes you have to save people from themselves. I’ll stay hyperbolic and say in several years time, we will all be drowning in type-inflated code bases. JavaScript people always find a way to make things hard.
- mikevm 5y ago
  Somehow people have been programming just fine in statically typed languages for decades without turning their code into a shitshow. It just appears that JS attracts a lot of poor programmers due to the low barrier to entry.
  - holoduke 5y ago
    Poor programmers everywhere. Java, C++, PHP, JavaScript. I have seen them all. Like C in JavaScript is so flexible that it is hard to enforce certain (company) standards. That makes it a bit more prone to issues. But many great examples of good plain js programs
- ballenf 5y ago
  One defense of this point is that I see developers writing Typescript code with the constant hinting/intellicode from IntelliJ and somewhat blind to the readability of the naked code. You get this tight coupling of code and editor/IDE with Typescript that I didn't see coming. The benefits from the coupling are very real and probably outweigh the costs, but there is a price to be paid. It means that you have to manually go line by line through new code in your editor instead of scanning only with your eyes. It also makes reviewing the code anywhere else harder -- GitHub, etc. This is made more painful when types are necessary to understanding code, but the types are found in a file far away. But this is coming from someone who sometimes gets nostalgic for the days of printing out code, moving over to a big empty desk with pen in hand. Then going back to the terminal to make those changes. I also have seen ballooning function signatures that would have otherwise resulting in refactoring to an options object or otherwise refactoring.
  - runawaybottle 5y ago
    but the types are found in a file far away. Don’t even get me started on that. It seems, now more than ever, we need another ‘JavaScript the Good Parts: 2021 Update’. A lot has been introduced in the last decade, and not all of it should be used to the degree we are using them. I just don’t know who has the credibility to pull it off at this moment.
  - brundolf 5y ago
    Something I've found that really helps is putting a soft-ban on named types with generic type parameters. You almost never truly need them if you aren't writing a library, and they add a whole lot to inscrutability.
  - afiori 5y ago
    I am a strong believer that typed languages in general should have a compiler annotation mode that with configurable level of verbosity formats explicit types and structural info (dead code, exhaustive matching) into structured comments. This could maybe also be a pre-commit git hook transformation so that you could see how type changes propagate. The essential feature must be that the compiler overwrites them often and that they must be informative only.
    - brundolf 5y ago
      This is a good idea. Languages with advanced type inference have only become mainstream in the last 5 years or so, so I bet we're going to see a lot of innovations like this crop up over time
j-pb 5y ago
We don't use it because we found it to be too brittle. The type system is really bolted on. We've hit super weird bugs, in the compiler. And any kind of preprocessing/compilation introduces layers that make in-process debugging much harder. If browsers actually spoke a strongly typed functional language a la ML/Haskell natively we'd probably switch in a heartbeat. But otherwise it's either vanilla js (no jsx either, simply htm) or Rust compiled to WASM. And we'd advocate for its removal because it incurs opportunity costs. The deno team is small enough as is, and we don't think that TS is a selling point for it. The great tooling it provides is however so we'd rather see more of that.
- brundolf 5y ago
  TypeScript support is Deno's main selling point for many people. That was the headlining feature, that's the first thing most people know about it, and I think that's the only reason it's gotten significant traction. The other stuff has value, but it's a huge thing to ask an entire ecosystem to pack up shop and move. You have to offer more than just incremental improvements to performance, tooling, and permissions-management. You have to offer a paradigm-shift. I think Deno would be dead in the water if it didn't offer TypeScript as a first-class citizen, despite all the other ways it improves on Node. As for the type system itself: it is bolted on, yes, and I don't think that's a weakness. Flow tried to be a JS type system that wasn't bolted-on, and it was horrible to use because it was constantly fighting against the base language and all of its idioms. TypeScript is empathetic to JavaScript programmers: it knows things will never be perfect, so it gives you the tools to make them really quite good but gets out of your way when it reaches its limits. I think this is a wonderful thing and a huge driver of its success. Don't let perfect be the enemy of good.
  - j-pb 5y ago
    You act as if the typescript compiler and source-maps suddenly stopped working once they're out of the core. I think you're hugely underselling the value that deno provides as a tool and attribute too much virtue to TS. Maybe the advertisement for deno had it backwards. If people knew how much better it is than node, it'd gain significantly more traction. Instead they just think it's "that typescript" thing and ignore it. If deno dies it's probably because of that typescript shadow, not despite of it.

Question from someone who rarely uses TypeScript: why don't you use TypeScript and why do you advocate for its removal?

by keb_ 5y ago

Question from someone who rarely uses TypeScript: why don't you use TypeScript and why do you advocate for its removal?

I can tell you why I don’t like it. Everyone’s subtle OCD seems to come out with Typescript. Instead of cutting down on the number of function arguments, people don’t give a shit. They add more and more args, and maniacally define the types for every little thing. It’s like some odd version of list-making (many people get a kick out of compulsively making these detailed lists). It used to be that you think very carefully about how to keep a function simple, but Typescript is bringing out this dark side in people that allows them to just define 15 argument functions, so long as is has a nice exhaustive Type. Sometimes you have to save people from themselves. I’ll stay hyperbolic and say in several years time, we will all be drowning in type-inflated code bases. JavaScript people always find a way to make things hard.

mikevm 5y ago
Somehow people have been programming just fine in statically typed languages for decades without turning their code into a shitshow. It just appears that JS attracts a lot of poor programmers due to the low barrier to entry.
- holoduke 5y ago
  Poor programmers everywhere. Java, C++, PHP, JavaScript. I have seen them all. Like C in JavaScript is so flexible that it is hard to enforce certain (company) standards. That makes it a bit more prone to issues. But many great examples of good plain js programs
ballenf 5y ago
One defense of this point is that I see developers writing Typescript code with the constant hinting/intellicode from IntelliJ and somewhat blind to the readability of the naked code. You get this tight coupling of code and editor/IDE with Typescript that I didn't see coming. The benefits from the coupling are very real and probably outweigh the costs, but there is a price to be paid. It means that you have to manually go line by line through new code in your editor instead of scanning only with your eyes. It also makes reviewing the code anywhere else harder -- GitHub, etc. This is made more painful when types are necessary to understanding code, but the types are found in a file far away. But this is coming from someone who sometimes gets nostalgic for the days of printing out code, moving over to a big empty desk with pen in hand. Then going back to the terminal to make those changes. I also have seen ballooning function signatures that would have otherwise resulting in refactoring to an options object or otherwise refactoring.
- runawaybottle 5y ago
  but the types are found in a file far away. Don’t even get me started on that. It seems, now more than ever, we need another ‘JavaScript the Good Parts: 2021 Update’. A lot has been introduced in the last decade, and not all of it should be used to the degree we are using them. I just don’t know who has the credibility to pull it off at this moment.
- brundolf 5y ago
  Something I've found that really helps is putting a soft-ban on named types with generic type parameters. You almost never truly need them if you aren't writing a library, and they add a whole lot to inscrutability.
- afiori 5y ago
  I am a strong believer that typed languages in general should have a compiler annotation mode that with configurable level of verbosity formats explicit types and structural info (dead code, exhaustive matching) into structured comments. This could maybe also be a pre-commit git hook transformation so that you could see how type changes propagate. The essential feature must be that the compiler overwrites them often and that they must be informative only.
  - brundolf 5y ago
    This is a good idea. Languages with advanced type inference have only become mainstream in the last 5 years or so, so I bet we're going to see a lot of innovations like this crop up over time

j-pb 5y ago

We don't use it because we found it to be too brittle. The type system is really bolted on. We've hit super weird bugs, in the compiler. And any kind of preprocessing/compilation introduces layers that make in-process debugging much harder. If browsers actually spoke a strongly typed functional language a la ML/Haskell natively we'd probably switch in a heartbeat. But otherwise it's either vanilla js (no jsx either, simply htm) or Rust compiled to WASM. And we'd advocate for its removal because it incurs opportunity costs. The deno team is small enough as is, and we don't think that TS is a selling point for it. The great tooling it provides is however so we'd rather see more of that.

brundolf 5y ago
TypeScript support is Deno's main selling point for many people. That was the headlining feature, that's the first thing most people know about it, and I think that's the only reason it's gotten significant traction. The other stuff has value, but it's a huge thing to ask an entire ecosystem to pack up shop and move. You have to offer more than just incremental improvements to performance, tooling, and permissions-management. You have to offer a paradigm-shift. I think Deno would be dead in the water if it didn't offer TypeScript as a first-class citizen, despite all the other ways it improves on Node. As for the type system itself: it is bolted on, yes, and I don't think that's a weakness. Flow tried to be a JS type system that wasn't bolted-on, and it was horrible to use because it was constantly fighting against the base language and all of its idioms. TypeScript is empathetic to JavaScript programmers: it knows things will never be perfect, so it gives you the tools to make them really quite good but gets out of your way when it reaches its limits. I think this is a wonderful thing and a huge driver of its success. Don't let perfect be the enemy of good.
- j-pb 5y ago
  You act as if the typescript compiler and source-maps suddenly stopped working once they're out of the core. I think you're hugely underselling the value that deno provides as a tool and attribute too much virtue to TS. Maybe the advertisement for deno had it backwards. If people knew how much better it is than node, it'd gain significantly more traction. Instead they just think it's "that typescript" thing and ignore it. If deno dies it's probably because of that typescript shadow, not despite of it.