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.

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

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)

No need for macros.

https://github.com/lite-jsx/core

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

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?

Oh, I get the value of comptime! I was specifically responding to the rust-like macros comment

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

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.

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

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

„sandbox, but its to contain the bored developers, not for security“

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

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.

You want manual memory management for your web apps?

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.

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.

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.

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.

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.

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

I use Rust for all the other reasons, real types being a major one of them:

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!

You stop noticing the borrow checker after a while and being able to write insanely parallel/performant code is quite rewarding.

Again, not all websites need to be usable on low end hardware/have a 1mb memory footprint - but there are a lot of use cases that would benefit.

Think, browser extensions that load on every tab and consume 150mb+ * number of tabs open and shares the main thread with the website.

ServiceWorkers that sit as background processes in your OS even when the browser is closed, that sort of thing.