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

301–310 of 570 posts

Re: Node.js adds experimental support for TypeScript

#301

Post by nyssos »

kcrwfrd_ wrote: post #98
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…

Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing? Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.

There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.

Re: Node.js adds experimental support for TypeScript

#303

Post by dobladov »

rty32 wrote: post #245
dobladov wrote: post #195

Earlier quoted context omitted.

You should write complex types in interfaces files where they belong, and there's full typescript support. I use this approach professionally in teams with many developers, and it works better for us than native TS. Honestly give it a try, I was skeptical at first.

In general JSDoc is just much more verbose and has more friction, even outside complex types. I recently finished a small (20 files/3000 lines), strictly typed JS project using full JSDoc, and I really miss the experience of using the real TypeScript syntax. Pain points: annotating function parameter types (especially anonymous function), intermediate variable type and automatic type-only import, these are the ones t…

I use snippets to write those, yes it's more verbose there's not denying that.

For me the advantages of just having JS files and not worrying about more complex source-maps, build files, etc definitely makes it worth it.

Re: Node.js adds experimental support for TypeScript

#304

Post by mablopoule »

epolanski wrote: post #274
dobladov wrote: post #180

Earlier quoted context omitted.

You can have this now adding types with JSDoc and validating them with typescript without compiling, you get faster builds and code that works everywhere without magic or need to strip anything else than comments. The biggest pain point of using JSDoc at least for me was the import syntax, this has changed since Typescript 5.5, and it's now not an issue anymore.

JSDoc absolutely does not scale and allows for very limited type programming. It's fine on toy projects, and somewhat I would say, for 99% of users that don't even know what a mapped or intersection type is.

JSDoc does not scale, but some projects are just better when they aren't scaled.

JSDoc is indeed fine on toy project, or in fact any project (even prod-ready ones) that doesn't warrant the trouble of adding NPM packages and transpilation steps.

Although they are rare, those type of small, feature-complete codebases do exists.

Re: Node.js adds experimental support for TypeScript

#305

Post by pier25 »

spankalee wrote: post #11

It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-standard runtime semantics and modulo whatever changes are necessary to integrate the grammar. So many runtimes and tools are integrating TypeScript now, and with multiple implementations, that a real standard is necessary. It'll be much harder to evolve TypeSc…

Another reason is probably performance. Executing TS would require a lot of extra CPU and even more energy than JS.

A lot of effort and money has been invested into JS engines. I wonder if making a TS native engine (which nobody has made yet) from scratch might make more sense than adapting JS engines to run TS.

Re: Node.js adds experimental support for TypeScript

#306

Post by lolinder »

nyssos wrote: post #301
kcrwfrd_ wrote: post #98

Earlier quoted context omitted.

Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing? Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.

There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.

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 you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Or an anecdote you can link to from someone else?

Re: Node.js adds experimental support for TypeScript

#307

Post by Shacklz »

_flux wrote: post #204
Shacklz wrote: post #42

Earlier quoted context omitted.

Taking one link out of the toolchain (tsc) would already be a huge blessing. And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run. The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kil…

Why is taking out the part that actually checks the types at the developer's side a huge blessing? Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://d…

> Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Oh, no, certainly we want to keep type-checking in the pipeline, somewhere.

However, if the browser "understood" typescript, your codebase could have immediate hot-reload, without any transpilation in-between. The type-checking could then be (and already is when using something like esbuild/swc) an entirely separate process that happens independently.

Webpack's HMR is pretty good, but not having to modify the code at all to have it work in the browser, that'd be much much better :)

... the browser being able to typecheck (and reject violating code) itself is certainly something I'd love to see eventually, but fully agreed, this is not happening anytime soon.

Re: Node.js adds experimental support for TypeScript

#308

Post by nthngy »

IMAO writing (hard-coding) TypeScript is deprecated and a waste of time. With all tech available nowadays it is possible to do the entire type check automatically in the IDE, even more so now with the help of AI. It's just a matter of time when we stop hard-coding type info. Better invest time and money in getting the IDE's work better for us.

Re: Node.js adds experimental support for TypeScript

#310

Post by revskill »

bythreads wrote: post #232
Shacklz wrote: post #33

Earlier quoted context omitted.

In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed. Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in…

agree enums in typescript are the devil

Could u explain why ?
Post reply on HN