You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apologies for not contributing to the language design aspects of this proposal but I feel compelled to discuss this point.
It's great to see the enthusiasm developers have about the prospect of improving JavaScript with features from other languages - however I can't help but feel we are missing the forest for the trees.
A lot of effort is going into these discussions while these features exist already in other languages. My feeling is that these discussions are driven by the need for language features that better serve modern/complex web application development and the energy put into these discussions is better served contributing towards WASM so we have the ability to run those languages directly in the browser.
If Rust, Golang and many other languages already support structs, why not focus our efforts on bringing better web integration for these languages to grant developers the ability to choose the language that best fits their design goals?
I suppose my assumption is that language feature discussions on JavaScript come at the expense of the development of wasm, which may not be the case. Perhaps these discussion serve as a proxy indicator of the need/demand there is for wasm.
The text was updated successfully, but these errors were encountered:
If Rust, Golang and many other languages already support structs, why not focus our efforts on bringing better web integration for these languages to grant developers the ability to choose the language that best fits their design goals?
It's a fair thing to question but I don't think we'll get to a satisfactory answer discussing it in this narrow scope so I'd prefer not to wade into discussing language adoption in the abstract.
I suppose my assumption is that language feature discussions on JavaScript come at the expense of the development of wasm, which may not be the case. Perhaps these discussion serve as a proxy indicator of the need/demand there is for wasm.
WasmGC structs and arrays exist, and shared versions are being developed. So this is definitely not at the expense of Wasm development, but is in parallel with.
While some of the design constraints overlap or are literally the same between the Wasm and JS proposals (because JS VMs are also Wasm VMs), many of the design questions in this proposal are about the surface language that deal with developer experience and ergonomics. Wasm, being a lower level target, has a different design space there: it needs to be a good target for Rust, Kotlin, etc, but leave those surface language concerns to the respective higher level source languages.
Interop with WebGPU is also painful in JavaScript, because WGSL has structs and JS doesn't, but JS still needs to populate arrays with them. You're forced to write to array buffers via collections of typed arrays (basically, one per scalar type). Keeping everything aligned properly as you edit the shaders is really horrible.
Apologies for not contributing to the language design aspects of this proposal but I feel compelled to discuss this point.
It's great to see the enthusiasm developers have about the prospect of improving JavaScript with features from other languages - however I can't help but feel we are missing the forest for the trees.
A lot of effort is going into these discussions while these features exist already in other languages. My feeling is that these discussions are driven by the need for language features that better serve modern/complex web application development and the energy put into these discussions is better served contributing towards WASM so we have the ability to run those languages directly in the browser.
If Rust, Golang and many other languages already support structs, why not focus our efforts on bringing better web integration for these languages to grant developers the ability to choose the language that best fits their design goals?
I suppose my assumption is that language feature discussions on JavaScript come at the expense of the development of wasm, which may not be the case. Perhaps these discussion serve as a proxy indicator of the need/demand there is for wasm.
The text was updated successfully, but these errors were encountered: