Hacker News Reader

Comment by sjapkee | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com