Comment by trusktr | Hacker News Reader

Comment by trusktr | Hacker News Reader

> 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.

I actually think there's a third way of "using JS to write Wasm", which is to have a JS library which has instructions to emit "hand-written" Wasm bytecode. Example of such a library: https://github.com/iden3/wasmbuilder

That's actually what I was thinking about when picking this option! Think of the following situation:

- You're a JS developer, and want to write a client / library mainly with JS

- You want to use Wasm only for some narrow, performance-critical parts

In this case, you may not want to use something like Rust, because that adds tooling overhead, makes the Wasm bytecode bigger & makes it harder to hand-optimize the Wasm. On the other hand, you might not want to directly write the Wasm in raw WAT, because that has crappy DX.

In this situation, having a JS library is a viable way to make the writing of raw Wasm somewhat more efficient. Example of this pattern being used in the wild: https://github.com/iden3/wasmcurves/blob/master/src/bls12381...

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).

Reply on news.ycombinator.com