171–180 of 570 posts
Earlier quoted context omitted.
They are not comparable. If anything, Kotlin is the equivalent in the JVM universe.
Kotlin is much closer to Java than to TypeScript even in terms of flexibility.
Earlier quoted context omitted.
What broken tooling are you talking about? tsc is broken? IE failed because it was a horrible browser that didn’t evolve for years and was incompatible with major web standard developments. Nothing to do with typescript, an open source, best in class type system and type checker.
“During the transpilation process, no type checking is performed, and types are discarded.” this node feature is primarily around disregarding typescript in favor of the underlying javascript it represents. that reminds me of this fun article: https://www.richard-towers.com/2023/03/11/typescripting-the-...
Nice to see Node.js getting parity on this with Deno and Bun
This reminds me of io.js situation, where in the end major fork changes were incorporated into Node. This is why I am comfortable staying with Node and npm for my projects - the features will eventually trickle down anyway.
I’m also not sure the features will eventually “tickle down”. I’m not sure NPM wants to adopt the advantages PNPM gives you as an example, and it’s probably a good thing too considering the basis of NPM is just a really solid system to build on top of which it wouldn’t be if it was very opinionated. One of the big issues Node has today is that it was very opinionated with CommonJS, which made sense at the time, but is a ginormous pain in the butt in the modern world. Though the blame is obviously not with Node alone.
Earlier quoted context omitted.
Yes, that’s explaining what type erasure is. “type as comments” is what Flow supports, literal comments for type annotations. I think we disagree on the terminology but agree on the goal of the proposal
Types as comments is what jsdoc supports. Flow is compiled like typescript. tsc does also support jsdoc though, so technically I think tsc is closer to supporting types as comments, though it's possible Flow has this also.
Earlier quoted context omitted.
And it has to go through slow compilation step. With Node you can have a cake and eat it too.
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…
Earlier quoted context omitted.
Yes, that’s explaining what type erasure is. “type as comments” is what Flow supports, literal comments for type annotations. I think we disagree on the terminology but agree on the goal of the proposal
The proposal would explicitly treat supported type annotation syntax as comments in the grammar . It is definitely types as comments, even if it is also type erasure. And it would apply to Flow’s type annotation syntax which is also not presently treated as comments, at least for the very large subset of that syntax which overlaps with the proposal.
Nice to see Node.js getting parity on this with Deno and Bun
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.
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,…
However, the node:crypto module still doesn't work 100%. So, I can't use it yet.
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…
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…
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.