Hacker News Reader

Comment by beardedetim | Hacker News Reader

I have a strong feeling that deno will be the io of our age: important for pushing node forward and ultimately be brought into node proper but not worth investing any apps/projects onto.

View on HN

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).

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...

I tend to think it's going to succeed. Node is already getting displaced (by various server runtimes that hew more closely to the browser) - the true future of javascript remains where it has always been -- the browser.

"browser compatible" javascript that runs in places other than the browser can (and should) only grow over time ...

deno is kind of a rust-wrapper around v8 -- how long before it becomes the api for the javascript engine used by the browser rather than v8 ...

I think (eventually) "import some_browser_only_api" will become an optional thing you can do when you want to make your code depend on browser only functionality -- with code that doesn't depend on the browser-only functionality able to run without it ...

I'm seeing Node all over the enterprise world at this point - hard to imagine it getting replaced already. Maybe newer startups aren't adopting it as readily, but I think it's pretty well established in big businesses now.

I see Deno as being better for scripts since you don't need extra dependencies or build pipelines to use typescript, and you likely don't need many dependencies anyway for small scripts. Node.js seems better for services since it has bigger ecosystem.

Reply on news.ycombinator.com