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

141–150 of 570 posts

Re: Node.js adds experimental support for TypeScript

#141

Post by wiseowise »

mdhb wrote: post #75
coffeemug wrote: post #68

Earlier quoted context omitted.

What's an example of a ceiling? Out of all the mass-market programming languages, TS arguably has the most advanced type system in the world. It's a modern marvel that they got it working on top of Javascript.

I don’t know what you mean here by advanced? If you mean the sheer amount of fuckery they have to do in order to make it work with JS perhaps you have a point. If you mean expressiveness or consistent or soundness then no, it’s actually very bad compared to almost anything else and I think the longer it goes on the more it starts to feel like a house of cards. The upside I guess is that whenever Safari decides to get…

> The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options.

Out of those three only Dart has nice DX story compared to JS world.

Re: Node.js adds experimental support for TypeScript

#142

Post by jddj »

harshitaneja wrote: post #88

I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java. I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem. And surprising…

I'm somewhere here as well. Personally I think what I want is the stdlib (without the current legacy/ all but deprecated bits) and ecosystem of c# but with the ease and power of structural algebraic types. AoT is fine, with option for single binary. Ideally runtimeless with clever trimming. If it also ran jitted in the browser all the better.

I also want compiler/type checker niceties like exhaustive pattern matching.

Re: Node.js adds experimental support for TypeScript

#143

Post by flohofwoe »

jjk7 wrote: post #23
vivzkestrel wrote: post #18

Earlier quoted context omitted.

its about time google chrome started making a typescript engine maybe? and get rid of JS in phases?

There are a few optimizations that types can use but 99% of applications wouldn't benefit from them anyways.

One advantage of Typescript in context of performance should be that it nudges one to not change the 'shape' of runtime objects too much, this should allow less runtime overhead in JS engines because code doesn't need to be re-jitted as often.

This doesn't require the type annotations at runtime though, it's just a side effect of code being written against a static type system.

Re: Node.js adds experimental support for TypeScript

#144

Post by teaearlgraycold »

seanmcdirmid wrote: post #116
qalmakka wrote: post #106

Earlier quoted context omitted.

> we all just wanted java with JIT Java was literally the thing that made the term "JIT" popular, so I really don't know what you were going for here. Also I just can't see how Typescript is in any way "closer" to Java - it's incredibly different IMHO. The only thing they have in common is probably the "Javascript" misnomer and the fact both support imperative programming, but that's it.

Typescript’s optional and unsound type system also does nothing for a JIT beyond what it could already do for JavaScript, you can’t do optimization if your types are unreliable. However, I really really like how Typescript’s type system super charges developer productivity (type errors via the compiler and feedback via the IDE), and don’t mind this part of the design at all.

You can use typescript types to compile functions. You just might need to deoptimize when you actually hit the function.

Re: Node.js adds experimental support for TypeScript

#145

Post by [deleted] »

mdhb wrote: post #75
coffeemug wrote: post #68

Earlier quoted context omitted.

What's an example of a ceiling? Out of all the mass-market programming languages, TS arguably has the most advanced type system in the world. It's a modern marvel that they got it working on top of Javascript.

I don’t know what you mean here by advanced? If you mean the sheer amount of fuckery they have to do in order to make it work with JS perhaps you have a point. If you mean expressiveness or consistent or soundness then no, it’s actually very bad compared to almost anything else and I think the longer it goes on the more it starts to feel like a house of cards. The upside I guess is that whenever Safari decides to get…

[deleted]

Re: Node.js adds experimental support for TypeScript

#146

Post by magnio »

zx8080 wrote: post #99
harshitaneja wrote: post #88

I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java. I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem. And surprising…

> we all just wanted java with JIT, more feature rich type system Java has JIT. How is TypeSript type system feature-richer than the Java one?

I don't use them directly much, but template literal generic and contidiontal types is probably the closest a mainstream language has inched towards dependent types.

Some examples of TypeScript power:

- SQL database in TypeScript types: https://github.com/codemix/ts-sql

- Statically typed raw SQL queries: https://github.com/andywer/squid?tab=readme-ov-file#tag-func...

- (Someone fill in your TS hackery for me)

Re: Node.js adds experimental support for TypeScript

#147

Post by boromisp »

hackandthink wrote: post #117
samtheprogram wrote: post #9

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…

"nor have tsc configured to automatically add .js extensions to its compiled output" It seems to be the default now: $echo 'console.log("test")' > t.ts $ tsc t.ts $ ls t.js t.ts $ node t.js test

What they probably meant was writing 'import "file.ts"' and have tsc emit 'import "file.js"'. https://github.com/microsoft/TypeScript/issues/49083

Re: Node.js adds experimental support for TypeScript

#149

Post by IshKebab »

wiseowise wrote: post #131
phartenfeller wrote: post #76

Earlier quoted context omitted.

There is an EcmaScript proposal to go in that direction: https://github.com/tc39/proposal-type-annotations I think this should be part of the language spec.

Beyond ugly. They should just make TS official and be done with it. E: I thought it was JSDoc proposal. Ignore the comment.

What do you mean ugly? This basically is making Typescript official.

They just can't have browsers doing the actual type checking because there isn't a specification for how to do that, and writing one would be extremely complicated, and I'm not sure what the point would be anyway.

Re: Node.js adds experimental support for TypeScript

#150

Post by mkesper »

wiktor-k wrote: post #118
miki123211 wrote: post #89

Earlier quoted context omitted.

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…

> Something like `foo.bar[function]()` is perfectly valid JS, A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".

Oh boy, just think functionName and it fits.
Post reply on HN