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

HypeScript: Simplified TypeScript type system in TypeScript's own type system

github.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#71

Post by LAC-Tech »

epolanski wrote: post #60
LAC-Tech wrote: post #48

Earlier quoted context omitted.

Yeah that would be weird. Using tsc to type check javascript - with JSDoc type annotations - works fine. You're really not missing much from "real" typescript, and you can save yourself a transpile.

It doesn't really work fine beyond a single file. I tried the experiment of .js files driven by typescript in JSDocs for around 10k lines and there is a night and day difference in what you can express, how and reuse it at the type level.

I'm experienced in doing this too.

Name one thing you can't do.

To clairfy, if I am sharing types between modules I tend to use .d.ts files. Still no transpiling needed.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#72

Post by LAC-Tech »

no_wizard wrote: post #65
LAC-Tech wrote: post #48

Earlier quoted context omitted.

Yeah that would be weird. Using tsc to type check javascript - with JSDoc type annotations - works fine. You're really not missing much from "real" typescript, and you can save yourself a transpile.

until you need to type the shape of objects, and want to share that shape with other files. You can't import JSDoc types from other files. At which point, you would be forced to create `types.d.ts` file or similar. Might as well be writing typescript. The limitations are too much for complex projects at scale. I strongly believe this is why Closure types didn't take off. That and Google's lack of developer relations…

You can use types written in a .d.ts file in javascript. You reference them with the JSDoc annotations.

And no it's not the case you may as well write typescript at that point - because you're still using the actual language the browser runs, and not transpiling.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#74

Post by xsmasher »

sanitycheck wrote: post #45
girvo wrote: post #28

Earlier quoted context omitted.

As others have pointed out, they're not really "strings" per se, or at least can be a lot stricter than a string might seem when used right. We use that constantly for useful things. The bigger reason why it is this way is to ensure you can write type annotations for stringly-typed Javascript. While Typescript is it's own thing really at this point, it still is very focused on making it possible to type-annotate JS c…

I found it interesting that I would never use strings this way in JS, but TS seems to encourage it. I definitely would not want to strip typing out of my TS code and try to maintain it as plain JS.

What would you use for a field called "stage" that could be set to 'dev' or 'stage' or 'prod'? Or other enum-type things?

I've seen pure JS enums like {'dev' : Symbol('dev'), 'prod' : etc} but I never use them because you can't send them over the wire.

You could use a type like {dev:true} | {prod:true} | {stage:true} but you still wind up comparing strings.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#75

Post by mmis1000 »

xsmasher wrote: post #74
sanitycheck wrote: post #45

Earlier quoted context omitted.

I found it interesting that I would never use strings this way in JS, but TS seems to encourage it. I definitely would not want to strip typing out of my TS code and try to maintain it as plain JS.

What would you use for a field called "stage" that could be set to 'dev' or 'stage' or 'prod'? Or other enum-type things? I've seen pure JS enums like {'dev' : Symbol('dev'), 'prod' : etc} but I never use them because you can't send them over the wire. You could use a type like {dev:true} | {prod:true} | {stage:true} but you still wind up comparing strings.

> {dev:true} | {prod:true} | {stage:true}

This can't be accessed safely. Because all value in typescript can be sub type of how it typed.

It means code following will pass.

    var a = { dev: true, get prod() { throw Error() } }
    var b: { dev:true } | {prod:true} | {stage:true} = a
And there is no guarantee that access any of these fields is safe.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#76

Post by phil294 »

faichai wrote: post #57
thrwawy74 wrote: post #53

Earlier quoted context omitted.

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

I loved it to. I'd love to make a typed coffeescript variant, which transpiles to TypeScript rather than JavaScript. My pet name for this is `tycoscript`.

This already exists, see [1]. Development has a bit stalled, but afaik the author wants to keep pursuing it. There's even a Discord server for this kind of project, see also this GitHub thread [2] where CS+TS is being discussed in general. Alternatively, you can code in Coffee with JSDoc type annotations, yielding a near-TypeScript experience in both IDE and output, albeit the annotation syntax can be a bit annoying, ironically.

[1] https://github.com/edemaine/coffeescript/blob/typescript/tes... [2] https://github.com/jashkenas/coffeescript/issues/5307

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#77

Post by spiralx »

staticassertion wrote: post #11
theK wrote: post #10

Am I the only one that feels uncomfortable with all that usage of strings in TS’s type system? Why not use pure literals instead of string literals? This is a genuine question, I’m trying to find out what the pros and cons where in the decision making process.

I think it's kind of cool. It reminds me a bit of C++ templates, which are "compile time duck typed". The benefit is that you get lose typing constructs that are evaluated strictly and at type check time , which is kinda nutty. It means that you can lean really heavily on the compiler. Sort of like using Python to generate Typescript, as random example - my Python code doesn't have to typecheck, but its output does,…

Which allows for things like this type that implements a simplified SQL query parser checked against a provided 'database' object:

https://github.com/codemix/ts-sql

This project was my go-to "nifty but pointless" example for TS string literal types before this article :)

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#78

Post by staticassertion »

spiralx wrote: post #77
staticassertion wrote: post #11

Earlier quoted context omitted.

I think it's kind of cool. It reminds me a bit of C++ templates, which are "compile time duck typed". The benefit is that you get lose typing constructs that are evaluated strictly and at type check time , which is kinda nutty. It means that you can lean really heavily on the compiler. Sort of like using Python to generate Typescript, as random example - my Python code doesn't have to typecheck, but its output does,…

Which allows for things like this type that implements a simplified SQL query parser checked against a provided 'database' object: https://github.com/codemix/ts-sql This project was my go-to "nifty but pointless" example for TS string literal types before this article :)

Yeah I saw that was cited and I love it. It's insane but super cool and I could imagine the approach being used for something similar to https://crates.io/crates/sqlx although there's probably better ways to do it lol

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#79

Post by noduerme »

brundolf wrote: post #63
dfee wrote: post #33

Earlier quoted context omitted.

This linked project is very cool! I wonder if this path is expressly a non-goal of the TypeScript team though…?

Yeah, giving types a runtime footprint is on the official list of non-goals for the TypeScript project: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Interesting.

> Instead, encourage programming patterns that do not require run-time metadata.

I can understand why. But there are times when any alternative pattern is a worse choice. Then it's left to the coder to hack together type checks however it's convenient. Does the Dog class really need a static variable typed to Dog|Cat... ? It would be nice if instead of a dozen nonstandard ways to do that, some metadata could be emitted if you wanted to. TS does weird stuff like emitting functions to define enums, for instance.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#80

Post by brundolf »

noduerme wrote: post #79
brundolf wrote: post #63

Earlier quoted context omitted.

Yeah, giving types a runtime footprint is on the official list of non-goals for the TypeScript project: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Interesting. > Instead, encourage programming patterns that do not require run-time metadata. I can understand why. But there are times when any alternative pattern is a worse choice. Then it's left to the coder to hack together type checks however it's convenient. Does the Dog class really need a static variable typed to Dog|Cat... ? It would be nice if instead of a dozen nonstandard ways to do that, some metadata c…

> Does the Dog class really need a static variable typed to Dog|Cat... ?

It doesn't- because classes are a native JS concept and not a TS concept; they already have the metadata to distinguish them

> TS does weird stuff like emitting functions to define enums, for instance

Not sure what's meant by this; TypeScript does introduce enum syntax which technically generates runtime code (one of the few instances), though it's just very light sugar over constants, and using it is also sorta advised against these days

Post reply on HN