Hacker News Reader

Comment by jondubois | Hacker News Reader

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

View on HN

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

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

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.

Reply on news.ycombinator.com