4 ms·

This is a plea to use TypeScript instead of JS. Why not. Strong typing is certainly great. But the reason I don't use TypeScript isn't any of those listed: it's

by bambax 2y ago

This is a plea to use TypeScript instead of JS. Why not. Strong typing is certainly great. But the reason I don't use TypeScript isn't any of those listed: it's because it needs a compilation step, and I don't want that.

iLoveOncall 2y ago
> it's because it needs a compilation step, and I don't want that Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type. It's probably not listed in the article because it's a nonsensical argument.
- archerx 2y ago
  >catches a mistake you'd have missed or your IDE out you used the wrong type. Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix. What I need is a StupidScript to save me from the stupidity of my logic errors… Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards unlock at the end of the match. The code is “correct” the right types go to the right place but there is a logic error somewhere that prevents certain rewards from unlocking.
  - medo-bear 2y ago
    At that point sir you would have no job. Your job is logic safety
    - akira2501 2y ago
      My job is to produce more value than I cost. Otherwise you're going to get laid off anyways.
      - medo-bear 2y ago
        Atta boy https://ih1.redbubble.net/image.4938275797.9978/fposter,medium,wall_texture,product,750x1000.webp https://ih1.redbubble.net/image.4938275797.9978/fposter,medi...
    - archerx 2y ago
      That's why I test the code and solve the logical issues? The joke was that the language would be smart enough to catch the less obvious stupid mistakes instead of obvious to solve type bugs.
      - medo-bear 2y ago
        someone once said something to me that stuck: computers are stupid. they do exactly and only what you tell them
  - sureIy 2y ago
    > the console tells me immediately and the exactly line to fix. Uh, yeah, that's a runtime error. Type safety tells you the error before you even hit save, let alone run and test. It's a wildly faster loop.
    - archerx 2y ago
      I'm still going to run it every change and those errors are rare and quick to fix.
      - dizhn 2y ago
        Something simple like assigning a string when it should be a number won't cause an error on the console but will cause bugs very hard to catch.
  - iLoveOncall 2y ago
    > Do people really have this issue? Yes. The point is that without type-safety and a compile-time type check, you have absolutely no way of knowing if you have an error like this until you hit that piece of code. The very fact that you think you don't have those kinds of issues just exemplifies how you actually are just ignorant to all the type errors you have in your code because you haven't tested enough, hit the right edge case, etc.
    - archerx 2y ago
      I have bunch of code/programs that have been running live on prod for years that are super stable with no errors that have been reported but what do I know?
  - steinuil 2y ago
    Types give you much more than just getting an error early when you call the wrong method on an object or pass a string where you needed a number. Once you have written down the shape of the data flowing through your program in a way that a compiler can check you'll be able to reason about the whole program better and you might find issues much faster. I think that types can directly help a lot with logic errors as well: one of the things people say most often when discussing typed programming language is that you can make illegal states unrepresentable, which means that you can encode logic into the type system itself.
    - archerx 2y ago
      That might be interesting, I'll check for some examples.
  - JoeyJoJoJr 2y ago
    > My errors are never type related Over the years I feel like I have read this comment at least ten times from different commenters (and the second time this month) and I cannot really fathom it. I consider myself a pretty good developer, and I have type errors many times a day. It is perhaps the most common error I encounter, and thankfully one of of easiest to fix with static typing. By far the biggest recent productivity gain I have made using types is by generating the types along with client code for APIs via a swagger doc. I cannot overstate the value in seeing the types update when the backend devs have changed the API, and getting a compiler error when it doesn’t match with your code. By having the types the next developer after me is going to be spending far less time getting up to speed with the codebase. I started programming with static types early in my career so perhaps I have become wired to lean heavily on the type system.
    - archerx 2y ago
      My first programming language was C/C++ and I learned dynamically typed languages after, I still prefer the dynamically type languages. I still do a lot of C/C++ code for micro controllers and the types are so annoying, either create a function for both ints and floats, templates or you cast the type. It's all so tedious, boring and uninteresting. I have made a lot of code that works on a lot of third party APIs (The major LLMS, Image generators, E-commerce stuff) and yea it's all been easy breezy and never thought I wish I had types. Different people just work in different ways.
