The future of JS: Types as Comments proposal and ESM

[skyrpex]

There's an ongoing proposal to allow TypeScript-like syntax in JavaScript: https://tc39.es/proposal-type-annotations/.

It basically will make JS engines to ignore types like in const age: number = 32;. I find it most interesting since it may allow working with .js extensions while having a full type checking system in place while you develop. This, in combination with ESM, may be the future.

In order to be compatible with this stuff in advance, our code shouldn't use enums but types instead, no namespaces and, in short, TypeScript features that need to generate additional code to work.

I believe we could easily get rid of those TS features and also adopt ESM. What do yo think?

[Chriscbr]

I'm in favor of adopting ESM given that's the direction most of the JavaScript ecosystem is trending.

our code shouldn't use enums but types instead, no namespaces and, in short, TypeScript features that need to generate additional code to work.

I'm curious where this would apply -- does this mean the code in @winglang/sdk?

I also wonder if there would be any benefits to the Wing compiler emitting JS with type annotations (e.g. to make it easier to debug Wing code in production). Since the type annotation proposal is not specific to TypeScript types, we could generate JavaScript like this:

// Wing
let api = new cloud.Api();
inflight () => {
  let url = api.url;
  log(url);
};

// JavaScript (inflight)
const url: Lifted<str> = api.url;
console.log(url);

[skyrpex]

Yes, the @winglang/sdk code base uses some TS enums which could be converted to type unions (eg, TraceType).

Regarding the wing-generated type annotations, it could make sense!