19 ms·

I literally just want Rust style macros and proc macros in JavaScript. e.g. using ``` const MyComponent = () => jsx!(<div></div>) ``` rather than a .tsx file.

I literally just want Rust style macros and proc macros in JavaScript. e.g. using ``` const MyComponent = () => jsx!(<div></div>) ``` rather than a .tsx file. That or wasm to be usable so I can just write my web apps in Rust

MrBuddyCasino 1y ago
I really really (really) don’t want Rust style macros and proc macros in JavaScript (or TypeScript), ever.
- apatheticonion 1y ago
  Might be a good idea to advocate for faster progress in wasm so fans of the feature don't try to pollute the language :p
  - MrBuddyCasino 1y ago
    „sandbox, but its to contain the bored developers, not for security“
teaearlgraycold 1y ago
You want manual memory management for your web apps?
- tekacs 1y ago
  Rust memory management is... profoundly not manual? Case in point: I use Rust/WASM in all of my web apps to great effect, and memory is never a consideration. In Rust you pretty much never think about freeing or memory. On top of that, when objects are moved across to be owned by JS, FinalizationRegistry is able to clean up them up pretty much perfectly, so they're GC-ed as normal.
  - teaearlgraycold 1y ago
    Wrangling the borrow checker seems pretty manual at times. And I don’t know why you’d bother with a persnickety compile time GC when JS’s GC isn’t a top issue for front end development.
    - zdragnar 1y ago
      The borrow checker just verifies that you're handling the concept of ownership of memory correctly. The actual management of memory- allocating, reclaiming, etc - are all handled automagically for you.
      - auggierose 1y ago
        There is no need for the concept of ownership of memory in JavaScript. So you are wasting time on a concept that doesn't matter in languages with a real GC. Dealing with ownership = manual memory management.
        zdragnar 1y ago
        This used to not be true- once upon a time, Internet Explorer kept memory separate for DOM nodes and JavaScript objects, so it was very easy to leak memory by keeping reference cycles between the two. Now, with all the desire for WASM to have DOM access I wonder if we'll end up finding ourselves back in that position again.
        zarzavat 1y ago
        You can still have ownership issues and leaks even with a GC, if an object is reachable from a root. e.g. object A is in a cache and it references object B which references objects C D E F G ... which will now never get collected. If A owns B then that is as expected but if A merely references B then it should hold a WeakRef
    - tekacs 1y ago
      I use Rust for all the other reasons, real types being a major one of them: https://hn.algolia.com/?type=comment&query=typescript%20sound%20author%3Atekacs https://hn.algolia.com/?type=comment&query=typescript%20soun... It's kinda exhausting to use TypeScript and run into situations where the type system is more of a suggestion than a rule. Passing around values [1] that have a type annotation but aren't the type they're annotated as is... in many ways worse than not typing them in the first place. [1]: not even deserialized ones - ones that only moved within the language!
alpinisme 1y ago
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.
krukah 1y ago
Maybe the (relative) lack of ecosystem has kept you away, but I really recommend checking out both Dioxus and Leptos. Leptos is incredibly similar to React, but with Rust ergonomics, and it's been a pleasure to learn and use. With an LLM by my side that knows React and Rust pretty well, I've found myself not even needing the React libraries that I thought I would, since I can easily build on the fly the features/components I actually need. I too, eventually gave up on React <> WASM <> Rust but I was able to port all my existing React over into Leptos in a few hours.
- apatheticonion 1y ago
  Yeah they are great, it's more the poor integration and lack of parallelism that makes it not worthwhile. Thunking everything through JavaScript and not being able to take advantage of fearless concurrency severely restrict the use-cases. May as well just use TypeScript and React at that point
JoelMcCracken 1y ago
Every once in a while I get a strong urge to hack on sweet.js to add typescript support
sriku 1y ago
The bun and other authors would probably do well to not repurpose already understood terminology. "Macros" are already understood to be code that produces other code. "Comptime" is a nice alternative, but bun's "macros" aren't macros in that sense. We had sweet-js macros as a library many years ago but it looks like it went nowhere, especially after an incompatible rewrite that (afaik) remains broken for even basic cases. (Caveat: been a while since I looked at it)
kitd 1y ago
No need for macros. https://github.com/lite-jsx/core https://github.com/lite-jsx/core
Wintamute 1y ago
Writing a web app at the moment with C++/Emscripten. What makes wasm unusable in Rust?
- apatheticonion 1y ago
  It's not unusable per-se, however being unable to take advantage of Rust's fearless concurrency and having to glue everything together with JavaScript severely restrict the usefulness. May as well just use TypeScript and React at that point. The dream is to be able to specify only a wasm file in an html script tag, have the tab consume under 1mb of memory and maximise the use of client hardware to produce a flawless user experience across all types of hardware.