- afiori 2y ago
  Normal application developers suffer less from it, but the reasons that made svelte move from TS to jsdoc apply to everyone. https://news.ycombinator.com/item?id=35892250 https://news.ycombinator.com/item?id=35892250 Personally I like using typescript's namespaces that have no nice-enough jsdoc/js equivalent, but if tsc/tsserver had an option to mutate in-place typescript syntax to jsdoc notations where possible I would use it as much as possible.
prmph 2y ago
With runtimes like Bun and Deno (and lately Node itself), you can run Typescript directly with pretty much zero config. There is transpilation behind the scenes, but the time that takes is minimal. I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.
- gr4vityWall 2y ago
  If you don't mind me asking, is there any particular reason you're not using Bun to bundle it?
  - prmph 2y ago
    I wasn't sure the Bun bundler was powerful enough to handle my needs. Bundling is a hard thing to get right, and I tried many, many tools and configurations over the years before settling on esbuild.
bryanrasmussen 2y ago
I think the not wanting a compilation step complaint is even worse than the it's too much typing complaint, and I say that as someone who does not much care for typescript despite using it almost exclusively for the last 5 years.
DexesTTP 2y ago
Do look into jsdoc typing and "//@ts-check". I do agree with you on the compilation, and this is the reason I'm still writing the occasional .js or .mjs file. However, the js I write starts with enabling ts-check and has all of its type information encoded as comment. This way, I'm getting the benefits of typescript while writing the code without needing the whole compilation step.
thiht 2y ago
> it needs a compilation step, and I don't want that That's such a weird requirement, maybe because I'm used to writing Go code in my day job. I work on some React webapps on the side and there's no way I would miss on TS, typing is just the only way to write code that you can actually refactor. Granted you get some of TypeScript safety for free thanks to `// @ts-check` and friends, but it's the bare minimum.

by bambax 2y ago

iLoveOncall 2y ago

> it's because it needs a compilation step, and I don't want that Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type. It's probably not listed in the article because it's a nonsensical argument.

archerx 2y ago
>catches a mistake you'd have missed or your IDE out you used the wrong type. Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix. What I need is a StupidScript to save me from the stupidity of my logic errors… Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards unlock at the end of the match. The code is “correct” the right types go to the right place but there is a logic error somewhere that prevents certain rewards from unlocking.
- medo-bear 2y ago
  At that point sir you would have no job. Your job is logic safety
  - akira2501 2y ago
    My job is to produce more value than I cost. Otherwise you're going to get laid off anyways.
    - medo-bear 2y ago
      Atta boy https://ih1.redbubble.net/image.4938275797.9978/fposter,medium,wall_texture,product,750x1000.webp https://ih1.redbubble.net/image.4938275797.9978/fposter,medi...
  - archerx 2y ago
    That's why I test the code and solve the logical issues? The joke was that the language would be smart enough to catch the less obvious stupid mistakes instead of obvious to solve type bugs.
    - medo-bear 2y ago
      someone once said something to me that stuck: computers are stupid. they do exactly and only what you tell them
- sureIy 2y ago
  > the console tells me immediately and the exactly line to fix. Uh, yeah, that's a runtime error. Type safety tells you the error before you even hit save, let alone run and test. It's a wildly faster loop.
  - archerx 2y ago
    I'm still going to run it every change and those errors are rare and quick to fix.
    - dizhn 2y ago
      Something simple like assigning a string when it should be a number won't cause an error on the console but will cause bugs very hard to catch.
