Deno Joins TC39

#1

Post by wongmjane » Mon, Dec 13, 2021, 11:16 AM UTC

Deno Joins TC39
deno.com

Re: Deno Joins TC39

#2

Post by lucacasonato » Mon, Dec 13, 2021, 11:46 AM UTC

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Re: Deno Joins TC39

#3

Post by robertvh » Mon, Dec 13, 2021, 12:06 PM UTC

lucacasonato wrote: post #2

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Congrats! Can you extend on your ideas for async iteration?

Re: Deno Joins TC39

#4

Post by lloydatkinson » Mon, Dec 13, 2021, 12:08 PM UTC

> Better support for non-JS assets in the ES module graph

Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...

Re: Deno Joins TC39

#5

Post by abagheri43 » Mon, Dec 13, 2021, 12:10 PM UTC

It was a good article. I really enjoyed what was published

Re: Deno Joins TC39

#6

Post by lucacasonato » Mon, Dec 13, 2021, 12:10 PM UTC

lloydatkinson wrote: post #4

> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...

No no, this is about things like importing WASM through the `import` keyword, or referencing assets statically through syntax:

Asset References: https://github.com/tc39/proposal-asset-references Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection

Re: Deno Joins TC39

#7

Post by lucacasonato » Mon, Dec 13, 2021, 12:12 PM UTC

robertvh wrote: post #3

lucacasonato wrote: post #2

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Congrats! Can you extend on your ideas for async iteration?

Mainly pushing proposals like https://github.com/tc39/proposal-iterator-helpers that make it easier to work with (async) iterators.

Re: Deno Joins TC39

#8

Post by nicoburns » Mon, Dec 13, 2021, 12:18 PM UTC

lloydatkinson wrote: post #4

> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...

I wouldn't worry about that. Node is moving to ECMAScript modules.

Re: Deno Joins TC39

#9

Post by akyoan » Mon, Dec 13, 2021, 12:24 PM UTC

nicoburns wrote: post #8

lloydatkinson wrote: post #4

> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...

I wouldn't worry about that. Node is moving to ECMAScript modules.

Node is not "moving to ESM", they don't even plan to deprecate CJS. They will continue to support both for the foreseeable future. Their docs still use `require` in a lot of places even though ESM has been enabled on stable releases for almost 2 years.

Re: Deno Joins TC39

#10

Post by selfmodruntime » Mon, Dec 13, 2021, 12:24 PM UTC

lucacasonato wrote: post #2

Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)

Congrats on your new role! Currently, I feel like addition to JavaScript is a lot slower than new CSS features, for example. What do you think are the chances that JS will one day get a larger batch of STL functions, instead of about a dozen each year?