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

271–280 of 570 posts

Re: Node.js adds experimental support for TypeScript

#271

Post by Waterluvian »

murmansk wrote: post #185
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.

[flagged]

Jsdoc is honestly fine for simple and smaller projects. But yeah, it’s definitely not nearly as expensive while being anywhere as succinct.

Re: Node.js adds experimental support for TypeScript

#272

Post by chrisweekly »

another-dave wrote: post #190
zarzavat wrote: post #184

Earlier quoted context omitted.

It’s an issue because node has a system of LTS releases, whereas TypeScript has quarterly updates, so the release cadence is different. Updating node is much more fraught than updating TypeScript. For example, it may break any native code modules. That’s why users are directed to use the LTS and not the most recent release, so that there’s enough time for libraries to add support for the new version. On the other han…

Though I'd primarily see this as a feature for the REPL or manual scripts where I'm not going to mind doing a `nvm use X`. For production use, I'd still put my TS files through a build pipeline as normal

tangential protip: if you're using nvm to manage node versions, take a look at fnm as a superior replacement. (It can read the same .nvmrc file to switch on cd into a given dir, but it's faster and "cleaner" wrt impact on your shell.)

Re: Node.js adds experimental support for TypeScript

#273

Post by [deleted] »

wiseowise wrote: post #121
zx8080 wrote: post #99

Earlier quoted context omitted.

> 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?

https://www.typescriptlang.org/docs/handbook/2/types-from-ty... https://www.typescriptlang.org/docs/handbook/2/template-lite... alone puts TS over anything that Java has.

[deleted]

Re: Node.js adds experimental support for TypeScript

#274

Post by epolanski »

dobladov wrote: post #180
pansa2 wrote: post #34

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them. It's interesting, though, that this approach in Python has led to several (4?) different popular…

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.

Re: Node.js adds experimental support for TypeScript

#275

Post by epolanski »

mananaysiempre wrote: post #260
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…

> A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.

What do you mean by unsound exactly.

I'm asking because there's no accepted definition of what an unsound type system is.

What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.

Re: Node.js adds experimental support for TypeScript

#276

Post by azangru »

silverwind wrote: post #233
azangru wrote: post #191

Earlier quoted context omitted.

There are union types for strings; and there are plain javascript objects (typed as const) if "namespace.name" syntax is desired. With these available, what is the point of enums?

Namespaces are also not supported as per https://github.com/nodejs/node/blob/main/doc/api/typescript.... . I for one can can live without all these features and will be banning via eslint.

Yes. Both namespaces and enums (and probably the "private" keyword on class methods) are an early addition to the language, which would have never been added if typescript from the very start aligned closely with Ecmascript.

Re: Node.js adds experimental support for TypeScript

#277

Post by djeastm »

miunau wrote: post #164
tstrimple wrote: post #56

Earlier quoted context omitted.

My days of being a real software developer are long behind me. So I'm totally willing to accept that I'm wrong here. But when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types. Suddenly I can accept non well defined data types (depending on my implementation) and can persist data that otherwise would have taken code changes and approval processes to accept. I…

Just use `any` or `unknown` when prototyping, then apply types once your happy paths start working for the first time to start catching the unhappy ones.

>then apply types once your happy paths start working for the first time to start catching the unhappy ones.

I.e. the "I'll go back and add safety later" strategy. Somehow I never seem to get around to doing it.

Re: Node.js adds experimental support for TypeScript

#278

Post by yen223 »

tomjen3 wrote: post #165
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…

The typesystem of Java was so laughably unpowerful that it severely constrained what you could write. In Typescript you have far more freedom, and all the benefits of strong types.

The fact that Java forced you to write types, and then made everything implicitly nullable so that you still get NullPointerExceptions at runtime after writing out all those types, was probably a big reason why dynamically-typed languages became popular.

Re: Node.js adds experimental support for TypeScript

#279

Post by tommy_axle »

bythreads wrote: post #230
BiteCode_dev wrote: post #212

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to d…

That's not entirely true. `z.string()` in Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. For those unfamiliar: `z.string()` effectively converts `mySchema` into a functional schema capable of parsing and validation. For example: `mySchema.parse("some data")` returns successfully. `mySchema.parse(321)` throws an e…

There's also typescript-to-zod that makes it possible to generate the zod schemas from your types.

Re: Node.js adds experimental support for TypeScript

#280

Post by VMG »

tpm wrote: post #119
VMG wrote: post #111

Earlier quoted context omitted.

1. *Type Inference*: TypeScript can automatically infer types from context, reducing the need for explicit type declarations. 2. *Union and Intersection Types*: Allows combining multiple types, offering more flexibility in defining data structures. 3. *Literal Types*: TypeScript supports exact values as types (e.g., specific strings or numbers), which can be useful for more precise type-checking. 4. *Type Aliases*: Y…

That's just an copy-paste of some features, not a comparison with Java which does most of that too.

most of that? name one
Post reply on HN