5 ms·

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 mon

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.
      - 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).
ilikehurdles 4y ago
Type-checking doesn’t take any serious codebase to “zero run-time errors in production.” It’s not a magic pill. Monitoring tools are useful for far more than telling about runtime errors.
- HelloNurse 4y ago
  Typescript type declarations check that the Rube Goldberg tooling du jour managed to process them, proving that the user managed to follow instructions.
mplanchard 4y ago
I’ve worked at several typescript shops and I have certainly never seen “absolutely zero runtime errors in production.” Even Rust, which has a much stronger type system than TS, does not prevent all runtime errors. Types can prevent a certain class of bugs/errors, and that’s great, but zero runtime errors is overstating it by a wide margin.
- kajaktum 4y ago
  So you’d rather have more bugs than less? Given any piece of JS code, you can’t actually reason about it unless you also know its caller. Or you do defensive programming. At which point, why even bother.
  - mplanchard 4y ago
    That's not what I said at all. I generally choose to work with languages with strong, static types, because I appreciate the added documentation and security the types provide. That said, I'm not going to sit here and pretend like I can just ignore the possibility of runtime errors because I write Rust and Typescript. I'm also not going to pretend like there's anything wrong with working in a language without static typing. I'm an emacs user, so I write plenty of Emacs Lisp and have a great time with it. I used to write Python professionally before type annotations were introduced, and yet still somehow managed to produce software that worked. Types are great, but they're just one tool in the toolbox.
    - kajaktum 4y ago
      >Types are great, but they're just one tool in the toolbox. Of course, everything is just tool. Its up to us to decide if we want to use it or not. What I don't understand is why wouldn't you use it. I totally understand if its fun to cobble together some webserver using only bash scripts. But if you're writing something as big, complex, and widely used as ESLint, I am very surprised if you don't choose something that is more performant and maintainable. It is almost irresponsible. I have plenty of fun side projects that should never ever be used in production because I know its really bad. I never claimed that using Rust will magically make all your sort implementation correct. Of course this is an insane claim. But like I said, if you take any snippet of JavaScript, you actually cannot reason about it without looking at all the calls to that function, plus all the functions that calls to that. Given any variable S, what is its value? Who knows. I guess you just have to run this massive test suite that we wrote. There's WAY more possible incorrect JavaScript code than there are Rust. I have written webservers in TypeScript and Rust. The moment I get something out of serde in Rust, I know for a fact this is a string. If the key doesn't exist, its None. In TypeScript, I don't have the same confidence. Did they wrote the correct validator? Wait did they add a default value? Does this interface match what we have? Oh its a string...but its actually Date. Wait...why does this bool keep returning false...(https://stackoverflow.com/questions/59046629/boolean-parameter-in-request-body-is-always-true-in-nestjs-api https://stackoverflow.com/questions/59046629/boolean-paramet...) I could have written 1000s of unit tests...Or just use type and fail the "test" at compile time. >there's anything wrong with working in language without static typing Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
ballenf 4y ago
Inspecting deployed code without the transpilation noise is sometimes nice. Or maybe there's a workaround for that?
- jwond 4y ago
  You could use source maps. Besides, I’d imagine the deployed code would be minimized anyway regardless of whether TypeScript is used.
  - postalrat 4y ago
    Are there any advantages to minimizing server code?
- mcluck 4y ago
  Source maps allow you to read your code exactly as it was written
cloverich 4y ago
While it does reduce numerous errors, it does not enforce or even reveal exceptions like Java / Go / Rust. Typescript is my preferred language, but IMHO if reducing production errors is the goal I think there are better choices still.

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.
    - 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).

ilikehurdles 4y ago

Type-checking doesn’t take any serious codebase to “zero run-time errors in production.” It’s not a magic pill. Monitoring tools are useful for far more than telling about runtime errors.

HelloNurse 4y ago
Typescript type declarations check that the Rube Goldberg tooling du jour managed to process them, proving that the user managed to follow instructions.

mplanchard 4y ago

I’ve worked at several typescript shops and I have certainly never seen “absolutely zero runtime errors in production.” Even Rust, which has a much stronger type system than TS, does not prevent all runtime errors. Types can prevent a certain class of bugs/errors, and that’s great, but zero runtime errors is overstating it by a wide margin.

kajaktum 4y ago
So you’d rather have more bugs than less? Given any piece of JS code, you can’t actually reason about it unless you also know its caller. Or you do defensive programming. At which point, why even bother.
- mplanchard 4y ago
  That's not what I said at all. I generally choose to work with languages with strong, static types, because I appreciate the added documentation and security the types provide. That said, I'm not going to sit here and pretend like I can just ignore the possibility of runtime errors because I write Rust and Typescript. I'm also not going to pretend like there's anything wrong with working in a language without static typing. I'm an emacs user, so I write plenty of Emacs Lisp and have a great time with it. I used to write Python professionally before type annotations were introduced, and yet still somehow managed to produce software that worked. Types are great, but they're just one tool in the toolbox.
  - kajaktum 4y ago
    >Types are great, but they're just one tool in the toolbox. Of course, everything is just tool. Its up to us to decide if we want to use it or not. What I don't understand is why wouldn't you use it. I totally understand if its fun to cobble together some webserver using only bash scripts. But if you're writing something as big, complex, and widely used as ESLint, I am very surprised if you don't choose something that is more performant and maintainable. It is almost irresponsible. I have plenty of fun side projects that should never ever be used in production because I know its really bad. I never claimed that using Rust will magically make all your sort implementation correct. Of course this is an insane claim. But like I said, if you take any snippet of JavaScript, you actually cannot reason about it without looking at all the calls to that function, plus all the functions that calls to that. Given any variable S, what is its value? Who knows. I guess you just have to run this massive test suite that we wrote. There's WAY more possible incorrect JavaScript code than there are Rust. I have written webservers in TypeScript and Rust. The moment I get something out of serde in Rust, I know for a fact this is a string. If the key doesn't exist, its None. In TypeScript, I don't have the same confidence. Did they wrote the correct validator? Wait did they add a default value? Does this interface match what we have? Oh its a string...but its actually Date. Wait...why does this bool keep returning false...(https://stackoverflow.com/questions/59046629/boolean-parameter-in-request-body-is-always-true-in-nestjs-api https://stackoverflow.com/questions/59046629/boolean-paramet...) I could have written 1000s of unit tests...Or just use type and fail the "test" at compile time. >there's anything wrong with working in language without static typing Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.

ballenf 4y ago

Inspecting deployed code without the transpilation noise is sometimes nice. Or maybe there's a workaround for that?

jwond 4y ago
You could use source maps. Besides, I’d imagine the deployed code would be minimized anyway regardless of whether TypeScript is used.
- postalrat 4y ago
  Are there any advantages to minimizing server code?
mcluck 4y ago
Source maps allow you to read your code exactly as it was written

cloverich 4y ago

While it does reduce numerous errors, it does not enforce or even reveal exceptions like Java / Go / Rust. Typescript is my preferred language, but IMHO if reducing production errors is the goal I think there are better choices still.