proposal-structs

JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.) Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3]. [1] https://github.com/WebAssembly/js-string-builtins/blob/main/... [2] https://github.com/WebAssembly/esm-integration/tree/main/pro... [3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#...

> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language. Prisma is currently being rewritten from Rust to TypeScript: https://www.prisma.io/blog/rust-to-typescript-update-boostin... > Yet projects inevitably get to the stage where a more native representation wins out. I would be careful about extrapolating the performance gains achieved by the Go TypeScript port to non-compiler use cases. A compiler is perhaps the worst use case for a language like JS, because it is both (as Anders Hejlsberg refers to it) an "embarassingly parallel task" (because each source file can be parsed independently), but also requires the results of the parsing step to be aggregated and shared across multiple threads (which requires shared memory multithreading of AST objects). Over h

I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoption is gained though. I don't think the Pipe Operator would be as useful in comparison. I really hate how long the Records & Tuple proposal has been languishing at stage 2. It could've shipped years ago if not for a syntax debate that dragged on and on without being fruitful[1] EDIT: there is a class based version of this, that is stage one, for adding structs[2]. They behave similarly. [0]: https://github.com/tc39/proposal-reco