Nice, but without support for Enums, for me it's mostly useless.
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?
Node.js adds experimental support for TypeScript
191–200 of 570 posts
Re: Node.js adds experimental support for TypeScript
#192Earlier quoted context omitted.
You're saying it like it's an absolutely good thing. Some (many?) users would rather pay the cost upfront in compilation time (doesn't really matter if it's AOT or JIT) than pay the same cost many times over through a significantly slower runtime. JVM also scales up to supercomputers (and everything in between) if you want it to, so depending on your requirements a single-threaded alternative might not even be an opt…
I’ll use C++ or Rust for such use cases.
Okay!
Re: Node.js adds experimental support for TypeScript
#193It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.
It is Bun influence / competition I guess. Good for everyone.
Re: Node.js adds experimental support for TypeScript
#194One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…
I'm not worried about that too much to be honest.
To me beyond v4.4 or so, when it started being possible to create crazy recursive dependent types (the syntax was there since ~4.1 - it's just that the compiler complained), there weren't a lot of groundbreaking new features being added, so unless an external library requires a specific TS version to parse its type declarations, it doesn't change much.
Re: Node.js adds experimental support for TypeScript
#195Earlier 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]
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.
Re: Node.js adds experimental support for TypeScript
#196Earlier quoted context omitted.
Native Java via GraalVM starts up in milliseconds.
And it has to go through slow compilation step. With Node you can have a cake and eat it too.
It does not "have" to go through such a step, by the way, because you can simply run such code on the JVM.
Re: Node.js adds experimental support for TypeScript
#197If 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 people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments.
It's not just comments. It's also, like the name "type hint" suggests, a hint for your IDE to display better autocomplete options.
Re: Node.js adds experimental support for TypeScript
#198It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.
The recently-added test runner is very cool too!
I tested it a few months ago. However, the output isn't very human friendly.
Re: Node.js adds experimental support for TypeScript
#199Earlier quoted context omitted.
And it has to go through slow compilation step. With Node you can have a cake and eat it too.
You can't be serious about comparing the technological capabilities of the JVM and Node and objectively declare the latter as the winner. Compilation times are also an absolute non-issue. You don't compile for development. You do it for production (in the rare circumstances that you need it).
[deleted]
Re: Node.js adds experimental support for TypeScript
#200One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…
It's already the case for ECMAScript and I don't see why TypeScript should be treated differently when Node.js has to transpile it to JavaScript and among other things ensure that there are no regressions that would break existing code.
Unlike Python typing it's not only type erasure: enums, namespaces, decorators, access modifiers, helper functions and so on need to be transformed into their JavaScript equivalent.