5 ms·

I have been working with node for a couple of years now, not my choice but it isn’t tragic. This team uses TypeScript, I honestly don’t get the problem TypeSc

I have been working with node for a couple of years now, not my choice but it isn’t tragic. This team uses TypeScript, I honestly don’t get the problem TypeScript is trying to solve. JavaScript has lots of wacky problems but its main advantage to me was the loosy goosy approach to types. I was a smalltalk programmer back in the 1990s and it felt pretty comfortable if very primitive in the way of tools. Typescript just seems unnecessary. Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge. Now I find out there were competing jails. What a strange ecosystem.

eternityforest 3y ago
Type checking has caught SO many bugs that would otherwise have taken a 30 second test to find. The time savings really adds up, and it catches a fair amount of bugs that otherwise would have made it to prod. To me it's one of the top requirements for a modern language.
verelo 3y ago
This is so my experience. Also when you can just declare something as “any” and effectively say f it to the entire concept they’re trying to enforce…what’s the point? From time to time human nature takes over and you use any, and the disease has started the spread. If i wanted loose types, i wouldn’t have used typescript. So “pick a side” is all i can ever think when i work with ts.
- seper8 3y ago
  You know you can do loose types in C# and many other "strongly typed" languages too?
- vundercind 3y ago
  “Any” is incredibly useful. It lets you transition JS code to TS without having to do the whole thing at once. It lets you work with libraries written in JavaScript without having to immediately find or write types for them. The language would be nearly unusable in the real world without it, and that’d have been even more true in its early days.
- tom_ 3y ago
  You need a getout clause sometimes, and it's useful to have one. (You should prefer "unknown", though, which requires you to cast the value on each use, over "any", which treats the value as being of all possible types. You can configure eslint to moan at you if you use "any": https://typescript-eslint.io/rules/no-explicit-any/ https://typescript-eslint.io/rules/no-explicit-any/)
- wruza 3y ago
  The point is you have most things covered and that one that is too complex to type you ignore and rely on softer contracts there.
lucianbr 3y ago
How large are the projects you worked on? Usually type safety is more useful and appreciated in large projects, where strict interfaces between modules are more valuable. In small projects, the advantage is for the loosy-goosy, because you can move faster and anyway you have the whole thing in your head, or most of it. There is a lot of text written and voice recorded over what type safety is good for. It's reasonable to disagree, but to "honestly don't get" what the point of it is seems kinda strange. Like you haven't really looked into it.
- mhh__ 3y ago
  I think the point isn't really about the value of type safety but rather the value-add of bothering with the whole of typescript (as in the type safety they provide rather than an abstract ideal) versus some other solution. It's quite annoying IMO. Some of the things it can be infer are reasonably impressive but then that gets balanced out with having to write out a lot of crap that something a bit more HM-like would be able to nail immediately (rather than just "Any!? Fuck you"). That and the refusal to add other value-adds (despite being a compiler in all but name) hobbles the union types and so on.
  - throwaway11460 3y ago
    Could you give me some examples of this unnecessary code? Are you using type inference to its full capabilities? It's only really necessary to declare types at interfaces (function arguments, etc)... Is that what you're referring to?
- ReflectedImage 3y ago
  It's not really true that type safety is useful for large projects. It's generally better to do proper micro-services. Type safety is the inferior way of doing it where you get hit with a double whammy of long compile times and extreme code verbosity.
  - zogrodea 3y ago
    Network API contracts/documentation are just an attempt of type safety over the untyped network boundary. Network communications are the most tedious and annoying part of programming for me because of the validation of the request body and checking that it has all the fields needed. Microservices only increase the amount of documentation needed. I would prefer to lessen the amount of documentation by letting the compiler/code do the work instead.
