TypeScript 3.4 - Hackdot

Re:TypeScript 3.4 by asark on Saturday March 30, 2019 @01:05PM (#19530496)

Typescript also significantly reduces communication overhead and provides machine-verifiable documentation, making it way easier to figure out WTF is going on with unfamiliar or long-out-of-sight code. People who don't love TS compared with vanilla JS must work entirely differently from me—using it's the only time I've not hated writing JS. Tons of time-wasting poking about and background anxiety just gone. It's great, and costs almost nothing.

[ Parent | on HN ]

Re:TypeScript 3.4 by phamilton on Saturday March 30, 2019 @01:26PM (#19530609)

Typescript is a gamechanger with generated interfaces. We use it heavily with an RPC framework and pulling down the generated client and server packages have drastically minimized integration issues.

It just takes away the mental overhead of making something conform to a spec. It probably doesn't save us much on production bugs, but it makes development faster.

[ Parent | on HN ]

Re:TypeScript 3.4 by jondubois on Saturday March 30, 2019 @02:46PM (#19531041)

Generated interfaces are an anti-pattern. Types force tight coupling between clients and servers. What if a third-party project written in a different language wants to communicate with your server using their own client? Types will make it more difficult for them to integrate because:

1. If they're using a dynamically typed language, this gives them extra work to typecast everything back and forth whenever they need to communicate with your system.

2. Even if they use types, maybe their type system is not compatible with yours and they need to do a lot of tedious extra work to typecast everything.

[ Parent | on HN ]

Re:TypeScript 3.4 by asark on Saturday March 30, 2019 @03:18PM (#19531215)

Huh? Everything always has a type anyway. It's sometimes just harder to know what it is. Specifying doesn't make the types appear out of nowhere, it just documents them.

[ Parent | on HN ]

Re:TypeScript 3.4 by true_religion on Saturday March 30, 2019 @03:21PM (#19531233)

I wouldn't call that an antipattern.

I treat other systems like I do the database and enforce consistency at the API level.

I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API.

Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.

[ Parent | on HN ]

Re:TypeScript 3.4 by tom_ on Saturday March 30, 2019 @05:45PM (#19532078)

No, it makes it easier, because they have a specification to work from, and they can probably just use that spec to generate their own glue code, assuming any is necessary.

I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.

[ Parent | on HN ]

Re:TypeScript 3.4 by phamilton on Sunday March 31, 2019 @08:11AM (#19535186)

I've found it to be annoying in the other direction. A type system like protobuf isn't rich enough for the problem domain. We end up building a lot of additional validation into the servers and clients that could have been enforced by the service/types spec.

[ Parent | on HN ]

Re:TypeScript 3.4 by phamilton on Sunday March 31, 2019 @08:03AM (#19535176)

Which is why our rpc services accept json in addition to protobuf. Yay, problem solved.

[ Parent | on HN ]

Re:TypeScript 3.4 by zwerdlds on Saturday March 30, 2019 @03:14PM (#19531195)

what is the solution? runtime errors?

[ Parent | on HN ]