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

91–100 of 158 posts

Re: Deno Joins TC39

#91

Post by AprilArcus »

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…

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.

Re: Deno Joins TC39

#92

Post by jollybean »

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…

TS design goals and non-goals [1]

It's very much designed to be a layer of abstraction over JS.

I am as much a fan of TS, however, it's not likely ever going to be the thing that it's really close to being.

[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: Deno Joins TC39

#93

Post by dten »

hajile wrote: post #68
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 :-)

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/

Record and Tuple are actively being worked on: https://github.com/tc39/proposal-record-tuple -- currently Stage 2.

Re: Deno Joins TC39

#94

Post by asoneth »

andrewflnr wrote: post #74
asoneth wrote: post #51

Earlier quoted context omitted.

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

The stakes could be drastically lower or drastically higher depending on what the software is used for.

For example, we might want to make sure software used in avionics, aerospace, weapons systems, voting machines, medical devices, cryptography, power plants, policing, finance, etc is carefully engineered. But I agree with your main point that there's still a baseline of competence necessary -- we need both good tooling and good people.

That reminds me of a lament from a friend at the Software Engineering Institute that the profession missed the boat on the kind of licensure most engineering disciplines have. (That is, any software developer can refer to themselves as an "engineer" without taking any tests, accepting any liability, or meeting any other legal requirements.)

Re: Deno Joins TC39

#95

Post by conaclos »

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…

TypeScript is still experimenting with its type system and it has numerous edge cases. I could be more in favor to specify and support a minimal subset of TypeScript rather than the entire TypeScript. Basically we could start by enabling type annotations, enum declarations, and type-aliases.

Re: Deno Joins TC39

#96

Post by pier25 »

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.

How will Deno react if that happens?

Re: Deno Joins TC39

#97

Post by msoad »

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 JavaScript which failed due to how big the ambitions were. I'm not sure if there is any more appetite for adding types to JS tho.

In very very serious big applications like a 3D editor you can fall back to WebAssembly and use your favorite typed language. For smaller apps TypeScript is good enough. This way JavaScript stays simple and lean.

Re: Deno Joins TC39

#98

Post by Zababa »

brundolf wrote: post #88
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/

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.

Re: Deno Joins TC39

#99

Post by jamil7 »

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…

Would expanding wasm capabilities be a better long term option here instead of supporting TS directly? Opening the browser up to a whole lot of languages, including Typescript (AssemblyScript exists already).

Re: Deno Joins TC39

#100

Post by spankalee »

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…

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.

Post reply on HN