 Okay, so how many of you already know what WebAssembly is? Okay, that's pretty good. I really have two things to say in this talk, and that is that one, WebAssembly is awesome, and it's not limited to the web. And the other is that I think that we should explore ways to combine WebAssembly and Python because there's a lot of interesting opportunities there. And in this talk, I'll demonstrate free ways in which we can do that. But let's start at the beginning. So first, get this out of the way. WebAssembly is often abbreviated as WASM, and these are just one and the same thing, and I'll use both terms in this talk. So WebAssembly is an open standard, so it's being developed by people from Mozilla, Google, Microsoft, and even Apple. So all the big names are on board. And it's a standard for representing executable code at a very low level. So the code that it represents is going to execute at more or less native speed. So in the classic way that a programming language works, like Rust or C, you have this programming language which is designed to be readable by humans. A computer cannot execute that code directly. It is first compiled to machine codes and these are the instructions that the computer will execute. If a programming language wants to be able to work on different platforms or even on different operating systems on the same hardware, you need to compile it, you need different compilers basically. What WebAssembly does, it sits like in between of that. It's a very low level representation of code, but it's just high level enough so that it does make very little assumptions about the underlying hardware. That makes that it can be used as a generic machine code, so to say. And this last step of compilation to go from WebAssembly to the actual machine code of the current machine that you're running on is the responsibility of the environment that runs the WebAssembly module. So in most cases, that would be the browser. So you load a WebAssembly module in your browser and the moment that is instantiated, it will do the compiling for you. And all major browsers can do that for about a year now. So you can already use WebAssembly. So carrying on. So WebAssembly is also designed to be very compact. So the resulting binaries are very memory efficient. At the same time, WebAssembly comes with a human-readable representation and there's a one-to-one relationship between the two. So you can always turn the binary representation into the text representation and the other way around. That's a great feature, for instance, when you're debugging. And last but not least, WebAssembly is also safe. It's being designed primarily to run in the browser and you don't want any random Web applications to be able to crash your Web page, let alone your system. So WebAssembly is designed in such a way so that the codes can be validated to great extent at the compile stage. So all in all, there is a lot of awesomeness in WebAssembly. And it comes to no surprise that WebAssembly is being adopted by many open-source communities. For instance, the Lua community. They are very excited because they now can write Web Apps in Lua. The Rust community is very excited because they just want to write everything in Rust, including things for the Web. I've even seen people get excited about being able to write Web Apps in C++. The JavaScript community may be a bit different. I think it depends on who you ask. They either see it as their salvation or as a threat. But in all seriousness, WebAssembly will not replace JavaScript. JavaScript will probably be around for quite some time. But what WebAssembly will do is bring an end to the monopoly that JavaScript has in the browser. So then the Python community, that's us. There doesn't seem to be a lot of enthusiasm from our side. At least I have not seen a lot of things. I've heard a few things, seen a few things. This morning, I actually heard that the site team is trying out some things with it, which is very exciting. But for the rest, there's not a lot happening, it seems. And maybe this makes sense because all these statically compiled languages, it's pretty straightforward for them. Instead of compiling to x86 or whatever, they compile to WebAssembly and then they can render applications on the Web. Of course, there's some things that you have to do. It's not easy, but it's pretty straightforward. Python is an interpreted language, so it's different. We cannot do it in that way. And also, Python is a bit weird because we have this ecosystem with a lot of... We have site and we have number. There's a lot of weird things that we're doing with our language. So it's not very obvious where we can use WebAssembly. Nevertheless, I think there are several ways in which we can make use of WebAssembly. And I will demonstrate or mention three use cases in this talk. So this is probably a good time to introduce PPCI. So PPCI is a project by Wendell Bauman, who sits over there, and he has worked very hard for several years on making a pure Python compiler infrastructure. So that's a set of compilers and tooling written in pure Python. It's completely crazy, but it's very nice because it's very hackable. And last year, Wendell and I met and I was giving a talk at Euroscipy about WebAssembly and we sort of caught up and we've collaborated over the past year to bring support for WebAssembly to this library. And in this talk, I'll be using that library in some of the demos. So the first use case, I don't have any demos for this, but I think it's definitely worth mentioning because it's probably the first thing that comes to mind when you think about Python and WebAssembly. And this is, let's compile a Python interpreter to WebAssembly. For instance, take the source code of Cpython, compile it to WebAssembly, and then you can run it in a web, and therefore you can run your Python code on the web. You can also do this with other Python interpreters. So for instance, MicroPython, you could compile to WebAssembly and run on the web or PyPy. So some examples, the most notable is Pyodeid, which takes Cpython and a couple of scientific libraries like Pandas, Matplotlib and NumPy, and it allows you to do data science in your browser in a sort of notebook-like environment without having to install anything on your local system. PyPyJS is relatively well-known, and tomorrow there's a talk about RustPython, which is an experimental Python interpreter written in Rust, and Rust can be compiled to WebAssembly so you can do the same thing. Super noted though that in all these cases, the Python code is still running in a VM, so this is not some sort of silver bullet to make your code run fast, it just will make it possible to run it in a browser. So the second use case that I would like to mention is to compile a subset of Python to WebAssembly. So compile snippets of Python that use a subset of the syntax of Python, and compile that to a WebAssembly module. And once you have that module, you can run it anywhere. And with anywhere, I mean everywhere where there is a WebAssembly compiler, and that is in this case, or at this moment, that's all the modern browsers and Node.js, and as I will show also Python to some extent. But I think that a few years from now anywhere will mean almost anywhere. So to illustrate this, I wrote a simple function that can calculate prime numbers. So for instance, we ask you to calculate a thousand prime number, and that will give us 7,919. And we can compile this code to WebAssembly. So we have implemented a very simple Python to WebAssembly compiler, which takes quite a few shortcuts. The most important one is that we assume that all variables are floating point numbers. And that makes a lot of things quite a bit easier. So we take our... Is there a socket loose or something? Do you know? Everything seems to be getting worse, right? So anyway, we combine the find prime function together with a small main function, basically to bootstrap it, and then we can compile that to a WebAssembly module. So this WebAssembly module, this M is an internal representation of a WebAssembly module. And we can use that to, for instance, show the bytes that... So basically the binary representation of this WebAssembly module. And similarly, we can show the texture representation of this WebAssembly module. So this is the human readable form. Well, with a bit of effort. And we can also show the interface. And we'll look at this last bit quite a bit more further in this talk, because the interface shows us what the module needs from the environment in which it runs, and also what it provides. But let's actually run this module. So we have implemented a few simple functions. For instance, to run the code in Node. So in this case, Python is calling out to the Node.js executable, running it in a sub-process, giving it the WebAssembly binary, and then Node will execute the WebAssembly module that we just compiled. And we can see that we get the same result. And similarly, we can run it in a notebook. In this case, Python will send the binary WebAssembly module to the browser via some IPython mechanics, and then we execute it in JavaScript. So basically what we did, we had a simple piece of code in the form of a function. We compiled it to a WebAssembly module. Now we can run it, well, at least in Node.js and in the browser. But as I mentioned, we also added support to PPCI to compile WebAssembly to a native machine code. And that means that we can do this. So if we decorate our function with, in this way, this function is compiled to WebAssembly, then compiled to machine code, wrapped into a new function, and now we can execute this code and run it on native machine code. And it's quite a bit faster now. It's not like massively faster yet, because we don't do any optimization. It's just really one-to-one relationship. But you can see where this could go if you follow this along. So to summarize this, if we take the approach of statically compiling a subset of Python to WebAssembly modules, you can use that, for instance, to run snippets of codes for your web applications, because you can run it in the browser. Or you can use it to run codes much faster. If you take this further, you can make solutions to WebAssembly. One very nice feature of this is that the binaries, the WebAssembly modules, are actually cross-platform. And that can mean a lot, for instance, with packaging. I should note, though, that the part into WebAssembly compiler is really a proof of concept. It needs a lot of work to be a proper compiler. And also, you need a WebAssembly to native compiler. And this is all working perfectly in modern browsers, especially in Firefox. They take a really good effort to make it work really well and really fast. But the version that we have in Python is really in an experimental phase yet. So the final use case that they would like to present is to use Python as a platform to bind and run WebAssembly modules. So we're seeing that we can run and execute WebAssembly modules in Python. What if we take this further? What if we would make it possible to load multiple WebAssembly modules, possibly written with different programming languages and binding them together? They have these very explicit interfaces. We can bind them together in Python and then running them as one coherent application. I think this could work very well because historically Python has always been a very good glue language and Python also has a very rich ecosystem. So if we went this way, we could turn Python or the Python ecosystem in a really multi-language ecosystem. And to demonstrate this somewhat I've I've taken the rocket game and this is a game which is written by someone else in Rust. So it's written in Rust and then compiled to WebAssembly. It was used as an example to run Rust on the Web. The game looks like this. You control a little rocket. You can steer, you can shoot and that's basically it. So if you browse the repository where this code is residing there is a little file there called program.wasm It's 60 kilobyte it is the the code compiled to WebAssembly. This is the WebAssembly module basically. So I downloaded this module. I renamed it to rockets.wasm and for the rest I didn't touch it at all and I can load this in memory using ppci. So this is again the internal representation of the WebAssembly module. We again can show the bytes. Of course it's a lot more than this module that we saw. We can also show the textual representation. Human readable is relative here I think. But we can also show the interface and this is where it gets interesting because the interface defines imports and exports and the imports are the things that this module needs from the environment. So we can see that it needs the sign function and the cosine function and it needs some drawing functions because it's really a game engine. It leaves the drawing to the host environment. So it needs the function to draw the bullets, the enemies, the particles, etc. And we can also see that it exports some things and most importantly these are the controls to steer the ship. So turning left, right and shooting. So if we look at this repository a bit closer we can see that there's a lot of rust there but there's a little bit of JavaScript too. And we can see the draw player, the draw enemy function and these are really HTML5 canvas drawing calls. So what's really happening this Web Assembly module is loaded into JavaScript and there's a little bit of JavaScript surrounding it to support it. There's the code to load and compile the module and there's a little bit of code to provide the sine function, cosine function and drawing the drawing calls. And also to turn JavaScript key events and use them to control the ship using the exported functions. So if we want to run this module in Python we need to do the same. We need to give it the sine function, cosine function and some drawing function. So we need something to draw to, we need something to capture key events and we can for instance use Qt for that. And what we then get is something that looks like this. We have a bunch of functions. For instance the draw enemy functions that we do the Qt drawing calls there and in total it's just like 100 or 200 lines of code. We basically wrap all these methods up into a small dictionary which is sent along with the instantiation of this module and then it works. So then we get, if we run this we get this. So what we see here is a game written in Rust, compile to Web assembly and now running in Python. And I intentionally made everything really big because then it's easy to see in the back. So it gets better. So instead of Qt you can also use Promtulkit. So Promtulkit is a UI a way to create user interfaces in the shell. I tried just now and it didn't work because the wifi is stuck so let's try again real quick. So this is really geeky but yeah. Of course, yeah you can shoot this a bit, especially over this re-fiction. Anyway, at some point I thought well this game is not so hard to play, let's make an eye on it. So I wrote a little bit of C code it's really not that much which really it looks at what is the closest enemy tries to ship towards it and then when the angle is small enough shoot. And there's a website called WASM Fiddle and you can write C code there then you hit a button and then out comes a WebAssembly module. So I use that and then I downloaded the WebAssembly module and then we can load it in here. And we can show the interface. So we can see that it needs it needs a toggle shoot, a toggle turn left and toggle turn right. So it makes sense because it needs to have control of the ship and also it exports a draw player and draw it is not going to actually draw these but it needs to coordinate studio calculations. So if we bring this together we get this. So this is a game engine written in Rust, an AI written in C and bound together and working together as one coherent application in Python. Running on Windows, yeah. So I should really say that all of what I've shown is really experimental and nothing is really ready for use from the Python end but nevertheless WebAssembly is already usable and it's definitely coming and it's really awesome and it's definitely not limited to the Web. And I would like to encourage everyone to explore ways in which we can combine WebAssembly and Python because there's definitely more use cases possible and I just showed three examples here. Yeah, that's it. Thank you. So thanks for showing how it's useful for Python because this is actually more eye-opening the web part and sort of like playing a devil's advocate a bit. What do you think about the web part and like because everyone is basically jumping, oh I'm going to just use my language, my favorite language to write web now and how is it different from basically Java times or like ActiveX times or ActiveScript in Flash basically and no this yeah that's a very good question but this is different in several ways in that these WebAssembly modules are more lightweight. Basically yeah and they expose basically they expose what they need from the host environment. For instance I need a sign function, I need a cosine function and maybe the host environment will provide that but it could also be that another WebAssembly module provides it and the host system to get it basically. So it skills up much better I guess than for instance Java applets. Thanks Thanks for the presentation very nice presentation I have two questions first one is which subset of Python did you work on to convert into WebAssembly? Yeah in this case it is a very well basically I stopped when my example was working. It assumes that every variable is a float for instance and that makes things a lot easier so if you want to extend this it would be very good to use type annotations so that you can use multiple different types and still statically compiled but yeah it's a very very strict subset at this point it's really proof of concept. My second question is to which extent can one manipulate the browser DOM with WebAssembly? You need to basically you need to provide an import function so that you get something from JavaScript to manipulate the DOM so there's no way so on itself WebAssembly cannot do a lot. It cannot do file IO because it has to be safe right? So if you want to manipulate the DOM you need to define a function that you import and then in JavaScript you're going to make that function available. That's how it works. Thank you for the talk. I think you might just have answered part of the question one of the things I do is that I write tutorials and so the first use case seems really interesting to have Python interpreter running in WebAssembly. But what would be the limitations and maybe they are different for the tree that you showed? For example, for importing Python modules how would that work to import Python modules third-party modules and would it be able to open sockets like to run a web server inside the browser could you run things like a web server? Good question. If you are in a browser there's no way to create a normal socket. Running a web server would be hard. But you have web sockets so you could expose them. So again, you need to have some kind of import or export mechanism so that in JavaScript basically you write the you provide somehow web socket functionality to the WebAssembly module. And for importing modules these are really the parts where compiling something to WebAssembly is hard. A file IO, stuff like that you need to somehow convert it to use the browser's virtual file system that it exposes stuff like that. And importing you have some mechanism to do that but it's different. Could you like for example directly from PyPI or something like that? Possibly. I have not played with that part myself so I'm not sure. Could we see it? Can WebAssembly written by Python assess the database? Come again? Database assessment. Database access from WebAssembly you mean? Yeah, you could. The only thing is that you then need to for instance then you define imports for accessing and manipulating the database and then in Python you write a little bit of glue code to actually provide that functionality. So directly from WebAssembly, no but you can import any functionality that you need and then you need to write some supporting codes in Python or JavaScript depending where you're running to make it work. So you are saying when you compile your native Python code handling SQL when you compile that WebAssembly there won't be a single WebAssembly file. Sorry, I don't understand your question. Think about you have a native Python code handling SQL whichever it is and you'll compile that into a WebAssembly file that won't just work right you want to wrap everything into a WebAssembly file and run it? No. Unless your compiler is somehow aware of that and automatically generates the imports and the generating code so maybe we can talk afterwards and explain more details. You showed for running the WebAssembly in Python I think you showed passing it to Node shipping it to a browser and getting results back so when you were running the QT application where was the WebAssembly running? It's running inside the Python process. So what is the run time of that? What is the run time for the WebAssembly? Well, it's machine code so it's being compiled to machine code it's loaded into the Python process and then running there. That's for the rockets like the rocket game engine we emulated it because we have some bugs in it and we were unable to fix them before the talk so all the other parts are running truly on machine code and the rockets in this presentation was emulated but it's an implementation detail. So WebAssembly is compiled into machine code by the... It makes use of a trick that was published in a lightning talk a few years ago at SciPy where you can load machine code into Python memory and then execute that it's basically based on that. Please give our speaker another round of applause.