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

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

431–440 of 570 posts

Re: Node.js adds experimental support for TypeScript

#431

Post by thr0w »

WorldMaker wrote: post #392
nfriedly wrote: post #380

Earlier quoted context omitted.

For the old libraries I maintain that are typescript and transpiled into .cjs and .mjs for npm, I'll probably just start shipping all three versions. For a new thing I was writing from scratch, yeah, I might just ship typescript and not bother transpiling. [edit: Apparently not. TS is only for top-level things, not libraries in node_modules according to the sibling comment from satanacchio who I believe is the author…

Why are you still transpiling to .cjs in 2024? ESM is supported in every LTS version of Node now. We can kill CJS, we have the power.

> ESM is supported in every LTS version of Node now. We can kill CJS, we have the power.

I'd rather kill ESM. And it's not fully supported in Node. It doesn't work in the REPL.

Re: Node.js adds experimental support for TypeScript

#432

Post by wiseowise »

Dylan16807 wrote: post #423
wiseowise wrote: post #329

Earlier quoted context omitted.

Yeah. I saw JSDoc and closed it, lol.

Specifically, you saw the section titled "Limits of JSDoc Type Annotations"?

Specifically, I saw JSDoc syntax and it triggered me so much that I closed the page and threw my phone away in disgust at absurdness of even the idea that someone thought having something like this unironically is a remotely good idea.

Re: Node.js adds experimental support for TypeScript

#433

Post by 9dev »

sesm wrote: post #361
simplify wrote: post #270

Earlier quoted context omitted.

Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.

Because Flow is an actual developer tool, not a rent-seeking landgrab with a marketing budget.

I don’t know what axe you have to grind, but TypeScript is firmly in the hands of the community now. There’s not much Microsoft could do to change that. In what way would it be rent-seeking?

Re: Node.js adds experimental support for TypeScript

#434

Post by tpm »

afiori wrote: post #427
nequo wrote: post #410

Earlier quoted context omitted.

I am not familiar with TypeScript. Is there something that you can achieve with union types that you can’t with sum types or type classes in Haskell?

TL;DR: Typescript is unsound so it can add a lot more type-level features that would make a sound type system undecidable Conceptually no, almost every useful union type can be easily converted to a sum type. In my opinion the difference is in the ergonomics and in the implicit structural subtyping. For example a common union type is number|string , and the beatiful part is that to use a value of such a type you do n…

> For example a common union type is number|string

So that's like my beloved Perl then.

Re: Node.js adds experimental support for TypeScript

#435

Post by mcluck »

hot_gril wrote: post #367
ZhongXina wrote: post #161

Earlier quoted context omitted.

Better for what? Quickly churning out short-lived code to get the next round of funding, definitely. Writing (and _supporting_) "serious" projects over the long term, which also require high performance and/or high scalability, and can rip through terabytes of data if needed, definitely not. (All IMHO from lots of personal experience.)

It's good for things that don't involve ripping through terabytes of data, which is actually a lot of things. And idk if I'd use Java for that either.

I'm actually in this exact position right now. The vast majority of the time I write in TS but I have a need to process a whole lot of data so I went for Rust instead. Java is too much of a headache for me, personally

Re: Node.js adds experimental support for TypeScript

#436

Post by pcthrowaway »

spankalee wrote: post #414
pcthrowaway wrote: post #44

Earlier quoted context omitted.

Types as comments is what jsdoc supports. Flow is compiled like typescript. tsc does also support jsdoc though, so technically I think tsc is closer to supporting types as comments, though it's possible Flow has this also.

Types _in_ comments is different from types _as_ comments. "Types as comments" refers to how type expressions are parsed.

jsdoc is a format for supplying types (and annotations) as comments as well.

I think I get the distinction you're trying to make, but I don't think the nuance there is significant enough to merit differentiating the two.

Re: Node.js adds experimental support for TypeScript

#437

Post by IshKebab »

parasense wrote: post #401
zarzavat wrote: post #298

Earlier quoted context omitted.

The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square b…

Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes...…

Sure, you can use Canadian Aboriginal Syllabics!

https://www.reddit.com/r/rust/comments/5penft/comment/dcsq64...

Re: Node.js adds experimental support for TypeScript

#438

Post by umvi »

sureIy wrote: post #419
andrewmcwatters wrote: post #374

Earlier quoted context omitted.

TypeScript in its current usage reminds me of Hello, World! or FizzBuzz Enterprise Edition. There's almost more code dedicated to typing than the actual running software itself in some codebases I've seen. The authors trick you with reasonable examples on https://www.typescriptlang.org , but in the wild, you have these ridiculous codebases that couldn't control themselves and they have this insane ratio of multiple d…

I also get lost in types sometimes, but the point of types is that they help you. Typescript lets you just use `as any` and `as unknown` as you please, but you want complex constraints you will need complex types. There are some type libraries that parse GraphQL queries and CSS selectors. They’re crazy to look at but they’re hugely helpful.

Maybe I just have bad luck, but most of the libraries I've tried that are "crazy to look at" seem good in theory but are janky in practice. For example, openapi-fetch (https://github.com/openapi-ts/openapi-typescript/tree/main/p...), on paper seems great, but has lots of jank in practice.

And I would wager the bugs and jank are in no small part due to the extremely complex generics/constraints.

Re: Node.js adds experimental support for TypeScript

#439

Post by hajile »

zoul wrote: post #86
pansa2 wrote: post #69

Earlier quoted context omitted.

> Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type h…

In my experience unsoundness is almost never a problem in practice, see here for details: https://effectivetypescript.com/2021/05/06/unsoundness/

Unsound types are never a problem until they are at which point you are staring at code that SHOULD be working, but is somehow breaking.

Re: Node.js adds experimental support for TypeScript

#440

Post by lolinder »

nyssos wrote: post #404
lolinder wrote: post #306

Earlier quoted context omitted.

Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language. Do…

> Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Sure. The usual Java-style variance nonsense is probably the most common source, but I see you're not bothered by that, so the next worst thing is likely object spreading. Here's an anonymized version of something that cropped up in code review earlier this week: const incomingValue: { name:…

I mean... yes, there's a footgun there where you have to know to spread first and then add the new properties. That's just a good practice in the general case: an intermediate type that fully described the data wouldn't have saved you from overwriting it unless you actually looked closely at the type signature.

And yes, TypeScript types are "at least these properties" and not "exactly these properties". That is by design and is frankly one reason why I like TypeScript over Java/C#/Kotlin.

I'd be very interested to know what you'd do to change the type system here to catch this. Are you proposing that types be exact bounds rather than lower bounds on what an object contains?

Post reply on HN