Pushing the limits of the Web with WebAssembly
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Garcia, Jon Lopez
The Web is omnipresent nowadays and meets most of the needs of our applications. For almost 10 years, leading browsers have been working hard to push the boundaries and performance of our connected apps. This is also the main reason why WebAssembly, the new binary standard initially implemented by Safari, Chrome, Firefox and Edge, appeared. It allows the execution, in the browser, of your favourite programming languages at almost native speed. During this session, we browse the current means implemented by browsers to optimise the execution of JavaScript code. We will outline the limitations of current solutions, the benefits provided by the WebAssembly and review its performance. Enjoy the future of the Web, now!
 Hi everyone, welcome to this talk. My name is John. I'm an open source engineer at Hackages and during the next 25 minutes we are going to talk about the web. In my opinion, the web is an amazing platform. And I think that we can all agree on one fact is that the web has evolved a lot since its beginning. We went from sending simple text over the wire to providing a full experience to the end user. And I think one key component within the web that has brought this experience is JavaScript, right? But so JavaScript built in 1985, shipped within the Netscape browser, was aiming to provide some dynamism to the static content of the web. But what we were trying to achieve with JavaScript at that time, it's a much smaller part of what we are doing with it now. So the way that it was executed at that time is quite different from the way it is executed nowadays. So at that time JavaScript was interpreted. And take a closer look at what interpretation is. For example, here we have in the middle our interpreter, JavaScript interpreter. And on the right side we have kind of like the Burmese machine in the CPU. On the left we have a bunch of JavaScript code lines calling add functions, passing numbers. And when the execution hits the first line, the line is sent to the interpreter. The interpreter does his job, evaluates both parameters, their type, what we are trying to achieve, and then outputs some machine code that gets directly executed by the CPU. Next line, same process, again, evaluating both parameters, same what kind of types they are, and then outputting some machine code. And the thing here that this mechanism worked until kind of 2005 when big JavaScript apps started to come onto the scene. And one example is Google Maps, which also started to hit kind of like a performance issue with those JavaScript apps. And why? Because at the end, doing a simple addition in JavaScript is not trivial. You have to check both operands' types and regarding their, regarding the evaluation, you will output some different code. So you cannot really count on the language by itself. You have to wait until runtime. So one of the mechanisms that browsers applied to solve this issue, it's a very well known mechanism, which is called just-in-time compilation. And if we take back the same example, we still have both items there, but you have a third one, a third component within the system, which is the just-in-time compiler. We take, again, the same lines. First line is sent to the interpreter. It does the same, evaluates, interprets, outputs some machine code, and that's it. Second line, same process. Evaluate it, both parameters, and then output some machine code. But this time, the interpreter has monitored the code and the execution. And it has some feedback about the execution. So you can see that, okay, we try to execute twice the same function, passing twice numbers. Why don't, so it marks that function as hot. And then pass it to the just-in-time compiler to compile it and output some, the same machine code that it was previously outputted, store it somewhere in memory and lock that memory region so we cannot override it. Third line comes to execute it. And then there, the interpreter says, okay, I know this ad function. It's not the first time. I just asked the just-in-time compiler to compile it and put it somewhere in memory. So all still are still both parameters, numbers? Yes? Okay, you can then take the one that I just compiled it and directly execute it. And if you see this here, what we have done, what the engine have done is just that he made a shortcut for the execution of a function. And we call that a fast path, okay? And that's when JavaScript gave us his top speed. And just to show you the difference between non-jitted code, so non-jitted JavaScript and jitted JavaScript, I just launched an instance of Chrome disabling the optimization of JavaScript. And you can see for eight rubber denser, it's kind of laggy on the left side, but on the right side, it's kind of going very well. You can even, I think, increase until 15 and it's still okay. But then, well, we had the performance issue with JavaScript, with interpretation, we compiled it and it works pretty well. Why do we want to go further? Well, the thing is that I didn't tell you the whole story. If we go back to example, and this time I'm sending, instead of two numbers, one string and one number, the interpreter will try again to say, okay, I know this function, I just tore it somewhere. But are still those two parameters numbers? Nope. So what he's doing is that he's going to fall back to interpretation and erase the compiled version that he had. Yeah, super animation. So then what's the problem with JavaScript? I mean, not the problem, I don't want to offend you. I'm sorry. I'm sorry. What's the thing? What JavaScript is lacking to be optimized before execution? Well, JavaScript is just lacking predictability. If you take the same version, the same, I mean, two versions of the same code, one written in C and another in JavaScript, you can clearly see that in C, the language provides some hints to the compiler so he can optimize code before runtime. When, if you look at the JavaScript side, there's not much going on there. Even the number of parameters are not really fixed. So you can pass more than two if you want. So if we quickly recap what we learned here, oh, no, maybe what we have to, so we, we can optimize JavaScript in school and you can have really good performance with it's not a problem. But the thing is that JavaScript is not predictable. So the industry browsers have tried to solve this problem. I mean, to solve that, to fix this. And they tried to run some more predictable code within the browser. And one of the initiatives is, for example, portable native clients from Google, which was to, to run some, some C++ modules within the browsers sandboxed. So it's, it's secured. But it didn't really took off. After that, Mozilla came with an idea of just taking a subset of JavaScript, which was more predictable. And they call it, they called, they call it as and a jazz. But it wasn't enough because it was still JavaScript at the end. And in 2015, browsers reunited and tried to come up with something that they could agree on to go a step further to push the limit of the web. And that's where WebAssembly came onto the scene. And what is WebAssembly? If we take quickly just the, the text from the official page, which is quite dense, I'm going to read it. So WebAssembly abbreviated wasm is a binary instruction format for a stack based virtual machine was designed as a portable target for compilation of high level languages like C, C++ Rust, enabling deployment on the web for client and server application. A lot of things. We are going to try to read it again, but step by step. So WebAssembly abbreviated wasm is a binary instruction format. So it just means that it is set of instruction encoded in a binary way. So it's quite efficient to load it. Design as a portable target for compilation. So two things here. Portable, it means that WebAssembly is not just designed for the web, but it's also designed to run outside the web on all the platforms. And target for compilation means that you don't have necessary to write WebAssembly. It's quite low level. You are more kind to, you're more likely to write in higher level languages like C, C++ Rust, Go, C sharp, Java, whatever. And you compile to WebAssembly. So how the process goes? Simply you take a bunch of files, C, C++ here, I just, okay, I mentioned just C and C++. You compile it to intermediate representation. It's almost always LLVM. I will skip the details about LLVM, okay. But normally this part is quite hidden from the developer perspective, okay. And then you compile as a backend compilation to a simple.wasm in this case is the name, but it was a module, okay. And with which tool, for example, one of the main tool to compile to WebAssembly is scripting, which first mission, mainly mission is to provide, to bring other languages on the web. So then how do you consume this simple.wasm? Well, you fetch the resource. I think you all know this. You fetch the resource and then you just call the JavaScript API, WebAssembly APIs that are nowadays available in all the browsers, the major browsers, and then you receive, you receive a.wasm module which you can call function on it here exported from. And those functions were originally written in another language. So what are the goals of WebAssembly? WebAssembly wants to be performant, run at nearly native speed. After that, WebAssembly wants to be portable, okay. So not only running on the web, but also running in other platforms. And secure, secure by default is one of the main concerns of WebAssembly, being more secure than JavaScript. Performance, well, I might disappoint you, but JavaScript is not, I mean, sorry, WebAssembly is not so much faster, some are more faster than super optimized compiled JavaScript. At the end, they quite run nearly at native space, speed, sorry. But the thing is that JavaScript, I mean, WebAssembly will more likely to stay on the fast path when you have an optimized version of it, while JavaScript will kind of deoptimize easily and falls back to interpretation. And to illustrate my point, here you have a multiple, just diagram showing multiple execution of the same code in JavaScript and then the same code in WebAssembly in blue. WebAssembly is faster, okay, but the point here is to show that for multiple execution of the same code in JavaScript, you cannot predict the performance, while in WebAssembly it's quite almost the same. Also, WebAs can be decoded, validated, and compiled in a fast, single pass, equally with either just-in-time or ahead-of-time compilation. If you check how JavaScript is handled within a browser, you first fetch the whole resource, and then you parse it, compile it, and execute it. All that in the main thread. There are some exceptions, okay, not everything happens sometimes in the main thread, but that's kind of the regular way of doing it. But browsers handle WebAssembly in another way. So while fetching the packets, while fetching the resource, the wasn't modules, the browser will directly compile the bytes on the fly, and when it's done, it will execute on the main thread, and the compilation doesn't happen on the main thread, so it does not block users. Just to show you the difference of performance, you have 30 robot dancers here, and you can see that JavaScript is quite laggy. When you switch the execution to WebAssembly, it goes back to normal, and you can even increase the number, and I'm going, I go there until, I think, 120, but you will not see the difference because the screen is too short, yeah. Okay, so portable. At the beginning, the first version of was meant to at least work on the browser. So the way of execute was to provide some GS glue code that when a wasn't module was trying to do something that the browser couldn't handle, at least the JavaScript will handle the code and simulate something, emulate something. For example, calling a file system, you cannot call a file system within the browser. So when folks try to run wasn't outside of the browser, what they tried to do is just to run the existing wasn't module outside the browser. So there were kind of emulating GS glue code that was emulating a system interface, so it's not really the most optimized way to do it. So a need of, as much as wasm is a language for a conceptual virtual machine, it needed a system interface, a standardized system interface for a conceptual operating system. That's when WebAssembly system interface came onto the scene. It's just a specification that runs that WebAssembly modules can call to make some system APIs call. It's just an operating system. Let's say it's kind of like a POSIX way of doing it. So then the diagram becomes like that. You have the non-browser or browser runtime that implement wasm and expose some system interface API that wasn't modules can interact with. I wanted to show you one tweet of Solomon Hikes, which is the founder of Docker. That is saying that if wasm wasm existed in 2008, we wouldn't have needed to create a Docker. That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope wasm is up to the task. Also folks from Clever Cloud, a French company that is I think here, maybe you have met them, are running function as a service in WebAssembly directly on the hyper vat user. So no operating system between the code and the hardware. Okay, WebAssembly wants to be secured by default. Nowadays, when you code, the result set of binary is just 20% your code and 80% dependencies that you haven't written. Then what happened is that the way that we execute programs nowadays is just they execute within the ambient authority. So me as an admin of my machine, I'm going to ask my program to run and then I'm going to provide him my whole set of keys, the permissions that he can run. Maybe he doesn't need it, but it's okay. I just wrote the code so I know it will not do some malicious things. The problem is that it also passed the whole set of keys to its dependencies. Okay. And sometimes you have a malicious dependency. Okay, so that malicious dependency can then use all the rights that you provide to execute some malicious code. WebAssembly wants to execute itself as a capability based systems. So it means that I still have this whole set of keys, but when I'm going to run the whole program, I'm not going to pass all the permissions. I'm just going to pass the permission that I think my program needs to perform his task. Okay. So I'm just passing here kind of one key and then this key is passed to all the other dependencies. But this time the malicious code is quite blocked and cannot really perform the malicious task. Also, one abstraction that WebAssembly wants to provide is called nano processes. So the idea here is to execute competing modules, wasn't modules in the same process. So the result is kind of like that. So you have the whole process, which is like the big box, blue box. And then inside you will have like the first one is your main module, the one that you have written. And it has dependencies to other modules, but they all run within kind of sandboxed way. And they think that they are alone within the memory space, the process. It's just a software fault isolation. So why our wasm wants to be secure? Because first it provides capability based systems. Also it's sandboxed by default. So you can run low level code in a secure way. And also nano processes provide a way to communicate between different modules a lot, lot, lot much faster than inter process communication. And the end result is kind of like that. So you write your first, you write your main module in for example Rust, and then you consume some dependencies that were originally written in other languages like C++, Go, and so on. I mean, there are a lot, there are not only these languages. There are a lot of more, but well. So projects. I just took two examples. There are a lot. Okay, but you can check. As you are all JavaScript developers, I wanted to show you assembly script, which is just, it's a subset of TypeScript that does not compile to JavaScript or transpile to JavaScript, but compiles directly to wasm modules and web assemblies. Okay. And because I'm a.NET guy, I wanted to show you, I'm also the.NET guy. I wanted to show you that you can run now the CLR, so the.NET on the browser through web assembly. And they provide now kind of a framework which is quite similar of like Angular to write front end applications in C-sharp. Go check this link. It's really interesting. There are a lot of things. And that guy, Mbassu, I think he's Italian, and he's doing a C++ front end library to write front end application that compiles to web assembly. And it has also provided kind of like G6 syntax for C++. It's super interesting. The bytecode aliens. So big companies reunited and tried to push web assembly in a secured by default web. And they call themselves bytecode aliens. These are all the four founders of the aliens. And you see pretty big names. And just to tell you, fastly, it's running 10% of the internet. And I will end up my talk with one quote that I think it's kind of resumed what I feel about web assembly. It's that web assembly is the first fast multilanguage retargetable and safe intermediate representation that we have ever agreed upon as a community. So, that's the video of SD. Thank you. Any questions? I have a question about Node.js. Node.js can run native C++. And you can run wasm. What do you think is better to run Node.js wasm or C++? It's a question that a lot of folks are asking. To be honest, I think that for now it's C++ that will continue to be like the major solution to provide native performance within Node modules. But at the end, it will switch to web assembly modules. Because I don't know, in my humble opinion, I think it's kind of like the future of the industry in this perspective. But they both fix some of your issues which is giving you performance and so on. Hi. Web assembly is a fairly young language. Do you have an overview of the tools and debugging tools around it? Because as it's a binary format, I guess it's a little bit harder to debug than, let's say, vanilla JavaScript. Yes. Okay. So, there are already, I think, some browsers that provide debugging tools to work with web assembly modules. You have, I think within Modzilla Firefox, you can already kind of work with it and debug. The thing is that I didn't mention, and you're right, web assembly has two representations. It has the one that browsers use to execute it, which is the binary format because it's low-deficient and so on. But for human readable, it's not the most human readable format. So, they also have a text representation, which is web assembly text, I think, what? Or something? It's called web assembly. And then you can really clearly see that it's low-level, kind of like an assembly code. I have a question about the micro front end. How will the assembly do in this architecture? Assembly. Yeah, web assembly. Web assembly will do in which architecture? In the micro front end. The micro front end architecture. Okay. Web assembly are quite, I mean, it's composed of several modules. So, if your concern is to say, do I have to download the whole module, big, big, big module to execute it? No. You can kind of speed it and in the future, you will be able to lazy load it. So, stop now. Yeah, I cannot do that. Yeah, I think you can already do that now. Because at the end, as you saw, you're just fetching a resource on the Internet and then you can fetch it whenever you want. To be specific, can I run Blazor? Sorry? Can I run Blazor? Yes, I will say yes. There is no really, they're not competing. I mean, if you download it into your browser, you can run it on both sides. But maybe you will struggle a bit to make them work together. But I think it's completely feasible, of course. Okay. Is WebAssembly able to access to the GPU? Okay. So, this talk that I've done, it's normally much, much larger and I'm covered all the topics. One thing that, so your question is, is it possible to call some GPU APIs from WebAssembly? Right now, no. Because the only thing that provides that is standardized is Wazzy, which is kind of like a system interface to call some OS APIs. The thing is that Wazzy wants to extend itself. And so, in the future, you would be able to call some specific, domain specific low-level APIs. And for example, GPUs, okay? Or you will be able to call, I don't know, something related to blockchain or whatever. So, Go check on the Internet. We want to extend themselves and they're open to feedback from the community. Thank you so much. Thank you. I'm as well. So, if you don't know the other context, he might be available just outside for questions. Yes. Yes. So, the exit, looking...
 Hi everyone, welcome to this talk. My name is John. I'm an open source engineer at Hackages  and during the next 25 minutes we are going to talk about the web. In my opinion, the  web is an amazing platform. And I think that we can all agree on one fact is that the web  has evolved a lot since its beginning. We went from sending simple text over the wire  to providing a full experience to the end user. And I think one key component within  the web that has brought this experience is JavaScript, right? But so JavaScript built  in 1985, shipped within the Netscape browser, was aiming to provide some dynamism to the  static content of the web. But what we were trying to achieve with JavaScript at that  time, it's a much smaller part of what we are doing with it now. So the way that it  was executed at that time is quite different from the way it is executed nowadays. So at  that time JavaScript was interpreted. And take a closer look at what interpretation  is. For example, here we have in the middle our interpreter, JavaScript interpreter. And  on the right side we have kind of like the Burmese machine in the CPU. On the left we  have a bunch of JavaScript code lines calling add functions, passing numbers. And when the  execution hits the first line, the line is sent to the interpreter. The interpreter does  his job, evaluates both parameters, their type, what we are trying to achieve, and then  outputs some machine code that gets directly executed by the CPU. Next line, same process,  again, evaluating both parameters, same what kind of types they are, and then outputting  some machine code. And the thing here that this mechanism worked until kind of 2005 when  big JavaScript apps started to come onto the scene. And one example is Google Maps, which  also started to hit kind of like a performance issue with those JavaScript apps. And why?  Because at the end, doing a simple addition in JavaScript is not trivial. You have to  check both operands' types and regarding their, regarding the evaluation, you will output  some different code. So you cannot really count on the language by itself. You have  to wait until runtime. So one of the mechanisms that browsers applied to solve this issue,  it's a very well known mechanism, which is called just-in-time compilation. And if we  take back the same example, we still have both items there, but you have a third one,  a third component within the system, which is the just-in-time compiler. We take, again,  the same lines. First line is sent to the interpreter. It does the same, evaluates,  interprets, outputs some machine code, and that's it. Second line, same process. Evaluate  it, both parameters, and then output some machine code. But this time, the interpreter  has monitored the code and the execution. And it has some feedback about the execution.  So you can see that, okay, we try to execute twice the same function, passing twice numbers.  Why don't, so it marks that function as hot. And then pass it to the just-in-time compiler  to compile it and output some, the same machine code that it was previously outputted, store  it somewhere in memory and lock that memory region so we cannot override it. Third line  comes to execute it. And then there, the interpreter says, okay, I know this ad function. It's  not the first time. I just asked the just-in-time compiler to compile it and put it somewhere  in memory. So all still are still both parameters, numbers? Yes? Okay, you can then take the  one that I just compiled it and directly execute it. And if you see this here, what we have  done, what the engine have done is just that he made a shortcut for the execution of a  function. And we call that a fast path, okay? And that's when JavaScript gave us his top  speed. And just to show you the difference between non-jitted code, so non-jitted JavaScript  and jitted JavaScript, I just launched an instance of Chrome disabling the optimization  of JavaScript. And you can see for eight rubber denser, it's kind of laggy on the left side,  but on the right side, it's kind of going very well. You can even, I think, increase  until 15 and it's still okay. But then, well, we had the performance issue with JavaScript,  with interpretation, we compiled it and it works pretty well. Why do we want to go further?  Well, the thing is that I didn't tell you the whole story. If we go back to example,  and this time I'm sending, instead of two numbers, one string and one number, the interpreter  will try again to say, okay, I know this function, I just tore it somewhere. But are still those  two parameters numbers? Nope. So what he's doing is that he's going to fall back to interpretation  and erase the compiled version that he had. Yeah, super animation. So then what's the  problem with JavaScript? I mean, not the problem, I don't want to offend you. I'm sorry. I'm  sorry. What's the thing? What JavaScript is lacking to be optimized before execution?  Well, JavaScript is just lacking predictability. If you take the same version, the same, I  mean, two versions of the same code, one written in C and another in JavaScript, you can clearly  see that in C, the language provides some hints to the compiler so he can optimize code  before runtime. When, if you look at the JavaScript side, there's not much going on there. Even  the number of parameters are not really fixed. So you can pass more than two if you want.  So if we quickly recap what we learned here, oh, no, maybe what we have to, so we, we can  optimize JavaScript in school and you can have really good performance with it's not  a problem. But the thing is that JavaScript is not predictable. So the industry browsers  have tried to solve this problem. I mean, to solve that, to fix this. And they tried  to run some more predictable code within the browser. And one of the initiatives is, for  example, portable native clients from Google, which was to, to run some, some C++ modules  within the browsers sandboxed. So it's, it's secured. But it didn't really took off. After  that, Mozilla came with an idea of just taking a subset of JavaScript, which was more predictable.  And they call it, they called, they call it as and a jazz. But it wasn't enough because  it was still JavaScript at the end. And in 2015, browsers reunited and tried to come  up with something that they could agree on to go a step further to push the limit of the  web. And that's where WebAssembly came onto the scene. And what is WebAssembly? If we take  quickly just the, the text from the official page, which is quite dense, I'm going to read  it. So WebAssembly abbreviated wasm is a binary instruction format for a stack based virtual  machine was designed as a portable target for compilation of high level languages like  C, C++ Rust, enabling deployment on the web for client and server application. A lot  of things. We are going to try to read it again, but step by step. So WebAssembly abbreviated  wasm is a binary instruction format. So it just means that it is set of instruction  encoded in a binary way. So it's quite efficient to load it. Design as a portable target for  compilation. So two things here. Portable, it means that WebAssembly is not just designed  for the web, but it's also designed to run outside the web on all the platforms. And  target for compilation means that you don't have necessary to write WebAssembly. It's quite  low level. You are more kind to, you're more likely to write in higher level languages  like C, C++ Rust, Go, C sharp, Java, whatever. And you compile to WebAssembly. So how the  process goes? Simply you take a bunch of files, C, C++ here, I just, okay, I mentioned just  C and C++. You compile it to intermediate representation. It's almost always LLVM. I  will skip the details about LLVM, okay. But normally this part is quite hidden from the  developer perspective, okay. And then you compile as a backend compilation to a simple .wasm in this case is the name, but it was a module, okay. And with which tool, for example,  one of the main tool to compile to WebAssembly is scripting, which first mission, mainly  mission is to provide, to bring other languages on the web. So then how do you consume this  simple.wasm? Well, you fetch the resource. I think you all know this. You fetch the resource  and then you just call the JavaScript API, WebAssembly APIs that are nowadays available  in all the browsers, the major browsers, and then you receive, you receive a.wasm module  which you can call function on it here exported from. And those functions were originally  written in another language. So what are the goals of WebAssembly? WebAssembly wants to be  performant, run at nearly native speed. After that, WebAssembly wants to be portable, okay.  So not only running on the web, but also running in other platforms. And secure, secure by default  is one of the main concerns of WebAssembly, being more secure than JavaScript. Performance,  well, I might disappoint you, but JavaScript is not, I mean, sorry, WebAssembly is not so  much faster, some are more faster than super optimized compiled JavaScript. At the end,  they quite run nearly at native space, speed, sorry. But the thing is that JavaScript, I  mean, WebAssembly will more likely to stay on the fast path when you have an optimized  version of it, while JavaScript will kind of deoptimize easily and falls back to interpretation.  And to illustrate my point, here you have a multiple, just diagram showing multiple  execution of the same code in JavaScript and then the same code in WebAssembly in blue.  WebAssembly is faster, okay, but the point here is to show that for multiple execution  of the same code in JavaScript, you cannot predict the performance, while in WebAssembly  it's quite almost the same. Also, WebAs can be decoded, validated, and compiled in a fast,  single pass, equally with either just-in-time or ahead-of-time compilation. If you check  how JavaScript is handled within a browser, you first fetch the whole resource, and then  you parse it, compile it, and execute it. All that in the main thread. There are some  exceptions, okay, not everything happens sometimes in the main thread, but that's kind of the  regular way of doing it. But browsers handle WebAssembly in another way. So while fetching  the packets, while fetching the resource, the wasn't modules, the browser will directly  compile the bytes on the fly, and when it's done, it will execute on the main thread,  and the compilation doesn't happen on the main thread, so it does not block users. Just  to show you the difference of performance, you have 30 robot dancers here, and you can  see that JavaScript is quite laggy. When you switch the execution to WebAssembly, it goes  back to normal, and you can even increase the number, and I'm going, I go there until,  I think, 120, but you will not see the difference because the screen is too short, yeah.  Okay, so portable. At the beginning, the first version of was meant to at least work on the  browser. So the way of execute was to provide some GS glue code that when a wasn't module  was trying to do something that the browser couldn't handle, at least the JavaScript will  handle the code and simulate something, emulate something. For example, calling a file system,  you cannot call a file system within the browser. So when folks try to run wasn't outside of  the browser, what they tried to do is just to run the existing wasn't module outside  the browser. So there were kind of emulating GS glue code that was emulating a system interface,  so it's not really the most optimized way to do it. So a need of, as much as wasm is  a language for a conceptual virtual machine, it needed a system interface, a standardized  system interface for a conceptual operating system. That's when WebAssembly system interface  came onto the scene. It's just a specification that runs that WebAssembly modules can call  to make some system APIs call. It's just an operating system. Let's say it's kind of like  a POSIX way of doing it. So then the diagram becomes like that. You have the non-browser  or browser runtime that implement wasm and expose some system interface API that wasn't  modules can interact with. I wanted to show you one tweet of Solomon Hikes, which is the  founder of Docker. That is saying that if wasm wasm existed in 2008, we wouldn't have  needed to create a Docker. That's how important it is. WebAssembly on the server is the future  of computing. A standardized system interface was the missing link. Let's hope wasm is up  to the task. Also folks from Clever Cloud, a French company that is I think here, maybe  you have met them, are running function as a service in WebAssembly directly on the hyper  vat user. So no operating system between the code and the hardware. Okay, WebAssembly  wants to be secured by default. Nowadays, when you code, the result set of binary is  just 20% your code and 80% dependencies that you haven't written. Then what happened is  that the way that we execute programs nowadays is just they execute within the ambient authority.  So me as an admin of my machine, I'm going to ask my program to run and then I'm going  to provide him my whole set of keys, the permissions that he can run. Maybe he doesn't need it,  but it's okay. I just wrote the code so I know it will not do some malicious things.  The problem is that it also passed the whole set of keys to its dependencies. Okay. And  sometimes you have a malicious dependency. Okay, so that malicious dependency can then  use all the rights that you provide to execute some malicious code. WebAssembly wants to execute  itself as a capability based systems. So it means that I still have this whole set of  keys, but when I'm going to run the whole program, I'm not going to pass all the permissions.  I'm just going to pass the permission that I think my program needs to perform his task.  Okay. So I'm just passing here kind of one key and then this key is passed to all the  other dependencies. But this time the malicious code is quite blocked and cannot really perform  the malicious task. Also, one abstraction that WebAssembly wants to provide is called  nano processes. So the idea here is to execute competing modules, wasn't modules in the same  process. So the result is kind of like that. So you have the whole process, which is like  the big box, blue box. And then inside you will have like the first one is your main  module, the one that you have written. And it has dependencies to other modules, but  they all run within kind of sandboxed way. And they think that they are alone within  the memory space, the process. It's just a software fault isolation. So why our wasm  wants to be secure? Because first it provides capability based systems. Also it's sandboxed  by default. So you can run low level code in a secure way. And also nano processes provide  a way to communicate between different modules a lot, lot, lot much faster than inter process  communication. And the end result is kind of like that. So you write your first, you  write your main module in for example Rust, and then you consume some dependencies that  were originally written in other languages like C++, Go, and so on. I mean, there are  a lot, there are not only these languages. There are a lot of more, but well. So projects.  I just took two examples. There are a lot. Okay, but you can check. As you are all JavaScript  developers, I wanted to show you assembly script, which is just, it's a subset of TypeScript  that does not compile to JavaScript or transpile to JavaScript, but compiles directly to wasm  modules and web assemblies. Okay. And because I'm a.NET guy, I wanted to show you, I'm  also the.NET guy. I wanted to show you that you can run now the CLR, so the.NET on the  browser through web assembly. And they provide now kind of a framework which is quite similar  of like Angular to write front end applications in C-sharp. Go check this link. It's really  interesting. There are a lot of things. And that guy, Mbassu, I think he's Italian, and  he's doing a C++ front end library to write front end application that compiles to web  assembly. And it has also provided kind of like G6 syntax for C++. It's super interesting.  The bytecode aliens. So big companies reunited and tried to push web assembly in a secured  by default web. And they call themselves bytecode aliens. These are all the four founders of  the aliens. And you see pretty big names. And just to tell you, fastly, it's running  10% of the internet. And I will end up my talk with one quote that I think it's kind of  resumed what I feel about web assembly. It's that web assembly is the first fast multilanguage  retargetable and safe intermediate representation that we have ever agreed upon as a community.  So, that's the video of SD. Thank you. Any questions?  I have a question about Node.js. Node.js can run native C++. And you can run wasm. What  do you think is better to run Node.js wasm or C++? It's a question that a lot of folks  are asking. To be honest, I think that for now it's C++ that will continue to be like  the major solution to provide native performance within Node modules. But at the end, it will  switch to web assembly modules. Because I don't know, in my humble opinion, I think it's  kind of like the future of the industry in this perspective. But they both fix some of  your issues which is giving you performance and so on.  Hi. Web assembly is a fairly young language. Do you have an overview of the tools and debugging  tools around it? Because as it's a binary format, I guess it's a little bit harder to  debug than, let's say, vanilla JavaScript. Yes. Okay. So, there are already, I think,  some browsers that provide debugging tools to work with web assembly modules. You have,  I think within Modzilla Firefox, you can already kind of work with it and debug. The thing  is that I didn't mention, and you're right, web assembly has two representations. It has  the one that browsers use to execute it, which is the binary format because it's low-deficient  and so on. But for human readable, it's not the most human readable format. So, they also  have a text representation, which is web assembly text, I think, what? Or something? It's called  web assembly. And then you can really clearly see that it's low-level, kind of like an assembly  code.  I have a question about the micro front end. How will the assembly do in this architecture?  Assembly.  Yeah, web assembly.  Web assembly will do in which architecture?  In the micro front end.  The micro front end architecture. Okay. Web assembly are quite, I mean, it's composed  of several modules. So, if your concern is to say, do I have to download the whole module,  big, big, big module to execute it? No. You can kind of speed it and in the future, you  will be able to lazy load it.  So, stop now.  Yeah, I cannot do that.  Yeah, I think you can already do that now. Because at the end, as you saw, you're just  fetching a resource on the Internet and then you can fetch it whenever you want.  To be specific, can I run Blazor?  Sorry?  Can I run Blazor?  Yes, I will say yes. There is no really, they're not competing. I mean, if you download  it into your browser, you can run it on both sides. But maybe you will struggle a bit to  make them work together. But I think it's completely feasible, of course.  Okay. Is WebAssembly able to access to the GPU?  Okay. So, this talk that I've done, it's normally much, much larger and I'm covered  all the topics. One thing that, so your question is, is it possible to call some GPU APIs from  WebAssembly? Right now, no. Because the only thing that provides that is standardized is  Wazzy, which is kind of like a system interface to call some OS APIs. The thing is that Wazzy  wants to extend itself. And so, in the future, you would be able to call some specific, domain  specific low-level APIs. And for example, GPUs, okay? Or you will be able to call, I don't  know, something related to blockchain or whatever. So, Go check on the Internet. We want to extend  themselves and they're open to feedback from the community.  Thank you so much. Thank you. I'm as well.  So, if you don't know the other context, he might be available just outside for questions.  Yes. Yes.  So, the exit, looking...
