Feature: Deno support

[sambacha]

I am guessing v3 of Hardhat is being planned. With that said It may be benifical to give Deno a serious consideration.

Native web worker support

see this issue about NodeJs having web worker support

sane FFI see https://deno.land/manual/runtime/ffi_api

• If Hardhat is going to adopt a Rust based EVM solution this would be easier I would imagine than working with Nodejs as is

X-Typescript-Types

HRE could adopt providing responses with a custom X-TypeScript-Types HTTP header when the types (.d.ts) is defined. This is useful for deno type checks (link).

Note The idea being that as solc supports imports via URL, there may be use cases in having type checking work like that (am unsure of this just an idea). This would be for browsers

Example (Browser): pass the ?no-check query to disable the X-TypeScript-Types header if some types are incorrect:

import SafeTransferLib from "https://abi.storage/rari-capital/solmate@0.7.0/~/SafeTransferLib?no-check"

see esm.sh/

Possibility for Interoperable packages

All required remote dependencies are referenced in a file called deps.ts and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies. If now for example one remote dependency is used in several files, upgrading to a new version of this remote dependency is much simpler as this can be done just within deps.ts.

/**
 * deps.ts
 *
 * This module re-exports the required methods from the dependant remote module.
 */
 export { SafeTransferLib } from "https://x.nest.land/ramda@0.7.0/source/index.js?pin=0x0000DeployedAddress

see https://deno.land/manual/examples/manage_dependencies

Maintain NodeJS Compatibility easily with dnt

Deno to NodeJs dnt allows you to develop your Deno module mostly as-is and use a single Deno script to build, type check, and test an npm package in an output directory. Once built, you only need to npm publish the output directory to distribute it to Node.js users.

WebAssembly and Rust

The old bottleneck for web performance used to be the network. But the new bottleneck for web performance is the CPU, and particularly the main thread. Packets go brrrrrrrr. Really though moving towards decoding wasm vs parsing javascript is where we want to be heading right?

Don't listen to any of this, I just wanted to hear yall's thoughts on the idea, I did not find an issue with respect to the scope of this topic.

Cheers, and happy July 4th!

[github-actions[bot]]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: d090669b-9ce7-4068-97dd-943e747a5912

[alcuadrado]

Hey @sambacha,

Thanks for this and the other issues/PRs that you opened. Now that 2.10 is out will evaluate all of them.

I follow the deno ecosystem a bit, and I'm impressed with its progress. I haven't thought about how packages can work both in deno and node, but thanks for the pointer.

Currently, Hardhat heavily depends on some node specific behavior. The major examples are the plugin system depending on how modules are loaded and cached, and Solidity dependencies on node's resolution algorithm. We consider both to be somewhat undesirable and we want to change them. If in the process we can make HH compatible with deno, that'd be great.

[sambacha]

Hey @sambacha,

Thanks for this and the other issues/PRs that you opened. Now that 2.10 is out will evaluate all of them.

I follow the deno ecosystem a bit, and I'm impressed with its progress. I haven't thought about how packages can work both in deno and node, but thanks for the pointer.

Currently, Hardhat heavily depends on some node specific behavior. The major examples are the plugin system depending on how modules are loaded and cached, and Solidity dependencies on node's resolution algorithm. We consider both to be somewhat undesirable and we want to change them. If in the process we can make HH compatible with deno, that'd be great.

Yup, I think actually adopting a new cache system would be the biggest boost given the benchmarks I have seen. The Deno stuff as you pointed out is not worth the squeeze.

Now that EthereumJs is ESM compatible, maybe some potential avenues there.

Congrats on the new release btw!

[stavalfi]

The community asks for it!

[StrawberryChocolateFudge]

I give a bump to this. Hardhat would be great with Deno! The permission management would help avoid future supply-chain attacks, so less DeFi hacks and compromised private keys, if you ask me!

Deno supports importing node_modules now so it should be possible to use hardhat with it and with the permission management I don't need to trust in dependencies. I can verify my app is not doing stuff I don't grant explicit access for.