TypeScript’s quirks: How inconsistencies make the language more complex • Hacker News Board

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#21

Post by jolux » Sat, Feb 01, 2020, 2:00 AM UTC

earthly wrote: post #20

I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this: const shasta = new Cat("Maine Coon") printDog(shasta) > Dog:Maine Coon I see a huge red flag. Coming from C/C++ it looks like a joke. W…

It’s structural static typing, a perfectly cromulent class of type system, and much more easily compatible with dynamics types.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#22

Post by virtue3 » Sat, Feb 01, 2020, 2:01 AM UTC

earthly wrote: post #20

I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this: const shasta = new Cat("Maine Coon") printDog(shasta) > Dog:Maine Coon I see a huge red flag. Coming from C/C++ it looks like a joke. W…

Because you can get some decent typing with some compiler help AND leverage the entire node/js eco system super easily. Which is kind of the whole point.

As someone that's done c/c++/c#/lua/js/ts I've found typescript to be really awesome because it differentiates the types from the objects. Which has given me a much better appreciation of typing rather than the traditional OOP everything.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#23

Post by smoyer » Sat, Feb 01, 2020, 2:02 AM UTC

Sounds like we're about to see a book titled "TypeScript - The Good Parts". That was actually one of my favorite JavaScript books and led to my early adoption of CoffeeScript (since it purposely fixed the "bad" and "ugly" parts at the back of the book.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#24

Post by habosa » Sat, Feb 01, 2020, 2:06 AM UTC

Ok since we have a lot of TS people here maybe someone can help me out.

Let's say I have a simple interface with a few fields. I want to make sure incoming JSON conforms to that interface.

I realize at runtime the interface isn't there, but is there some tool I can use to compile a utility to check JSON against an interface without having to write a duplicative JSONSchema or something else?

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#25

Post by stefan_ » Sat, Feb 01, 2020, 2:08 AM UTC

habosa wrote: post #24

Ok since we have a lot of TS people here maybe someone can help me out. Let's say I have a simple interface with a few fields. I want to make sure incoming JSON conforms to that interface. I realize at runtime the interface isn't there, but is there some tool I can use to compile a utility to check JSON against an interface without having to write a duplicative JSONSchema or something else?

io-ts [1] is what I think most people use for this

1: https://github.com/gcanti/io-ts

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#26

Post by earthly » Sat, Feb 01, 2020, 2:09 AM UTC

andrew_n wrote: post #9

aratakareigen wrote: post #7

How does TypeScript ensure encapsulation if it doesn't have nominal types? Edit: The article says "magical hidden properties".

Programming TypeScript has a section on “Simulating Nominal Types” [1]. You define a type that’s impossible to create naturally, and provide a function that asserts something is of that type. type CompanyID = string & {readonly brand: unique symbol} type OrderID = string & {readonly brand: unique symbol} type UserID = string & {readonly brand: unique symbol} type ID = CompanyID | OrderID | UserID function CompanyID(i…

> TypeScript can be very confusing sometimes

That's not good. A type system should be crystal clear, predictable and reliable.

> and given the learning curve

Types should not be a complex thing with a steep learning curve. If you know Assembler and C it's pretty clear what types are about. Added complexity to your codebase is what you should try to avoid at all times. We have a limited capacity of things we can think of at a time, developers should therefore focus on things that really matter. In my daily work I see highly complex piles of spaghetti in TS that are 'type safe' and easy to refactor..

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#27

Post by BigJono » Sat, Feb 01, 2020, 2:12 AM UTC

earthly wrote: post #20

I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this: const shasta = new Cat("Maine Coon") printDog(shasta) > Dog:Maine Coon I see a huge red flag. Coming from C/C++ it looks like a joke. W…

I've never used Typescript, but I don't think these are really 'major' flaws. That's just my perspective as someone that's being doing FE for over a decade and picks this stuff up fairly quick. Obviously it's more of a problem for newbs that probably aren't going to read that paragraph about discriminated unions and grok it straight away.

Having said that, I absolutely hate the ending of this blog post. I see blog writers do this all the time. He's just given three detailed, concrete negatives about Typescript, given enough information to infer that these quirks could be problematic for beginners and cost your team time and resources. Then at the end, he suggests that you use Typescript and waves it all away with some ambiguous bullshit about how static typing saves you a bunch of time.

There's so many of these claims that are just taken as common knowledge/best practices, that everyone treats as absolute truth that overrules everything else, even good concrete examples. I've been building entire apps myself for over a decade now, using both plain and typed (flow) JS, and every time I've seen somebody try and elaborate on how static typing saves you all this time, it's some pissant todo list bug that I would have solved in 5 seconds with plain JS.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#28

Post by BigJono » Sat, Feb 01, 2020, 2:14 AM UTC

felixfbecker wrote: post #4

leetrout wrote: post #3

The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type. The correct use of: printDog({ breed: "Airedale", age: 3 }) is to explicitly cast it: printDog({ breed: "Airedale", age: 3 } as Dog) [0] https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p... [1] https://www.typescriptlang.org/docs/handbook/advanced-type…

Casting can hide errors. It's better to assign it to a variable first that has a type declaration. const dog: Dog = { breed: "Airedale", age: 3 } printDog(dog) An IIFE is safe too: printDog(((): Dog => ({ breed: "Airedale", age: 3 })())

Yeah and both of those are less readable, and used everywhere add up to a really crap code base relative to the same code in plain JS.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#29

Post by Kinrany » Sat, Feb 01, 2020, 2:19 AM UTC

leetrout wrote: post #3

The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type. The correct use of: printDog({ breed: "Airedale", age: 3 }) is to explicitly cast it: printDog({ breed: "Airedale", age: 3 } as Dog) [0] https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p... [1] https://www.typescriptlang.org/docs/handbook/advanced-type…

Casting may hide errors and is unnecessary in this case: `as const` will work just as well.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#30

Post by jvilk » Sat, Feb 01, 2020, 2:25 AM UTC

habosa wrote: post #24

Ok since we have a lot of TS people here maybe someone can help me out. Let's say I have a simple interface with a few fields. I want to make sure incoming JSON conforms to that interface. I realize at runtime the interface isn't there, but is there some tool I can use to compile a utility to check JSON against an interface without having to write a duplicative JSONSchema or something else?

I wrote a tool that may be useful here; it generates a TypeScript definition file and runtime type checking logic given examples of the objects you want to accept.

https://jvilk.com/MakeTypes/