WebAssembly for Web Developers (Google I/O ’19) 

Yeah, in Surma I had on 1.5, when she got on stage I had to reduce to 1,25, but I didn't pay too attetion.

Sometimes the gap between is more distracting than compressing the information via playback speed. I recommend for smoother comprehension playing at 1.5 or 1.75 for optimal gap filling. Your most likely able to hear the whole more clearly

@@yixe2253 Maybe to you but I used the word to mean something incredible or really good. Nothing negative here.

use react for everything haha

I think your use-case fits the goals of WebAssembly, although I agree that it wasn’t the most _prominent_ use-case. Seeing how people are now building desktop runtime and even entire OS’es with WebAssembly, the portability aspect is definitely getting more traction than before.

@@dassurma OS's? with WebAssembly? WoW!

@@dassurma what os?

Yeaah true. Struggle makes us better. I know how you feel

The context switch from a dynamically typed, garbage collected language to a statically typed, manually managed language is the key issue here. C++ and JS share a lot of syntax, yet switching between them is much harder than JS Ruby or C++ Rust. Both can be learned but being productive in both, at the same time, is another matter.

Personally, I find that JS and C/C++ share too much, so they collide in my muscle memory and I end up with other issues. On the other hand, Rust and TypeScript have both enough difference and enough similarities that I can write in both without... writing both in. Using both Rust and TypeScript alleviates some common issues, but not all. Having only experience in JS causes issues, as does having only experience in Rust or C++. All of them follow their own information, but not all of them have all of that information available right away.

As a web developer, I'd rather stick with js than having to learn another language like c++.

Couldn't agree more, I code in c, c++, python, JavaScript and kotlin.

Only the Optimized JS code CAN be as fast as C. Interpreted is always slower, but it gets optimized to machine code. And C is not faster than machine code.

C like the speed of light? Nah son

@@undeaddutch underrated comment :D

Serial port is one of the last missing APIs on the web for security reasons. WebUSB gets you access to most modern devices. Web Serial is in the works, but not there yet, sadly :(

Just like any other API, you can if it exists in the context, but it leaves much to the JS bindings (imports). WebAssembly is unlikely to ever have direct access to APIs, as there are basically no APIs that get used directly. If some means of doing so were available (eg document.querySelector, TextEncoder/TextDecoder) it would have to be either using only top-level data (such as the self or window contexts) or using something such as a with statement to be semantic (eg import './k.wasm' with {data(a, b) {return a + b;}}) rather than other means. Of course, there are issues with that, but it stands to reason that the web would be capable of adapting.

I mean, that is _literally_ what my entire talk was about. If you don’t want to learn another language, take a look at AssemblyScript, which allows you to use WebAssembly by writing TypeScript. I also mention that both Emscripten and Rust do API tunneling to expose browser APIs in WebAssembly. If you want to see an example, take a look at the Rust ecosystem, where you can manage the entire DOM in Rust: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html

Hi, Thanks for the reply. since we use web assembly to directly execute without the other intermediate process, can't we do this same with JS? I mean since JS goes through parsing and interpretation and another optmization process like Ignition/Turbo things so what if chrome/v8 could give us that optimized byte codes and we send those byte codes to users instead of raw unparsed javascript which eventually goes through the same process on all the machines. Sorry if i asked wrong question, just was my curosity

You don’t really learn WebAssembly, but rather a language that compiles to WebAssembly. Rust has an excellent Getting Started guide for WebAssembly! rustwasm.github.io/docs/wasm-bindgen/

Here is also a link for learning Webassembly with C++ from WebAssembly's website: webassembly.org/docs/c-and-c++/

Someone had to say it.

Sort of, without the typical shitty java performance

Because wasm is strictly typed and js is dynamically typed and jit interpreted rather than compiled

WASM is meant to run other languages in the browser, it would be pointless to compile JS to WASAM, JS already works natively in the browser.

Probably because its mot typed. U can compile typescript into assembly using assemblyscript

What's the point of using wasm anymore if you want to write JavaScript? Why not simply run that JS on the main thread.

It might actually not be _impossible_, but it’s definitely hard. WebAssembly heavily relies on type information (as do most compilers) and you don’t have any types in JavaScript in the _written_ form of JavaScript. So you can’t really compile it. You can try to infer a lot (which TypeScript tries to do!), but it’s much more reliable and easy to have the developer annotate types.

nothing but disassemble the web haha!

You should dig more, it's sandboxed :)

Can't do that much in a sandbox.

Surma Surma Surma Surma.

@@dassurma Reminds me of when I'm escaping backslashes for the RegExp constructor...

Surma etc.

Surma Bhopali

As a developer this is how I see typescript

It works the other way too

I'm a C++ dev and that was my reaction. I spent weeks talking about how bad it was to my work colleagues and then it magically clicked.

I feel like you misunderstood my point. I show data how JavaScript and WebAssembly have the same peak performance. It’s not just a random claim - it’s based on measurements. And you can use the DOM in WebAssembly, you just need to expose it. Take a look at wasm-bindgen: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html

I am not so sure, maybe for a dialect of TS that has benefits when compiled to WASM. You would have to either disallow dynamic code and data so you don't need a JIT/Interpreter inside the TS compiled to WASM module or somehow have this handled by the Browser JS runtime which then also needs to effectively communicate with the compiled into WASM TS module. Maybe this is what it will converge to: WASM having a standardized and fine grained interface to the JS runtime all of its objects/DOM within the Browser to avoid duplication and waste in the WASM module. This challenge here is to not compromise the achieved security with the JS runtime in the Browser and still keep it effectively communicating with potentially buggy / malicious WASM modules.

Wait, are you saying that AssemblyScript _interprets_ TypeScript via WebAssembly? Because that is _not_ the case. AssemblyScript actually compiles a TypeScript-like language to WebAssembly. And data-passing between JS and Wasm already is extremely efficient, so I am not quite sure what you are saying.

@@dassurma exactly) I meant the TypeScript language, not the TypeScript compiler. Certain types available and the overall platform might be different, but the language itself is definitely robust enough.

