4 ms·

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 investi

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.

eyelidlessness 5y ago
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).
- The_rationalist 5y ago
  this is a moot point as ts-node exist. What's lacking is native esmodule support.
  - Master_Odin 5y ago
    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.
    - The_rationalist 5y ago
      .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)
  - eyelidlessness 5y ago
    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-modules https://github.com/TypeStrong/ts-node#native-ecmascript-modu...
- ignoramous 5y ago
  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).
- dgb23 5y ago
  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.
  - eyelidlessness 5y ago
    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.
    - dgb23 5y ago
      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.
      - eyelidlessness 5y ago
        Yeah I see the benefits too. At least we’re going to get immutable data structures.
devmunchies 5y ago
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.
breatheoften 5y ago
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 ...
- clpm4j 5y ago
  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 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.

eyelidlessness 5y ago

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

The_rationalist 5y ago
this is a moot point as ts-node exist. What's lacking is native esmodule support.
- Master_Odin 5y ago
  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.
  - The_rationalist 5y ago
    .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)
- eyelidlessness 5y ago
  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-modules https://github.com/TypeStrong/ts-node#native-ecmascript-modu...
ignoramous 5y ago
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).
dgb23 5y ago
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.
- eyelidlessness 5y ago
  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.
  - dgb23 5y ago
    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.
    - eyelidlessness 5y ago
      Yeah I see the benefits too. At least we’re going to get immutable data structures.

devmunchies 5y ago

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.

breatheoften 5y ago

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

clpm4j 5y ago
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.