Uh, I am Lynn Clark, and I make code cartoons, and I also work at Mozilla on things like, what assembly?

Which is we'll be talking about today, and I'm joined by Tell Schneider, right, who leads our Web assembly tooling efforts and who will be fully nuts in on some of their work.

So First Off won his Web assembly.

What assembly is a way of running programming languages other than Java script on the Web, up until now to run code on a Web page, the only language he could use his job.

A script.

But now that there's Web assembly can use other languages like C, you're c++ or Rust, I've noticed that some people have a misconception about Web assembly, though people think that the M V P that landed in browsers and 2017 is the final version of Web assembly.

And I can understand where that misconception comes from because the Web Assembly CD is really committed to backwards compatibility.

So the Web assembly that you write today will continue to work far into the future.

But that doesn't mean that it's feature complete, and that's far from The case, in fact, features air coming toe Web assembly, which will fundamentally alter what you could do with Web assembly.

I think of these future features kind of like the skill tree in a video game.

We fully filled in the top few of these skills, but there's still this whole skill tree underneath unlock so that we can unlock all of these different applications.

So let's look at what's been filled in already, and then we can see what's yet to come.

What assembly story starts with unscripted, which made it possible to bring large sea and c++ code basis to the Web for things like desktop applications and games.

And it did this by trans piling that code to Java script, and at first that Java script would run pretty slow.

But then the Firefox engineer saw how you could add optimization sze to the Js engine to make it run fast.

And that gave us has, um, Js.

Once the other browser vendors saw how fast as Andreas was, they started adding the same optimization to their engines as well.

But that wasn't the end of the story.

It was just the beginning.

Engines could still make this go faster, but they couldn't do it in Java script itself.

Instead, they needed a new language, one that was designed specifically to be compiled Thio, and that was Web assembly.

So what were the skills needed for the some BP, this minimum viable product running C and C plus plus on the Web website least, designers knew that eventually they would want to support languages other than just see in C++.

So they needed a language agnostic compiled target, something like the assembly language that things like desktop applications are compiled to like X 86.

But this assembly language wouldn't be for an actual physical machine.

It would be for a conceptual machine that compiler Target had to run very fast to meet users.

Expectations for smooth interactions and game play.

And it also need to load fast because the Web's users are usedto pretty fast load times.

But these kinds of applications are very large code bases, which means that there's a lot to download when you first visit you Earl.

So we needed our compiler target to be compact so I could go over the Internet quickly.

These languages also needed to manage memory differently from Java script.

They need to be able to directly manage their memory.

And this is because languages like C and C Plus plus have a low level language feature called Pointers and Pointers.

Need to be able Thio, take a memory address and read and write directly from that memory address.

But you can't have a program that you downloaded from the Web.

Just accessing your memory willy nilly in order to provide a way to access memory like a native program is used to.

But to keep the browser secure, we had to create something that could give access to a very specific part of memory and nothing else to do.

This Web assembly uses a linear memory model, and that's implemented using type to race, which are basically just Java script Reyes.

Except the items that are in this ray are bites bites of memory.

So when you're accessing it, you're just using Iranian Dixie's, which you've been treat as though they were memory addresses.

And this means that you can pretend that this array is c++ memory.

So with all of those things in place, you could run desktop applications and games in your browser as if they were running natively on your computer, and that was pretty much the skill set that woman suddenly had.

One was released as an M V P.

It truly was an M v P.

A minimum viable product.

This allowed certain kinds of applications to work, but there was still a whole host of other applications that needed to be unlocked.

So the next achievement to unlock is heavier weight desktop applications.

Can you imagine if something like photo shop was running in your browser?

If you could load it on any of your devices and start working with your files like you can with the meal, we've already started seeing things like this.

For example, the auto CAD team has made their CAD software available through the browser, and Adobe has made light room available through the browser using Web assembly.

But there are still a few features that we need to make sure all of these applications, even the heaviest of heavyweight applications, work well in the browser.

First, a support for multi threading modern day computers have multiple cores that can process things in parallel.

But to make use of these cores, you need support for threatening.

There's another bit of modern hardware that processes things in parallel and that Cindy single instruction multiple data.

With Cindy, it's possible to take a chunk of memory and split it up across different execution units, which are basically like oars.

And then you have the same bit of code.

The same instruction run across all of those execution units, but on different parts of the data.

Another hardware capability is 64 bit addressing.

Memory addresses are just numbers.

So if your memory addresses for only 32 bits long, you only have so many memory of justice enough for four gigabytes.

But most modern hardware support 64 bit addressing, which offers 16 exabytes of memory addresses.

That's a big difference.

Adding 64 bit support will take the artificial limitation on memory address space out of Web assembly.

But these applications don't just need to run fast load times need to be fast, too.

One mix up here is to do something called streaming compilation, where you compile the file as it's being downloaded, and Web assembly was designed to enable.

This unti eared compiler also helps.

So in Firefox we have two compilers.

The 1st 1 The baseline compiler starts when the download starts for the first time.

Then another compile, earthy, optimizing compiler runs on several feds in the background and that one takes longer to compile.

But the code that it generates is extremely fast.

We're also working on a new optimizing compiler called Crane Lift and Cream Lift is designed to actually speed up that initial compile time so can compile code and parallel at a function by function level.

But the code it generates is still fast, and we're currently working to see if we can make it generate code that's even faster and when it's executing than our current optimizing compiler.

But there's an even better trick we can use to skip compiling most of the time.

Unlike with Java script.

If you load the same Web assembly file twice, it compiles to the same machine code so we can store that compiled code in the http cash and then when the pages loading and it goes to check the cash instead of pulling out that source code, it pulls out the compiled code.