imetatroll 3y ago
I have never had typescript really get in my way and it does have an escape hatch if you need it so, personally, I would always prefer to use it.
IshKebab 3y ago
It sounds like you have simply not experienced the problems that loosy goosy types cause. They tend to be biggest when you're working on large projects and on other people's code. If you've only done small projects or projects where you are the primary author then you may not run into the issues. You essentially end up doing what Typescript does but in your head without writing anything down. The problems it solves are: * Bugs! It catches lots of bugs. * Navigating code efficiently. You can just click stuff to go to its definition or uses. * Refactoring code reliably. You can now rename variables without making mistakes. * Reading code. It can be extremely difficult to understand code without static types because you don't know what anything is or where anything goes unless you run it (which can be very difficult). Not Typescript, but as an example I was trying to understand some code in Gitlab like `auto_cancel_from_rules.merge(auto_cancel_from_config)`. "what does `merge` do?" I wondered. Literally could not find it. You can't search for `merge`, way too many results. I don't know what the types of the variables are so I can't look it up. I spent about 15 minutes looking around and eventually gave up. With static types you can literally just click it and it will take you to the definition.
- jerf 3y ago
  If I never again in my career have to encounter the God Function that everything in the system calls one way or another and takes 9 arguments, all of which are something like "either a string identifying an ID, or a function yielding a string, or a function that yields a list or an iterator of strings, or an object with a GetID method, or if the third parameter was falsy, a function to be called if the user is not authenticated", I will be pleased. Or the function that has literally 40 parameters, 36 of them optional, and while each of them may be individually reasonably well defined you will never work out what all combinations of them do, and you can also know there is no test and no spec for all possible combinations. (Unlike the former which is characteristic of local codebases and bad discipline, the latter is the basis of major dynamic scripting language libraries.) Dynamic typing doesn't have to get that messy, but it takes discipline that is very hard to enforce at scale. Static typing can sort of approximate that level of mess but it takes a lot more work, and perhaps even more importantly, it's a lot safer to fix. But every significantly-sized dynamic scripting code base I've encountered has certainly had at least one of those two issues deeply, deeply ground into it.
stiiv 3y ago
In my opinion, JavaScript's main advantage is that it can be run in browsers in addition to other (i.e. server) environments. If you're building something simple, and the type/shape of function parameters is either very obvious or very well-guarded, TypeScript's returns diminish. However: As a reviewer of complex code, I want to see annotations so that I can better understand what I'm reviewing. As an author of complex code, I want to clearly communicate the intent of functions I write, so that they are not misused by other developers. As someone who supports the use of my software, I want to reduce errors by guaranteeing the correct types/shapes of function arguments. ...and I'm just getting started. These are all very compelling needs in my experience.
sebstefan 3y ago
It solves the problem of having your type mismatches happening at runtime as exceptions and weird behaviors when they could be happening at compile-time as a type error instead I've worked with both Javascript and Typescript and the ease of patching up Typescript projects you're not familiar with is unmatched compared to Javascript. At least when my code compiles, I'm sure the plumbing is correct
vundercind 3y ago
> JavaScript has lots of wacky problems but its main advantage to me was the loosy goosy approach to types. It runs in the browser. That’s always been its only advantage. Even now that it’s much better than it used to be: still true. > Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge. TIL machine-readable and -verifiable versions of the documentation you should be writing anyway (but probably aren’t) is a jail. Also one of the reasons I didn’t worry about it going the way of other compile-to-JS languages is that it’s output is nearly identical to what I would have written anyway, so it’s got a clean and easy “escape hatch”. But maybe I write unreadable sludge.
- tom_ 3y ago
  I've had it generate some verbose stuff when using .?, along these lines: (_c = this.log) === null || _c === void 0 ? void 0 : _c.withIndent(' ', () => { var _a; // (pointless ?. silence eslint) (_a = this.log) === null || _a === void 0 ? void 0 : _a.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `); }); This was originally this: this.log?.withIndent(' ', () => { // (pointless ?. silence eslint) this.log?.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `); }); If you have a long chain of ?., perhaps it gets really ugly.
  - madeofpalk 3y ago
    Right - if you use a language feature that is newer than your compile target, it will compile down 'modern' syntax like that. I'm not sure what else you would expect.
    - tom_ 3y ago
      The discussion topic was cases where the js output includes a bunch of extra junk, so this is just intended as an example of that! Mostly the output looks pretty much like the input. (The compile target in my case is ES2017, as configured in August 2018. I can probably update that.)
  - 3y ago
