19 ms·

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

baybal2 5y ago
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?
- lucacasonato 5y ago
  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.
  - megaman821 5y ago
    Is there some proposal for making the type syntax valid? No type checking just JavaScript parsing code with types and ignoring it.
    - lucacasonato 5y ago
      No such proposal exists right now, but this will be a point of immediate focus for me.
    - pier25 5y ago
      How will Deno react if that happens?
      - lucacasonato 5y ago
        Deno will behave just like Chrome or Firefox would: we ignore the checks when running your code. We would have a `deno check` subcommand to perform a typecheck. You could optionally run this automatically before a `deno run` by passing a `--check` flag.
robertvh 5y ago
Congrats! Can you extend on your ideas for async iteration?
- lucacasonato 5y ago
  Mainly pushing proposals like https://github.com/tc39/proposal-iterator-helpers https://github.com/tc39/proposal-iterator-helpers that make it easier to work with (async) iterators.
selfmodruntime 5y ago
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?
- lucacasonato 5y ago
  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 you think are missing?
  - deleted 5y ago
    [deleted]
  - amitport 5y ago
    'range' a-la python
    - wruza 5y ago
      Range a-la python is a generator and is pretty straightforward in js as is. There is no need for a complicated solution and/or as part of stdlib, imo: function* range(x, y) { while (x <= y) {yield x++} // or ‘<‘ if you want half-open one } for (let n of range(3, 5)){ console.log(n) } array = [...range(3, 5)] console.log(array)
      - amitport 5y ago
        It's also straight forward to implement in python. It is common enough to be standard so people won't reinvent the wheel. And it should be available to people learning the language before they learn generators. Array.prototype.indexOf is also pretty simple as are many core functions.
phist_mcgee 5y ago
Hey luca, Huge fan of the achievements that Deno has made in recent years. Several questions: How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards? Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat? Again, huge fan of Deno, and happy to hear about this announcement.
- lucacasonato 5y ago
  > How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosystem into a single style, like in Go. > Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? I think many developers do not care about permissions, and also will not in the future. This is a problem, but not something that can be tackled overnight. Security is often not emphasized enough in our industry unfortunately. Because of this I think sane defaults and opt ins are good - they push people to think about security at the most basic level. Maybe the log4shell attack also shows people that it is a good idea to sandbox server side scripts aggressively (something we have been pushing for), to prevent large scale system takeovers through a single vulnerable entrypoint. > Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards? There is work being done on this. I don't have too much to share right now, but expect some updates on this early next year. JS has to evolve to support some form of type annotations first class to stay relevant. > Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat? Maybe, maybe not. I think it is still to early to tell. I do think that so far it is looking like it. People seem to be doing less weird stuff like "leftpad" with Deno so far. Ideally all these little helper modules should just be part of JS directly (hit me up with suggestions!) > Again, huge fan of Deno, and happy to hear about this announcement. Thanks, glad you like it :-)
SiVal 5y ago
Will there be a Deno equivalent of Electron?
- AaronO 5y ago
  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.
  - mattlondon 5y ago
    Glad to hear this is still on the table! I have been very keenly watching this space waiting for this to land here :)
  - spankalee 5y ago
    Why not PWAs?
  - SiVal 5y ago
    Thanks, Aaron. I think people who have been using Node for years are skilled at the old Node ways and have huge inertia in their skills, their own code, and others' Node code. For them, the ideal platform would be Node plus some upgrades. I'm guessing they would rather extend their inertial frame of reference than leave it behind. Then there are others of us who have been saying no to Node and legacy JS for years. We have no such legacy to maintain and no intention of ever creating any. But some of us (at least I) would reconsider platforms built from scratch on a new TypeScript foundation rather than layered on a pre-ES6 foundation. That would include a Deno-based Electron. You might have more luck converting people who don't use Node than getting Node users to abandon their legacy. The state of cross-platform desktop apps is terrible. All attention is on mobile, and desktop OS makers have almost zero interest in supporting cross-platform desktop apps. (MS cares a little more than zero, Apple less than zero and barely tolerates their own Mac-only developers.) Only something browser/Chromium based seems realistic for the next few years. On the server, there are a lot of alternatives to Node that are considered better by (and very popular with) large segments of the market. Deno will be one of them, I think. But for cross-platform desktop apps, Electron would be rejected completely if the alternatives weren't so bad and unlikely to get better. A better Electron, despite its inherent problems, could end up more popular than server-side Deno. Just a thought.
mschuetz 5y ago
What are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.
- benmccann 5y ago
  Do you have a link to the proposal?
  - mschuetz 5y ago
    https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions Allows you to contain temporary variables to where they are needed, rather than having them remain active through the remainder of the current scope. You could do that with immediately invoked function expressions, but they are too verbose to be really viable for this. You could also use extra functions, but extra functions don't always make sense. Currently I'm frequently doing this: Without do expression: let result; { let tmp = 123; result = tmp * 2; } With do expression it would become this: let result = do { let tmp = 123; tmp * 2; }
