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.

I think you're mistaken there: AssemblyScript is much newer, it's momentum is only just getting started. AssemblyScript is one of the top three most desired languages for WebAssembly now: https://blog.scottlogic.com/2021/06/21/state-of-wasm.html

In the past year it has gained numerous libraries and bindings, including from Surma from Google. Stay tuned...

It is fair to like Rust, but there is nonetheless an influx of web developers who already know JavaScript and TypeScript moving to AssemblyScript to (finally) experience what Wasm is all about. They don't want to move to other languages. I believe their experience should be highly valued, and as optimal as possible.

This influx is the reason why AssemblyScript is now in the top three WebAssembly languages next to C++ and Rust (https://blog.scottlogic.com/2021/06/21/state-of-wasm.html) and should not be taken lightly.

There is a huge opportunity here to build an optimal foundation for these incoming developers, so that they won't be let down.

The influx has only just begun.

Ideally though, interface types would give languages options: the ability to choose which format their boundary will use. Obviously a JS host and a language like AssemblyScript would align on WTF-16, while a Rust Wasm module running on a Rust-powered Wasm runtime like wasmtime could optimally choose UTF-8.

I'm hoping things will be designed with flexibility in mind for this upcoming most-generic runtime feature.

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.

The poll will happen in this meeting on August 3rd:

https://github.com/WebAssembly/meetings/blob/main/main/2021/...

The upcoming Interface Types spec for WebAssembly was thinking to not support WTF-16 string format, which means any Wasm modules (for example those written in AssemblyScript, a web-inspired language) passing strings from one side to the other (f.e. from Wasm to JS) will experience two things:

- an extra performance cost due to format conversion at the boundary,

- as well as negative implications on security and data integrity,

thus making this a loss for the web if Interface Types will not be fully compatible with the web (JavaScript) by default.

Hope that sums it up in one sentence. :)

How would an end developer write code in one fashion (f.e. `let foo: string = "hello "`) while the compiler makes that work perfectly in every scenario? It would take a high amount of engineering effort compared to having one format that works well in the web to begin with.

How does a compiler ensure that when that string is passed to a Rust Wasm module it goes to it in UTF-8 and then when moments later the same string is passed by the same module to JS it goes over as WTF-16?

How will the compiler know where the string is being passed after compilation (at runtime)?

What new syntax would you propose for TypeScript to make it possible to work with all strings types? How would you keep TS/JS developer ergonomics up to par with what currently exists?

If Interface Types we're to consider web as a first class citizen (because Wasm originated as a web feature) then interop between Wasm modules and JS would considered of utmost importance, without making a web language ,(such as AssemblyScript) have to go through great lengths to engineer that aforementioned complication.

Because if they did, then interop with JS would require performance-losing conversion any time a string needs to be sent from one side to the other, making Web a secondary and irrelevant target compared to native.

That's not what the web needs. The web needs WebAssembly to work flawlessly with JavaScript for maximal potential, so the web will be great and not just a performance landmine that native developers will laugh (as much) at.

Yes, but WebAssembly operates at the boundary with JS, and that is not UTF-8. JS uses WTF-16 at runtime, and if WebAssembly did too then this would make interop between Wasm and JS a first-class feature with maximal performance and without security and data integrity issues.

Note that AssemblyScript rides on TypeScript language syntax. How would

``` let foo: string = "whatever" ```

be able to work in any similar sense as TS/JS if? How can that map to multiple string types? The idea is both AS and TS use the same syntax for strings, and are compatible across boundaries (TS for JS side, AS for Wasm side). Having multiple string types is possible, but this would greatly reduce developer ergonomics.

Solid took what in theory everyone knew would be the best approach to UI tree manipulation and composition, and made the theory come true: reactive fine-grained updates.

The concept isn't new. For example, fine-grained reactivity existed in old frameworks like Knockout.js, in Qt before web frameworks, in alternative frameworks like Aurelia, and even in Mobx with React.

But Solid finally makes the concept have it's theoretical potential fully realized.

Definitely worth checking out!

I also wrote an article that has some additional reasons to love Solid that aren't listed in the above release article:

https://dev.to/trusktr/a-few-reasons-why-i-love-solid-js-403...