pjc50 3y ago
> I was a smalltalk programmer back in the 1990s Smalltalk (and languages in the same academic orbit, like LISP derivatives) seems to be a tool that fits a few people's hands very well, but there are no large smalltalk projects for two reasons: - that doesn't actually suit most people, so it's harder to find developers - the language maps well to one (1) human brain that keeps a model of what's happening, but that breaks down when larger teams of developers are involved. I guess that keeps the "small" in smalltalk.
- ReflectedImage 3y ago
  Well it's a lack of training problem. Someone properly trained with something like Smalltalk will on average output 3x the amount of software as someone trained on something like Java. There are big advantages to doing it.
  - EMM_386 3y ago
    > Well it's a lack of training problem. The industry spends billions of dollars on developers writing Java. If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it. They're not, because that's not the problem.
    - randomdata 3y ago
      > If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it. No they wouldn't. While not bad long-term thinking, by the time developers are up to speed with Smalltalk and realizing three times the output, the competition using the ecosystem its developers already knew will have launched something and won over the customers. It doesn't matter how much software you can crank out after you've already lost.
- randomdata 3y ago
  > but there are no large smalltalk projects for two reasons: But mostly because it was expensive. Objective-C and Ruby got you halfway there for free, and there is nothing developers love more than something that is free.
Vinnl 3y ago
> that down compiles to unreadable sludge. I think there might be a couple of other tools around in your setup (that might influence your feelings). TypeScript mostly just strips out type annotations, so the output looks pretty close to your input.
madeofpalk 3y ago
Maybe I'm just not as good of a developer as you, but I often fail to understand 100% of the codebase, or I even make mistakes sometimes. Having a system catch my back to tell me what else I need to update in my refactor is a huge help for me. Maybe that's just not a problem those 10x developers have? > instead they built a stupid jail that down compiles to unreadable sludge Does it? The Typescript compiler mostly just erases types, leaving the code otherwise the same. Here's a non-trival example https://tsplay.dev/mA078N https://tsplay.dev/mA078N, where the output is basically the same as the input, just with type syntax erased. IIRC the only 'language feature' that Typescript actually compiles is enums, which is a bit of a big blob. There's compiler flags to 'fix' that, or you can just not use enums.
wruza 3y ago
It’s practical. You change your structures and forget places to fix. Typescript trying to solve that. Edit: Also you can follow typedefs of a library and make sense of it without relying on its documentation quality or deciphering the code.
G3rn0ti 3y ago
I think the biggest advantage TypeScript gives is discoverability when using a language server driven development environment. Hover over a function and you’ll get its signature and doc string. This will work quite quickly due all of the type information pointing back to its definition. This kind of static analysis is impossible in a weakly typed language due to the fact a random variable could hold anything at runtime. In this case an IDE cannot help you much inside an unfamiliar code base. At my workplace a team of test engineers wrote an entire little test framework around our application. It‘s using webdriver.io under the hood but defines all test classes in type script. Everytime I need to inspect a failing test I open it up in my Emacs and jump around the test method definitions quickly and easily and enjoy inline doc strings popping up wherever I set my cursor on. So the task of fixing a test becomes quite easy despite not having written the framework. Back when we used JS or Perl this task used to be quite obscure. On the other hand when I see react applications written in typescript I become quite skeptical of the supposed architectural benefits of static typing in front end logic. While React applications were already difficult to grasp, static typing constraint make refactorings even more headachy and I receive Java‘s spring framework vibes constantly.
- pjc50 3y ago
  > I think the biggest advantage TypeScript gives is discoverability when using a language server driven development environment. +1: I'm much slower working in environments where I have to do this manually. This is why I've been infiltrating Python type annotations in our codebase.

