5 ms·

38%? This is bullshit. Even if that statement were true (which I highly doubt), it is still deceptive because it does not account for: - The 2x to 3x extra ti

38%? This is bullshit. Even if that statement were true (which I highly doubt), it is still deceptive because it does not account for: - The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. This is time which could have been spent on writing more tests. - The new bugs which TypeScript introduces that JavaScript did not have related to things like source mapping issues, outdated DefinitelyTyped definitions, TypeScript version mismatches, the illusion of runtime type safely when dealing with parsed JSON data from remote clients, etc... I could talk at lengths about the problems but there are so many that it would take me about an hour to write them down. I have over 1 year of experience with TypeScript in multiple projects and earlier in my career I used ActionScript 3.0 (also typed ECMAScript) for over 3 years so unlike the people who make the decision to move to TypeScript, I know what I'm saying. It's going to kill collaboration between projects. I really hope that browser vendors are smart enough to wait for all the hype to die before adding native TypeScript runtime in browsers. I'm certain that the hype will die when people realize that TS is just the same as Java. During the most difficult time in their existence, companies like AirBnb could rely on JavaScript to build high quality software. I think that in reality this move to TypeScript has nothing to do with software quality and everything to do with keeping their employees busy and degrading their skill level so that they will not be able to join a competing startup in the future. This is just a strategy to turn their employees into corporate cattle and keep them locked into some kind of internal AirBnb private module ecosystem which will be completely disjoint from any universal module ecosystem. Developers will use less and less open source modules and more and more private company modules to do their work. The reason is because the company's type system will eventually conflict with the type systems of all third party open source modules.

austincheney 8y ago
> The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. I think you are doing something wrong. I switched over to TypeScript for my personal projects 2 years ago and never experienced that. If anything there are a few rare cases where I run into problems up front due to type conflicts, but really each of these cases likely would have resulted in expected maintenance down the road. Problems down the road were pushed much forward. The increase of effort was tiny, and its possible to really say, but this could have been a cost savings over the costly concerns of debugging an embedded problem. > I have over 1 year of experience with TypeScript in multiple projects and earlier in my career I used ActionScript 3.0 (also typed ECMAScript) for over 3 years so unlike the people who make the decision to move to TypeScript, I know what I'm saying. That isn't very much experience for the claims you are making.
sjapkee 8y ago
>The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. This is time which could have been spent on writing more tests. What's the reason to write tests for things, that just should works? You shouldn't think about tests like "What error does it throw if I pass that type?" With type checking you just won't have that type of issues.
- zihotki 8y ago
  Second that, the tests take time to write and they come with cost of development and also with cost of support in long-term. So having less of this kind of tests should be time-wise and economically-wise benefitial.
- jondubois 8y ago
  >> "What error does it throw if I pass that type?" With type checking you just won't have that type of issues. That's incorrect. If the object was parsed from JSON (e.g. sent to the server by a remote client), then you still need to do a type/schema check with TypeScript because types are only checked at compile time; not at runtime. If you have good integration tests, you don't need to explicitly check for types in JavaScript; type incompatibilities will show up as logic errors in the tests. For example, if you add 100 with '23', you will get '10023' - You don't need to use `typeof ... === 'number'` in order for your test suite to pick this up as a logic error. Even if your test case is written in TypeScript, you still need to account for the possibility that the front end will pass the value as a string; so the JavaScript test is the same size as the TypeScript one.
  - sjapkee 8y ago
    > If the object was parsed from JSON Just stop using it. Use gRPC. It's binary -> faster. It's support TypeScript -> type safely. Type safety is a complex thing. If there is a type-safe instrument instead of type-unsafe, you should use it. >If you have good integration tests, you don't need to explicitly check for types in JavaScript It works only in the perfect world, where tests are always relevant and tests all cases. But we live in the imperfect world. With people, which may forget to update tests/documentation/etc. and things in something like JS still will works. But in the type-safe world things are different. If you forgot to add or deleted some fields - it'll break. If you pass wrong type - it'll break. Type is a test, that always actual.
