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])
Deno Joins TC39
71–80 of 158 posts
Re: Deno Joins TC39
#72Earlier 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.
Re: Deno Joins TC39
#73Earlier 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_...
Re: Deno Joins TC39
#74Earlier 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…
Re: Deno Joins TC39
#75Hey - 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/
The proposal is humming along through the stages at a good pace.
Re: Deno Joins TC39
#76Earlier 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…
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
#77Earlier 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.
Re: Deno Joins TC39
#78Hey - 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/
Re: Deno Joins TC39
#79Earlier 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…
Re: Deno Joins TC39
#80Earlier 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!
As this is an engine feature rather than a spec thing, there is nothing me (or any other TC39 delegate) can do.