Matteo Collina

@bnoordhuis what you are saying is incorrect regarding n-api and http2. They followed the exact same path before landing in core with the majority of the work being done in...

> @mcollina The salient point is that n-api was available as a npm module before it got built into core and that was what allowed it to collect feedback and...

> To drive home the point why that is relevant to websockets: they shouldn't be added to core until it has evolved a stable API. I think that is effectively...

> Getting mildly off-topic but okay, for posterity: https://www.npmjs.com/package/node-addon-api - released some months before the first node.js release that bundled n-api. ~~node-addon-api never bundled n-api, it's just a C++ wrapper...

The problem is more profound: it's virtually impossible to get a green CI without resuming. _I currently have 7 PRs that I'm restarting CI every day_. Something that would be...

The architecture and integration of the two is radically different. When switching to the wasm one we actually got an improvement in performance. I _think_ it might be possible to...

@nodejs/tsc we have a decision to make here. One of the reasons we stopped using the native http_parser was due to the use of `process.bindings()` for retrieving it (https://github.com/nodejs/undici/issues/22#issuecomment-650584032) Assuming...

FWIW building the wasm needed by undici is completely automated (otherwise is _very hard_ to do it by hand).

It really depends on the subsystems we are targeting. It's impossible to make a generic call.

What's the process of making this a reality? I think we should really care about the dynamic transpilers goal here.