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

51–60 of 158 posts

Re: Deno Joins TC39

#51

Post by asoneth »

deepstack wrote: post #19
phist_mcgee wrote: post #11

Earlier quoted context omitted.

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 la…

Personally front end developers need to step up their games learn how to develop or else don't think they have business developing software front-end or back-end. This whole idea of bring in as much developers as possible at cost of developer competency has being harmful for developer and tech community.

In my opinion, what has been most harmful for evolution of the software engineering profession is the tendency to blame individual developers for not being infallible instead of fixing chronic failures in tooling, processes, and funding.

The medical profession, aviation, even rail transportation [1] have all progressed past the point where avoidable failures are entirely the responsibility of the individual.

Of course, there was resistance in those fields as well because some considered themselves an "above-average" doctor or pilot who didn't need safeguards, checklists, union rules, or laws. But it empirically improved outcomes.

[1] https://www.youtube.com/watch?v=A3AdN7U24iU

Re: Deno Joins TC39

#52

Post by egeozcan »

lucacasonato wrote: post #33
jerrygoyal wrote: post #32

Earlier quoted context omitted.

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?

Yes.

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.

Re: Deno Joins TC39

#53

Post by spmurrayzzz »

nicoburns wrote: post #48
lucacasonato wrote: post #27

Earlier quoted context omitted.

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.

The TC39 process is well-documented, you can check out the stages and guidance for providing input here: 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

Re: Deno Joins TC39

#54

Post by easrng »

thegagne wrote: post #49

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…

You want a Content Security Policy[0]

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Re: Deno Joins TC39

#55

Post by thegagne »

easrng wrote: post #54
thegagne wrote: post #49

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…

You want a Content Security Policy[0] [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Ah yes, I forgot about that browser side, but server side is that a thing?

Re: Deno Joins TC39

#56

Post by lucacasonato »

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…

I am not aware of any specific proposals right now. There was some talk a while back about supporting SRI hashes inside of an import map, but that sorta dissolved. For Deno at least you can use a `lock.json` file with the `--lock` and `--lock-write` flags: https://deno.land/manual/linking_to_external_code/integrity_...

Re: Deno Joins TC39

#57

Post by tarjei_huse »

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 miss being able to create a hash from an array in a quick way. You always end up with

let bar = [{id: zz, }, {id: y},...]

let foo = {}

bar.forEach(v => foo[v.id] = v)

I'd love to have something like:

let foo = bar.toMap(v => [v.id, v])

Re: Deno Joins TC39

#58

Post by lucacasonato »

egeozcan wrote: post #52
lucacasonato wrote: post #33

Earlier quoted context omitted.

Yes.

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.

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.

Re: Deno Joins TC39

#59

Post by wiredearp »

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…

Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.

Re: Deno Joins TC39

#60

Post by lucacasonato »

megaman821 wrote: post #45
lucacasonato wrote: post #40

Earlier quoted context omitted.

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.

No such proposal exists right now, but this will be a point of immediate focus for me.
Post reply on HN