So this gets compiling completely, and there are ways to skip even more work.

So stay tuned to see what else happens to improve load times.

Where are we with supporting these heavyweight applications right now for the threating, we have a proposal that's pretty much done.

But a key piece of that Chair Dre buffers had to be turned off and browsers earlier this year.

Last year, they will be turned again.

Turned on again soon, though Cindy is under active development at the moment.

For 1064 we have a good picture of how this is going to work, and that's pretty similar to how X 86 or arm got support for 64 bit addressing and Firefox added streaming compilation last year in Firefox.

We actually compiled the code so fast that's basically done compiling by the time you downloaded the file and other browsers are adding streaming, too, and we also added our baseline compiler last year, and other browsers have been adding the same kind of architecture in Firefox.

Http Cash earnings close and it isn't close and chrome as well, and other improvements are in discussion, even though this is all still in progress.

Heavyweight applications are still coming out today because Web assembly already gives these applications the performance that they need.

But once these features are all in place, there's going to be another achievement unlocked, and more of these heavyweight applications are going to be able to come to the browser.

But Webb assembly isn't just for desktop applications.

It's also meant for regular small modules Web development, the kind of Web development that you're used to if you have a module that does a lot of heavy computation or processing, that's a good use case for Web assembly.

And again, we're already seeing some of this.

So the part sir, in the Source Maps library that's used in Web Pack and Firefox Dev.

Tools that was rewritten and rust compiled toe Web assembling is now 11 times faster, and the Gutenberg Parson WordPress is now an average of 86 times faster, with its rewrite and rust compiled Web assembly.

But for this to go mainstream, we need to have a few more things in place.

First calls between Java script and Web assembly need to be fast.

When Webb Assembly first came out, these calls weren't fast because engines needed to optimize them.

We finished our working on this and Firefox last summer.

And now some of these calls are actually faster than non in lines JavaScript to Java.

Script calls.

That brings us to another thing, though you often need to pass data between your job, script and Web.

Somebody functions.

Need to pass arguments into your Web, suddenly function or return values from it at the moment.

What assembly?

Only state assembly only understands numbers.

So this means that you can't pass more complex things in like objects.

You need to convert your object into numbers, put it in the linear memory and then pull it back out on the Web assembly side and figure out what it is.

That's kind of complicated, and it takes some time to convert the data into linear memory.

So we need this to be easier and faster.

We also need to integrate with yes modules.

Right now, you can't use important export with waza modules, but that means that the Web assembly module isn't really part of the Js module graph.

Just being able to import export doesn't get us all the way there, though we also need ways to distribute and bundle Web assembly modules.

What's the M.

P M.

For Web assembly.

Well, what about MPM?

What's the Web pack or parcel for Web assembly?

Well, what about Web Pack in parcel?

These modules shouldn't look any different to the people that are using them, So why should we create a whole other ecosystem?

And there's one more thing.

Support for older versions of browsers, even those that don't know what Web assembly is like.

11.

So where are we on all of these things?

Well, calls between JavaScript and Web assembly or Fast and fireworks now, and other browsers are also prioritizing this for easy and fast Dave Exchange.

There are a few proposals that will help with this, such as any ref host bindings and weak refs.

I unfortunately, don't have time to go into the detail on that.

But in the meantime, the rust ecosystem has created tools that automate the handling of this stuff for you for S module integration.

The proposal is pretty far along for tool chain support tools in the Rust Ecosystem Comm package.

Your code for M.

P.

M and the bundlers are also actively working on support.

And finally, for backwards compatibility, there's the wah's um two Js tool that takes a wise and pile and spits out the equivalent Java script.

Now that job script isn't gonna be fast, but at least it will work in older versions of browsers that don't know what Web assembly is.

Once we unlock this achievement, we open the path to another two.

Rewriting large parts of Java script framework, some Web assembly and making it possible for statically type compiled to Java script languages to compile the Web assembly instead.

Languages like Scala Js or Reason or else for both of these use cases whether simply needs to support high level language features.

So first, let's look at rewriting parts of Js frameworks.

For a framework like react.

You could paralyze the virtual dom dipping algorithm with a language that has really ergonomic support for parallel ization like rust.

And you can also speed things up by reducing memory usage and allocating memory differently.

But you'd still need to interact with Java script objects, things like components from that code.

You can't just rewrite everything in linear memory because that would be difficult and inefficient, so you need to be able to integrate with the browsers built in garbage collector and that will also help languages that compiled to job script like Scala, Jess, Reason and L'm.

Because these languages they already use JavaScript garbage collector when they compiled two Js.

And that's the same GC that Web assembly will be using when it's running in the browser so they won't need to change their G C.

We also need better support for handling exceptions, and we need good to bugging support Browsers today make it easy to bug your your Java script.

Using dub tools, we need that same kind of support for Web assembly.

And finally, for many functional languages, you need a feature called Tail Calls.

So where are we on all of this for garbage collection?

Our team already has a prototype of this working, but it will still take some time for these proposals to go through standardization.

So we're probably looking at some time next year.

Exception.

Handling is still in the research and development phase for debugging.

There's currently some support and browser deaf tools, but it's still not ideal.

So there's a subgroup of the Web assembly CG that is working on specifying that, and the tail calls proposal is also underway once those are all in place will have unlocked Js frameworks, and many compile two Js languages.

So those are all achievements that we can't unlock inside of the browser.

But what about outside the browser now?

You may be confused when I talk about outside the browser, because isn't the browser what you used to view the Web and isn't that right in the name Web assembly?

But the truth is, technologies like HTML and CSS and Java script are only part of what makes the Web there the visible part there what she used to make user interfaces, so they're the most obvious part.