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
``` 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
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.
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
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)
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.
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.
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.
The actual management of memory- allocating, reclaiming, etc - are all handled automagically for you.
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.
If A owns B then that is as expected but if A merely references B then it should hold a WeakRef
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!
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.