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

221–230 of 570 posts

Re: Node.js adds experimental support for TypeScript

#221

Post by bezier-curve »

gaptoothclan wrote: post #206

A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simple…

Typescript is safer JS. You're still using JS with TS. The "bolted on" phrasing makes me think your issue may be more the absence of more opinionated frameworks like Django, that manage everything out of the box. I love using Django, but it's a little harder to go off the beaten path with it.

Re: Node.js adds experimental support for TypeScript

#222

Post by gaptoothclan »

__alias wrote: post #210
gaptoothclan wrote: post #206

A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simple…

I mean the obvious answer is language familiarity, If your projects frontend code is in javascript/typescript ( which it is ), then using node is an easy choice. Shared libraries, shared types, etc etc

I was in the paradigm, there was very little code reuse from front to backend, some time performing validation I would like to have that option, but I would not have that as a killer feature that determined the language I use.

Re: Node.js adds experimental support for TypeScript

#223

Post by silverwind »

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…

Imho standardizing the syntax is enough and this is what https://github.com/tc39/proposal-type-annotations does.

The type checker is immensely complex and should be left out so that other type checkers can be developed, e.g. similar to how it's for Python today.

Re: Node.js adds experimental support for TypeScript

#224

Post by aitchnyu »

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…

Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".

Re: Node.js adds experimental support for TypeScript

#225

Post by gaptoothclan »

bezier-curve wrote: post #221
gaptoothclan wrote: post #206

A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simple…

Typescript is safer JS. You're still using JS with TS. The "bolted on" phrasing makes me think your issue may be more the absence of more opinionated frameworks like Django, that manage everything out of the box. I love using Django, but it's a little harder to go off the beaten path with it.

My phrasing there was a direct comparison of developer experience between golang and nodejs. Golang has a very complete core library, I try to avoid frameworks as much as possible. For me I rarely have to think about the language or ecosystem, everything I want or need is already part of the language, testing, linting are some great examples

Re: Node.js adds experimental support for TypeScript

#226

Post by re-thc »

thecopy wrote: post #183
spoiler wrote: post #156

Earlier quoted context omitted.

It's possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?

TypeScript evolves independent of Node, and the syntax you can use depends on your `typescript` version in the `package.json`

Not if SWC or your tooling doesn't support it.

Re: Node.js adds experimental support for TypeScript

#227

Post by LelouBil »

aitchnyu wrote: post #224
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…

Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".

You are right, they aren't. In the JavaScript languages which is what gets actually executed, there are no typescript types.

The parent commenter was talking about a way for nodejs to provide, via an API, the content of type annotations on fields/functions/variables like in python.

However, in python the type annotations are a property of the object at run time, whereas they are completely stripped before execution for typescript.

So I'm not sure how it would work except by changing the typescript philosophy of "not changing runtime execution"

Re: Node.js adds experimental support for TypeScript

#228

Post by itsmeste »

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.

I strongly agree, but JSDoc isn't "the cool thing". So it's left to be used by us, who care (and read their docs).

Re: Node.js adds experimental support for TypeScript

#229

Post by gampleman »

aitchnyu wrote: post #224
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…

Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".

In JS, classes do retain runtime information. So the `instanceof` is a real runtime operator that works by checking the prototype chain of an object. So checking subclasses can be done at runtime.

However, in TS other type information is erased at compile time. So if you write

    type Foo = "a" | "b";
the runtime code will see that just as a plain string.

Re: Node.js adds experimental support for TypeScript

#230

Post by bythreads »

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 exception.

I've used it in places where you need runtime validation and in process verification - it works pretty well for that and you can extract the types from it via :

const A = z.string(); type A = z.infer; // string

Meaning if you define your types in zod first, and infer their types from that you get compile and runtime type checking.

---

It a bit of an overkill for nimble and fast code bases though - but works wonders for situations where in process proofing needs to be done, and in all honesty it isn't that big of a task to do this.

Post reply on HN