My personal vision of Wing v2024

[skyrpex]

I'm still thinking about the direction of Wing. I still have a vision similar to the first one I had at the beginning and wanted to share it again:

• Wing is a strict, statically-analyzable subset of TypeScript (eg, no dynamic typing, no eval, no global, etc) with the addition of the inflight keyword / phase
• Wing's only responsibility is generating code objects that bundle inflight functions into preflight, along with metadata such as a reference to the lifted objects and the required permissions
• Wing allows importing TypeScript and JavaScript libraries, and using them in preflight and inflight
• If Wing can't statically analyze a code path, it emits a warning and offers to assign all permissions to the related inflight host (maybe using config files)
• Async and ESM can be used everywhere in preflight and inflight

My reasoning for these choices is:

• No context switching between languages
• No fancy syntax or features that are hard to understand
  • Everything is solved in JS/TS nowadays!
• Less surface of responsibility for Wing. Only static analysis and code generation
  • Obviously, more effort would go into understanding TS types from Wing
• Code generation is simpler because it's almost a 1:1 from Wing to JavaScript
• Allowing users and library author to customize the bundling opens up a lot of possibilities, such as:
  • Compiling APIs into a single lambda or multiple lambdas
  • Interoperability with current frameworks such as Next.js, Vercel, Astro, etc

An example of what I picture:

// main.w
import { defineConstruct } from "wing";
import { createApi, createFunction, createBucket } from "@wing/cloud";
import type { IApi } from "@wing/cloud";

// Importing a typescript package.
import { nanoid } from "nanoid";

const id = nanoid();

const api = await createApi("ApiId");

await createFunction("FunctionId", inflight async () => {
    console.log({
        // Lifting a string.
        id,
        // Lifting a function.
        anotherId: nanoid(),
        // Lifting a token.
        apiUrl: api.url,
    });
});

interface CustomBucketProps {
    api: IApi;
}
interface ICustomBucket {
    bucketName: string;
    putObject: inflight async (key: string, value: string) => Promise<void>;
}
const createCustomBucket = defineConstruct(async (props: CustomBucketProps): ICustomBucket => {
    const bucket = await createBucket("BucketId");
    return {
        bucketName: bucket.name,
        putObject: inflight async (key, value) => {
            await bucket.putObject(key, value);
        },
    };
});

const customBucket = await createCustomBucket("CustomBucketId", { api });

[MarkMcCulloh]

statically-analyzable subset of TypeScript (eg, no dynamic typing, no eval, no global, etc) with the addition of the inflight keyword / phase

By definition this would not actually be a subset of typescript, so it would lose any benefit of the connotation (e.g. no existing tooling would work with it). If you take out the inflight keyword, this is basically the goal with @wingcloud/framework.
What do you think are the important factors for @wingcloud/framework to maybe reach this goal, if possible?

[skyrpex]

First of all, I want to say that your work in @wingcloud/framework is great! Please, do not think I don't appreciate that.

By definition this would not actually be a subset of typescript, so it would lose any benefit of the connotation (e.g. no existing tooling would work with it).

I don't need Wing to work in TypeScript, but the other way around: I want TypeScript to (mostly, in a sane way) work in Wing. If I was a TypeScript customer, I'd really appreciate that since that would mean my codebase could remain mostly the same. Refactoring efforts would be minimal if no dynamic language features were used, so simply rename file.ts to file.w and you can start blasting inflights.

If you take out the inflight keyword [...]

That's the only and most distinguishable feature I'd like Wing to have!

What do you think are the important factors for @wingcloud/framework to maybe reach this goal, if possible?

The main issue IMO is around the verbosity and the lifting limitations. For example:

import { main, lift, cloud } from "@wingcloud/framework";
import { nanoid } from "nanoid";

main((root) => {
  new cloud.Function(
    root,
    "Nanoid",
    lift({}).inflight(async () => {
      // Can't access nanoid without lifting it explicitly.
      return nanoid();
    })
  );
});

The other important part is allowing the user to customize the bundling so they can build crazy stuff.

[MarkMcCulloh]

I don't need Wing to work in TypeScript, but the other way around: I want TypeScript to (mostly, in a sane way) work in Wing.

This is the intent of @wingcloud/framework. It allows typescript to work in wing (the toolchain). We might be saying the same thing though.
I do see the appeal of just being able to rename .ts and .w and start flying though.

The main issue IMO is around the verbosity and the lifting limitations. For example:

Your example does work since recently there was an improvement to automatically "lift" imports. And in this case no explicit lifts are happening so it can be shortened a tiny bit too:

import { main, inflight, cloud } from "@wingcloud/framework";
import { nanoid } from "nanoid";

main((root) => {
  new cloud.Function(
    root,
    "Nanoid",
    inflight(async () => {
      // ESM might still be an issue here, but that is solvable
      return nanoid();
    })
  );
});

In general verbosity is an issue for sure, I do have some ideas for automatic lifting in some cases though.

[skyrpex]

The lifting compilation errors are very useful, though. Even if the syntax for lifting is verbose, if only we could see lifting errors in the editor, it would be a much better DX.

[MarkMcCulloh]

if only we could see lifting errors in the editor, it would be a much better DX.

Luckily this improvement is feasible via https://github.com/microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin. Investing in a language service plugin is something I've been super interested to see what other dx can be unlocked.

[eladb]

@skyrpex As @MarkMcCulloh mentioned, I believe the work he is doing around TypeScript is basically in the direction of your vision. It will be great to dogfood it and provide some feedback for what you'd like to see, but I think it's definitely going in that direction.