- iLoveOncall 2y ago
  > Do people really have this issue? Yes. The point is that without type-safety and a compile-time type check, you have absolutely no way of knowing if you have an error like this until you hit that piece of code. The very fact that you think you don't have those kinds of issues just exemplifies how you actually are just ignorant to all the type errors you have in your code because you haven't tested enough, hit the right edge case, etc.
  - archerx 2y ago
    I have bunch of code/programs that have been running live on prod for years that are super stable with no errors that have been reported but what do I know?
- steinuil 2y ago
  Types give you much more than just getting an error early when you call the wrong method on an object or pass a string where you needed a number. Once you have written down the shape of the data flowing through your program in a way that a compiler can check you'll be able to reason about the whole program better and you might find issues much faster. I think that types can directly help a lot with logic errors as well: one of the things people say most often when discussing typed programming language is that you can make illegal states unrepresentable, which means that you can encode logic into the type system itself.
  - archerx 2y ago
    That might be interesting, I'll check for some examples.
- JoeyJoJoJr 2y ago
  > My errors are never type related Over the years I feel like I have read this comment at least ten times from different commenters (and the second time this month) and I cannot really fathom it. I consider myself a pretty good developer, and I have type errors many times a day. It is perhaps the most common error I encounter, and thankfully one of of easiest to fix with static typing. By far the biggest recent productivity gain I have made using types is by generating the types along with client code for APIs via a swagger doc. I cannot overstate the value in seeing the types update when the backend devs have changed the API, and getting a compiler error when it doesn’t match with your code. By having the types the next developer after me is going to be spending far less time getting up to speed with the codebase. I started programming with static types early in my career so perhaps I have become wired to lean heavily on the type system.
  - archerx 2y ago
    My first programming language was C/C++ and I learned dynamically typed languages after, I still prefer the dynamically type languages. I still do a lot of C/C++ code for micro controllers and the types are so annoying, either create a function for both ints and floats, templates or you cast the type. It's all so tedious, boring and uninteresting. I have made a lot of code that works on a lot of third party APIs (The major LLMS, Image generators, E-commerce stuff) and yea it's all been easy breezy and never thought I wish I had types. Different people just work in different ways.
afiori 2y ago
Normal application developers suffer less from it, but the reasons that made svelte move from TS to jsdoc apply to everyone. https://news.ycombinator.com/item?id=35892250 https://news.ycombinator.com/item?id=35892250 Personally I like using typescript's namespaces that have no nice-enough jsdoc/js equivalent, but if tsc/tsserver had an option to mutate in-place typescript syntax to jsdoc notations where possible I would use it as much as possible.

prmph 2y ago

With runtimes like Bun and Deno (and lately Node itself), you can run Typescript directly with pretty much zero config. There is transpilation behind the scenes, but the time that takes is minimal. I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.

gr4vityWall 2y ago
If you don't mind me asking, is there any particular reason you're not using Bun to bundle it?
- prmph 2y ago
  I wasn't sure the Bun bundler was powerful enough to handle my needs. Bundling is a hard thing to get right, and I tried many, many tools and configurations over the years before settling on esbuild.

bryanrasmussen 2y ago

I think the not wanting a compilation step complaint is even worse than the it's too much typing complaint, and I say that as someone who does not much care for typescript despite using it almost exclusively for the last 5 years.

DexesTTP 2y ago

Do look into jsdoc typing and "//@ts-check". I do agree with you on the compilation, and this is the reason I'm still writing the occasional .js or .mjs file. However, the js I write starts with enabling ts-check and has all of its type information encoded as comment. This way, I'm getting the benefits of typescript while writing the code without needing the whole compilation step.

thiht 2y ago

> it needs a compilation step, and I don't want that That's such a weird requirement, maybe because I'm used to writing Go code in my day job. I work on some React webapps on the side and there's no way I would miss on TS, typing is just the only way to write code that you can actually refactor. Granted you get some of TypeScript safety for free thanks to `// @ts-check` and friends, but it's the bare minimum.