pushing_the_limits_of_the_web_0_167.png pushing_the_limits_of_the_web_168_3539.png pushing_the_limits_of_the_web_3540_4667.png pushing_the_limits_of_the_web_4668_6635.png pushing_the_limits_of_the_web_6636_7199.png pushing_the_limits_of_the_web_7200_8123.png pushing_the_limits_of_the_web_8124_12299.png pushing_the_limits_of_the_web_12300_14111.png pushing_the_limits_of_the_web_14112_15263.png pushing_the_limits_of_the_web_15264_16715.png pushing_the_limits_of_the_web_16716_17639.png pushing_the_limits_of_the_web_17640_18299.png pushing_the_limits_of_the_web_18300_19067.png pushing_the_limits_of_the_web_19068_19643.png pushing_the_limits_of_the_web_19644_20411.png pushing_the_limits_of_the_web_20412_20471.png pushing_the_limits_of_the_web_20472_22115.png pushing_the_limits_of_the_web_22116_22643.png pushing_the_limits_of_the_web_22644_23051.png pushing_the_limits_of_the_web_23052_24239.png pushing_the_limits_of_the_web_24240_24779.png pushing_the_limits_of_the_web_24780_27899.png pushing_the_limits_of_the_web_27900_28703.png pushing_the_limits_of_the_web_28704_29327.png pushing_the_limits_of_the_web_29328_29567.png pushing_the_limits_of_the_web_29568_30623.png pushing_the_limits_of_the_web_30624_31331.png pushing_the_limits_of_the_web_31332_31931.png pushing_the_limits_of_the_web_31932_33791.png pushing_the_limits_of_the_web_33792_34031.png pushing_the_limits_of_the_web_34032_35051.png pushing_the_limits_of_the_web_35052_35147.png pushing_the_limits_of_the_web_35148_39659.png pushing_the_limits_of_the_web_39660_39773.png