MrBuddyCasino 1y ago

I really really (really) don’t want Rust style macros and proc macros in JavaScript (or TypeScript), ever.

apatheticonion 1y ago
Might be a good idea to advocate for faster progress in wasm so fans of the feature don't try to pollute the language :p
- MrBuddyCasino 1y ago
  „sandbox, but its to contain the bored developers, not for security“

teaearlgraycold 1y ago

You want manual memory management for your web apps?

tekacs 1y ago
Rust memory management is... profoundly not manual? Case in point: I use Rust/WASM in all of my web apps to great effect, and memory is never a consideration. In Rust you pretty much never think about freeing or memory. On top of that, when objects are moved across to be owned by JS, FinalizationRegistry is able to clean up them up pretty much perfectly, so they're GC-ed as normal.
- teaearlgraycold 1y ago
  Wrangling the borrow checker seems pretty manual at times. And I don’t know why you’d bother with a persnickety compile time GC when JS’s GC isn’t a top issue for front end development.
  - zdragnar 1y ago
    The borrow checker just verifies that you're handling the concept of ownership of memory correctly. The actual management of memory- allocating, reclaiming, etc - are all handled automagically for you.
    - auggierose 1y ago
      There is no need for the concept of ownership of memory in JavaScript. So you are wasting time on a concept that doesn't matter in languages with a real GC. Dealing with ownership = manual memory management.
      - zdragnar 1y ago
        This used to not be true- once upon a time, Internet Explorer kept memory separate for DOM nodes and JavaScript objects, so it was very easy to leak memory by keeping reference cycles between the two. Now, with all the desire for WASM to have DOM access I wonder if we'll end up finding ourselves back in that position again.
      - zarzavat 1y ago
        You can still have ownership issues and leaks even with a GC, if an object is reachable from a root. e.g. object A is in a cache and it references object B which references objects C D E F G ... which will now never get collected. If A owns B then that is as expected but if A merely references B then it should hold a WeakRef
  - tekacs 1y ago
    I use Rust for all the other reasons, real types being a major one of them: https://hn.algolia.com/?type=comment&query=typescript%20sound%20author%3Atekacs https://hn.algolia.com/?type=comment&query=typescript%20soun... It's kinda exhausting to use TypeScript and run into situations where the type system is more of a suggestion than a rule. Passing around values [1] that have a type annotation but aren't the type they're annotated as is... in many ways worse than not typing them in the first place. [1]: not even deserialized ones - ones that only moved within the language!

alpinisme 1y ago

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.

krukah 1y ago

Maybe the (relative) lack of ecosystem has kept you away, but I really recommend checking out both Dioxus and Leptos. Leptos is incredibly similar to React, but with Rust ergonomics, and it's been a pleasure to learn and use. With an LLM by my side that knows React and Rust pretty well, I've found myself not even needing the React libraries that I thought I would, since I can easily build on the fly the features/components I actually need. I too, eventually gave up on React <> WASM <> Rust but I was able to port all my existing React over into Leptos in a few hours.

apatheticonion 1y ago
Yeah they are great, it's more the poor integration and lack of parallelism that makes it not worthwhile. Thunking everything through JavaScript and not being able to take advantage of fearless concurrency severely restrict the use-cases. May as well just use TypeScript and React at that point

JoelMcCracken 1y ago

Every once in a while I get a strong urge to hack on sweet.js to add typescript support

sriku 1y ago

The bun and other authors would probably do well to not repurpose already understood terminology. "Macros" are already understood to be code that produces other code. "Comptime" is a nice alternative, but bun's "macros" aren't macros in that sense. We had sweet-js macros as a library many years ago but it looks like it went nowhere, especially after an incompatible rewrite that (afaik) remains broken for even basic cases. (Caveat: been a while since I looked at it)

kitd 1y ago

No need for macros. https://github.com/lite-jsx/core https://github.com/lite-jsx/core

Wintamute 1y ago

Writing a web app at the moment with C++/Emscripten. What makes wasm unusable in Rust?

apatheticonion 1y ago
It's not unusable per-se, however being unable to take advantage of Rust's fearless concurrency and having to glue everything together with JavaScript severely restrict the usefulness. May as well just use TypeScript and React at that point. The dream is to be able to specify only a wasm file in an html script tag, have the tab consume under 1mb of memory and maximise the use of client hardware to produce a flawless user experience across all types of hardware.