eternityforest 3y ago

Type checking has caught SO many bugs that would otherwise have taken a 30 second test to find. The time savings really adds up, and it catches a fair amount of bugs that otherwise would have made it to prod. To me it's one of the top requirements for a modern language.

verelo 3y ago

This is so my experience. Also when you can just declare something as “any” and effectively say f it to the entire concept they’re trying to enforce…what’s the point? From time to time human nature takes over and you use any, and the disease has started the spread. If i wanted loose types, i wouldn’t have used typescript. So “pick a side” is all i can ever think when i work with ts.

seper8 3y ago
You know you can do loose types in C# and many other "strongly typed" languages too?
vundercind 3y ago
“Any” is incredibly useful. It lets you transition JS code to TS without having to do the whole thing at once. It lets you work with libraries written in JavaScript without having to immediately find or write types for them. The language would be nearly unusable in the real world without it, and that’d have been even more true in its early days.
tom_ 3y ago
You need a getout clause sometimes, and it's useful to have one. (You should prefer "unknown", though, which requires you to cast the value on each use, over "any", which treats the value as being of all possible types. You can configure eslint to moan at you if you use "any": https://typescript-eslint.io/rules/no-explicit-any/ https://typescript-eslint.io/rules/no-explicit-any/)
wruza 3y ago
The point is you have most things covered and that one that is too complex to type you ignore and rely on softer contracts there.

lucianbr 3y ago

How large are the projects you worked on? Usually type safety is more useful and appreciated in large projects, where strict interfaces between modules are more valuable. In small projects, the advantage is for the loosy-goosy, because you can move faster and anyway you have the whole thing in your head, or most of it. There is a lot of text written and voice recorded over what type safety is good for. It's reasonable to disagree, but to "honestly don't get" what the point of it is seems kinda strange. Like you haven't really looked into it.

mhh__ 3y ago
I think the point isn't really about the value of type safety but rather the value-add of bothering with the whole of typescript (as in the type safety they provide rather than an abstract ideal) versus some other solution. It's quite annoying IMO. Some of the things it can be infer are reasonably impressive but then that gets balanced out with having to write out a lot of crap that something a bit more HM-like would be able to nail immediately (rather than just "Any!? Fuck you"). That and the refusal to add other value-adds (despite being a compiler in all but name) hobbles the union types and so on.
- throwaway11460 3y ago
  Could you give me some examples of this unnecessary code? Are you using type inference to its full capabilities? It's only really necessary to declare types at interfaces (function arguments, etc)... Is that what you're referring to?
ReflectedImage 3y ago
It's not really true that type safety is useful for large projects. It's generally better to do proper micro-services. Type safety is the inferior way of doing it where you get hit with a double whammy of long compile times and extreme code verbosity.
- zogrodea 3y ago
  Network API contracts/documentation are just an attempt of type safety over the untyped network boundary. Network communications are the most tedious and annoying part of programming for me because of the validation of the request body and checking that it has all the fields needed. Microservices only increase the amount of documentation needed. I would prefer to lessen the amount of documentation by letting the compiler/code do the work instead.

imetatroll 3y ago

I have never had typescript really get in my way and it does have an escape hatch if you need it so, personally, I would always prefer to use it.

IshKebab 3y ago

