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

121–130 of 158 posts

Re: Deno Joins TC39

#121

Post by javajosh »

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…

*>...use types [at] runtime..."

Two things. First, TS conceives of itself as having no runtime component. If it did, I think people (including the TS devs) would be more confused.

Second, I'd say rather we need a runtime type system. In fact I've tried my hand at writing one in the most minimalist way possible, and have been working on it recently [1]. The type system is explicit in that a type is a JSON like object, similar to JSON schema, but 100x less code.

[1] https://github.com/javajosh/simpatico/blob/master/friendly.h... This is effectively the test harness for the module.

Re: Deno Joins TC39

#122

Post by munificent »

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…

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops.

There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static checking doesn't benefit end users. When I go to my bank's website, if their front-end code has a type error, it's not like I can fix it right then and there.

The type system is mostly a developer-time feature, so it makes sense to leave it out of the core runtime environment.

In other words, think of JavaScript/ECMAScript more like the architecture that browsers support. That needs to be slow-moving since it's deployed across billions of devices. TypeScript then just targets that.

Adding TypeScript directly to JavaScript would improve the world to about the same degree that adding C++ features directly to x64 machine code would.

Re: Deno Joins TC39

#123

Post by anderskaseorg »

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…

JS objects already have runtime types, and you can use them in catch clauses.

    try {
      …
    } catch (e) {
      if (e instanceof FooError) {
        …
      } else if (e instanceof BarError) {
        …
      } else {
        throw e;
      }
    }
There was once a Mozilla extension (https://web.archive.org/web/20200111091805/https://developer...) that allowed you to abbreviate the above to

    try {
      …
    } catch (e if e instanceof FooError) {
      …
    } catch (e if e instanceof BarError) {
      …
    }
It was never standardized, but since it’s just syntactic sugar, if there were demand, it could be standardized without bringing in an entirely new type system.

There would be at least two problems with using TypeScript types for this. Firstly, TypeScript types are unsound in a number of intentional and unintentional ways, meaning that it’s possible for the compile-time and runtime types to disagree, even in fully typed code. Secondly, TypeScript can express many types that cannot be tested at runtime; for example, there is no way to tell whether a function accepts a string as an argument, or to guess the inner type of an empty array.

Re: Deno Joins TC39

#124

Post by eyelidlessness »

lucacasonato wrote: post #104
ducaale wrote: post #84

Earlier quoted context omitted.

Since TS/Deno has native support for JSX syntax, do you think Browsers will eventually support it as well?

No, I don't think so. JSX is too proprietary and not specified well enough. It is also rather ambiguous. If you want a "no compile" JSX: ```jsx const x = hello ; // is the same as const x = h("div", { color: "red" }, "hello"); ```

This is more true as a mental model/to the type system, but slightly more complicated when compiled.

First, there’s the “new JSX transform”, which involves auto-imports, has a different function signature, and defines fallback behavior for certain circumstances.

Second, JSX is only specified as a syntax extension. Some implementations—like SolidJS and its underlying dom-expressions compiler—don’t compile to hyperscript at all.

Re: Deno Joins TC39

#125

Post by benmccann »

mschuetz wrote: post #15
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 :-)

What are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.

Do you have a link to the proposal?

Re: Deno Joins TC39

#126

Post by The_rationalist »

munificent wrote: post #122
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…

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static c…

You are totally missing the point of reified generics and reflection.

Re: Deno Joins TC39

#127

Post by mschuetz »

benmccann wrote: post #125
mschuetz wrote: post #15

Earlier quoted context omitted.

What are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.

Do you have a link to the proposal?

https://github.com/tc39/proposal-do-expressions

Allows you to contain temporary variables to where they are needed, rather than having them remain active through the remainder of the current scope. You could do that with immediately invoked function expressions, but they are too verbose to be really viable for this. You could also use extra functions, but extra functions don't always make sense. Currently I'm frequently doing this:

Without do expression:

    let result;
    {
        let tmp = 123;

        result = tmp * 2;
    }
With do expression it would become this:

    let result = do {
        let tmp = 123;
     
        tmp * 2;
    }

Re: Deno Joins TC39

#128

Post by moron4hire »

munificent wrote: post #122
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…

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static c…

This is not true. There are a number of ways that TypeScript's type-checking can be subverted at runtime, particularly when dealing with APIs that return JSON. You have to trust that the API has returned exactly what you are expecting, or write your own very detailed validation scripts. It's similar to the sorts of testing one would do in vanilla JavaScript without TypeScript, but now executing all the time at runtime.

As a developer, in the case of an API change that violated my assumptions, I would personally prefer my applications to fail-hard at the point of the API call, rather than to have my scripts run merrily on and only error in some other code far away from the root-cause when one of those assumptions fails.

However, I have a lot of hope that runtime type checking based on auto-code generation around TypeScript's interfaces could be developed in a future version of TypeScript.

Re: Deno Joins TC39

#129

Post by brundolf »

jerrygoyal wrote: post #32
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 :-)

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?

It’s always been there just for type checking, hasn’t it?

Re: Deno Joins TC39

#130

Post by forty »

lucacasonato wrote: post #38
forty wrote: 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…

I'm not convinced :)

Admittedly the largest project I'm working on is mostly in TS now, and I probably get most of the benefits of the import syntax even if require is used under the hood (including linters, which I think worked even before we switched to typescript).

Post reply on HN