3 ms·
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. I
by 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 agoOh, I get the value of comptime! I was specifically responding to the rust-like macros comment
- apatheticonion 1y agoThere 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.