It sounds like you have simply not experienced the problems that loosy goosy types cause. They tend to be biggest when you're working on large projects and on other people's code. If you've only done small projects or projects where you are the primary author then you may not run into the issues. You essentially end up doing what Typescript does but in your head without writing anything down. The problems it solves are: * Bugs! It catches lots of bugs. * Navigating code efficiently. You can just click stuff to go to its definition or uses. * Refactoring code reliably. You can now rename variables without making mistakes. * Reading code. It can be extremely difficult to understand code without static types because you don't know what anything is or where anything goes unless you run it (which can be very difficult). Not Typescript, but as an example I was trying to understand some code in Gitlab like `auto_cancel_from_rules.merge(auto_cancel_from_config)`. "what does `merge` do?" I wondered. Literally could not find it. You can't search for `merge`, way too many results. I don't know what the types of the variables are so I can't look it up. I spent about 15 minutes looking around and eventually gave up. With static types you can literally just click it and it will take you to the definition.

jerf 3y ago
If I never again in my career have to encounter the God Function that everything in the system calls one way or another and takes 9 arguments, all of which are something like "either a string identifying an ID, or a function yielding a string, or a function that yields a list or an iterator of strings, or an object with a GetID method, or if the third parameter was falsy, a function to be called if the user is not authenticated", I will be pleased. Or the function that has literally 40 parameters, 36 of them optional, and while each of them may be individually reasonably well defined you will never work out what all combinations of them do, and you can also know there is no test and no spec for all possible combinations. (Unlike the former which is characteristic of local codebases and bad discipline, the latter is the basis of major dynamic scripting language libraries.) Dynamic typing doesn't have to get that messy, but it takes discipline that is very hard to enforce at scale. Static typing can sort of approximate that level of mess but it takes a lot more work, and perhaps even more importantly, it's a lot safer to fix. But every significantly-sized dynamic scripting code base I've encountered has certainly had at least one of those two issues deeply, deeply ground into it.

stiiv 3y ago

In my opinion, JavaScript's main advantage is that it can be run in browsers in addition to other (i.e. server) environments. If you're building something simple, and the type/shape of function parameters is either very obvious or very well-guarded, TypeScript's returns diminish. However: As a reviewer of complex code, I want to see annotations so that I can better understand what I'm reviewing. As an author of complex code, I want to clearly communicate the intent of functions I write, so that they are not misused by other developers. As someone who supports the use of my software, I want to reduce errors by guaranteeing the correct types/shapes of function arguments. ...and I'm just getting started. These are all very compelling needs in my experience.

sebstefan 3y ago

It solves the problem of having your type mismatches happening at runtime as exceptions and weird behaviors when they could be happening at compile-time as a type error instead I've worked with both Javascript and Typescript and the ease of patching up Typescript projects you're not familiar with is unmatched compared to Javascript. At least when my code compiles, I'm sure the plumbing is correct

vundercind 3y ago

> JavaScript has lots of wacky problems but its main advantage to me was the loosy goosy approach to types. It runs in the browser. That’s always been its only advantage. Even now that it’s much better than it used to be: still true. > Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge. TIL machine-readable and -verifiable versions of the documentation you should be writing anyway (but probably aren’t) is a jail. Also one of the reasons I didn’t worry about it going the way of other compile-to-JS languages is that it’s output is nearly identical to what I would have written anyway, so it’s got a clean and easy “escape hatch”. But maybe I write unreadable sludge.

tom_ 3y ago
I've had it generate some verbose stuff when using .?, along these lines: (_c = this.log) === null || _c === void 0 ? void 0 : _c.withIndent(' ', () => { var _a; // (pointless ?. silence eslint) (_a = this.log) === null || _a === void 0 ? void 0 : _a.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `); }); This was originally this: this.log?.withIndent(' ', () => { // (pointless ?. silence eslint) this.log?.pn(`Buffer address: 0x${utils.hex8(bufferAddress)} `); }); If you have a long chain of ?., perhaps it gets really ugly.
- madeofpalk 3y ago
  Right - if you use a language feature that is newer than your compile target, it will compile down 'modern' syntax like that. I'm not sure what else you would expect.
  - tom_ 3y ago
    The discussion topic was cases where the js output includes a bunch of extra junk, so this is just intended as an example of that! Mostly the output looks pretty much like the input. (The compile target in my case is ES2017, as configured in August 2018. I can probably update that.)
