6 ms·

> You get a massive bug catcher for free with TypeScript...it tells me their philosophy/priorities are completely backward. This is a superficial take. TypeScr

> You get a massive bug catcher for free with TypeScript...it tells me their philosophy/priorities are completely backward. This is a superficial take. TypeScript is not free. You are adding a compilation step that takes time, slowing down feedback in certain workflows, as well as a rather large dependency. It certainly can be worth asking why they chose JS given some of your perceived benefits of TS but not using it doesn't mean that their philosophy is backwards.

tengbretson 4y ago
[flagged]
- jrockway 4y ago
  There are no code smells in personal projects, but this isn't one anyway. Every text editor I've ever used has had a single button inside that editor to change the code in the editor to what you just typed in. For an author who has written a blog post on how they eschew unit tests, this is probably the most important feature for one. A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.
vouwfietsman 4y ago
Just a headsup, these days the typescript tooling is actually ergonomic with esbuild and vite. If you still use javascript and know about this tooling, I am very curious why you would choose to do so, because esbuild will literally compile AND bundle all your js before you can say "compilation".
- turblety 4y ago
  What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code. Also, using esbuild to transpile your TS will not actually check the types. It just transforms it back to JS. For typescript, you really need the official library which is slow and bloated.
  - vouwfietsman 4y ago
    Yes you need an extra build step, but really I cannot overstate how simple this step is. There is no webpack config hell, there is no giant dependency chain, there is no long wait for anything, there is no magic file globs and mimetypes. In 10-100ms, esbuild (a single small dependency) will take 3 command line arguments, grab all your linked TS from a single TS entrypoint file, and spit out a single (possibly minified) js file that you can immediately invoke with node. Instead of node bla.js, you do esbuild && node bla.js, you don't care what happens inside. Indeed it will not check your types, but as stated elsewhere your IDE can do this for you. This is actually beautiful because it allows you to get correctness feedback on your code but your code will never fail to run due to arbitrary type complaints. If you later feel like you want the full correctness of TS, maybe during CI/CD, you can run the slower compiler and get a gatekeeper telling you if you are doing something fishy.
  - smt88 4y ago
    > What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code. It is free if your IDE uses the TypeScript language server and gives you errors integrated with your code editor. You don't have to transpile if you don't want to. You can, as you said, just use esbuild to strip away the type information. > For typescript, you really need the official library which is slow and bloated. See above. You absolutely don't. And it's not slow or bloated at all. It has incremental builds, which are essentially instantaneous after the initial build.
vbezhenar 4y ago
deno consumes typescript. IMO every JS engine should just consume typescript (without type checking). AFAIK TypeScript is designed to be easily consumed by JS engines. It's a pity that V8 ignores that property.
- capableweb 4y ago
  > deno consumes typescript. I don't think it does, it comes with a TS compiler built-in, and "can run TS" by compiling said TS to JS and evaluating that. Deno is still using V8, so unless Deno has changed recently, it does not "consume TS" and no mainstream JS engine does.
  - smt88 4y ago
    As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step. There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept, and it's against the philosophy of the project. TypeScript is metadata for devs.
    - capableweb 4y ago
      > As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step. That's fine, doesn't make the truth any different that it doesn't actually read TS without compiling it, as parent said. > There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept [...] TypeScript is metadata for devs It does make sense to have a runtime for TypeScript directly. There is bunch of optimizations that can only happen after the runtime understands the type of the values, and if you keep switching the type of the variable value it'll be able to do less of those optimizations. So you could probably end up skipping a lot of inference if the types gets shipped to the runtime as well as the rest of the source, vs just the source.
smt88 4y ago
> This is a superficial take. I've been using TypeScript in server-side, client-side, and hybrid projects for 8 years. Since then, I've inherited JS projects and felt like I was being forced to use a rock when I was used to having hammers. My take isn't superficial. > You are adding a compilation step that takes time The entire project is compiled only when testing or deploying. As far as testing goes, having static types dramatically reduces the number of times you have to run a program before shipping it. The net is that there's less time waiting for builds, not more. And anyway, most projects compile in 2 seconds or less. There is a huge net time saving no matter how you look at it. > slowing down feedback in certain workflows This is incredibly vague. Which workflows? And why does it matter in those workflows? The majority of feedback given by TypeScript is during the editing process, and that feedback is instantaneous because it comes from the language server and doesn't require recompiling. > a rather large dependency No. It's a dev dependency and doesn't ship with your code. You have to install it locally at some point, so I guess if a few MB of space is important to you, it's a problem. Otherwise it isn't.
- adamddev1 4y ago
  I agree 1000%. I am baffled by people still saying that the cost of TypeScript is not worth it. 1 unit of effort in setup at the start of a project for 1000 units of effort saved every day through lack of bugs, structural integrity, extensibility, intellisense help, and so much more. O(1) setup cost for O(n2) productivity gains.

