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

111–120 of 158 posts

Re: Deno Joins TC39

#111

Post by brundolf »

Zababa wrote: post #98
brundolf wrote: post #88

Earlier quoted context omitted.

I haven’t read the full post, but what’s the benefit of adding language support for records and tuples at this point? My understanding is that engines already optimize the objects/arrays version of those concepts pretty well, and TypeScript enforces the semantics on the dev side.

> My understanding is that engines already optimize the objects/arrays version of those concepts pretty well They don't, using libraries that guarantee runtime immutability has a heavy performance cost in JS currently.

By “object approach” I just meant “making a bunch of objects with the same shape”. I’ve read that V8 can optimize these into flat structs.

Is immutability part of the proposed standard? And if so, what’s the benefit over using Object.freeze?

Re: Deno Joins TC39

#112

Post by Zababa »

brundolf wrote: post #111
Zababa wrote: post #98

Earlier quoted context omitted.

> My understanding is that engines already optimize the objects/arrays version of those concepts pretty well They don't, using libraries that guarantee runtime immutability has a heavy performance cost in JS currently.

By “object approach” I just meant “making a bunch of objects with the same shape”. I’ve read that V8 can optimize these into flat structs. Is immutability part of the proposed standard? And if so, what’s the benefit over using Object.freeze?

Immutability is the whole point of records and tuples. You can read more about them on the proposal: https://github.com/tc39/proposal-record-tuple.

Re: Deno Joins TC39

#113

Post by benjaminjackman »

spankalee wrote: post #100
benjaminjackman wrote: post #44

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…

SRI really, really should be out of band, otherwise SRI digest changes invalidate the entire module graph (and import cycles become a major pain). I think they're much better as a part of import maps, and later fetch maps so they can apply to non-JS resources like CSS.

I don't think it's clear cut that it should be out of band 100% of the time. I think there are use cases where inline is useful.

Cycles are definitely an issue, I am not sure there is even way to work around that, except to pull the cycles apart (which may not always be possible but is usually not a bad programming practice when it is). However at the library level, libraries tend not to circularly import each other. If it's being done at the inside a project level the build tool would be generating it so dealing with the module graph being invalidated may not be a hassle (or even necessarily a bad thing), in that case it could modify the files or it could be generating a lock file / import map (which I agree has benefits at that level of not forcing every source to be transpiled, but some of that probably still has to happen for module reloading e.g. appended search parameters to the module path for cache invalidation / module reloading during development like vite.js does for example, and realistically given the nature of the ecosystem some transpilation is going to have to happen either because of .ts or just because of browser differences).

For a top-level deps.ts / dep.js file pattern there probably won't be any cycles. That pattern is to declare a root deps.js file for your project that locks things down and re-exports from third party libraries a use the exports from that as the basis for other imports. For this pattern I think SRI would be extremely helpful and add enough benefit to justify it (even though SRI may not be used in the cases you listed).

Also for smaller projects or main modules having the SRI hash inline is really helpful.

Re: Deno Joins TC39

#114

Post by Scarbutt »

hajile wrote: post #90
adamddev1 wrote: post #78

Earlier quoted context omitted.

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

Proper tail calls are ALREADY part of the spec. Google and Mozilla simply chose to ignore the spec.

More like Google, Mozilla just waits to see if Google is going to implement it since they can't think for themselves.

Re: Deno Joins TC39

#115

Post by lucacasonato »

frutiger wrote: post #75
hajile wrote: 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/

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.

Exactly. I am very much in favor of them though. They would be a great addition to the language.

Re: Deno Joins TC39

#116

Post by lucacasonato »

wiredearp wrote: post #59
lucacasonato wrote: post #14

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…

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.

Yup, we'll ship them once they go Stage 3/4 (when Chrome ships them in stable).

Re: Deno Joins TC39

#117

Post by anderskaseorg »

TimTheTinker wrote: post #108
AprilArcus wrote: post #91

Earlier quoted context omitted.

TypeScript is great and everything, but Microsoft owns the standard and the single functioning checker, and haven't published a specification or even a grammar.

The TypeScript checker/compiler is Apache 2.0 licensed, so I'm not sure there's room to complain, unless you disagree with the direction they're taking the project: https://github.com/microsoft/TypeScript/blob/main/LICENSE.tx...

Nobody disputes that TypeScript is open source, but there’s still a vast difference between a single open-source implementation and a specification that’s suitable for standardization. The implementation inevitably has bugs, and there needs to be a way to decide which bugs are actually “features” that other implementations will need to emulate.

(Here’s the specification for ECMAScript, for example: https://tc39.es/ecma262/)

To be clear, I am not bashing Microsoft here—just pointing out a reason that TypeScript can’t be declared “the next version of JavaScript”, which is the context of this thread.

Re: Deno Joins TC39

#118

Post by jonny_eh »

msoad wrote: post #97
disease wrote: post #86

> As TypeScript is a core part of the Deno ecosystem, we are also very interested in pushing for even closer alignment of TypeScript and JavaScript in the future. I've wondered why the frontend community hasn't gotten together and said, "The next version of JavaScript - is TypeScript!" I've been using TypeScript for five years professionally now and cannot understate how much easier it has made large frontend (not ju…

Types in TypeScript are great but if JavaScript ever wants to add types it has to be something like a real programming language types in which you can use types in runtime as well. Like in a catch clause I can assert the type of the error and do things with it once that assertion is done. Many other useful things when types space and runtime space are not totally separate. ES4 was the first shot at adding types to Ja…

> it has to be something like a real programming language

It's a nice feature request but there's no one feature that makes a programming language "real".

Re: Deno Joins TC39

#120

Post by brundolf »

Zababa wrote: post #112
brundolf wrote: post #111

Earlier quoted context omitted.

By “object approach” I just meant “making a bunch of objects with the same shape”. I’ve read that V8 can optimize these into flat structs. Is immutability part of the proposed standard? And if so, what’s the benefit over using Object.freeze?

Immutability is the whole point of records and tuples. You can read more about them on the proposal: https://github.com/tc39/proposal-record-tuple .

Ah so these are actual persistent data structures. Got it, that makes more sense.

The use of the term "tuple" here is odd; I've only ever seen it used to describe fixed-width, non-homogenous sequences. These look more like immutable lists (though I guess they can serve both purposes).

Post reply on HN