181–190 of 570 posts
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.
Virtual Threads alone challenge this assumption.
Syntax bloat is not a feature.
Earlier quoted context omitted.
On the topic of typescript - yes. However Bun has a lot more tools baked in than Node does at (bun test for instance). Would be real nice to see Node start adopting more ideas from Bun and others.
I find it interesting that everyone looks at Bun and shames Node saying they need to catch up to Bun and implement stuff Bun has but Node doesn't, yet nobody is like Bun should catch up with feature parity of Node. Node isn't trying to replace Bun, Bun is trying to replace Node so it should be the one who needs to match parity.
One 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 possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?
One 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…
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.
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 hand, I usually adopt a new TypeScript version as soon as it comes out.
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.
Earlier 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.
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).
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.
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…
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]
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…
For production use, I'd still put my TS files through a build pipeline as normal