Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Joins TC39

deno.com

Post reply on HN
Print view View original

41–50 of 158 posts

Re: Deno Joins TC39

#41

Post by lucacasonato »

maga wrote: post #39

This is great news! Good luck, Luca! > 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. [1] https://github.com/tc39/proposal-resizablearraybuffer

Yeah, this is something we have been thinking about too. Something else along those lines would be read-only buffers, and with that a copy-on-write operation for buffers. They could result in a significant speedup for many operations.

Re: Deno Joins TC39

#42

Post by lucacasonato »

lucacasonato wrote: post #41
maga wrote: post #39

This is great news! Good luck, Luca! > 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. [1] https://github.com/tc39/proposal-resizablearraybuffer

Yeah, this is something we have been thinking about too. Something else along those lines would be read-only buffers, and with that a copy-on-write operation for buffers. They could result in a significant speedup for many operations.

* a copy-on-write copy operation of buffers (that returns a read only buffer)

Re: Deno Joins TC39

#43

Post by mattlondon »

AaronO wrote: post #22
SiVal wrote: post #12

Earlier quoted context omitted.

Will there be a Deno equivalent of Electron?

Aaron@Deno here, we've been exploring something with the Tauri team but don't have a concrete release on the roadmap since we're focusing on other priorities. I believe an Electron alternative is an important part of the Deno stack, so hopefully we'll ship a first iteration next year.

Glad to hear this is still on the table! I have been very keenly watching this space waiting for this to land here :)

Re: Deno Joins TC39

#44

Post by benjaminjackman »

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

Hi Luca - congratulations! I have a quick question, have their been any proposals to add Subresource Integrity hashes (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) to the import syntax? I think this effects Deno more acutely than other projects since Deno supports / (encourages?) directly importing from a url with a precise version number encoded in the url. It would be nice to add another layer of safety on top and be able to assert that the module received is exactly as expected. Thanks!

Re: Deno Joins TC39

#45

Post by megaman821 »

lucacasonato wrote: post #40
baybal2 wrote: post #35

Earlier quoted context omitted.

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?

No, I think this will eventually stop. JavaScript is getting more mature. I would not be surprised if the TypeScript syntax will be legacy in a few years, because JS caught up.

Is there some proposal for making the type syntax valid? No type checking just JavaScript parsing code with types and ignoring it.

Re: Deno Joins TC39

#46

Post by Zababa »

lucacasonato wrote: post #14
selfmodruntime wrote: post #10

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…

I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.

Re: Deno Joins TC39

#47

Post by FragenAntworten »

lucacasonato wrote: post #14
selfmodruntime wrote: post #10

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…

'enumerate', as in Python.

'clamp' and 'sortBy', as in Lodash.

Set methods for union, intersection, difference, etc.

Re: Deno Joins TC39

#48

Post by nicoburns »

lucacasonato wrote: post #27
mschuetz wrote: post #15

Earlier quoted context omitted.

What are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.

I think they are great! Especially in combination with pattern matching ( https://github.com/tc39/proposal-pattern-matching ), or when using JSX.

Do you have any insight into how the TC39 process works, and how one might drive this work forwards? I feel like expression-orientation is the main thing missing from JavaScript at this point, and I'd love to contribute. But it's not at all clear to me how to actually do so.

Re: Deno Joins TC39

#49

Post by thegagne »

Something I’d like to see, in browsers, Cloudflare Workers, Deno, etc: explicit network firewall in the software stack.

An example with Workers, one script might only need to fetch from Backblaze. I’d like to set their host as a whitelisted address, and so even if a log4j type vuln happens, it can’t go anywhere except Backblaze.

I think this could even work in browser-land? If you don’t need to pull in any resources outside the original host, deny any fetch made unless it’s added to a whitelist. For browsers this would need to be opt-in for backwards compatibility, but an ideal state would be opt-out (to allow all).

Re: Deno Joins TC39

#50

Post by gecko »

benjaminjackman wrote: post #44
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 :-)

Hi Luca - congratulations! I have a quick question, have their been any proposals to add Subresource Integrity hashes ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ) to the import syntax? I think this effects Deno more acutely than other projects since Deno supports / (encourages?) directly importing from a url with a precise version number encoded in the url. It would be nice to add another layer…

You can do that right now, albeit not directly in the import: it's done via an explicit `lock.json` file (https://deno.land/manual@v1.16.4/linking_to_external_code/in...). I'm tempted to agree that having some ability either to directly import, or even just to have that better integrated (right now, you have to ask for the lockfile to be used and pass an explicit path), would probably be a good idea.
Post reply on HN