hyniea 8y ago
Why do Javascript developers get so touchy whenever someone mentions types? I really don't think you were using TypeScript correctly from everything you've written.
- dunefox 8y ago
  If you look at his other comments, it's clear he doesn't understand type systems.
- jondubois 8y ago
  >> I really don't think you were using TypeScript correctly from everything you've written I've worked in multiple high-performing teams and have only received positive feedback for my TypeScript code so I'm pretty sure that I'm using it correctly. I don't like it, but that doesn't mean I'm not good at it. It's not in my personal interest to say bad things about TypeScript. I'm just sharing my honest unbiased experience.
mbrodersen 8y ago
I call BS on "2x to 3x extra time". I started out writing Javascript and then switched to Typescript. I ended up writing code faster!

austincheney 8y ago

> The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. I think you are doing something wrong. I switched over to TypeScript for my personal projects 2 years ago and never experienced that. If anything there are a few rare cases where I run into problems up front due to type conflicts, but really each of these cases likely would have resulted in expected maintenance down the road. Problems down the road were pushed much forward. The increase of effort was tiny, and its possible to really say, but this could have been a cost savings over the costly concerns of debugging an embedded problem. > I have over 1 year of experience with TypeScript in multiple projects and earlier in my career I used ActionScript 3.0 (also typed ECMAScript) for over 3 years so unlike the people who make the decision to move to TypeScript, I know what I'm saying. That isn't very much experience for the claims you are making.

sjapkee 8y ago

>The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. This is time which could have been spent on writing more tests. What's the reason to write tests for things, that just should works? You shouldn't think about tests like "What error does it throw if I pass that type?" With type checking you just won't have that type of issues.

zihotki 8y ago
Second that, the tests take time to write and they come with cost of development and also with cost of support in long-term. So having less of this kind of tests should be time-wise and economically-wise benefitial.
jondubois 8y ago
>> "What error does it throw if I pass that type?" With type checking you just won't have that type of issues. That's incorrect. If the object was parsed from JSON (e.g. sent to the server by a remote client), then you still need to do a type/schema check with TypeScript because types are only checked at compile time; not at runtime. If you have good integration tests, you don't need to explicitly check for types in JavaScript; type incompatibilities will show up as logic errors in the tests. For example, if you add 100 with '23', you will get '10023' - You don't need to use `typeof ... === 'number'` in order for your test suite to pick this up as a logic error. Even if your test case is written in TypeScript, you still need to account for the possibility that the front end will pass the value as a string; so the JavaScript test is the same size as the TypeScript one.
- sjapkee 8y ago
  > If the object was parsed from JSON Just stop using it. Use gRPC. It's binary -> faster. It's support TypeScript -> type safely. Type safety is a complex thing. If there is a type-safe instrument instead of type-unsafe, you should use it. >If you have good integration tests, you don't need to explicitly check for types in JavaScript It works only in the perfect world, where tests are always relevant and tests all cases. But we live in the imperfect world. With people, which may forget to update tests/documentation/etc. and things in something like JS still will works. But in the type-safe world things are different. If you forgot to add or deleted some fields - it'll break. If you pass wrong type - it'll break. Type is a test, that always actual.

hyniea 8y ago

Why do Javascript developers get so touchy whenever someone mentions types? I really don't think you were using TypeScript correctly from everything you've written.

dunefox 8y ago
If you look at his other comments, it's clear he doesn't understand type systems.
jondubois 8y ago
>> I really don't think you were using TypeScript correctly from everything you've written I've worked in multiple high-performing teams and have only received positive feedback for my TypeScript code so I'm pretty sure that I'm using it correctly. I don't like it, but that doesn't mean I'm not good at it. It's not in my personal interest to say bad things about TypeScript. I'm just sharing my honest unbiased experience.

mbrodersen 8y ago

I call BS on "2x to 3x extra time". I started out writing Javascript and then switched to Typescript. I ended up writing code faster!