- lucacasonato 5y ago
  I think they are great! Especially in combination with pattern matching (https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching), or when using JSX.
  - nicoburns 5y ago
    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.
    - spmurrayzzz 5y ago
      The TC39 process is well-documented, you can check out the stages and guidance for providing input here: https://tc39.es/process-document/ https://tc39.es/process-document/ The do expression proposal is currently stage 1, so its very early. You can check out the issue tracker there to see some of the related discussion. Standards work can be deceptively hard, even for simple things. I think the do expression proposal is a good example of that. Edit: forgot to link to the issue tracker I referenced above https://github.com/tc39/proposal-do-expressions/issues https://github.com/tc39/proposal-do-expressions/issues
Vinnl 5y ago
Hey Luca! What does > Better support for explicit resource management refer to?
- lucacasonato 5y ago
  Things like https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.
jerrygoyal 5y ago
As modern JS is getting closer to typescript in terms of new methods, latest syntax etc. What is the future of TS? will it be there for just type checking?
- lucacasonato 5y ago
  Yes.
  - egeozcan 5y ago
    could you imagine that some JS proposal adds the ability to ignore TS-like type annotations to the engines, so we don't even have to strip them? this may help development heavily, also making the browser and deno nearly identical environments.
    - lucacasonato 5y ago
      Yes, this would be great, and it will probably happen eventually. This is something we want to work on soon - expect something in the coming weeks.
      - ducaale 5y ago
        Since TS/Deno has native support for JSX syntax, do you think Browsers will eventually support it as well?
        lucacasonato 5y ago
        No, I don't think so. JSX is too proprietary and not specified well enough. It is also rather ambiguous. If you want a "no compile" JSX: ```jsx const x = <div color="red">hello</div>; // is the same as const x = h("div", { color: "red" }, "hello"); ```
        eyelidlessness 5y ago
benjaminjackman 5y ago
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/Subresource_Integrity 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!
- gecko 5y ago
  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/integrity_checking 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.
  - benjaminjackman 5y ago
    Ok that makes a lot of sense, the link you shared helped explain things in denoland quite well (and reminds me that I really need to give it another go). From the link I see this example: in src/deps.ts // Add a new dependency to "src/deps.ts", used somewhere else. export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts"; Then essentially a create/update lock-file command is run. Then the lock file is checked into version control. Then another developer checks it out and runs a cache reload command. As you mentioned in practice it's definitely a bit too manual, but should be one of those things that can be automated so it's not the end of the world. Having said I think having it in the import syntax would provide a few benefits: 1. No extra steps need to be run & hopefully IDEs could auto-complete the hash. 2. Would hopefully be standardized with the browser allowing for native browser support as well (or perhaps lock.json could be standardized with something like import maps) 3. Having it right there provides an extra level of assurance that the integrity hash is going to be used (especially in files intended to be used in the browser and in deno ... not sure how common that is though).
hajile 5y ago
Are you going to push for records and tuples? Eich was pushing for them in 2011 and they still haven't arrived. https://brendaneich.com/2011/01/harmony-of-my-dreams/ https://brendaneich.com/2011/01/harmony-of-my-dreams/
- frutiger 5y ago
  He doesn’t need to, the authors of the proposal are on the committee and are planning to see it through. The proposal is humming along through the stages at a good pace.
  - lucacasonato 5y ago
    Exactly. I am very much in favor of them though. They would be a great addition to the language.
    - BrendanEich 5y ago
      Yes, Bloomberg has a big JS investment due to the Terminal (20MLOC of JS last I heard) and they have employed the records and tuples champions.
- adamddev1 5y ago
  Or how about TCO (tail-call optimization)? Please pretty please!
  - lucacasonato 5y ago
    TCO is something that specific JS engines need to implement. It is implemented in JSC (Safari), but not in V8 or SpiderMonkey. Also see https://v8.dev/blog/modern-javascript#proper-tail-calls https://v8.dev/blog/modern-javascript#proper-tail-calls. As this is an engine feature rather than a spec thing, there is nothing me (or any other TC39 delegate) can do.
    - adamddev1 5y ago
bartq 5y ago
When cross platform windowed WebGPU on Deno? It would be interesting for many kinds of apps.
- lucacasonato 5y ago
  We are not sure about windowed WebGPU right now. We will try to come up with some form of "Deno Desktop" next year, but I have no real ETA for that.
