[HN Gopher] Running TypeScript Natively in Node.js
___________________________________________________________________
Running TypeScript Natively in Node.js
Author : jauco
Score : 36 points
Date : 2025-07-17 20:41 UTC (2 hours ago)
(HTM) web link (nodejs.org)
(TXT) w3m dump (nodejs.org)
| gabrielsroka wrote:
| See also from 6 months ago
| https://news.ycombinator.com/item?id=42630790
| jadbox wrote:
| This is great to finally see get added. I wonder why they decided
| to build their own type stripper instead of just bundling
| tsc/swc. It feels like Node.js is going to be plagued with bugs
| whenever TypeScript adds new type constructs, which may take
| months to get patched.
| Eric_WVGG wrote:
| Would it be possible for the maintainers of Typescript to
| provide an official stripper that could be deployed alongside
| new versions of Typescript, and then snapped in?
| yladiz wrote:
| I'm not certain but I would be surprised if the TS and Node
| devs didn't discuss the functionality that's in Node now,
| since TS must have some definition of what an erasable type
| is (or rather, what few features aren't erasable, like
| enums), since the corresponding --erasableSyntaxOnly flag in
| TS was probably made specifically because of Node.
| mosdl wrote:
| Its just stripping types, so new constructs should not matter -
| there is no parsing.
| eyelidlessness wrote:
| It uses swc under the hood.
| Normal_gaussian wrote:
| Whilst I use an esbuild based build pipeline to produce
| production artifacts, I've found that the combination of native
| type transformation and node:test improvements is now sufficient
| to do away with most test frameworks.
|
| My nodejs projects have tests that run faster and have fewer
| breaking dependencies.
|
| The two things I have to do are to always annotate type imports
| with type (I have a script for that), and to use file extensions
| on imports.
| steve_adams_86 wrote:
| I don't mean this rhetorically, but what are the benefits of
| using node over something like deno now? It has been so long
| since I lived in the node ecosystem. I imagine it has gotten
| quite a bit better. Is the main benefit just
| ecosystem/compatibility stuff? Deno sometimes has some odd
| compatibility issues, but not often. The low-overhead, sane
| defaults, just-build kind of nature of it has become very
| appealing to me. Being able to build CLIs in portable binaries
| using a language my coworkers understand is really nice (despite
| that they're like 60mb, haha). I prefer Go personally, but
| ultimately prefer being able to collaborate.
| reactordev wrote:
| It's purely ecosystem at this point. Deno, Bun, any runtime is
| more modern. It's nice they are catching up but by the time
| typescript is a native citizen in node, others may take the
| crown. The codebase is ooof.
|
| That said, there's something to be said about being the first
| mover and having the ecosystem so node isn't going away anytime
| soon, nor is the npm/npx ecosystem.
|
| Go has the ability to, with a goja fork [1], to execute ESM but
| you would still need to transpile using another go tool to run
| it. I have such a runtime but it's nowhere near as fast as bun
| or deno. I use it mainly so I can have agents do my local
| bidding.
|
| [1] https://github.com/grafana/sobek
| leptons wrote:
| >It's purely ecosystem at this point.
|
| Definitely not just about ecosystem.
|
| When AWS Lambda supports Deno, then maybe someday further
| down the line, I might think about trying it once for
| something unimportant. If that goes well, then we'll see.
| ChrisArchitect wrote:
| News from January https://nodejs.org/en/blog/release/v23.6.0
| russellbeattie wrote:
| I honestly wish Microsoft and TypeScript enthusiasts would
| transform it into an official standalone language and stop
| polluting the JavaScript ecosystem.
|
| Like C++, it could be a true superset of JS, importing JS code
| freely into TypeScript projects. It would also allow TypeScript
| to do whatever it wanted and not have to worry about
| transpilation. If it needs to work in the browser, it can be
| bundled into web assembly.
| wrs wrote:
| This is a mischaracterization of TypeScript. Unlike the
| relationship of C++ to C, TS is explicitly not a separate
| language from JS, and introduces no new capabilities. There's
| no engine that executes TypeScript. It doesn't do anything (*)
| that JavaScript doesn't do. It just layers a type system onto
| JavaScript so you can tell when your JS code doesn't make
| sense.
|
| (*) with small exceptions like enums, which some think were a
| mistake for that reason
| Sacro wrote:
| C++ isn't a superset of JS, nor is it a superset of C
| jasonthorsness wrote:
| How does it pollute? Hasn't the presence of TypeScript pushed a
| lot of awesome features back into the later versions of
| JavaScript?
___________________________________________________________________
(page generated 2025-07-17 23:00 UTC)