trusktr

Two things:

- speed up in some cases - ability to compile the same app to native

Node.js has reliable sandboxes for JS code without the need for Wasm.

Perhaps they are, but they don't want to.

Yes indeed, I got ASWebGLue (WebGL bindings for AssemblyScript) running in Node.js this way, with bindings to the webgl-raub package.

That's definitely interesting, but seems a bit less convenient compared to, for example, writing some TypeScript (compiled to Wasm) and importing that into the JS like we already can with AssemblyScript. AS recently gained the ability to output native ES Modules (containing Wasm and exposing the exported APIs) to import into native ES Modules in plain JS (with type definitions).

I was thinking to fork a browser engine, and bind wasm directly to the DOM without any JS. Anyone interested in teaming up on this?

You can do that with bindings currently. Interface types should only make it easier (for languages with utf-8 strings, as interface types does not support WTF-16 strings like in Java or JavaScript yet).

> I do wonder whether some respondents are incorrectly identifying AssemblyScript as JavaScript?

Perhaps we should include HTML and CSS in the list of languages to choose from next year! :P

I picked JavaScript thinking of AssemblyScript as a tool (not a language) to use JavaScript (with types) as a language compiled to WebAssembly. Maybe the results are not accurate.

I also use Wasm for web (the largest category of use so far) and would not use a JavaScript engine inside Wasm to talk to plain JavaScript in a browser (I don't think any web developer would hehe).

Perhaps the survey should have an option to choose

"JavaScript running in a JavaScript engine inside WebAssembly",

and

"JavaScript compiled to WebAssembly",

to make the results clear as to which "JavaScript" people are using.

Does a JavaScript engine inside WebAssembly even count as a "WebAssembly language"? Or is that C++ and Rust actually?

Does running a browser in WebAssembly make HTML and CSS WebAssembly languages too?

I think that NEAR users just use the SDK, I don't think the users chose JS specifically for it to be in Wasm.

If Interface Types doesn't convert WTF strings to UTF, the flaw won't have to be documented, and the risk that someone forgets to do the right thing and causes a program to break will be eliminated. This seems like a better outcome. I haven't been able to think of downsides of not "sanitizing". Can you list those?

AssemblyScript is a compiler that aims to compile TypeScript code (with slight differences to be able to make sense in Wasm, though trying to minimize those differences) into Wasm. To remain compatible with TypeScript (which is AssemblyScript's goal) and be an optimal language for Wasm that will communicate with TS/JS on the other side, the type `string` would need to be in the same format to avoid any perf hit or data loss while passing thing if that type across the Wasm-JS boundary.

I'm not sure what type of compiler to label that as, but that's the goal.

This is exactly right. UTF-8 is the transmission format that your HTML gets sent in, but it is not the format of strings in JavaScript at runtime.

The problem being discussed is about runtime interoperability between JS (with WTF-16 string format) and WebAssembly.

Yep, it will impact any language with WTF-16. Those languages may incur a performance hit if the vote passes to not support "expressive UTF-16", but more notably, there will be data integrity issues that can lead to security issues.