Live data from Hacker News

Deno Joins TC39

deno.com

71–80 of 158 posts

Re: Deno Joins TC39

#71

Earlier quoted context omitted.

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

const foo = bar.reduce((hash, item) => { hash[item.id] = item; return hash; }, {});

Re: Deno Joins TC39

#72

Earlier quoted context omitted.

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

Deno has permissions to do this: https://deno.land/manual@v1.11.3/getting_started/permissions . Deno Deploy (our serverless offering) has no support for permissions yet (still in beta), but we are expecting this to happen soon.

Nice!

Re: Deno Joins TC39

#73

Earlier quoted context omitted.

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_...

There's an issue for that to be added as part of import assertions https://github.com/tc39/proposal-import-assertions/issues/11...

Re: Deno Joins TC39

#74
post #51

Earlier quoted context omitted.

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

While I agree in this case: at the edges, there still exist people who just should not be allowed to be doctors or engineers. The main difference with software is that the stakes tend to be drastically lower...

Re: Deno Joins TC39

#75
post #68

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

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/

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.

Re: Deno Joins TC39

#76
post #34

Earlier quoted context omitted.

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.

ESM is not a frontend thing. ESM is the standardized way of doing module imports in JS. It has a lot of benefits for server side developers too: - 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…

Exactly this and I'm a little disappointed, though not surprised that the response was "well it works for me so what's wrong with it? it's only for frontend". It's actually part of the language.

You also forgot another super important point:

- It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flux-inverter tower of cards collapses when a commonjs module somehow leaks in from node_modules?

Re: Deno Joins TC39

#77
post #9

Earlier quoted context omitted.

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.

I heard there was a movement internally for a while to block adoption of ES modules because the core team members "didn't like ES modules" (again, what I saw tweeted a long time ago and don't remember the source). So that certainly can't be helping adoption of it. This is one of the reasons Deno is superior - it makes use of language features not a badly designed module format.

Re: Deno Joins TC39

#78
post #68

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

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/

Or how about TCO (tail-call optimization)? Please pretty please!

Re: Deno Joins TC39

#79

Earlier quoted context omitted.

ESM is not a frontend thing. ESM is the standardized way of doing module imports in JS. It has a lot of benefits for server side developers too: - 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…

Exactly this and I'm a little disappointed, though not surprised that the response was "well it works for me so what's wrong with it? it's only for frontend". It's actually part of the language. You also forgot another super important point: - It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flu…

Oh, 100% agree on that point :D

Re: Deno Joins TC39

#80
post #68

Earlier quoted context omitted.

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/

Or how about TCO (tail-call optimization)? Please pretty please!

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.

As this is an engine feature rather than a spec thing, there is nothing me (or any other TC39 delegate) can do.

Post reply on HN