speedgoose 5y ago
Do you have discussions about not adding too many features to JavaScript? It's already quite complex for beginners.
- lucacasonato 5y ago
  This is always a consideration when adding new features. It is however also important to keep the language up to date with other modern languages. If you don't innovate, you die. There is always a cost/benefit calculation to be made.

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?

lucacasonato 5y ago
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.
- megaman821 5y ago
  Is there some proposal for making the type syntax valid? No type checking just JavaScript parsing code with types and ignoring it.
  - lucacasonato 5y ago
    No such proposal exists right now, but this will be a point of immediate focus for me.
  - pier25 5y ago
    How will Deno react if that happens?
    - lucacasonato 5y ago
      Deno will behave just like Chrome or Firefox would: we ignore the checks when running your code. We would have a `deno check` subcommand to perform a typecheck. You could optionally run this automatically before a `deno run` by passing a `--check` flag.

robertvh 5y ago

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

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

selfmodruntime 5y ago

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?

lucacasonato 5y ago
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 you think are missing?
- deleted 5y ago
  [deleted]
- amitport 5y ago
  'range' a-la python
  - wruza 5y ago
    Range a-la python is a generator and is pretty straightforward in js as is. There is no need for a complicated solution and/or as part of stdlib, imo: function* range(x, y) { while (x <= y) {yield x++} // or ‘<‘ if you want half-open one } for (let n of range(3, 5)){ console.log(n) } array = [...range(3, 5)] console.log(array)
    - amitport 5y ago
      It's also straight forward to implement in python. It is common enough to be standard so people won't reinvent the wheel. And it should be available to people learning the language before they learn generators. Array.prototype.indexOf is also pretty simple as are many core functions.

phist_mcgee 5y ago

Hey luca, Huge fan of the achievements that Deno has made in recent years. Several questions: How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards? Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat? Again, huge fan of Deno, and happy to hear about this announcement.

lucacasonato 5y ago
> How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy? This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosystem into a single style, like in Go. > Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults? I think many developers do not care about permissions, and also will not in the future. This is a problem, but not something that can be tackled overnight. Security is often not emphasized enough in our industry unfortunately. Because of this I think sane defaults and opt ins are good - they push people to think about security at the most basic level. Maybe the log4shell attack also shows people that it is a good idea to sandbox server side scripts aggressively (something we have been pushing for), to prevent large scale system takeovers through a single vulnerable entrypoint. > Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards? There is work being done on this. I don't have too much to share right now, but expect some updates on this early next year. JS has to evolve to support some form of type annotations first class to stay relevant. > Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat? Maybe, maybe not. I think it is still to early to tell. I do think that so far it is looking like it. People seem to be doing less weird stuff like "leftpad" with Deno so far. Ideally all these little helper modules should just be part of JS directly (hit me up with suggestions!) > Again, huge fan of Deno, and happy to hear about this announcement. Thanks, glad you like it :-)

SiVal 5y ago

Will there be a Deno equivalent of Electron?

AaronO 5y ago
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.
- mattlondon 5y ago
  Glad to hear this is still on the table! I have been very keenly watching this space waiting for this to land here :)
- spankalee 5y ago
  Why not PWAs?
- SiVal 5y ago
  Thanks, Aaron. I think people who have been using Node for years are skilled at the old Node ways and have huge inertia in their skills, their own code, and others' Node code. For them, the ideal platform would be Node plus some upgrades. I'm guessing they would rather extend their inertial frame of reference than leave it behind. Then there are others of us who have been saying no to Node and legacy JS for years. We have no such legacy to maintain and no intention of ever creating any. But some of us (at least I) would reconsider platforms built from scratch on a new TypeScript foundation rather than layered on a pre-ES6 foundation. That would include a Deno-based Electron. You might have more luck converting people who don't use Node than getting Node users to abandon their legacy. The state of cross-platform desktop apps is terrible. All attention is on mobile, and desktop OS makers have almost zero interest in supporting cross-platform desktop apps. (MS cares a little more than zero, Apple less than zero and barely tolerates their own Mac-only developers.) Only something browser/Chromium based seems realistic for the next few years. On the server, there are a lot of alternatives to Node that are considered better by (and very popular with) large segments of the market. Deno will be one of them, I think. But for cross-platform desktop apps, Electron would be rejected completely if the alternatives weren't so bad and unlikely to get better. A better Electron, despite its inherent problems, could end up more popular than server-side Deno. Just a thought.

mschuetz 5y ago

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

benmccann 5y ago
Do you have a link to the proposal?
- mschuetz 5y ago
  https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions Allows you to contain temporary variables to where they are needed, rather than having them remain active through the remainder of the current scope. You could do that with immediately invoked function expressions, but they are too verbose to be really viable for this. You could also use extra functions, but extra functions don't always make sense. Currently I'm frequently doing this: Without do expression: let result; { let tmp = 123; result = tmp * 2; } With do expression it would become this: let result = do { let tmp = 123; tmp * 2; }
