Hacker News Reader

> 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.

>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.

>> "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.

> 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.

JSON is the best, simplest, most robust, most readable, most flexible data interchange format ever invented and fastest to integrate with external systems. No way I would give it up for Protocol Buffers - That's like going back to the old SOAP protocols.

Have you tried integrating with an external service via a SOAP API? It would be quicker to rewrite the entire service from scratch than to integrate with it.

Also, I'm not a big fan of gRPC; their decision to use HTTP2 instead of WebSockets was a huge mistake. HTTP was designed to transfer hypertext documents; RPCs are meant to transfer raw data; not hypertext documents. In a way, gRPC makes the same mistake as TypeScript; instead of fixing the problem at the root, they take an already complex solution which works well as a base and then they add more complexity on top in an effort to make it behave in a simpler way than the underlying technology.

You can't make something simpler by adding more complexity on top. You just can't.

You can't call something simple, if you can't to determine how it's working at each step. In JS all you can say is just "with that sort of data looks like it works well, but with others it can throw error or has undefined behavior". With types it works or not works. There is no type issues, only algorithm issues. Of course it's simpler.

There are trade-offs, for example if you pass "3" should it also work when passing in "three" !? By limiting possible errors/inputs, you also make it harder to use.

It's simpler to use when you see interface. Otherwise you should read all function code to find out how it works and what kind of data you can pass into it. Of course you can say, that there is should be comments/documentation, but your code should be the best documentation itself.

That's a semantic error, not a type error.

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.

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.

>> 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.

If you look at his other comments, it's clear he doesn't understand type systems.

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!