Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

211–220 of 570 posts

Re: Node.js adds experimental support for TypeScript

#211

Earlier quoted context omitted.

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

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…

I made it sure to decouple the transpiler from node itself, the transpiler is in a npm package called amaro, that is bundled in node. The goal is to allow user to upgrade amaro indipendently so we dont have to lock a ts version for the whole lifespan of a release

Re: Node.js adds experimental support for TypeScript

#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 do:

    const mySchema = z.string();
Which is basically reinventing what typescript is already doing.

Re: Node.js adds experimental support for TypeScript

#214

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

Lots of people do of course use other languages for the frontend. (Or go for thin frontends, ala HTMX )

Re: Node.js adds experimental support for TypeScript

#215

Earlier quoted context omitted.

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

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…

TypeScript feels "boring" enough at this point that being a few years behind isn't gonna be an issue in most cases. For teams who want to stay on the absolute latest release of TypeScript but want to be more conservative with their Node version, external compilation will remain necessary; but for someone like me, where TypeScript has been "good enough" for many years that I'm not excited by new TypeScript releases, this feature will be really nice.

("Boring" in this context is a compliment, by the way)

EDIT: Though reading other comments, it seems like you can update the typescript stripper independent of node? That makes this moot anyway

Re: Node.js adds experimental support for TypeScript

#216

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,…

Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.

Yeah, besides that, leaving out the extension also creates ambiguity when the same filename exists with multiple file extensions.

Re: Node.js adds experimental support for TypeScript

#217
post #209

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 guess if you already know Javascript, or have inhouse experience vs. learning Go. We use it with cdktf as previous fe experience, seemed logical vs. Go

sorry was going to add that there are probably more javascript developers in the jobs market, although there is a limit to the usefulness of these developers.

In the company I worked at we were fairly small and did not have huge applications running on node, so it made that journey easier

Re: Node.js adds experimental support for TypeScript

#218
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…

> If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript Node.JS isn't the only JS runtime. You'll still have to compile TS to JS for browsers until all the browsers can run TS directly. Although some bundlers already do that by using a non-official compiler, like SWC (the one Node's trying out for this feature). > In Python, I've even heard of p…

> It's not just comments. It's also a hint for your IDE to display better autocomplete options.

Ah yes, autocomplete is another benefit of machine-readable type hints. OTOH there's an argument that another IDE feature, informational pop-ups, would be better if they paid more attention to comments and less to type hints:

https://discuss.python.org/t/a-more-useful-and-less-divisive...

Re: Node.js adds experimental support for TypeScript

#219

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,…

Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.

Re: Node.js adds experimental support for TypeScript

#220
post #4

My favorite deno feature is coming to node directly. Awesome! Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again a…

btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx. https://github.com/privatenumber/tsx

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.
Post reply on HN