tengbretson 4y ago

[flagged]

jrockway 4y ago
There are no code smells in personal projects, but this isn't one anyway. Every text editor I've ever used has had a single button inside that editor to change the code in the editor to what you just typed in. For an author who has written a blog post on how they eschew unit tests, this is probably the most important feature for one. A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.

vouwfietsman 4y ago

Just a headsup, these days the typescript tooling is actually ergonomic with esbuild and vite. If you still use javascript and know about this tooling, I am very curious why you would choose to do so, because esbuild will literally compile AND bundle all your js before you can say "compilation".

turblety 4y ago
What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code. Also, using esbuild to transpile your TS will not actually check the types. It just transforms it back to JS. For typescript, you really need the official library which is slow and bloated.
- vouwfietsman 4y ago
  Yes you need an extra build step, but really I cannot overstate how simple this step is. There is no webpack config hell, there is no giant dependency chain, there is no long wait for anything, there is no magic file globs and mimetypes. In 10-100ms, esbuild (a single small dependency) will take 3 command line arguments, grab all your linked TS from a single TS entrypoint file, and spit out a single (possibly minified) js file that you can immediately invoke with node. Instead of node bla.js, you do esbuild && node bla.js, you don't care what happens inside. Indeed it will not check your types, but as stated elsewhere your IDE can do this for you. This is actually beautiful because it allows you to get correctness feedback on your code but your code will never fail to run due to arbitrary type complaints. If you later feel like you want the full correctness of TS, maybe during CI/CD, you can run the slower compiler and get a gatekeeper telling you if you are doing something fishy.
- smt88 4y ago
  > What if you're not building a browser app. For a server side, NodeJS app? Sure, you can add a build step on the back end, but that's not free, as it comes with setup, having to run a transpiler before your code. It is free if your IDE uses the TypeScript language server and gives you errors integrated with your code editor. You don't have to transpile if you don't want to. You can, as you said, just use esbuild to strip away the type information. > For typescript, you really need the official library which is slow and bloated. See above. You absolutely don't. And it's not slow or bloated at all. It has incremental builds, which are essentially instantaneous after the initial build.

vbezhenar 4y ago

deno consumes typescript. IMO every JS engine should just consume typescript (without type checking). AFAIK TypeScript is designed to be easily consumed by JS engines. It's a pity that V8 ignores that property.

capableweb 4y ago
> deno consumes typescript. I don't think it does, it comes with a TS compiler built-in, and "can run TS" by compiling said TS to JS and evaluating that. Deno is still using V8, so unless Deno has changed recently, it does not "consume TS" and no mainstream JS engine does.
- smt88 4y ago
  As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step. There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept, and it's against the philosophy of the project. TypeScript is metadata for devs.
  - capableweb 4y ago
    > As a user, I don't care how Deno works under the hood. All that matters is that I don't have my own build step. That's fine, doesn't make the truth any different that it doesn't actually read TS without compiling it, as parent said. > There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept [...] TypeScript is metadata for devs It does make sense to have a runtime for TypeScript directly. There is bunch of optimizations that can only happen after the runtime understands the type of the values, and if you keep switching the type of the variable value it'll be able to do less of those optimizations. So you could probably end up skipping a lot of inference if the types gets shipped to the runtime as well as the rest of the source, vs just the source.

smt88 4y ago

> This is a superficial take. I've been using TypeScript in server-side, client-side, and hybrid projects for 8 years. Since then, I've inherited JS projects and felt like I was being forced to use a rock when I was used to having hammers. My take isn't superficial. > You are adding a compilation step that takes time The entire project is compiled only when testing or deploying. As far as testing goes, having static types dramatically reduces the number of times you have to run a program before shipping it. The net is that there's less time waiting for builds, not more. And anyway, most projects compile in 2 seconds or less. There is a huge net time saving no matter how you look at it. > slowing down feedback in certain workflows This is incredibly vague. Which workflows? And why does it matter in those workflows? The majority of feedback given by TypeScript is during the editing process, and that feedback is instantaneous because it comes from the language server and doesn't require recompiling. > a rather large dependency No. It's a dev dependency and doesn't ship with your code. You have to install it locally at some point, so I guess if a few MB of space is important to you, it's a problem. Otherwise it isn't.

adamddev1 4y ago
I agree 1000%. I am baffled by people still saying that the cost of TypeScript is not worth it. 1 unit of effort in setup at the start of a project for 1000 units of effort saved every day through lack of bugs, structural integrity, extensibility, intellisense help, and so much more. O(1) setup cost for O(n2) productivity gains.