- 3y ago

pjc50 3y ago

> I was a smalltalk programmer back in the 1990s Smalltalk (and languages in the same academic orbit, like LISP derivatives) seems to be a tool that fits a few people's hands very well, but there are no large smalltalk projects for two reasons: - that doesn't actually suit most people, so it's harder to find developers - the language maps well to one (1) human brain that keeps a model of what's happening, but that breaks down when larger teams of developers are involved. I guess that keeps the "small" in smalltalk.

ReflectedImage 3y ago
Well it's a lack of training problem. Someone properly trained with something like Smalltalk will on average output 3x the amount of software as someone trained on something like Java. There are big advantages to doing it.
- EMM_386 3y ago
  > Well it's a lack of training problem. The industry spends billions of dollars on developers writing Java. If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it. They're not, because that's not the problem.
  - randomdata 3y ago
    > If they could spend 3 times less by simply training developers to use Smalltalk instead, they'd be doing it. No they wouldn't. While not bad long-term thinking, by the time developers are up to speed with Smalltalk and realizing three times the output, the competition using the ecosystem its developers already knew will have launched something and won over the customers. It doesn't matter how much software you can crank out after you've already lost.
randomdata 3y ago
> but there are no large smalltalk projects for two reasons: But mostly because it was expensive. Objective-C and Ruby got you halfway there for free, and there is nothing developers love more than something that is free.

Vinnl 3y ago

> that down compiles to unreadable sludge. I think there might be a couple of other tools around in your setup (that might influence your feelings). TypeScript mostly just strips out type annotations, so the output looks pretty close to your input.

madeofpalk 3y ago

Maybe I'm just not as good of a developer as you, but I often fail to understand 100% of the codebase, or I even make mistakes sometimes. Having a system catch my back to tell me what else I need to update in my refactor is a huge help for me. Maybe that's just not a problem those 10x developers have? > instead they built a stupid jail that down compiles to unreadable sludge Does it? The Typescript compiler mostly just erases types, leaving the code otherwise the same. Here's a non-trival example https://tsplay.dev/mA078N https://tsplay.dev/mA078N, where the output is basically the same as the input, just with type syntax erased. IIRC the only 'language feature' that Typescript actually compiles is enums, which is a bit of a big blob. There's compiler flags to 'fix' that, or you can just not use enums.

wruza 3y ago

It’s practical. You change your structures and forget places to fix. Typescript trying to solve that. Edit: Also you can follow typedefs of a library and make sense of it without relying on its documentation quality or deciphering the code.

G3rn0ti 3y ago

I think the biggest advantage TypeScript gives is discoverability when using a language server driven development environment. Hover over a function and you’ll get its signature and doc string. This will work quite quickly due all of the type information pointing back to its definition. This kind of static analysis is impossible in a weakly typed language due to the fact a random variable could hold anything at runtime. In this case an IDE cannot help you much inside an unfamiliar code base. At my workplace a team of test engineers wrote an entire little test framework around our application. It‘s using webdriver.io under the hood but defines all test classes in type script. Everytime I need to inspect a failing test I open it up in my Emacs and jump around the test method definitions quickly and easily and enjoy inline doc strings popping up wherever I set my cursor on. So the task of fixing a test becomes quite easy despite not having written the framework. Back when we used JS or Perl this task used to be quite obscure. On the other hand when I see react applications written in typescript I become quite skeptical of the supposed architectural benefits of static typing in front end logic. While React applications were already difficult to grasp, static typing constraint make refactorings even more headachy and I receive Java‘s spring framework vibes constantly.

pjc50 3y ago
> I think the biggest advantage TypeScript gives is discoverability when using a language server driven development environment. +1: I'm much slower working in environments where I have to do this manually. This is why I've been infiltrating Python type annotations in our codebase.