Only in chrome behind a flag atm, it will eventually be enabled by default in all browsers.

Well Golang is not a system programming language, unlike c, c++ and rust, it is still a high level language. As long as they dont have an implementation for garbage collection and runtimes that high level languages rely on it order to run, they can not include any high level language, but as they said, they are working on it, so Golang and co will come sooner or later anyway. But since google is heavly invested in wasm, Golang will prop come sooner rather than later.

At the moment compiling go to wasm will also ship go's garbage collector and this results in large file sizes. Once wasm makes use of the browser's native garbage collector Go and many other languages will become viable options.

It can.

It can but its still in early stages: github.com/golang/go/wiki/WebAssembly

It can. The entire point of WASM is you can use ANY language.

Why does the time of compilation have anything to do with what WebAssembly can do?

Surma

It's a cool name.

You are right, as I said very clearly in the talk: JavaScript and WebAssembly have the same peak performance. But the entire first half of the talk was about the fact that WebAssembly is not (just) about performance, but also to allow the web to run existing code from other languages. Using JavaScript as a compile target has been tried (asm.js) and didn’t work out too well, amongst other things because parsing and compiling JavaScript is quite expensive. WebAssembly on the other hand was designed to fill that niche.

Shoutout to Nick Fitzgerald from Mozilla’s Rust team.

dwhxyz I think you’re underestimating the ability of web developers. Sure we’ll have to learn some new things but I really don’t understand how that is a barrier? Did the programmers not learn a new language and syntax in the first place?

You are right, if you come from C# or JS, you probably haven’t been confronted with manual memory management. But to assume that these developers are incapable of learning is a pretty drastic generalization. And as I mentioned: Native garbage collection is coming to WebAssembly, making these languages a much more natural fit for WebAssembly. We are just at the beginning of WebAssembly, so currently it’s certainly only for bleeding-edge lovers. But I don’t think it will necessarily stay that way :)

Learn rust. You essentially get free garbage collection via the compiler without having to think about allocation/deallocation of heap memory too much (in most application cases). Also you can use smart pointers in c++ to avoid too much manual allocation/deallocation

Can you back up that claim that “a lot of devs” want to do that? I know there is a vocal group of people that say that, but my impression is that most _web_ developers don’t even know much about WebAssembly yet (hence me giving this talk) and are quite comfortable and happy with JavaScript. Again, to me it’s a symbiotic relationship, not adversarial.

@@dassurma I feel like you underestimate the amount of people whom misuse technology that is made available... As an example, Rusts' wasm-bindgen allows the use of document selectors in rust. Is it actually useful? Perhaps. Is there any reason in it? Perhaps not. So saying that "a lot of devs" want to do that is in poor taste, but if the statistics of webassembly calling DOM APIs in some way comes out (eg in HTTP Archive), you might see /some/ use of it. Not necessarily a lot, but it will be a thing that is used to some degree. There may be people who use it to call things directly. It's not exactly that difficult to say that,

i have yet to meet a person both claiming js to be a hell and knowing js beyond jquery.

You rang?

Just build it! The Rust team already did it! rustwasm.github.io/docs/wasm-bindgen/examples/dom.html

NEVER.

@@dassurma lol.. even though it's boring to see Squoosh since I/O 18 Squoosh is actually a bunch of good JS technology cramped into one app. There is preact, WASM, Service Worker, and many more and it actually deserves to be a role model for how a Web App should be developed these days.

WASM will never replace JavaScript!

no just put it in WASM

It is bytecode....Assembly language varies with Operating system, Processor, etc. Just as Java is compiled to bytecode which is then interpreted by Java Virtual Machine.

Maybe it is Chrome. Maybe it’s not.

@@dassurma or maybe I was saying it was chrome. to make a joke. as they are hiding the name.

It's not. You'll find out in @Surma's and Jake's (@jaffathecakeuk) podcast... I'll leave you cliff-hanging though 😛

Now are you talking about me or the software?

Blazor is pretty bleeding edge and doesn’t actually produce high-quality output yet. The hello world demo is 1.3 mb in wasm dependencies. I decided to focus on WebAssembly fundamentals so that developers can learn and appreciate how much work those kind of frameworks do for you and also to have a _choice_ whether to take matters into their own hands. My talk was already pretty tight, so some things had to be left on the cutting room floor.

@@dassurma Don't get me wrong. Your talk was high quality and Enlightening about WebAssembly. But if a web developer watched your talk, I think that leaving the room, will have a taste of WebAssembly being something strange and deep that has nothing to do with him, which is wrong. WebAssembly, as i am sure you know, is the promise of unified binary format across platforms, including the browser. And that is a really big change, a revolution actually, maybe even bigger than the browser as an application platform. This is my point of view and to be honest, from the few people that do low level stuff, almost nobody do them on the browser.

@@dassurma Great talk! I believe you could have put a conceptual diagram with at least (Blazor) .NET called out as an experiment that Microsoft is researching. And maybe call out the universal programming promise next time. One language/runtime of choice other than JavaScript/V8 for both browser as well as server.

A little bit. Not really. More generic, more secure and completely standardized through the W3C.