Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

I find it highly unlikely that Node will ever choose to support TypeScript out of the box. I’d love to be wrong, but it would be a sharp departure from their “bring your own” approach (eg with --loader/--require, the former being under active development).

View on HN

Even more unlikely is Deno "merging" in to Node. Deno is sponsored by the Deno Company, and even at this nascent stage, it is a whole ecosystem unto itself (package manager, linter, bundler, transpiler, development tools, ide integrations, edge platform and so on).

I think some version of Typescript type hints or similar will eventually get adopted as a standard for JS. TS and similar are kind of like a testing ground and will eventually be obsolete if it remains that prevalent and useful.

I’ve pored over TC-39 proposals and it seems the general sway of proposals that are moving forward or successful are:

- ergonomics (convenience methods/parity across collection types)

- improve safety for broader use cases (realms etc)

- embrace FP (records and tuples)

- being a good faith language target for typed extensions

Even very narrow type system stuff seems to stall and feels like it’s going to wither in stage 1 or get bikeshedded to death. Proposals which directly overlap with static typing explicitly eschew any of that overlap to be able to proceed.

Part of me wishes Flow had won, even though I’m all in on TypeScript, because at least Flow had an optional story that could be built into the language and allowed to thrive on its merits and adoption. I can’t see a future where TypeScript or some variant gets folded into the language, because despite being gradual it’s explicitly a separate syntax with a build step. And I know the TS team is very engaged with TC-39, but the language syntax is very much in flux, and a Python-style “type hints ignored at runtime by default” is basically a deadlock or at least reasonably threatens to be one.

Im just imagining the benefits of runtime recognized type information for browsers/node. This plus proper immutable data structures would be a dream. Well we have WASM at least.

Yeah I see the benefits too. At least we’re going to get immutable data structures.

this is a moot point as ts-node exist. What's lacking is native esmodule support.

Native esmodule loading has been a thing since node 12, almost 3 years ago. You just have to turn on a flag or use the `.mjs` file extension.

.mjs has no typescript equivalent to my knowledge. The alternative is to set type: module in my package.json. doing this broke my Vue.js default projet (no idea why) therefore browser/webpack has better support for import in typescript than ts-node (what is missing, commonjs support? no idea but the user experience was atrocious)

It does support ESM, with a --loader[1], but even with its SWC option it’s still significantly slower than the esbuild loader I’m working on. Unfortunately, esbuild isn’t totally compatible with tsc, so it’s not a drop-in replacement without plugins.

1: https://github.com/TypeStrong/ts-node#native-ecmascript-modu...

Reply on news.ycombinator.com