3 ms·

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 pr

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.
    - camgunz 4y ago
      The typescript compiler is slow, and sometimes you have to escape hatch the type system, or use libraries that aren't typed. Type annotations can be pretty complicated, and at least sometimes are very noisy and make code less readable. You probably have tests anyway, and depending on your problem space, type errors may be such a small proportion of your errors that a using a type checker isn't justifiable. Finding an error in your typescript code from a JavaScript error message is hard and frustrating (there is always a source map bug). As an aside, at least to me your posts are coming off as really combative in this thread. You might get more constructive responses if you adopted a more curious, open tone. Edit: found this on page... 4 of HN? https://twitter.com/swyx/status/1350427690814251010 https://twitter.com/swyx/status/1350427690814251010 .
      - selfmodruntime 4y ago
        Now that is a good example. I've encountered the problem of compile times myself. I've asked Daniel Rosenwasser about reimplementing the TSC compiler in a compiled language for a better speedup, but he said it wasn't worth the hassle because the compiler moves so fast and the spec is pretty vast at it's current state. > type errors may be such a small proportion of your errors that a using a type checker isn't justifiable This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is. > As an aside, at least to me your posts are coming off as really combative in this thread You are correct in this. Sorry. I will fix my comments to come off as less abrasive.
        camgunz 4y ago
        > I've asked Daniel Rosenwasser about reimplementing the TSC compiler in a compiled language for a better speedup, but he said it wasn't worth the hassle because the compiler moves so fast and the spec is pretty vast at it's current state. Oh super interesting! I wonder if the solution is like, tsc becomes a reference compiler. I'm pretty sure people would absolutely love a Rust implementation that was fast but a little behind. A lot easier to daydream about than to do though, haha. > This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is. Yeah and I do miss this in dynamic languages. Interfaces (and typed data structures) have great descriptive power just on their own. There are run time packages for this (prop-types, etc) but... run time is worse haha.
doix 4y ago
> 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. [citation needed]... My experience is the exact opposite. Javascript code bases I've worked with had crazy mega functions that would accept any arbitrary input and try to return something. Typescript code bases (in my experience) tend to be more modular because the interfaces between things are clearly defined. If you want to use code written by someone else, it's immediately obvious what structure your data needs to have to work with their code. > 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. I mean, they are talking about having parts written in rust: > Rust-based replacements. Once we have a more well-defined API, we may be able to swap out pieces into Rust-based alternatives for performance. This could look like creating NAPI modules written in Rust for Node.js, writing in Rust and compiling to WebAssembly, creating a standalone ESLint executable written in Rust that calls into the JavaScript portions, or other approaches. That looks like an _extremely_ complex build system setup compared to using the Typescript. They are also planning to document the types anyway: > ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages. The only possible trade-off I can think of is that type checking with tsc + JSDoc results in a faster build than using typescript directly. Personally, I find it a bit odd to use tsc + JSDoc instead of TS, but hey, they can do what they want.
Aeolun 4y ago
I’m not sure I’d say pure JS is easier to contribute to. Having type information around your codebase makes it much easier to know what comes from where, even if you haven’t traced the source of the variable all the way to the start. Like, you are theoretically correct, but practically the extra complexity of using Typescript over Javascript is running ‘npm install typescript’ after installing node. You certainly have less build tooling without tsc, but the benefit there is tiny. There’s some mild reasons to go for pure JS, and a lot of absolutely gigantic reasons to go for Typescript (in my opinion).

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.
  - camgunz 4y ago
    The typescript compiler is slow, and sometimes you have to escape hatch the type system, or use libraries that aren't typed. Type annotations can be pretty complicated, and at least sometimes are very noisy and make code less readable. You probably have tests anyway, and depending on your problem space, type errors may be such a small proportion of your errors that a using a type checker isn't justifiable. Finding an error in your typescript code from a JavaScript error message is hard and frustrating (there is always a source map bug). As an aside, at least to me your posts are coming off as really combative in this thread. You might get more constructive responses if you adopted a more curious, open tone. Edit: found this on page... 4 of HN? https://twitter.com/swyx/status/1350427690814251010 https://twitter.com/swyx/status/1350427690814251010 .
    - selfmodruntime 4y ago
      Now that is a good example. I've encountered the problem of compile times myself. I've asked Daniel Rosenwasser about reimplementing the TSC compiler in a compiled language for a better speedup, but he said it wasn't worth the hassle because the compiler moves so fast and the spec is pretty vast at it's current state. > type errors may be such a small proportion of your errors that a using a type checker isn't justifiable This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is. > As an aside, at least to me your posts are coming off as really combative in this thread You are correct in this. Sorry. I will fix my comments to come off as less abrasive.
      - camgunz 4y ago
        > I've asked Daniel Rosenwasser about reimplementing the TSC compiler in a compiled language for a better speedup, but he said it wasn't worth the hassle because the compiler moves so fast and the spec is pretty vast at it's current state. Oh super interesting! I wonder if the solution is like, tsc becomes a reference compiler. I'm pretty sure people would absolutely love a Rust implementation that was fast but a little behind. A lot easier to daydream about than to do though, haha. > This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is. Yeah and I do miss this in dynamic languages. Interfaces (and typed data structures) have great descriptive power just on their own. There are run time packages for this (prop-types, etc) but... run time is worse haha.

doix 4y ago

> 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. [citation needed]... My experience is the exact opposite. Javascript code bases I've worked with had crazy mega functions that would accept any arbitrary input and try to return something. Typescript code bases (in my experience) tend to be more modular because the interfaces between things are clearly defined. If you want to use code written by someone else, it's immediately obvious what structure your data needs to have to work with their code. > 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. I mean, they are talking about having parts written in rust: > Rust-based replacements. Once we have a more well-defined API, we may be able to swap out pieces into Rust-based alternatives for performance. This could look like creating NAPI modules written in Rust for Node.js, writing in Rust and compiling to WebAssembly, creating a standalone ESLint executable written in Rust that calls into the JavaScript portions, or other approaches. That looks like an _extremely_ complex build system setup compared to using the Typescript. They are also planning to document the types anyway: > ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages. The only possible trade-off I can think of is that type checking with tsc + JSDoc results in a faster build than using typescript directly. Personally, I find it a bit odd to use tsc + JSDoc instead of TS, but hey, they can do what they want.

Aeolun 4y ago

I’m not sure I’d say pure JS is easier to contribute to. Having type information around your codebase makes it much easier to know what comes from where, even if you haven’t traced the source of the variable all the way to the start. Like, you are theoretically correct, but practically the extra complexity of using Typescript over Javascript is running ‘npm install typescript’ after installing node. You certainly have less build tooling without tsc, but the benefit there is tiny. There’s some mild reasons to go for pure JS, and a lot of absolutely gigantic reasons to go for Typescript (in my opinion).