3 ms·

After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. So as a fanboy, when I read thi

After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. So as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case. I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. They don’t. They just become implicit. It takes something a computer is really good at, and shoves it into your brain. And as many point out: the types are, more than anything, documentation. But beyond any of that (and I feel this is the most important lesson): when there’s like a 100:1 ratio in favour of something, you’re probably wrong. Not always. But probably. And it’s your ball. You can take it and go home if you want. People can fork. But sometimes you need to, at best, say, “I simply do not understand you people, but you’re the overwhelming majority, so whether I like it or not, I need to leave things as-is.”

incrudible 3y ago
Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.
- Waterluvian 3y ago
  That’s true. For Python I add them as needed. It’s not all or nothing. You can change tsconfig to be fine with implicit any.
- digging 3y ago
  > Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
  - incrudible 3y ago
    You are using Typescript to prove that they're correct. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
skybrian 3y ago
One advantage of going to JsDoc type annotations for some libraries is that you don't need to deal with sourcemaps. People can use the source code as-is and they can bundle and minify it if they like. That doesn't seem to be what this is about, though.
- Waterluvian 3y ago
  Hmmm you got me thinking. I wonder if there’s a sensible story for ts to “compile” to JS with jsdoc annotations. I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.
com2kid 3y ago
> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. TS isn't an extra layer of complexity. Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity. Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity. Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity. Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity. Typescript makes you pay up front to remove a LOT of complexity down the line.
- IggleSniggle 3y ago
  I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all. TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't. I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types. OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
- acdha 3y ago
  I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere. Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
Jcampuzano2 3y ago
Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision". If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
- n2d4 3y ago
  What I found ironic was this part from the reasoning post: > [V]ery few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others. Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
  - petesergeant 3y ago
    I mean it’s also simply not true. Most JS developers who have been doing JS for at least ten years have explicitly gone from not caring that much about types to being thankful for them.
- arghwhat 3y ago
  To be fair, open source is not a democracy. The project owners/authors/maintainers can do things because they feel like it or prefer it, without having to justify it to anyone - even if everyone else openly hates it and the project loses users or contributors as a result. Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it. Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement. (I like neither JS nor TS, so eh.)

incrudible 3y ago

Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.

Waterluvian 3y ago
That’s true. For Python I add them as needed. It’s not all or nothing. You can change tsconfig to be fine with implicit any.
digging 3y ago
> Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
- incrudible 3y ago
  You are using Typescript to prove that they're correct. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

skybrian 3y ago

One advantage of going to JsDoc type annotations for some libraries is that you don't need to deal with sourcemaps. People can use the source code as-is and they can bundle and minify it if they like. That doesn't seem to be what this is about, though.

Waterluvian 3y ago
Hmmm you got me thinking. I wonder if there’s a sensible story for ts to “compile” to JS with jsdoc annotations. I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.

com2kid 3y ago

> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. TS isn't an extra layer of complexity. Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity. Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity. Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity. Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity. Typescript makes you pay up front to remove a LOT of complexity down the line.

IggleSniggle 3y ago
I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all. TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't. I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types. OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
acdha 3y ago
I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere. Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.

Jcampuzano2 3y ago

Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision". If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.

n2d4 3y ago
What I found ironic was this part from the reasoning post: > [V]ery few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others. Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
- petesergeant 3y ago
  I mean it’s also simply not true. Most JS developers who have been doing JS for at least ten years have explicitly gone from not caring that much about types to being thankful for them.
arghwhat 3y ago
To be fair, open source is not a democracy. The project owners/authors/maintainers can do things because they feel like it or prefer it, without having to justify it to anyone - even if everyone else openly hates it and the project loses users or contributors as a result. Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it. Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement. (I like neither JS nor TS, so eh.)