Hi all, new guy here!

I'm entertaining the idea of opening a proposal but wanted to get a sense on how the community feels about the concept before I commit a weekend to writing it out - haha.

Generally, it's the concept of the incorporation of Rust-inspired static macros. Macos are functions that take tokens and return static ECMAScript, similar to a template literal + eval however with LSP support and without the need for eval.

All macros would be defined by users, none defined in the language.

// Parse tokens and generate React.createElement() calls
const Foo = () => jsx!(<div>Hello World</div>)

// Create a getter/setter for a property
class Bar {
  #[observe]
  baz = undefined
}

The syntax itself can be changed, I am just defaulting to Rust syntax for familiarity, but something like jsx!() could be ~jsx() or anything (to avoid conflicts), I'm not opinionated here

While I know ECMAScript is not a compiled language, there are interesting use cases like;

• Enabling support for jsx/other templating languages without an external preprocessor/eval
• Macro annotations that facilitate more ergonomic mutation observability leading to more ergonomic syntax for frameworks like Vue/Angular
• A reduced need for custom compilers (ngc, .vue, .svelte)
• More ergonomic usage for tools like protobuf
• etc

This would also lead to support in preprocessors like TypeScript which could statically compile macros - offering an interesting/novel hybrid macro system.

Any thoughts on the concept?

Yes, I do agree that this idea shares utility with decorators however, due to the static nature of macros (accept tokens, return ecmascript), it expands the concept in various ways, like;

• Opening a path for preprocessors (like TypeScript, swc, probably v8) to do AoT compilation leading to applications being faster at runtime
• Incorporating the annotatability of variable assignments as well as class properties
• Runtime (and potentially AoT) transformation of tokens which allows parsing (and LSP support) for jsx, templating languages and even data formats like yaml, xml, protobuf, etc
• Many more use cases

const vueComponent = {
  template: vue!(<div>Hello {{data.world}}</div>),
  data: () => ({ world: 'World' })
}

const contents = yaml!(foo: 'bar')
// Expands to
// const contents = { foo: 'bar' }

LSPs would see the expanded form of macros and the macro implementation would define where errors occur in a transformation.

In the Rust world, this has been used to great effect to create GUI frameworks with vastly different approaches without preprocessors, some resembling React, others Vue:

• Web wasm frameworks [1] [2]
• Native desktop frameworks [1] [2]

For autocomplete, the LSP expands the macro and uses the output

const foo = add!(1, 1)

Would expand into

const foo = 2

So consumers see it as a number rather than a macro. It simply replaces itself with the transformed result.

As for refactoring; when someone implements a macro, they parse "tokens" which they move around into the equivalent valid language syntax.

The editor can unwind that to determine what to update - though there are some macros that are too complex and refactoring tools bail out.

Implementers can also throw during parsing, which bubbles up to the editor, showing errors in the correct place in the macro

These both sound easier for tooling to implement when the language extension is concrete

Macros are more of a preprocessing step rather than dynamic functionality (like decorators) - but there's a chicken and egg problem.

The best supported illustration of macros in tooling is the built-in transformation of jsx in TypeScript. There are many GitHub issues requesting to expand this to offer custom programmatic macros however it's has been deemed out of scope.

Attempts by other toolmakers to implement the functionality that macros offer have resulted in fragmented, brittle implementations (.vue files and .svelte files - custom tooling, editor plugins and poor support for test runners, linters, formatters, etc).

Decorators also feel like an attempt at addressing the same problem albeit at runtime.

After spending some time in the Rust world, I personally feel that there is evidence that the ES world shows a need for this type of functionality

the expanded code would also lack type annotations, meaning TypeScript would only be able to infer what might be a correct auto complete

It's likely that TypeScript would compile macros into TypeScript at compile time (and in the editor, like they do with jsx), where the emitted runtime code would be the static JavaScript equivalent

That said, if they simply strip the types and leave macros to be evaluated at runtime, then perhaps type information would be an issue

I'm also wondering for tools like swc, it wouldn't be able to execute the macros natively in Rust. It would need to delegate to JS adding overhead that negates the tools desire for speed

Calling into Nodejs is not as fast as running Rust native code directly and there is overhead in crossing from Rust to Nodejs, but it wouldn't be a substantial performance hit (can do hundreds of millions of nodejs calls per second).

There are also options like embedding Deno, QuickJS or llrt for macros that don't use niche nodejs functionality

If callable macros are defined using a templating syntax (like in Rust) then an interpreter could be written (or borrowed directly from an existing JS engine) and run entirely in Rust example

For auto-complete, when the macro is expanded, how is the IDE cursor position preserved?

If I get to the point where a proposal is actually on the cards, I will certainly dig deeper into how Rust does this to provide a clearer answer

I think so? Something like

let governor = new CountingGovernor(5);

let tasks = data.map(
  x => Promise.resolve(x)
    .lazyThen(async () => { using _ = await governor.acquire(); return await doWork(x); }
);

this gives you: task are not started until first polled, and no matter how many are being polled no more than 5 can be doing work at a time