Comment by apatheticonion

Comment by apatheticonion 8 hours ago

3 replies

View on Hacker News

One of the issues I find is that JavaScript itself holds back the ability of tool makers to experiment with practical novel alternatives.

TypeScript's tsx macro is designed with React-like libraries in mind and alternative frameworks need to create custom file types and LSPs just to get off the ground.

I'd love to see the JavaScript spec define a generic macro system to enable experimentation (with IDE support) for alternative frameworks.

For example, jsx/tsx could be expressed with an inline macro

    export App() {
      return jsx!(<div>Hello World</div>)
    }
While something like Vue or Svelte could implement their own inline macros rather than investing in tooling for their custom file types

   export class App {
      #[onChange]    // <- makes the prop a getter/setter
      value = Hello World
      
      constructor() {
        setTimeout(() => {this.value = "updated"}, 1000)
      }

      render() {
        return vue!(<div>{{this.value}}</div>)
      }
   }
If it's part of the spec, the browser could interpret it without a preprocessor and compilers like tsc/swc etc could precalculate the transformations and ship the transformed JavaScript (like we do today with tsx)
b_e_n_t_o_n 7 hours ago

Js has decorators for class fields so you wouldn't even need a macro for that. `@state accessor value = "hello world"` works.

I do like the idea of macros in general though.

Reply View 2 replies
  • apatheticonion 7 hours ago

    I explored JS decorators in the past but decorators are different in that they are a runtime operation that can't be statically compiled and can't be used on non-class properties.

    You probably know this already but macros on the other hand are just dumb expansions/computations of syntax transformed at compile time, like

        let result = add!(1 + 2);
    Would compile into

        let result = 3;
    Including macros into the JavaScript spec is a bit weird because it's an interpreted language so compile-time concepts don't really make sense (which is probably why decorators were proposed).

    But JavaScript is compiled more frequently than it isn't and we apply a crazy amount of transformations to it (typescript, tsx, path manipulation, styled-components, etc). IMO standardized compile-time manipulation with LSP integration would go a long way for language ergonomics.

    That would also mean transformations for things like jsx could be run _in the browser_ allowing people who don't want to use a bundler to run their code without one.

        // Removed by the bundler, can also be used in the browser
    import jsx from "react/jsx" 

    const App = () => jsx!(<div>>Foo</div>)
    Projects like this : https://github.com/developit/htm are an expression/symptom of that need
    Reply View 1 reply