31–40 of 158 posts
> More extensive standard library functions for (async) iteration Great news! I wrote an open source library called axax that adds a number of utility methods to async iterators - map, filter etc. I think having them as part of the language would be awesome. Standardising async cancellation would be neat too if Deno wants a challenge....
Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)
> 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...
What are the problems with commonjs/amd/umd? I'm only vaguely familiar with the JS ecosystem. Is it mainly that the dependencies can't be statically analyzed?
The main problem to me is this push to this ESM thing, which I don't know what it brings to me. I understand it's a frontend thing, so I'm not sure why nodejs end npm need to be impacted.
Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)
This is all when vanilla JS keeping very energetically absorbing new features from *-Scripts thanks to TC39 seemingly intentionally picking them?
Earlier quoted context omitted.
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?
I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that yo…
Earlier quoted context omitted.
What are the problems with commonjs/amd/umd? I'm only vaguely familiar with the JS ecosystem. Is it mainly that the dependencies can't be statically analyzed?
Yeah I have been happy with require/commonjs for the last ~10 years, I'm not sure why suddenly it seems to be a problem. The main problem to me is this push to this ESM thing, which I don't know what it brings to me. I understand it's a frontend thing, so I'm not sure why nodejs end npm need to be impacted.
- It has language syntax for importing and exporting instead of relying on an implicit global.
- It is asynchronous, allowing for top level await.
- It is reliably statically analyzable.
- Because it is asynchronous, module asset loading can happen in parallel which can mean a significant startup speedup for larger projects.
- It is standardized, so it behaves the same across Node, Deno, the web, bundlers, linters, and other tooling.
> Better support for explicit resource management
+1
Since everyone is making feature requests, I'd like to point out `ArrayBuffer.transfer`[1] -- ability to effectively move data without copying would do wonders for low-level/high-performance code in JS.
Hey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)
What you think of more *-Scripts built on top of JS keeping coming? Are you not afraid of TypeScript following the CoffeScript into obscurity because of WebDev community keeping chasing the new thing? This is all when vanilla JS keeping very energetically absorbing new features from *-Scripts thanks to TC39 seemingly intentionally picking them?