Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.asana.com

Post reply on HN
Print view View original

101–110 of 216 posts

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

#101

Post by garaboncias2 »

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?

We use TSOA[1] for that, it can build OpenApi specification from your ts interface. So its could be used for documentation and tsoa can validate but other tools can validate too

[1] https://github.com/lukeautry/tsoa

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

#103

Post by crimsonalucard »

shhsshs wrote: post #77
yawaramin wrote: post #70

Earlier quoted context omitted.

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript…

TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids. JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.

This is absolutely false all type checking in basically every typed language happens precompile time.

There is no trade-off here. You completely don't understand.

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

#104

Post by MaulingMonkey »

kazinator wrote: post #98
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

If you can pass a Cat to a Dog function, where is the better checking? That would be one of the hello-world test cases for a type checker bolted on to a dynamic language. That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

Note that you can only pass Cat to a Dog function if:

* All fields of Dog are also present in Cat, with compatible type signatures

* All functions of Dog are also present in Cat, with comaptible type signatures

"compatible type signatures" does seem to leave some suprising co/contravariance holes still when using wider union types, but C#/Java arrays also have co/contravariance holes and we don't automatically write off their entire type systems because of it. Or, well, at least I don't ;).

As a meaningless point of ancedata: Making these types sufficiently equivalent to fall through this type safety hole appears to be rare enough that I've never done so by accident - allowing me to be suprised by the article's example of passing a class Cat to a class Dog-accepting function being legal. While typescript has never been my primary dayjob, it's been a significant secondary part of my dayjob and hobby junk.

(EDIT: Minor clarifications)

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

#105

Post by meheleventyone »

kazinator wrote: post #98
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

If you can pass a Cat to a Dog function, where is the better checking? That would be one of the hello-world test cases for a type checker bolted on to a dynamic language. That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

The problem is less that the syntax exists and more that people are used to nominal typing so get confused with edge cases where structural typing departs from it. The type checker isn’t breaking any promises it made it’s just slightly different from people’s mental model of how types should work from experience of other languages.

It’s just a different kettle of fish to learn.

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

#106

Post by Findeton »

twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks.

However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using/developing an input validation library for the backend in Typescript (https://github.com/StrontiumJS/Framework/) that is composable and also returns the correct type in one go. We used a lot of try catches for that, but that makes validation slow. So we started using "maybe promises" which are similar to Scala's Futures with Success/Failure. But the fact you don't have pattern matching in Typescript like in Scala makes it a bit ugly.

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

#107

Post by danielnixon »

acemarke wrote: post #14
littlecranky67 wrote: post #12

Earlier quoted context omitted.

also bear in mind that support for discriminated unions is what made typescript work nicely with redux actions - that is be able to strongly type actions/reducers/dispatch functions. One thing I love about typescript is they care more for the actual JS/library ecosystem as-is, and don't design a language for an ecosystem that should-be.

FWIW, I'm a Redux maintainer, and I personally have never understood the point of trying to limit what actions are being dispatched. As long as your reducers and action creators are well typed, it shouldn't matter what other actions might be sent through. On that note, our new Redux Toolkit package is written in TS, and designed to work great in TS apps with a minimal amount of type declarations needed. Really just d…

> I personally have never understood the point of trying to limit what actions are being dispatched. As long as your reducers and action creators are well typed, it shouldn't matter what other actions might be sent through.

The value comes when you consider what happens if a reducer (or saga or whatever) is updated in a breaking way (or removed wholesale).

Example: consider a scenario where you use `connected-react-router`, your codebase fills up with history actions being dispatched, then one day you remove `connected-react-router`, or its major version is updated and introduces some breaking change.

If you have a union type that includes all your own actions plus the `LocationChangeAction` from connected-react-router (and you use is consistently - e.g. your components take `Dispatch`) then you'll learn about the breaking change when your app fails to compile.

The alternative is you catch it later than compile-time, at worst _much_ later.

You might decide that the overhead in this scenario isn't worth it, and that's your call to make (I believe it is worth it) but hopefully this gives an idea of the point.

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

#108

Post by bt4u »

ketzo wrote: post #94
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

Yup. Rather than bringing 100,000 devs from one typed language to another, Typescript brings 1,000,000 devs from untyped to typed.

There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed

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

#109

Post by gherkinnn »

jbob2000 wrote: post #45
nojvek wrote: post #39

Typescript is great but it has its evils because it’s a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problems. The more I use typescript I realize I want a more sound and stricter language. Like no prototype overriding at runtime.

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return…

I found that by explicitly having to write types, the structures become a lot less convoluted. You split things apart, give them names, spot patterns more easily, and encode all sorts of information in a type system. And knowing that all fields are there when you need them is a relief.

Of course a code review can catch it. Of course careful programming can as well. But those are external constraints.

Having internal constraints greatly reduces the amount of mess one can produce.

Admittedly, sometimes to a point to which you’ve typed yourself in to a corner.

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

#110

Post by gear54rus »

jillesvangurp wrote: post #79
nojvek wrote: post #39

Typescript is great but it has its evils because it’s a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problems. The more I use typescript I realize I want a more sound and stricter language. Like no prototype overriding at runtime.

I always think of it as a gateway drug that gets people into using other languages. Most fullstack developers I know are transitioning to things like Rust, Go, Swift, Kotlin, etc. Once javascript interoperability stops being a goal, there are many other languages that suddenly become attractive. The irony with the Javascript ecosystem is that most of it is now written in typescript or other languages. That includes m…

I sometimes think wasm was invented to rid this glorious js ecosystem of people who always moan about it so the rest of us can get back to 'improving tooling and best practices'.
Post reply on HN