3 ms·

That particular example is odd. What are you gaining by having a macro that needs a compile step vs no macro and just configuring your compile step to use a JSX

That particular example is odd. What are you gaining by having a macro that needs a compile step vs no macro and just configuring your compile step to use a JSX loader for js files?

trgwii 1y ago
The general idea is something like prebaking computation into your deployed JS/TS. This is much more general than JSX-related tools, and a lot cheaper to run. In JS applications I often find myself doing various small bits of work on startup, comptime.ts would move all these bits into build-time.
- alpinisme 1y ago
  Oh, I get the value of comptime! I was specifically responding to the rust-like macros comment
  - apatheticonion 1y ago
    There are quite a lot of valid use cases to being able to transform arbitrary tokens into JavaScript at "compile" time. One that already exists is JSX, which is a macro that is baked into the TypeScript compiler but is restricted/tailored to React-style libraries. We sort of get around this today using template literals and eval, but it's janky. https://github.com/developit/htm https://github.com/developit/htm A generic macro system could open the door to a framework like Svelte, Angular, Vue, etc being able to embed their template compilers (with LSP support) without wrapper compilers and IDE extensions. e.g. imagine syntax like this being possible (not saying it's good) ``` export class MyComponent { template = Vue.template!(<div>{{ this.foo }}</div>) #[Vue.reactive] foo = 'Hello World' constructor() { setTimeout(() => this.foo = 'Updated', 1000) } } svelte.init(MyComponent, document.body) ``` Where the `template!` macro instructs the engine how to translate the tokens into their JavaScript syntax and the `#[reactive]` macro converts the class member into a getter/setter that triggers a re-render calculation. It would need to be adopted by TC39 of course and the expectation would be that, if provided at runtime, a JavaScript engine could handle the preprocessing however transpilers should be able to pre-compute the outputs so they don't need to be evaluated at runtime.

That particular example is odd. What are you gaining by having a macro that needs a compile step vs no macro and just configuring your compile step to use a JSX loader for js files?

trgwii 1y ago

The general idea is something like prebaking computation into your deployed JS/TS. This is much more general than JSX-related tools, and a lot cheaper to run. In JS applications I often find myself doing various small bits of work on startup, comptime.ts would move all these bits into build-time.

alpinisme 1y ago
Oh, I get the value of comptime! I was specifically responding to the rust-like macros comment
- apatheticonion 1y ago
  There are quite a lot of valid use cases to being able to transform arbitrary tokens into JavaScript at "compile" time. One that already exists is JSX, which is a macro that is baked into the TypeScript compiler but is restricted/tailored to React-style libraries. We sort of get around this today using template literals and eval, but it's janky. https://github.com/developit/htm https://github.com/developit/htm A generic macro system could open the door to a framework like Svelte, Angular, Vue, etc being able to embed their template compilers (with LSP support) without wrapper compilers and IDE extensions. e.g. imagine syntax like this being possible (not saying it's good) ``` export class MyComponent { template = Vue.template!(<div>{{ this.foo }}</div>) #[Vue.reactive] foo = 'Hello World' constructor() { setTimeout(() => this.foo = 'Updated', 1000) } } svelte.init(MyComponent, document.body) ``` Where the `template!` macro instructs the engine how to translate the tokens into their JavaScript syntax and the `#[reactive]` macro converts the class member into a getter/setter that triggers a re-render calculation. It would need to be adopted by TC39 of course and the expectation would be that, if provided at runtime, a JavaScript engine could handle the preprocessing however transpilers should be able to pre-compute the outputs so they don't need to be evaluated at runtime.