lucacasonato 5y ago
I think they are great! Especially in combination with pattern matching (https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching), or when using JSX.
- nicoburns 5y ago
  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.
  - spmurrayzzz 5y ago
    The TC39 process is well-documented, you can check out the stages and guidance for providing input here: https://tc39.es/process-document/ https://tc39.es/process-document/ The do expression proposal is currently stage 1, so its very early. You can check out the issue tracker there to see some of the related discussion. Standards work can be deceptively hard, even for simple things. I think the do expression proposal is a good example of that. Edit: forgot to link to the issue tracker I referenced above https://github.com/tc39/proposal-do-expressions/issues https://github.com/tc39/proposal-do-expressions/issues

Vinnl 5y ago

Hey Luca! What does > Better support for explicit resource management refer to?

lucacasonato 5y ago
Things like https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.

jerrygoyal 5y ago

As modern JS is getting closer to typescript in terms of new methods, latest syntax etc. What is the future of TS? will it be there for just type checking?

lucacasonato 5y ago
Yes.
- egeozcan 5y ago
  could you imagine that some JS proposal adds the ability to ignore TS-like type annotations to the engines, so we don't even have to strip them? this may help development heavily, also making the browser and deno nearly identical environments.
  - lucacasonato 5y ago
    Yes, this would be great, and it will probably happen eventually. This is something we want to work on soon - expect something in the coming weeks.
    - ducaale 5y ago
      Since TS/Deno has native support for JSX syntax, do you think Browsers will eventually support it as well?
      - lucacasonato 5y ago
        No, I don't think so. JSX is too proprietary and not specified well enough. It is also rather ambiguous. If you want a "no compile" JSX: ```jsx const x = <div color="red">hello</div>; // is the same as const x = h("div", { color: "red" }, "hello"); ```
        eyelidlessness 5y ago

benjaminjackman 5y ago

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/Subresource_Integrity 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!

gecko 5y ago
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/integrity_checking 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.
- benjaminjackman 5y ago
  Ok that makes a lot of sense, the link you shared helped explain things in denoland quite well (and reminds me that I really need to give it another go). From the link I see this example: in src/deps.ts // Add a new dependency to "src/deps.ts", used somewhere else. export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts"; Then essentially a create/update lock-file command is run. Then the lock file is checked into version control. Then another developer checks it out and runs a cache reload command. As you mentioned in practice it's definitely a bit too manual, but should be one of those things that can be automated so it's not the end of the world. Having said I think having it in the import syntax would provide a few benefits: 1. No extra steps need to be run & hopefully IDEs could auto-complete the hash. 2. Would hopefully be standardized with the browser allowing for native browser support as well (or perhaps lock.json could be standardized with something like import maps) 3. Having it right there provides an extra level of assurance that the integrity hash is going to be used (especially in files intended to be used in the browser and in deno ... not sure how common that is though).

hajile 5y ago

Are you going to push for records and tuples? Eich was pushing for them in 2011 and they still haven't arrived. https://brendaneich.com/2011/01/harmony-of-my-dreams/ https://brendaneich.com/2011/01/harmony-of-my-dreams/

frutiger 5y ago
He doesn’t need to, the authors of the proposal are on the committee and are planning to see it through. The proposal is humming along through the stages at a good pace.
- lucacasonato 5y ago
  Exactly. I am very much in favor of them though. They would be a great addition to the language.
  - BrendanEich 5y ago
    Yes, Bloomberg has a big JS investment due to the Terminal (20MLOC of JS last I heard) and they have employed the records and tuples champions.
adamddev1 5y ago
Or how about TCO (tail-call optimization)? Please pretty please!
- lucacasonato 5y ago
  TCO is something that specific JS engines need to implement. It is implemented in JSC (Safari), but not in V8 or SpiderMonkey. Also see https://v8.dev/blog/modern-javascript#proper-tail-calls https://v8.dev/blog/modern-javascript#proper-tail-calls. As this is an engine feature rather than a spec thing, there is nothing me (or any other TC39 delegate) can do.
  - adamddev1 5y ago

bartq 5y ago

When cross platform windowed WebGPU on Deno? It would be interesting for many kinds of apps.

lucacasonato 5y ago
We are not sure about windowed WebGPU right now. We will try to come up with some form of "Deno Desktop" next year, but I have no real ETA for that.

speedgoose 5y ago

Do you have discussions about not adding too many features to JavaScript? It's already quite complex for beginners.

lucacasonato 5y ago
This is always a consideration when adding new features. It is however also important to keep the language up to date with other modern languages. If you don't innovate, you die. There is always a cost/benefit calculation to be made.